I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.

Type inference was on DLang far before that Kotlin even existed. The only difference it's that reuses "auto" keyword.

not claiming kotlin invented anything, just that after kotlin adopts something and it turns out to be useful, java will come along in a few years and implement it (or avoid it, depending on how it goes)

I mean, type inference goes decades before Dlang.

They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.

That said, we've been gnawing on this limb for a while...

Ill be old when null safety will finally arrive

This takes longer than game of thrones books

I still recall when java first came out, its all relative--but sure, a decade can seem like eons in software.

Am I understanding this correctly: a value type really only works when it fits on a 64 bit "cache line", and when larger, it falls back to normal heap allocated objects as before? Seems extremely limiting, no? Great for a boxing optimization, but not much else unless you're deal with very small data types regularly...

That's true for arrays of these value classes. Scalarization would help for larger local values though, since those would avoid pointer indirection for purely local values.

Larger types are supported, there is A notion of tearing. According to JVM spec even long and double could tear, not sure about practical implications though

Surely it can't be that, it destroys basically the entire value proposition of value types, unless you use a preprocessor to write everything as SOA.

And one bit for null! So “smaller data types” means 32bits! Yay! It’s 1995 again!

Reminds me of my teenage years when I'd echo spooky messages to other folks /dev/pttys to freak them out (messages i sent just magically appeared in their open terminals)

Why they didn't lock those down by using different creds per client in the computer lab I still don't know. Maybe it was a VAX limitation (at the time)?

I don't hate it. Covers all the bases: 1.1, 2, 3/quic and solves real problems: get query limitations vs body content & post-without-mutation. Yes there are preexisting workarounds, but they're non-obvious.

I switched to a nxtpaper pro phone which has a hardware switch for bw vs color modes and an e-ink like display (not as good but close enough)

I love it, mostly because it forces me to use phone less..

Tmux is n clients to 1 server.

Screen is 1 server to 1 client.

In screen each client session is a fork of the screen server. In tmux there's one server and many client forks iirc.

this is incorrect. you can have multiple clients using screen -x instead of screen -a

I didn't say you couldn't have multiple clients, I said clients and servers are the same process forked. Or did someone add distinct client/server support to screen finally? I know theres a lot of stuff bolted onto screen over the years but I wasn't aware they dropped forked servers for the tmux model...

Did a bit of digging; the first client gets forked to create the "server". The forked server then detaches and runs in the background. You're right that -x creates an entirely new, separate client process, unrelated to the OG client or the forked server.

Without -x though it works as originally described.

Edit: gnu screen 1.0 was originally released in 1987. The -x flag was released in screen 3.0 in the 90s. TIL

Fun fact, Snow Crash was originally written as a video game script (and it shows.)

I enjoyed snow crash probably up until 2/3rds through, same with cryptonomicon. I truly wish he would stick a god damn landing. I don't know what happens after the halfway marks. It's like a different writer takes over and it jumps the shark. I stopped reading his books after a while when they all seem to go off the rails. Damn shame really.

I'd argue that Anathem and Seveneves had actual conclusions.

Possibly The Baroque Cycle though it's been a while since I'd re-read it.

His political fiction (Interface and The Cobweb) were also fairly traditional, though he had a co-author on those.

I love all his books, no hate.

Anathem had perhaps the biggest deux ex machina in literary history, and seveneves had an entirely separate novella for an ending.

> Seveneves

Seveneves had a conclusion, and then an extra book...

Diamond Age is the most important science fiction book of all time... until you get to 2/3 of the way through and the guy in the ... underwater? hippy? drug dream? It never recovers.

Any sufficiently large (preexisting) codebase has subtlties and "load bearing" bugs that allow it to function.

In my personal experience, the vibe coded solutions are incapable of delivering "safe" changes outside of anything trivial without breaking something. Folks now just seem to think this is OK? The result is software like my password manager and banking apps no longer reliably work. The trade offs (currently) just aren't worth it imho.

Maybe once we get context windows in the 100M range these systems will handle large scale (and distributed in my case) backend systems just fine. They most certainly are not at the moment, at least not to preexisting backend software systems of modest complexity. Not even close.