Because the JVM takes another tradeoff against Go and Rust: it has a runtime interpreter+JIT, which causes even more performance overhead than Go's GC let alone Rust which - at runtime - is effectively a zero-cost abstraction over C and jemalloc.
The JVM GCs generally have much lower overhead than Go's does. Go imposes enormous collection costs on apps to try and drive latency so low. This is widely acknowledged in discussions of the various GC tradeoffs.
The GCs alone? Yes. The rest of their respective runtime architectures? Highly doubtful. As GC-dependent as Go may be, it still does end up as native code.
But frankly, comparing Go to Java when things like Rust exist ... seems analogous to comparing the z80 to the AVR when 32-bit ARM cores exist.
Offtopic/meta: for some reason your post was dead. The comment at the end is kind of pointless and flamey, Rust isn't that good, but doesn't seem to justify a post kill. I vouched for you to bring it back.
Not quite - Java is faster than Kotlin [0] but I've never seen a Golang app take more than 10 seconds (and that's something huge like Kubernetes or Docker components)
Go optimizes for fast compilation, as such the language has fewer internal checks for only the absolutely necessary. In my opinion, to be able to continue execution when an error happened earlier could be a blessing or a curse, and it depends on the programmer. I've been writing Go for 2 years now and I don't have a single case where I accidentally ignored an error. I have ignored errors, but usually for operations whose end result I don't care about or doesn't affect what happens next in the program.
There's also a recommended way of dealing with errors. I may not state it correctly but basically you build a pipeline of operations for a data type that represents the arguments (or data) of the operations. For example, to compress an image given a URL:
type Image struct {
src string
bytes []byte
width uint
height uint
err error
}
func NewImage(src string) Image {
return Image{src: src}
}
func (img Image) Get() {
if err != nil {
return
}
...
// Set error value if this operation fails
}
func (img Image) Compress {
if err != nil {
return
}
...
// Set error value if this operation fails
}
func (img Image) Err() error { return img.err }
img := NewImage("https://image.src/random-image.png")
img.Get()
img.Compress()
if img.Err() != nil {
// handle error just once
}
this does work... but it also requires two very significant points.
1: you must do this wrapping yourself, for everything you wish to simplify, as few libs do it.
2: you now have non-standard error handling and your tools will not warn you if you handle it wrong.
the second one, to me, is borderline fatal for this pattern. You can't look at this code and realize it's missing error handling (or doing it incorrectly), and you can't run `errcheck` to tell you that e.g. you're missing `err := img.Get()`.
That’s like asking “are type signatures for the compiler, or the programmer?” The answer is a bit of both: for the programmer to express intent, and for the compiler to check that intent is correct.
If your type system is powerful enough (like in Rust), then you can use it to express relations in your problem domain and have compiler enforce them for you before the code even runs.
I think you missed the "unless" in my question. I am well aware that having chosen to treat types as a first class problem, a coder can leverage that intent. My point is simply that there is a populous, productive world of software development in which typing is a humdrum issue for the coders. C.f. the last 30 years of Javascript and Python
What makes that an interesting question? That’s like saying “how would someone have an idea to tests their code unless they were trained to think about testing?” It feels like a tautology, and not particularly relevant.
(I love both dynamic and static typing. I think dynamic type systems are more useful than basic static type systems, but also really enjoy more expressive static type systems.)
Perhaps the programmer should be focused on the purpose the code serves, rather than the code as code object. Mental cycles devoted to thinking about types are, for most programs, overhead. It's perfectly reasonable to be a strong static-typing believer, though I am not. But it's also perfectly reasonable not to think about types when coding, as millions of useful programs have demonstrated.
FWIW, I've found many people new to programming expect something like types, even though they don't have the vocabulary for it yet. It really just depends on the individual.
Typing doesn't have to be static (or strong) to be there. When I write `a + b`, I intend `a` and `b` to be things such that the `+` operator makes sense for them. Might be two numbers, might be two strings, might be a string and a number if I'm using js/php, the point is that I always have an intention, implicit or explicit.