I'm one of those rare people who like both Java and Go - but I like them for different reasons, and people use them for different reasons. If memory consumption is a bottleneck for you, you'll choose Go. If your team is fluent in Java and you rely on Dependency Injection and stuff, you'll likely choose Java. They both have advantages and disadvantages that will make you choose one over the other, and choosing a language for a microservice is no exception from that (even though Go's startup times are a good fit for microservices) :) More on reddit.com

Some of the general points are mostly correct, but I am going to disagree with some and give some tips as someone who has done a lot in both langs... (pardon the long post, was bored this morning):

• Golang concurrency is not that much easier. Many developers will have an easier time working with futures, promises (i.e. CompletableFuture), thread pools, and concurrent collections than they will with select+channels. Just make sure they understand blocking/non-blocking selects and channel. Go is not just magically "less buggy", it takes discipline wrt state sharing/movement

• I personally find swagger/openapi specs to not be very good for code generation. Good enough for json model gen I guess, but do the HTTP req/resp yourself. Or if it's not a ridiculously sized or volatile API, just work with it directly.

• Don't get hung up on annotations vs other ways to specify routes, the difference is negligible. Consistency and difficulty are what matter.

• It is pretty company specific that Java is considered to have a clear devops edge because of some closed-source commercial monitoring system. Also, I don't consider dockerizing both to be that straightforward wrt runtime management of a VM and dependencies vs static compilation. When considering devops, ease of upgrade and package management should also be a concern (there are pros/cons for both langs here)

• Normal Go using shops shouldn't be leveraging a ton of code generation to work around lack of generics. It will get ugly fast. Just accept the language limits and work within them, especially for microservices.

• Don't get hung up on Java libraries. That hibernate is even listed to me screams that this comparison is not on modern Java and approaches. Again, microservices, nothing complicated. Just make the scaffolding and let your devs run w/ it.

• The lambda implementation in Java is not "hacky at best" and again, this reeks of a level of misunderstanding that makes me think someone else should put together a comparison doc for your company's sake. Also, whether defining anon functions and their types feels natural in Go compared to Java is subjective at best (I think Go is way wordier and explicit...whether that is good/bad is up to you)

• Dependency management in Go has not improved that much in my opinion, it just became more fragmented.

• Go does not do code analysis much better. That the lang has built in checks for unused variables is nothing compared to something that tells you that you are going to break at runtime w/ a nullable var (e.g. by using the checker framework in Java). These statements in the post, like many others, seem to be based on what comes with the package and not the ecosystem.

• Compiling Java code is not slow. I'm gonna have to see some numbers, especially in a reasonably sized application. Even start time is not really slow, especially for daemons.

Meh, I'll stop there...I think the author could use examples of simple Java microservice code and war stories of bad developer use of Go concurrency to even it out a bit. But I don't disagree with the general post or it's overall conclusion. Also, author is doing a disservice excluding Kotlin.

More on reddit.com

It depends a lot on what you're doing. When we experimented with writing microservices in Rust, we struggled with various cloud libraries not really being in a production state, whereas they're often very mature in Go. I'm not a huge fan of Go in general, but since it shares some of the advantages of rust (e.g. tiny docker images, speed to some extent) but has much better library support and is easier in some sense, it often wins out. If speed, correctness, memory usage (we saw quite major differences here, with rust using a lot less memory), interfacing with rust crates etc are extremely important, rust might win out. For a simple CRUD application that interfaces with cloud services, Go is probably better. More on reddit.com

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: Limiting your involvement with Reddit, or Temporarily refraining from using Reddit Cancelling your subscription of Reddit Premium as a way to voice your protest. I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns. More on reddit.com