←back to thread

Java at 30: Interview with James Gosling

(thenewstack.io)
253 points chhum | 7 comments | 16 May 25 13:05 UTC | HN request time: 0.881s | source | bottom
Show context
nelup20 ◴[16 May 25 21:01 UTC] No.44009800[source]▶
I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with).

It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.

replies(6): >>44009912 #>>44009928 #>>44009952 #>>44010109 #>>44010282 #>>44010468 #
kllrnohj ◴[16 May 25 22:21 UTC] No.44010282[source]▶
Personally I think C# is miles ahead of Java and in meaningful ways (like a drastically better implementation of generics, not to mention value types have existed for eons at this point and an FFI system that doesn't hate you for using it)

But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.

replies(12): >>44010302 #>>44010329 #>>44010450 #>>44010481 #>>44010493 #>>44010636 #>>44010692 #>>44010825 #>>44010902 #>>44011079 #>>44011124 #>>44012556 #
breadwinner ◴[16 May 25 23:25 UTC] No.44010692[source]▶
One area where C# really messed up is exception handling.

See https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

replies(4): >>44010987 #>>44011072 #>>44011368 #>>44011745 #
1. jayd16 ◴[17 May 25 01:33 UTC] No.44011368[source]▶
Java streams and a lot of other APIs are extremely ugly because of checked exceptions. Conversely, LINQ and delegates and a lot of other syntax is far cleaner in C#.

Your linked blog is pretty wild. Only throw RuntimeExceptions to crash? Why not just Exit if that's the proper thing to do?

If you treat all C# exceptions as RuntimeExceptions, then it satisfies the blog anyhow.

replies(3): >>44011399 #>>44011441 #>>44015573 #
2. breadwinner ◴[17 May 25 01:41 UTC] No.44011399[source]▶
> Why not just Exit if that's the proper thing to do?

Because you won't get a stack trace.

3. vips7L ◴[17 May 25 01:50 UTC] No.44011441[source]▶
Checked exceptions could still work across lambdas. Scala is doing research there: https://docs.scala-lang.org/scala3/reference/experimental/ca...
replies(1): >>44020234 #
4. breadwinner ◴[17 May 25 17:00 UTC] No.44015573[source]▶
Side effects are not allowed in functional style programming. Exceptions are side effects, it doesn't matter whether they are checked or unchecked exceptions.

https://jessewarden.com/2021/07/why-functional-programmers-a...

While composing methods in stream style is convenient, methods that can throw exceptions warrant more careful coding, so convenience should not always be the priority.

replies(1): >>44020229 #
5. int_19h ◴[18 May 25 10:02 UTC] No.44020229[source]▶
Exceptions are not side effects since no state mutation occurs.

If you really want to see everything through the FP lens, exceptions are exactly like Result<T, E> with implicit do-notation.

6. int_19h ◴[18 May 25 10:03 UTC] No.44020234[source]▶
One of the original lambda proposals for Java - the one from Neal Gafter - also had checked exceptions.

The problem is that you then need a way to capture exception specifications as generic type parameters to properly propagate contracts, which complicates the type system quite a bit. Which is why Java ultimately went with the much simpler proposal that didn't even try to tackle this.

replies(1): >>44043517 #
7. vips7L ◴[20 May 25 16:44 UTC] No.44043517{3}[source]▶
Yes I'm well aware, but that is uniquely a Java problem. With a sufficiently strong type system, like the one in Scala, you can easily make checked exceptions work across higher order functions.