Yeah. Spelling the name of the language wrongly is also a pretty clear indication the author isn't familiar with Go. And doesn't grok it gets used for very different stuff to Rust.

So their suggestion this was why Servo was dropped seems extremely bizarre.

Also things like computer language wars just don't factor into executives' thinking at all when they make big strategic decisions except in cases where it's a proxy for market capture, like dotnet where the language (C# mostly) was initially really about locking users into a delivery ecosystem on Microsoft. If you added up everyone in the boardroom of google and mozilla you would find less than 0.01 millifucks given about go vs rust in total.

You might as well ask Mark Zuckerberg about tabs vs spaces.

To be fair it's not just this author. For some reason people are absolutely obsessed with comparing Rust and Go, whereas more applicable comparisons would respectively be Zig or D, and a JVM language or C#

In practice they overlap a lot. I don't particularly understand why people say this. I've worked doing systems programming a lot (i.e: many many syscalls) and Go does this just fine.

Unless you're working on some kind of hard real time system, I can't see why you would discard Go.

Go was very much intended as a systems programming language. It's literally in the initial announcement[1]: "Go is a great language for systems programming with support for multi-processing, a fresh and lightweight take on object-oriented design, plus some cool features like true closures and reflection."

The whole cloud bonanza came later. A lot of Go programmers I know also don't really like it (myself included).

[1]: https://opensource.googleblog.com/2009/11/hey-ho-lets-go.htm...

But we agree that Rust is purposeful closer to C and Go is purposeful closer to Java / C#? Systems can surely be build by all of them. My memory of the origins of Go was in building services but not low level drivers or renderers.

When going systems programming, the differences between Java and C# become significant, specifically, Java lacks zero/low-cost interop, ability to work with C structs directly and does not allow you to directly port unsafe pointers-based code which you can do with C# and Rust. In this regard, C# is much closer to C++ and Rust with GC attached on top and certain opinionated choices rather than being a high level language completely abstracted away via VM.

Indeed true. One of the unique and underrated strengths of C#. But "System Programming" is not exactly operating system or fundamental service writing but much more often your stock ticker broker or WhatsApp backend. The terminology is very misleading IMHO.

"Systems programming" is an ill-defined term and different people seem to mean different things with it. I think the thing you're getting at is that Go has a GC and Rust doesn't. That's indeed a meaningful difference with lots of implications, both good and bad for both, which doesn't mean that Go is unsuitable for all systems programming.

Running programs with Java and C# (OpenJDK and Mono at least) is nothing like running a Go (or Rust) programs. You can't distinguish between a Go or Rust binary at a glance, but you can spot a Java or C# program easily.

In many ways Go is significantly more similar to C than Rust is, and in other ways Rust is more similar.

I agree that the word "System Programming" is really bad.

C# and Java modern ahead of time compilation, tree shaking and linking should make it similar to Go at that sense (as in single file, no runtime, etc). There is still a lot to do but they are reaching that playing field. Not motivated by the servers but by apps and cloud startup times I guess.

Right, I don't really keep up with the latest changes – generally running Java/C# has been a bit of a hassle, similar to Python or Ruby. e.g. I had to manually download .NET things from the Microsoft website, and keep my DOTNETHOME directory around as a runtime dependency, etc. Nothing like "just download this binary and that's all you need".

Related from a few days ago: https://news.ycombinator.com/item?id=37701769

This shouldn't be the case for .NET. You only have to download the tooling to build it (which can usually be done through package manager of your choice).

To run the built binaries, whether to require the runtime (by not including it in the executable) or not is a choice.

Tl;Dr of MSFT docs is:

    JIT (w/ Runtime): dotnet publish -c release -p:PublishSingleFile=true -p:PublishTrimmed=true
    JIT (w/o Runtime): dotnet publish -c release -p:PublishSingleFile=true --self-contained false
    AOT: dotnet publish -c release -p:PublishAot=true

These can be configured via .csproj properties too, there are multiple ways to set those depending on your needs. If you don't have any specific dynamically linked native dependencies included with your project, all of the options will be a single executable that you can just run. Do note that to use AOT on macOS you will need .NET 8 (right now it's RC1/preview).

In general, dotnet CLI commands are similar cargo (it had some of the features earlier, some later): dotnet new, build, add, publish, etc.

Right; to be honest I'm not a C# expert, I just did some stuff with RimWorld modding a while back, and when I did that I had to keep all that around for some tooling (specifically: ilspycmd) or it didn't work, but looks like I just couldn't figure it out. Checking my notes I used "dotnet tool install ilspycmd -g" with .NET 6 for this, but looks like I should have used "publish".

I've saved your comment here to look at if I go back to this in the future; thanks!

Not to mention there’s no business competition between free languages. Google, like all other major corps, are looking at Rust and want it to succeed. It is not “threatening” Go in any way (whatever that means – it’s not like Google is dependent on outside contributions for Go).

There’s a lot going on in the quoted text that immediately signaled to me the rest of the article wouldn’t be worth reading.

I wrote the article.

It will not surprise you that I think you're dead wrong.

Notably you have failed to register that what I am doing in that paragraph is attempting (possibly badly) to rebut this surprisingly widespread allegation.