4 ms·

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 G

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.

arp242 3y ago
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.html https://opensource.googleblog.com/2009/11/hey-ho-lets-go.htm...
- oaiey 3y ago
  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.
  - neonsunset 3y ago
    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.
    - oaiey 3y ago
      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.
  - arp242 3y ago
    "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.
    - oaiey 3y ago
      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.
      - arp242 3y ago
        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 https://news.ycombinator.com/item?id=37701769
        neonsunset 3y ago
        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.

arp242 3y ago

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.html https://opensource.googleblog.com/2009/11/hey-ho-lets-go.htm...

oaiey 3y ago
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.
- neonsunset 3y ago
  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.
  - oaiey 3y ago
    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.
- arp242 3y ago
  "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.
  - oaiey 3y ago
    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.
    - arp242 3y ago
      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 https://news.ycombinator.com/item?id=37701769
      - neonsunset 3y ago
        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.