The pie that Spotify divides up among the artists is a global one. It's not like you listen to one artist, so they get your 10 bucks every month. You're paying Taylor Swift, even though you never listen to her.

I don't know if this does semantic analysis of the program as well.

Just gotta read the last line too :P

Priority list should basically be:

0. Bicycles 1. Metro 2. Buses 3. EVs

(not counting emergency and service vehicles)

Yes, at more than twice the price for me.

> for the average person's protein intake, yes.

The average person doesn't need that ratio, reaching 60-90g of protein is trivial. That ratio is good for bodybuilding purposes. Now, eating that much tofu, that sucks. Generally, getting 200g of protein sucks, even when you eat protein powder.

    void new_thread(void (*run)(void*), void* context);

I don't know whether this counts as "very few use cases".

The Memory Ownership advice is maybe good, but why are you allocating in the copy routine if the caller is responsible for freeing it, anyway? This dependency on the global allocator creates an unnecessarily inflexible program design. I also don't get how the caller is supposed to know how to free the memory. What if the data structure is more complex, such as a binary tree?

It's preferable to have the caller allocate the memory.

    void insert(BinTree *tree, int key, BinTreeNode *node);

If you need to allocate for your own needs, then allow the user to pass in an allocator pointer (I guessed on function pointer syntax):

    struct allocator { void* (*new)(size_t size, size_t alignment); void (*free)(void* p, size_t size); void* context; }.*

The JVM being a stack-machine is probably the least controversial thing about it. Wasm, CPython and Emacs all also have a stack-based bytecode language. The value, of course, comes from having a generic machine that you can then compile down into whatever machine code you want. Having a register machine doesn't seem very useful, as it's completely unnecessary for the front-end compiler to minimize register usage (the backend compiler will do that for you).

Specifying classpath isn't fun, I agree with that. Launch performance isn't good, and is generally a consequence of its high degree of dynamicism and JIT compiler, though of course there are ways around that (Leyden).

> I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it

I agree, I also see very little value in manually writing JVM bytecode programs. However, compiling into the JVM classfile format? Pretty darn useful.

> Let's say only about 1/3 of the world's adult population is poised to take advantage of paid tools enabled by AI

2/3 of the world's adult population is between 15 and 65 (roughly: 'working age'), so that's 50% of the working world that is capable of using AI with those numbers. India's GDP per capita is 2750USD, and now the price tag is even higher than 5k.

I don't know how to say this well, so I'll just blurt it out: I feel like I'm being quite aggressive, but I don't blame you or expect you to defend your statements or anything, though of course I'll read what you've got to say.

Are you familiar with the new LightweightSynchronizer approach with an indirection via a table, instead of overwriting the markWord? I'd say that this has pushed the ParkingLot approach and Java's (Hotspot's, really) approach closer to each other than before. I think the table approach in Java could be encoded trivially into ParkingLot API, and the opposite maybe. Obviously the latter would be a lot more hamfisted.