←back to thread

Java at 30: Interview with James Gosling

(thenewstack.io)
253 points chhum | 9 comments | 16 May 25 13:05 UTC | HN request time: 0.956s | 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 #
sapiogram ◴[16 May 25 21:22 UTC] No.44009912[source]▶
My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.
replies(3): >>44010013 #>>44010083 #>>44010285 #
1. arccy ◴[16 May 25 22:22 UTC] No.44010285[source]▶
funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
replies(5): >>44010426 #>>44010656 #>>44010801 #>>44011174 #>>44020250 #
2. marginalia_nu ◴[16 May 25 22:42 UTC] No.44010426[source]▶
I think that's a bit unfair. Generally the stacktraces tell you exactly what and where the problem is. Generally shouldn't be more than a dozen lines or so.

The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.

3. hu3 ◴[16 May 25 23:18 UTC] No.44010656[source]▶
as someone who had to deal with Java stack traces the entire week, I feel attacked.

God bless Gemini 2.5 Pro which ate all the traces for breakfast.

4. frontfor ◴[16 May 25 23:45 UTC] No.44010801[source]▶
Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.
replies(1): >>44012899 #
5. jjav ◴[17 May 25 00:52 UTC] No.44011174[source]▶
> stacktraces where you need 3 vertical monitors stacked together

If you wrote code with such deep stacktraces, it's all on you.

There's a performance cost to all that excessive stack depth too, often.

6. lenkite ◴[17 May 25 08:27 UTC] No.44012899[source]▶
Tip of the Day: You can wrap errors using "fmt.Errorf" in Go - this gives you a nice chain of error messages which is a pseudo stack trace. Another tip is to define and leverage sentinel errors when wrapping errors so you can test using "errors.Is" higher up when doing error handling in the call-hierarchy - like when mapping to http errors or exit codes.

Using "fmt.Errorf" is lean and painless compared to defining custom errors.

replies(2): >>44013044 #>>44013120 #
7. dontlaugh ◴[17 May 25 09:06 UTC] No.44013044{3}[source]▶
It’s still not stack traces for every error, which is the default in every other language with stack unwinding.

In practice you have to use a combination of error wrapping and custom stack trace errors for your production logs to be useful on failure. The stdlib errors really should have stack traces.

8. homebrewer ◴[17 May 25 09:24 UTC] No.44013120{3}[source]▶
And be very careful in constructing your error messages so that grepping the error string does not return you 50 matches. It's not the same as getting the error message + file name + line number.

This is the whole story of Go, they pick something established and reimplement a heavily cut down version of it for "reasons", then slowly catch up to competition over the next decade or so.

9. int_19h ◴[18 May 25 10:06 UTC] No.44020250[source]▶
This is unfortunately common across most ecosystems today. Such lengthy stack traces are routine in JS, and fairly common in C++.