←back to thread

Java at 30: Interview with James Gosling

(thenewstack.io)
193 points chhum | 5 comments | 16 May 25 13:05 UTC | HN request time: 2.106s | source
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 #
neonsunset ◴[17 May 25 00:34 UTC] No.44011072[source]▶
IIRC all previous conversations about checked exceptions here ended up with the swift conclusion that they are heavily discouraged throughout Java code.
replies(1): >>44011113 #
1. breadwinner ◴[17 May 25 00:42 UTC] No.44011113[source]▶
> they are heavily discouraged throughout Java code

That's so ignorant. Read the article please.

replies(1): >>44011181 #
2. neonsunset ◴[17 May 25 00:54 UTC] No.44011181[source]▶
Let's revisit past conversations:

- https://news.ycombinator.com/item?id=43226624

- https://news.ycombinator.com/item?id=43584056

- https://news.ycombinator.com/item?id=36736326

And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between error and panic model. I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.

replies(2): >>44011309 #>>44011760 #
3. breadwinner ◴[17 May 25 01:20 UTC] No.44011309[source]▶
> I'm not sure what you found in (checked) exceptions.

I could copy/paste the entire article here... but it would be easier if you could take a gander: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

Summary:

Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library.

More crashy code: If a method starts throwing a new exception, you might not realize you need to update your error handling.

Dead code: If a method stops throwing an exception, old catch blocks may linger, becoming dead code.

replies(1): >>44012858 #
4. bigstrat2003 ◴[17 May 25 03:11 UTC] No.44011760[source]▶
> I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.

Reducing boilerplate is not a valuable goal in and of itself. The question is, does the boilerplate buy you something? I think that with checked exceptions it does. Having an explicit type signature for what errors a function can raise improves correctness a great deal because the compiler can enforce the contracts of those functions.

I agree that the Rust approach is good too, though I don't agree it has any strong advantages over the way Java does things. Both approaches are equally respectable in my view.

5. Kwpolska ◴[17 May 25 08:16 UTC] No.44012858{3}[source]▶
None of those arguments are convincing. In many cases, you can't handle errors more reasonably than just crashing or telling the user something went wrong. Java has RuntimeExceptions, which do not have to be declared in the function signature. Division by zero, or trying to index an array out of bounds, and the dreaded NullPointerException, are some examples of RuntimeExceptions.