Some do and it does but it all depends on what workload you're trying to perform. Ergo the question asking about defining a thread and how to handle scalability. Anybody who says they don't care about the hardware they're running on isn't a programmer to me. They're just coding.
I remember interviewing somebody who used threading in Python a lot and they were damn proud of it. They didn't get the job either because they didn't understand what threading was and couldn't even tell me the limitation threading has in Python. If somebody can't understand scalability, threads, cores, etc, and how they are all interconnected then there isn't a programmer before us.
What's in a name? That which we call a rose,
I'm not sure this is something I want to get into, especially if this is your attitude. I have a degree in software engineering, I've written C++ code with pthreads, mutexes and semaphores, I've malloc'd my own memory, I've programmed FPGAs, written some assembly, had an exam on Lisp, wrote a PID controller for a little motor on an ARM dev board.
I agree that a good Python programmer (and a Ruby programmer) should at least know what GIL is and how concurrency != parallelism, but I wouldn't consider it that critical. We have a JavaScript prodigy in our company who has no idea what Lisp is or how mutexes work, but guess what, he is insanely knowledgeable about JavaScript and browsers. People arrive to programming from different directions, having taken wildly different paths.
No true Scotsman?
Feel free to state your opinion on what makes a core. The HT example is a little extreme, but I'm pretty sure that there are (or were) CPUs that shared SIMD units between "cores", while other CPUs use multiple FPUs for every "core" without sharing, cores often share at least some levels of caches and I remember the first Intel quad core CPUs were technically two dual core CPUs (so there must have been some redundant circuitry) and that they were slower than expected because of this architecture.
Then you'll know that difference between a kernel thread being prioritized on a core and what people confuse with user library threading. I do care about this "low-level stuff" because I find web development to be a garbage dump full of clueless coders whose only interest is to indulge in the latest doo dah in their favorite language. I can't and no longer live in that environment as programmers rarely exist.
A competent Python programmer should know what the GIL is but they don't just as they don't know the difference between concurrency and parallelism but they are critical. It's why the web is full of all this trash because it's written by clueless programmers.
It is true that web dev has a proportion of bad programmers since it’s how a lot of people start learning programming.
This is the scary part. Front end is full of people I wouldn't give jobs to and they go down the stack to where it really can be critical to the business. I couldn't deal with these people so had to exit for my sanity. A lot of them are clueless on basic computing paradigms. I fear for the future.
In terms of applications, much of the backend complexity has been moved to the front end. Microsoft Office runs on a browser. The most popular UI/UX design tool is browser-based: Figma. You can then wrap these web applications with Electron and ship a desktop version. It's how many modern user-facing apps are built.
I find it tedious in truth. I prefer to be closer to the hardware as that's what motivates me. Running after the latest fad in the stack is just boring to me which is why I excited that world to return to my roots.
Definetly HT is not the same as “core” there are few differences and limitations, even the new SMT in the Ryzen is far better than Intel’s HTIt can run 8 hardware threads at once, so yes, it can definitely "truly process" 8 things simultaneously. M1 also supports 8 hardware threads at once.
Anyway, this discussion illustrates very well what I mean. What exactly are you counting as cores? The ability to run simultaneous execution contexts (threads)? Independent hardware backends? Independent hardware frontends? Hardware register sets? Execution schedulers? Modular hardware building blocks? Any of these things make sense, this way or another, as cores.
For a consumer, a core, is well, a certain promise of performance. A consumer expects an 8-core CPU to be roughly twice as fast as a 4-core CPU. This is generally true with a symmetric design, not so much with an asymmetric design.
Ah, well, it's all moot in the end. One can make this things arbitrarily complex as well as arbitrarily simple. The only sure thing is that the convenient times when we had a single CPU core and reasoning about these things was easy are long gone
You are ultimately right that they do drive things forward. There is value add in things like Marshmallow that allows for rich specification of parsing of inputs to a REST API but well, meh. I'd much rather do low level programming of an MCU to drive fan speeds in C.
I doubt this is the way Apple will go, it's inelegant and they have so much headroom (physical space and thermals) for increased core counts that I doubt it will be necessary. In the Mac Pro we might see upgradeable RAM and they'll use tiering in their OS memory management to prioritise on-package RAM over external DIMM (or whatever form factor they choose) and dedicated upgradeable GPUs (probably proprietary). I guess we will see.