Java, whether it be spring, micronauts, jee, whatever, is wasting CPU and Memory in the cloud costing you and/or your enterprise money.
golang is probably a good contender for business logic code where Java is widely used, but I feel ecosystem (libs, integrations) is not comparable to Java, so you take some risks while choosing golang.
I am not Go expert, but to me this is Go's big advantage: you can chose you want to have object GC controlled or be on stack and copied everywhere. GC controlled objects add lots of overhead, because malloc is expensive, and require lots of memory per object to track state and synchronize between thread, and that's why JVM tries to adapt something similar: https://openjdk.org/jeps/8277163
Also, any non-toy GC won't be using malloc, e.g. in Java's case allocating objects is barely more expensive than allocating them on the stack: they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it, and clearing the buffer.
yeah, all these logics still have significant overhead, especially memory wise, it is hard to reason when JVM decides to kick that or another optimization or not kick anything at all.
With value objects you have full control and bare-metal-native performance without compromises.
Not even you believe that, right? Especially with regards to Go.. Go is closer to JS than to Rust/C++.
also, golang has arena API now, and it also makes heap allocations super cheap if you manage to integrate it into app life cycle.
Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
I mean you can pass structs by ref or value around, which makes direct impact will they be on stack or heap.
> Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
Thank you, good to know, looks like big pros in favor of rust as lang for my next project.
Generic programming is a perfectly valid style, but are you saying it's essential to implement business logic?
Because, like, the last 3 languages that got adopted as the default business logic language didn't have them (Java pre 1.5, C, and Cobol).
I mean, don't get me wrong. It's quite useful once in a while, especially when working with containers, but I don't think of it as essential.
But I'm fine with it as long as people don't overdo it.
This thread was in the context of go generics, which generally means go 1.18, when user defined generics were added to the language. Go always had support for a minimal number of containers, I've never rolled my own when working in the language.
Go had special compiler support for slices, maps, and channels before then, and they got used as the default containers for everything.
Using those was annoying when you needed to do the same thing to, say, a slice of strings and a slice of ints, but if you aren't using a generic heavy style, it actually comes up surprisingly rarely. And, if I'm being honest, I'd consider most of the uses of generics I've seen the average enterprise dev use to be mistakes.
- no inheritance
- error codes with explicit handling everywhere
Go just assumes if you satisfy the interface, you’re good.