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".
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.
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!
