Generally, I see Go replacing a lot of projects that would have previously been written in Java (namely network services/backends). Compiler is a bit of an exception, for sure.

Yes… there’s a lot of overlapping territory, for sure. Just like how Java relaces a lot of projects that would have previously been written in C++ or C.

> like how Java relaces a lot of projects that would have previously been written in C++

hearing of this pains me

Cheaper and safer software pains you?

That's assuming it's cheaper and works, which in my experience is asking a LOT of the run of the mill Java dev.

The amount of CVEs for C++ apps is off the charts compared to java lol

Maybe that's because people use them.

delusional

Finally we agree.

Could you perhaps elucidate with a couple of bullet points? In my view Java / C# and Go are technically the same thing. There might be some cultural differences though, which honestly, people seem to care more about anyway.

On the technical side, Java and C# are OOP languages with nominal typing, compacting GCs (at least by default), objects are reference types, can't have a reference to a variable, strings are UTF-16, async is available via promises / tasks / futures, async scheduling is cooperative, and module boundaries are primarily type boundaries. Applications are typically shipped as platform-independent with a separate runtime. Interfaces are intrinsic to objects, from a runtime perspective. You can overload methods. Easy to dynamically load code at runtime.

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.

There are more overlaps with Java. It is gaining value types. Async is built into the runtime (see virtual threads), with preemptive scheduling. Its strings can be represented as bytes internally as well. It also has packages and modules for managing boundaries.

Java value types aren’t going to be even roughly comparable to what you can do in Go. It’s just gaining something with the name “value type”, don’t let the naming similarity lead you to believe that this is conceptually like how the same-named concept in Go works.

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.