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.
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...
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
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.