> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages. Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readab…
Quoted post unavailable.
I‘m sure there are better reasons for people liking Go other than what you described. This reads like a general dismissal.
> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages. Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readab…
There is absolutely nothing mentioned in your comment that Java or C# didn’t already do better 10 years ago, let alone now. The only somewhat redeeming quality of go is virtual threads, but that is not even the reason like 90% of its user base uses it for.
AOT compiler; single binary; standard library and package ecosystem well suited for a subset of programming tasks, while being much lightweight and less verbose than Java / C#.
Would not pick Go to make a website. But it's probably best tool to make a simple HTTP server or command line tool that deals with files or network.
One major difference that makes Golang lower level is that it compiles to machine code for the target CPU arch/OS instead of bytecode.
C# also supports AOT compilation. It's definitely not a low-level / high-level language differentiator. The term generally means the abstraction level you can reach.. I'd be tempted to define it as the distance to simple lambda-calculus in the lambda-cube
Oh, AOT compilation, great memories. How many year of CPU work and downtime it took from exchange servers, when you wait every update to “compile” for hours, just because it is awesome. Or when you getting laptop heating and you know - it is dotnet compiles and optimising something for you, another great update.
Yes, C# also supports ahead of time compatibility - it is portable for whole 20 years between windows computers. How cool is that?
Another advantage is speed - calculator or photo viewer only takes 1-3 seconds to open on 5 ghz 8 core cpu. Yet another advantage is size - only 3-5 gigabytes of different version libraries in your system and you are golden for a month (next you need to install preview updates, and then just updates and thats all you good, secure and protected by Windows Defender). In all these aspects C# is clearly superior language.
Does Go support separate compilation? The approach sounds like a change in the implementation of a generic function (changing the gcshapes) could cause client code to break unless it is recompiled as well. What am I missing?
There are "shared" and "c-shared" build modes[1], if that's what you mean. The latter is fairly obvious. The former is so rarely used that there was a proposal to remove it, but it turned out that some people did actually use it, but almost exclusively because of license terms. [1]: https://pkg.go.dev/cmd/go#hdr-Build_modes
Yocto/OE used to build Go in this shared mode just to conserve space that would otherwise be wasted by each Go program shipping its own copy of the standard library. It did shave off some MBs, so hard to say it wasn't useful especially if a bunch of +20MB binary blobs are a concern.
So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…
C# generics are delicious. Combined with the strong compiler and super good reflection features, you can do very well indeed with it.
It does have subtyping relationships via interface. It absolutely has subtypes in the co/contravariance. In theory, a slice of structs that implement an interface should be able to be used as a slice of that interface. But due to the implementation, that requires a full copy.
It’s not just a random implementation artifact. Since all slices in Go are mutable, it logically wouldn’t make sense to upcast them while keeping the reference. That would mean the ability to put other objects in the slice. Same for pointers. That’s a basic fact of type safety that people often get wrong. For example, the JVM famously allows upcasting arrays, with very surprising results.
Java fixed the mutability issue for its generics, you can insert Cats and Dogs into a concrete List, but you cannot insert them into a List.
There is absolutely nothing mentioned in your comment that Java or C# didn’t already do better 10 years ago, let alone now. The only somewhat redeeming quality of go is virtual threads, but that is not even the reason like 90% of its user base uses it for.
AOT compiler; single binary; standard library and package ecosystem well suited for a subset of programming tasks, while being much lightweight and less verbose than Java / C#. Would not pick Go to make a website. But it's probably best tool to make a simple HTTP server or command line tool that deals with files or network.
Java has AOT compilers since 2000, they just weren't free beer.
.NET was released with AOT compiler, although it only did dynamic linking (NGEN).
Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.
I think C# might be the closest mainstream language, but I’d say explicit pointers, interior pointers, and slices as the default list type might be things that make Go programming a little lower level. There are also other differences that would prevent using C#’s system as is - Go doesn’t have the reference/value type dichotomy or inheritance. I think they also wanted to be able to abstract across float/doubles etc…
Never used unsafe and raw pointers in C#? They exist since version 1.0.
Never used ArraySegments in C#? They exist since version 2.0
We use go in an embedded Linux environment. I do C#for web stuff and it would never cross my mind to do c# in an armv7 Raspberry. Also what about cross compilation? The c# runtime is not easily available to use in embedded devices at least that i know of. With go you just set it to compile statically and set the arch target. I can deploy it as a single binary. Love it after years of maintaining cross tool chains.