As someone who's got a lot of Java experience but almost no Go experience, I worry that I've been coddled with a humongous standard library for pretty much everything, from collections of every sort to handling of time, units, strings, I/O buffers, and pretty much every data structure I might need. Do you find that the Go ecosystem is rich enough that you can find whatever you require?

In my experience, in most cases you realize you’re imminent to reinvent a wheel, you start sifting through the packages available and check GitHub, see what one or another package is up to, then I check whether the functionality that I need is well tested, in many cases it is not, sometimes you get perplexed skimming through the issues, there are few uniformly good packages in many cases, you always see something popping up that’s been smoothed out in a Java pendent long ago. It’s tricky.

With JVM bound projects I’ve rarely felt compelled to actually examine the rather foundational packages. With Go, however, I’m often surprised, even when looking at the more popular packages or framework, kind of a different attitude, you know. Same goes to the Go runtime system behavior. The deeper you look the more you can see, I guess. There’s always a caveat somewhere around the corner.

That said, I do have a few Go systems in production. I love the lower memory footprint though it often comes at a cost of unnecessary CPU thrashing, which for the IO bound services I consider acceptable. I see some companies move to Go, the sentiment I’ve perceived is mixed.

As someone who has been through Java->Go, get ready to write a LOT of for loops. You will need to use your IDE abbreviations a lot. Especially for "if err != nil". No exceptions nor result types. Go is a LOT more verbose than Java when compared at the whole file level thanks to these missing features.

Go has no comfortable streams or standardized functional interfaces and generics is still in the "baby" phase. Though to be fair, Java generics is also merely toddler level, compared to C++/Rust.

To be honest, I like the latest Java releases better than Go. Go had an advantage over Java thanks to in-built virtual concurrency, but that advantage has been lost with Java 21 virtual threads.

Go still retains the advantages of a stream-lined yet full-featured and cohesive standard library, fast compilation and crisp, native executables. (However, for the last bit, GraalVM has been rapidly improving for Java)

Go introduced generics as of recently therefore you won’t find many of the more sophisticated collection types like trees and sorted lists etc. However there is an effort to include the usual suspects in the standard lib.

Yes I had the exact same question. Philosophically I like Go better but I worry in practice that Java has me spoiled

The Go ecosystem has everything one needs. The cryptography stuff is nicer than any Java library (sorry BouncyCastle), first class tls everywhere, very decent http client/server support and tons community routers, third-party collections are easy to come by, ssh in standard library, any package from the internet can be directly pulled as a dependency, packages can be renamed without the need of shadowing, kafka clients, any cloud sdk, everything what one can imagine.

I was a heavy java snd scala user before 2018 and 5 years later I’m not missing anything. For what it’s worth, life got easier when I moved to Go.

> Do you find that the Go ecosystem is rich enough that you can find whatever you require?

For what I require (which is atm concurrent web services, restful and grpc APIs, occasional CLIs, k8s tools), it's on par with java

For collections, I don't think go has the same variety as java built in but there are 3rd party implementations for more niche data structures like rb trees. Bare essentials like arraylists and hashmaps come built in

In general, yeah ecosystem is more than good enough for me. Only big thing that I can think of that's missing is gui stuff like swing in java

I was a Java dev for many years and I vastly prefer Go. A lot of it for me has to do with the inversion of control libraries providing "fake" simplicity, but becoming a nightmare when you have to try and figure out what thing in the background is know causing a bean conflict.

The extremely straight control flow of Go makes it much easier to maintain in the long term IMO.

Part of maintainability is readability and ease of debugging, and I agree that Go shines here. But another part is the ease of refactoring and rewriting. My experience is that Go codebases which aren't fundamentally doing very much nevertheless become ossified through sheer volume. This is especially the case when you have layered packages (MVC, etc) and consequently a lot of mocks. Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth. This is largely because fully explicit control flow needs to be fully explicitly unit tested every single time. Those tests weigh a lot.

> Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth.

I've experienced the same thing in java, and similarly with testing different conditionals/exception cases in java

Usually most of the mock annoyingness I've personally dealt with is from repetitive, unrefactored test coverage

Does go have something similar to spring, or is there a framework baked into the language

You can write service structs which depend on service structs similar to spring, and there are libraries which can generate the code that does the wiring for you.

I've always wired my stuff manually in Go though, which is useful if I want to optionally load different subsystems because of some config, etc.

The dependency management story (and noted by the author) is one where I wish people would just steal Java's approach.

1) Every package is namespaced 2) Namespaces are DNS names that you can prove you own

It eliminates typosquatting, and the drama of "someone created a bunch of helloworld crates just to grab the good package names"

I think Go's approach is similar - if you have a public repo, then whatever the DNS name is gives you a unique module name. For example, both of these modules can exist, and I can import both into a given Go project:

github.com/rs/zerolog

mysite.com/myforks/zerolog

“foo.int” is a valid domain but is not possible to use as a Java namespace. What do you do when your company gets bought or changes names? (com.sun.whatever vs. com.oracle.whatever)

Yeah, not a valid Java package name, but can still be used as a group id for your artifact although it'd feel a tad odd.

Sorry, I realise I've been overloading package to mean "dependency you download" (I'll stick to artifact now) when package has an existing meaning in Java, and I'm muddying the waters a tad there.

There's no requirement for Java package names in an artifact to match the group id. E.g.,

> my-domain.com -> com.my-domain (NOTE: The groupId should reverse the domain name exactly, even if the domain name contains hyphens or other characters that would result in an invalid Java package name. Hyphens are perfectly acceptable in groupIds, and you would not need to change your Java package name to match it)

https://central.sonatype.org/publish/requirements/coordinate...

> com.sun.whatever

Oracle owns sun.com and runs artifacts that use that group id prefix, so yeah, when you get bought or change names, you can just keep the old name up and running. If you can't, or don't want to, I have seen some projects change group id, and there's tooling for artifact publishers to do so in a way that doesn't break end users, it's a bit clunky, but doesn't tend to occur that often. https://maven.apache.org/guides/mini/guide-relocation.html

Having artifact group id tied to DNS names isn't super-duper flexible, but it offers some assurance that the dependency you're introducing is published by the people you think, so attackers can't easily steal crypto wallet info by publishing pandass pndas pandsa to catch people who typoed pandas etc. etc.

I think that requirement applies to the maven central GroupID, which may or may not be related to the Java package name.