Go has structural typing, non-compacting GCs, allows you to freely choose value / reference types, can make references to variables, strings are bytes or UTF-8, async is built-in to the runtime, async scheduling is preemptive, and module boundaries are defined by the package you’re in. Applications are typically shipped as native code with a linked-in runtime. Interfaces are extrinsic to objects, from a runtime perspective. You cannot overload functions. Hard to dynamically load code at runtime.
When I write it down like this, they don’t seem all that similar to me. They’re all… garbage collected and imperative? Memory safe (or mostly) by default? That doesn’t seem like a lot of commonalities.
“They are all used for backend programming” isn’t really that interesting because backend is where you can choose whatever language you want. Facebook has a ton of Hack backend, Jane Street has OCaML, etc.
Virtual threads are not preemptive. Maybe you can point me to documentation that says otherwise, but my understanding is that virtual threads are scheduled at blocking IO points or places where the thread interacts with the runtime.
Strings can be represented internally as bytes in Java but this is kind of an optimization which happens behind the scenes under specific scenarios, and it’s not a part of the string API like it is with Go. What you’re saying is technically correct but it’s not relevant.
You can use package-private accessibility in Java but surely you can see the clear difference between the way Java and C# work, and the way that languages like Rust, Go, and Haskell work, where the module is the primary technique for modularization (rather than the class).
I’m really just trying to describe differences here, so I don’t think it’s really useful to fight over the technical details. Go doesn’t walk like Java, doesn’t quack like Java, it doesn’t look like Java when you squint your eyes.
