5 ms·

> Both languages seem to be competing for the same user base and they both seem to be "systems programming" languages, so there must be a winner, right? No, Go

> Both languages seem to be competing for the same user base and they both seem to be "systems programming" languages, so there must be a winner, right? No, Go isn't a systems programming language because it has a GC. This matters in constrained environments, like when doing embedded development, or for real time systems. Sorry, but Go isn't in the same category as Rust or C/C++. Go is in the category of Java and C#. And IMO its only advantage is that it can produce lighter binaries. And while Java and .NET are evolved towards building lighter binaries, you can't evolve a GC-ed language towards one without a GC.

Veedrac 9y ago
From the article: > Go is not even a systems programming language.
user5994461 9y ago
Go is for distributed systems. It can be for system programming, depending on what you mean by system programming. I would personally not assimilate system programming to embedded.
- axaxs 9y ago
  And even then, it's ok. Hell how many places has Java been embedded?
  - sah2ed 9y ago
    Plenty. https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card
    - deleted 9y ago
      [deleted]
    - user5994461 9y ago
      Or billions of places to talk in numbers. Java is running on so many smart cards, TV and set top box nowadays. It's almost everywhere.
    - axaxs 9y ago
      I feel maybe my comment was misunderstood. I was saying that a GC doesn't disqualify a language from systems work, even embedded, using java as an example...
- camus2 9y ago
  > Go is for distributed systems Go is for distributed SERVERS.
  - zzzcpan 9y ago
    Yeah, Go is pretty bad at distributed systems programming, well, idiomatic Go. It can be tolerable if we throw away all those poorly designed idiomatic networking packages and multithreading. But it's definitely not for distributed systems. Its niche is more in boring servers and command-line apps where an interpreted language would be too slow, too memory hungry or harder to ship, where you can get away with only the simplest concurrency, but still prepared to deal with time-consuming concurrency bugs. Like a typical commercial CRUD app, a command line automation and data processing utility, a quick one-off program.
    - user5994461 9y ago
      Or in simpler terms. Any server app where python/perl/ruby are too slow, and you can't use java/C#/C++ for some reasons.
dom96 9y ago
> No, Go isn't a systems programming language because it has a GC. I don't think a GC excludes a programming language from being considered a "systems programming language".
- jimktrains2 9y ago
  Please explain how you're going to GC on an 8bit microcontroller, or even an AMD64 when the bios/EFI passes control to you. GC requires a runtime; something needs to provide that runtime. (JavaChips were interesting, thought iirc it only ran a certain subset of Java?)
  - ben0x539 9y ago
    What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC?
    - jimktrains2 9y ago
      Because that subset of the language will often be different from the actual language.
    - camus2 9y ago
      > What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC? At that point you'd better off using C or C++ directly. Go gives you absolutely no advantage, only costly abstractions.
      - ben0x539 9y ago
        in C you're writing allocators without using malloc(), a part of the stdlib defined in the language spec. doesn't really feel qualitatively different to write Go without GC allocation. i guess it's more work but it's also not a showstopper that should decide whether Go is a systems programming lang or isn't. i mean it's not like we're talking about writing the Ruby runtime in Ruby here. advantages of writing the Go runtime in Go might include, just spitballing here, avoiding ffi cost for runtime calls, enabling better optimizations around/into runtime calls, simplifying the build process, or even just enabling Go enthusiasts to contribute to the runtime without learning C. talking about actual language features, i think I'd almost be tempted over just by Go having a module system, but there's probaby a few other subjective ergonomic benefits that you can use without falling into the GC requirement. I'm not sure what exactly decided it for them, maybe i should look that up. there's probably gonna be some OS-level non-Go shims written in either C or assembly or the weird Go way to write assembly but i feel that's fair as C-written runtimes probably need to have at least some inline asm somewhere as well.
Jdam 9y ago
> Sorry, but Go isn't in the same category as Rust or C/C++. From the article: > 99% of the time, Go is "good enough" and that 1% where it isn't, you'll know. And then take a look at Rust, because the two languages complement each other pretty well.
- SideburnsOfDoom 9y ago
  Yes, that means that 99% of the time you don't need a systems programming language. It's probably also true, depending on the specific case.
- wtetzner 9y ago
  And for that 99%, Java or C# or OCaml or any number of other languages were already good enough. Not really sure what Go brings to the table.
atombender 9y ago
Oberon [1] showed that a GC-based language could be used as a systems programming language. The various variants -- Oberon OS, Active Oberon, Bluebottle OS, A2, EthOS [2] -- were entirely written in Oberon (plus assembly), with GC at the OS level and I believe in some (all?) cases even in the kernel. Oberon had a huge influence on Go, as did Wirth's other languages. Robert Griesemer worked at ETH Zürich (where all of this was conceived) for a while. Then there's Singarity [3]. [1] https://en.m.wikipedia.org/wiki/Bluebottle_OS?wprov=sfti1 https://en.m.wikipedia.org/wiki/Bluebottle_OS?wprov=sfti1 [2] http://www.progtools.org/article.php?name=oberon&section=compilers&type=tutorial http://www.progtools.org/article.php?name=oberon&section=com... [3] http://en.wikipedia.org/wiki/Singularity_(operating_system) http://en.wikipedia.org/wiki/Singularity_(operating_system)

