Setup isn't perfect, but I rarely game and it has very little overhead.

audio does glitch from time to time though, probably scheduler delays or whatever.

I get saving 8 bytes per row seems attractive, but the tradeoff is not explained.

In an case, a great boost for containers on bare metal or maybe core-pinned VMs.

I have an unreasonable hatred of gradle and its imperative, choose-your-own-language build files, every buildfile being structured differently.

Hateful.

Not even talking about how slow it is, no I don't want the garbage demon running somewhere.

Java had green threads in 1997, removed them in 2000 and brought them back properly now as virtual threads.

I'm kinda glad they've sat out the async mania, with virtual threads/goroutines, the async stuff just feels like lipstick on a pig. Debugging, stacktrackes etc. are just jumbled.

Nothing against the article though, but maybe someone knows a good writeup.

I'm not a vegan or whatever, but get real with the impact of meat production.

Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways.

The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with go in every aspect of devx, and better in IDE support, expressiveness, and dependency mgmt.

Why on earth would you give this monstrosity of a company so much free labour?

I get that volunteering is fun, but donating your time and competence to a hyper capitalist company is short sighted. I hope there was appropriate compensation, and I'm not including "early access".

Not sure how this works for larger data structures, but my first thought was that this should be implemented as some microcode or instruction.

Most computation is not thaat jitter sensitive, perception is not really in the nano to microsecond scale, but maybe a cool gadget for like dtrace or interrupt handers etc.

I use jersey+glassfish to build very small micro-profile applications. It's stable, small and works.

Not a fan of the HK2 dpendency injector though. Maybe that's my general dislike of how convoluted the spec and implementation (of EE di) is.

I hate how sprawling the (other) implementations are, no it is not ok to pull in 90mb dependencies to support things I don't need. These app servers tend to grow into huge uncontrollable messes. Nobody uses standalone containers anymore and forcing people to pull in all or nothing for the embedded version is just asinine engineering.

I'm undecided about my stance for gen AI in code. We can't just look at the first order and immediate effects, but also at the social, architectural, power and responsibility aspects.

For another area, prose, literature, emails, I am firm in my rejection of gen AI. I read to connect with other humans, the price of admission is spending the time.

For code, I am not as certain, nowadays I don't regularly see it as an artwork or human expression, it is a technical artifact where craftsmanship can be visible.

Will gen AI be the equivalent of a compiler and in 20 years everyone depends on their proprietary compiler/IDE company?

Can it even advance beyond patterns/approaches that we have built until then?

I have many more questions and few answers and both embracing and rejecting feels foolish.

But I assume you mean predictable in the sense of reacting simiarly to similar inputs.