Good on you. I absolutely hate reading the output from Opus. It's disrespectful to make people read it, and to share AI output without reading and understanding it first.
Both. Neither is a viable mass-market alternative in my opinion. Cross-platform office software is just a difficult problem. I think they could be appropriate for some nonprofit/government work, which I think is where they do well today.
If you saw a homeless person in a library, would you be able to tell them they smell to their face? Do you have that kind of "bravery"? Or is it just here, amongst your "peers."
I like to write code and still do, for like, Screeps. With AI I can have it do the mundane stuff, and use my knowledge/skills to guide it in a better product direction than others do (IMO).
Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic.
I'm not comparing this to "null-restricted types", since that's a draft JEP that hasn't made it even into a preview feature. Go also had multiple proposals for explicit nilability in types, and while they probably have less prospect of ever seeing the light of day compared to Project Valhalla, as things currently stand, Go is in the same position as Java: They are both extremely prone to NEPs out-of-the-box and they both have external tooling that can help you avoid them.
Java null checkers have more comprehensive coverage potential compared to Go, but Go is the more ergonomic one here. You don't need a single extra annotation on your code.
It's a panic in Go, not an exception. In practice that's usually a whole process crash. You can catch panics and kinda use them like exceptions, but it's not conventional.
Oh, net/http recovers from a panic inside a handler and sends error 500. I don't know if that was always the default. Where I worked before, our own Go servers didn't recover, and it did cause outages.
This is kinda bad practice. Go and Rust panics are similar, they aren't exceptions that you can safely recover from. Say there's a panic in the middle of modifying some global state like a database connection. Hence complaints about the net/http recover like https://github.com/golang/go/issues/25245 . But I guess they decided it's worse to let servers crash from trivial mistakes.
reply