alt Hacker News> * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.
While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I think there's something to say about Go's model where the package is just in some Git hosting and a release is just creating a tag. As a package maintainer, this is just pure bliss compared to the Maven thing.
> and really dislike the experience of trying to run a Go service compared to a JVM service.
What are you running into specifically? I have the complete opposite experience. With Go, 1 small binary comes out that I can run anywhere (and put into a distroless container), whereas with Java I have to find a way to somehow run a full JVM (most often with (large parts of) an OS too).
Perhaps you're alluding to the things you can do with JMX, but I have never really seen much benefit in that. I found it trivial to add similar functionalities with internal HTTP endpoints easily. But since I don't have much experience in this particular area, probably I'm missing something.
Yeah, publishing a package is a PITA for the precise reasons of maintaining trust in, and the quality of the packages.
That's why you need documentation to publish to Maven central, that's why your package needs to specify its license, GPG checksum etc.
Yep, it's a lot harder than publishing to Pypi or Cargo, but I'm now firmly of the opinion that it's good that it is. The gates between you and publishing a package are there for deliberate reasons.
> Perhaps you're alluding to the things you can do with JMX
Yep, specifically things like "set the logger org.foo.package.Bla to DEBUG while the app is running", without restarting and without having to add an internal HTTP endpoint to be able to accomplish that. It's just there for free, every JVM logging library and metrics library exposes itself via JMX for that same reason - ease of observability, without restarts, without custom code.
E.g., I can access Kafka client metrics via JMX anytime I like. JConsole will even give me pretty graphs.
If I want them in Prometheus, I run the app with a Java agent that takes those MBean metrics and exports them in Prometheus format on an HTTPS endpoint.
I understand you can accomplish much the same with some internal HTTP endpoints, but that presumes they exist.
If you need them, but that microservice hasn't deliberately exposed them, you need to change the code, and then make a new release, which slows down your ability to diagnose what's going on right now.
In Java, every observability library exposes itself via JMX, all you had to do as a sysop was ensure that the JMX port was open.
Also, the ability to easily observe the metrics of the VM itself via JMX so I can see what's going on with GC in a running app without having to explicitly expose that.
If you suspect a memory leak, or something that should be GC-able isn't, or that there's far too many object allocations occurring that's smashing the first gen portion of the heap and causing excessive GC pauses, the instrumentation to investigate it as your app runs is right there, it's baked into the JVM.
That's why I miss it - the JVM was built to be instrumented and observed by the people running it.
I really wish Golang and everyone else would emulate the Java approach to observable metrics as well as the Java approach to logging and packaging.
There's no shame in stealing the good ideas Java had, but no-one seems to, to my frustration.