5 ms·
Now in 2023 I'd strongly think twice before investing heavily in Java. For the vast majority of use cases where Java is utilized Go ends up being a better choic
by alfalfasprout 4y ago
Now in 2023 I'd strongly think twice before investing heavily in Java. For the vast majority of use cases where Java is utilized Go ends up being a better choice w/ cleaner codebases, static binaries (none of this JDK/JRE deployment mess), and phenomenal performance. Not to mention proper interop with native (C/C++) code without JNI funny business.
- slaymaker1907 4y agoI work at Microsoft and I'd use Java (not even C# and yes at work) a hundred times before I'd consider using Go again. Go dependency management is a bit better these days, but the build system is an absolute mess, logging is dreadful, and IDE support seems pretty primitive. Also, Exceptions are vastly superior for most services compared to returning an error outside of a few edge cases since most of the time I have no idea how to handle errors at the callsite and really just need to handle any errors at a high level (like reverting the transaction and returning an HTTP error code).
- miohtama 4y agoWhy do Go still insists no exceptions?
- fweimer 4y agoGo has exceptions, with the usual stack unwinding. The standard library does not use them (for the most part, panics are sometimes used to simplify error handling code, see encoding/gob). It's like Perl and Rust in this regard. Undocumented exceptions/panics are often considered security vulnerabilities by the Go team. The argument against exceptions is that non-local control flow can introduce obscure bugs, like forgetting to clean up resources on the (invisible) exceptional execution path. On the other hand, without exceptions, it's possible to end up with no error handling at all by accident, and that too is not visible in the source code (but linters can help, of course). Many languages which are anti-exception as a matter of principle still use them to report out-of-memory conditions, out-of-bounds array indices, integer division by zero, or attempts to access absent optional values. Not doing this results in code that is simply too verbose.
- vips7L 4y ago> like forgetting to clean up resources on the (invisible) exceptional execution path Except this is still possible on the non-exceptional execution path. You simply just need to forget the defer call. The only thing that solves this is RAII and destructors.
- jsyolo 4y agoYou explained Go but why not C#?
- ashishb 4y agoI have used both Go and Java extensively. I prefer Go. However, I have to admit that checked exceptions is the best thing about Java compared to Go.
- ok_dad 4y agoI love how these people think I have a choice in languages to use, or that I haven’t tried several others as well and honestly don’t mind the idea of Java. My company wants to make money don’t cutting edge algorithms, not test out Google’s language du an.
- pjmlp 4y agoThe choice is to switch job.
- ok_dad 4y agoI love how these people think I have a choice in languages to use, or that I haven’t tried several others as well and honestly don’t mind the idea of Java. My company wants to make money don’t cutting edge algorithms, not test out Google’s language du jour.
- listenallyall 4y ago> I love how these people think I have a choice in languages to use Probably because you wrote, "At my workplace, we’re thinking about using it" and not "my workplace is demanding we use it" > or that I haven’t tried several others (I'm not the person who replied and suggested Go, but your comment does make it sound like you are in the language-evaluation phase, not the "we're fully committed to Java after reviewing multiple options" phase)
- ok_dad 4y agoMy friend, I specifically asked for good Java resources, but did not ask for other opinions. Those who suggested other languages were just cutting in to the conversation. I don’t care about their reasoning, I just wanted to learn Java.
- listenallyall 4y agoThen you should have ended the comment at the question mark: "Is there a good guide to learning modern Java?" The end. YOU obfuscated your own comment with everything after it.
- whimsicalism 4y agoSimple binaries, terrible abstractions.
- matsemann 4y agoYou talking about JDK/JRE deployment mess means you haven't looked at java for 5+ years, as that's no longer an issue. Hence it's hard to trust your advice when you're so off. And no, the vast majority of use cases for java isn't distributing binaries or interoping with JNI.
- pron 4y agoNo more JRE deployment mess (https://openjdk.org/jeps/282 https://openjdk.org/jeps/282) -- in fact the JRE no longer exists; no more need for JNI (https://openjdk.org/jeps/442 https://openjdk.org/jeps/442). Java in 2023 is not what you may remember.
- pianoben 4y agoHaving done in-depth work both with JNI and with cgo, I don't agree that Go is without "funny business". Indeed, cgo leaves a lot to be desired IMO, especially if you with to distribute a library for other projects to consume. The interplay between native and managed code is also fairly tricky.