Just on the monitoring part, Go has nothing even close to VisualVM, Flight Recorder, JRebel, VM agents, JMX.
No mention of AOT compilers, JIT caches, and so forth.
Many people like to write about how Golang is so simple, but the drawback of that simplicity is that many features of other languages are either covered by additional dependencies or by inflating code size. It's just as possible for Go projects to devolve into big balls of mud as for any other language.
When you have lots of junior devs, you are more concerned with this upstart time, and I think in this case for example, Java makes it very easy to write poor code, or use poor packages. Yes a master in Java can take advantage of the extremely mature ecosystem with tools like those you have mentioned, but for those who are not experienced like you, they may get better productivity out of what you see as the less powerfull tool.
Something like JRebel would generally be a big no-no for Kubernetes, where the container image of the operator is expected be immutable (at least in terms of the code running in there). It may or may not be okay for developing an operator, but that's certainly venturing into a bit of an unknown territory.
VM agents and JMX are usually replaced by explicitly adding Open Telemetry support and/or a Prometheus endpoint. It's certainly more boilerplate and manual work, but so many more things are explicit in Go, that's just something you've got to buy into. If you're using Rust or Typescript this could be a lot more automated but that's not the case for Go.
Advanced profiling is probably something you'd have to give up, but I doubt a Spring shop would be deeply into profiling. The low hanging fruit is to just throw away spring and get an immediate 200%-400% performance boost.
But the JVM is still a more mature platform. Throughput is better on the JVM than on Go and some things are very troublesome in Go (basically anything that requires code generation).
My personal "cool tool" that I can run on the JVM but doesn't have a mature equivalent in Go is PIT[1] for mutation testing. But not everybody will be using mutation testing, just like not everybody will be using JRebel or JMX. And it doesn't mean everybody should. If you're a Spring a shop the thing you'll be probably missing most in Go would be things like Dependency Injection, Java-like ORMs, reflection magic and Spring Configuration Server.
As an example, the Go runtime does not honor container resource limits. You would think this would be one of the very first fundamental features supported out of the box by an advertised "cloud native" language.
You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs.
Go 1.19 only had this in its notes for memory changes
"...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program"
Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh...
This is the only mention of AOT
> Java's JIT (Just-In-Time) compiler and Go's AOT (Ahead-Of-Time) compiler are definitely two very different approaches and therefore hard to compare.
Zero content on all the options since Excelsior JET and other commercial alternatives came to be, or the free beer alternatives available nowadays.
JIT caches and plain old JIT aren't the same.
JIT caches are similar in concept to AOT with PGO, with the difference that instead of doing that once for the lifetime of the executable with data from test runs, it gets updated after each production execution.
Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles
> You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs.
I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue
> Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh...
We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19
If someone knows which cankerous Computer Scientist said this, I'd appreciate a reply.
Neither Go 1.19 nor any subsequent version has "solved" this issue.
For example, what do you think the following should print?
values := []int{4, 8, 15, 16, 23, 42}
for value := range values {
fmt.Println(value)
}
I also like the following one:
ch := make(chan int)
ch <- 1
fmt.Println(<-ch)
Golang is a fine language and simpler than most, but sadly "simpler" is not the same as "simple".
The Java standard library has a web server in it, it has JDBC. You could use those directly. That's comparable to the Go standard library. For real apps people don't do this because they want a lot more, like simplified database access or session management.
Look at this: https://pkg.go.dev/database/sql
It strongly resembles JDBC. Doing a database query with that is verbose and error prone. Compare the work needed to do a lookup query and map the results to a data structure with that to (Micronaut syntax, Spring is similar):
@JdbcRepository(dialect = Dialect.POSTGRES)
interface GophersRepository extends CrudRepository<Gopher, String> {}
var someGopher = gophersRepository.findById("goo");
Because there’s no one way solution to this problem, the problem isn’t unique to only Go, but every GC language because you’re starving the program if there isn’t sufficient CPU Quota it will all eventually lead to CPU throttling, this isn’t really the problem of Go or any other GC language but at the OS layer, the inherent nature of containers
Secondly am pretty sure the Linux CFS does not strictly follow the CPU Quota, tho there could be something like a panic or warning, or switching to entirely different memory management just for what ? people who want 10ms ?
Multithreaded collection types.
Configuring scheduling algorithms.
Pluggable services, cryptography algorithms, filesystem.
Sane way to manage dates, granted the original one was a bit clunky, but way better than parsing strings.
Sometimes I wonder if folks that criticise Java, and .NET, actually spend any time learning their standard libraries in practice.