Veedrac 9y ago

From the article: > Go is not even a systems programming language.

user5994461 9y ago

Go is for distributed systems. It can be for system programming, depending on what you mean by system programming. I would personally not assimilate system programming to embedded.

axaxs 9y ago
And even then, it's ok. Hell how many places has Java been embedded?
- sah2ed 9y ago
  Plenty. https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card
  - deleted 9y ago
    [deleted]
  - user5994461 9y ago
    Or billions of places to talk in numbers. Java is running on so many smart cards, TV and set top box nowadays. It's almost everywhere.
  - axaxs 9y ago
    I feel maybe my comment was misunderstood. I was saying that a GC doesn't disqualify a language from systems work, even embedded, using java as an example...
camus2 9y ago
> Go is for distributed systems Go is for distributed SERVERS.
- zzzcpan 9y ago
  Yeah, Go is pretty bad at distributed systems programming, well, idiomatic Go. It can be tolerable if we throw away all those poorly designed idiomatic networking packages and multithreading. But it's definitely not for distributed systems. Its niche is more in boring servers and command-line apps where an interpreted language would be too slow, too memory hungry or harder to ship, where you can get away with only the simplest concurrency, but still prepared to deal with time-consuming concurrency bugs. Like a typical commercial CRUD app, a command line automation and data processing utility, a quick one-off program.
  - user5994461 9y ago
    Or in simpler terms. Any server app where python/perl/ruby are too slow, and you can't use java/C#/C++ for some reasons.

dom96 9y ago

> No, Go isn't a systems programming language because it has a GC. I don't think a GC excludes a programming language from being considered a "systems programming language".

jimktrains2 9y ago
Please explain how you're going to GC on an 8bit microcontroller, or even an AMD64 when the bios/EFI passes control to you. GC requires a runtime; something needs to provide that runtime. (JavaChips were interesting, thought iirc it only ran a certain subset of Java?)
- ben0x539 9y ago
  What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC?
  - jimktrains2 9y ago
    Because that subset of the language will often be different from the actual language.
  - camus2 9y ago
    > What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC? At that point you'd better off using C or C++ directly. Go gives you absolutely no advantage, only costly abstractions.
    - ben0x539 9y ago
      in C you're writing allocators without using malloc(), a part of the stdlib defined in the language spec. doesn't really feel qualitatively different to write Go without GC allocation. i guess it's more work but it's also not a showstopper that should decide whether Go is a systems programming lang or isn't. i mean it's not like we're talking about writing the Ruby runtime in Ruby here. advantages of writing the Go runtime in Go might include, just spitballing here, avoiding ffi cost for runtime calls, enabling better optimizations around/into runtime calls, simplifying the build process, or even just enabling Go enthusiasts to contribute to the runtime without learning C. talking about actual language features, i think I'd almost be tempted over just by Go having a module system, but there's probaby a few other subjective ergonomic benefits that you can use without falling into the GC requirement. I'm not sure what exactly decided it for them, maybe i should look that up. there's probably gonna be some OS-level non-Go shims written in either C or assembly or the weird Go way to write assembly but i feel that's fair as C-written runtimes probably need to have at least some inline asm somewhere as well.

Jdam 9y ago

> Sorry, but Go isn't in the same category as Rust or C/C++. From the article: > 99% of the time, Go is "good enough" and that 1% where it isn't, you'll know. And then take a look at Rust, because the two languages complement each other pretty well.

SideburnsOfDoom 9y ago
Yes, that means that 99% of the time you don't need a systems programming language. It's probably also true, depending on the specific case.
wtetzner 9y ago
And for that 99%, Java or C# or OCaml or any number of other languages were already good enough. Not really sure what Go brings to the table.

atombender 9y ago

Oberon [1] showed that a GC-based language could be used as a systems programming language. The various variants -- Oberon OS, Active Oberon, Bluebottle OS, A2, EthOS [2] -- were entirely written in Oberon (plus assembly), with GC at the OS level and I believe in some (all?) cases even in the kernel. Oberon had a huge influence on Go, as did Wirth's other languages. Robert Griesemer worked at ETH Zürich (where all of this was conceived) for a while. Then there's Singarity [3]. [1] https://en.m.wikipedia.org/wiki/Bluebottle_OS?wprov=sfti1 https://en.m.wikipedia.org/wiki/Bluebottle_OS?wprov=sfti1 [2] http://www.progtools.org/article.php?name=oberon&section=compilers&type=tutorial http://www.progtools.org/article.php?name=oberon&section=com... [3] http://en.wikipedia.org/wiki/Singularity_(operating_system) http://en.wikipedia.org/wiki/Singularity_(operating_system)