←back to thread

253 points chhum | 1 comments | | HN request time: 0.21s | source
Show context
nelup20 ◴[] 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 ◴[] 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 #
arccy ◴[] 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 #
frontfor ◴[] 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 #
lenkite ◴[] 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 #
1. dontlaugh ◴[] No.44013044[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.