Those two aren’t natively compiled. They can be, but it’s not the norm, and it’s hard/time consuming.
Java’s type system isn’t as strong as it could be either. It is still lacking proper compile time support for null and there’s been no investment in making error handling better. I’ve written it every day for 10 years and the type system definitely doesn’t help you write correct programs.
I started this thread criticizing Go. I think it’s a terribly verbose language that has ignored all language dev of the last half century. It’s why I continue to write Java.
However, I don’t think that shields Java from its inability to make the language better. We still don’t have checked nulls and at this rate, even though there’s a draft JEP, I am not sure we will get them within this decade. The community still blindly throws unchecked exceptions because checked exceptions have received no investment to make them easy to work with.
The point of this thread is that people do want that. They want a natively compiled language (by default), that has checked nulls, errors represented in the type system, and has a GC.
Well, it's far from trivial to introduce such a change if you don't want to throw away 3 decades of code/assumptions. Of course null safety would be very welcome, I'm with you on this.
As for unchecked exceptions, that may be a bit of an "unreasonable ask". The only language that properly solves the problem are languages with effect types, which are an active research area. Every other language have either FP-like error values, or just unchecked exceptions (and there are terrible "solutions" like errno and whatever go does), or most likely both. E.g. Haskell will also throw exceptions, not everything is encoded as a value.
In my opinion both is the most reasonable approach, when you expect an error case, encode it as the return type (e.g. parsing an Integer is expected to fail). But system failures should not go there, exceptions solve it better (stuff like the million kind of connection/file system issues).
Nah man. They could make checked exceptions less boiler platey. Simple things like Swift’s try! Or try?, and making the try construct an expression would go a long way to increase checked error usage and therefore correctness. We don’t even need to solve the lambda problem. We just need to make it easy to deal with checked exceptions. Right now you have a minimum 5 lines of boiler plate to escape them.
Making it an expression would indeed by nice - I do like that in Kotlin, though it's still not particularly short there (but given that there are not really checked throws there, it's easy to just have a lambda for that).
I believe there was a proposal to incorporate it into the switch expression? That may make it slightly too complex though, with null handling and pattern matching.
Yes there was a proposal by Brian to make it into a switch expression: https://news.ycombinator.com/item?id=40088719, though that draft is already 1.5 years old and I don't expect it to be delivered anytime soon. It would alleviate some pain, but I really think we need something like try! to escape the compiler when some errors aren't possible:
A a;
try {
a = someThrowingFn();
} catch (AException ex) {
throw new IllegalStateException(ex); // not possible
}
becomes
var a = try! someThrowingFn();
or with Brian's proposal:
var a = switch (someThrowingFn()) {
case A anA -> anA;
case throws AException ex -> throw new IllegalStateException(ex);
}
...still a bit verbose and funky
You should check out Kotlin's proposal for error unions, I think it's pretty good and prevents a lot of boiler plate associated with results/exceptions: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441.... They propose a similar construct to try! with !! like they have for nullable types.
