3 ms·

Go being paddled by industry hot shots doesn't change the facts. A language designed for systems programming must have precise control on everything that goes o

Go being paddled by industry hot shots doesn't change the facts. A language designed for systems programming must have precise control on everything that goes on. When you are dealing with thousand threads on 100s of cores, every microsecond counts. When you are designing control software for aerial vehicles on embedded devices doing stuff in ISRs, every thing needs to be predictable. No one in their right mind will rely on gc in that kind of systems programming world.

abiox 9y ago
this is a narrow and arbitrary definition of "systems programming". you seem to be describing something closer to hard realtime computing, which is not the same thing.
- dboreham 9y ago
  Seriously? He's using the term in exactly the way everyone uses it, even Wikipedia : https://en.wikipedia.org/wiki/System_programming https://en.wikipedia.org/wiki/System_programming
  - abiox 9y ago
    if you read your link, even the wikipedia article authors do not restrict the notion to hard realtime computing. it's not really how "everyone" uses it. it's a narrowing that a subset of vocal people have been trying to push, i can only presume for ideological purposes.
- vvanders 9y ago
  That's one aspect, the other is targets with small(<10mb) footprints where GC falls over spectacularly when you don't have 2x your working set of free memory. These aren't uncommon targets, the PSP traditionally had 8mb of system memory. Lots of embedded routers and "IoT" things, etc. Part of this is confused by everyone having a different definition of "System Programming". In my view if there's a target where hardware constrains prevent suitable performance from a language then that language isn't fit to be considered a "System Programming" language.
  - pjmlp 9y ago
    A systems programming language is any language usable to write a full OS with it. http://www.projectoberon.com http://www.projectoberon.com The only thing that Go lacks in regards to Oberon are a few intrisics in the unsafe package, easily doable in Assembly, just like ANSI C requires on its libc for bare metal programming.
    - lodi 9y ago
      By that definition Haskell is a systems programming language: https://en.wikipedia.org/wiki/House_(operating_system) https://en.wikipedia.org/wiki/House_(operating_system)
      - pjmlp 9y ago
        Of course. C gets put into a pedestal, yet it is impossible to write an OS in pure ANSI C, without making use of language extensions or Assembly.
katastic 9y ago
People who are suggesting a GC language for systems programming have literally never tried it. They're just repeating slogans they heard someone else say. Anyone who had wouldn't dare suggest it's easy or a perfect candidate for the job. I've done it and it's a pain in the ass. Why? Because the GC is _non-deterministic_. On many languages it can fire up at any time, freeze your threads at any time, and take however long it wants to. "But it usually doesn't take that long!" And? AND? The problem is, you've immediately added a blackbox thread attached to all your data. Enjoy having your program segfault in areas that are completely unrelated because the GC didn't run the finalizer till later. Enjoy having to fix a bug that doesn't have a repeatable effect. You're automatically writing multi-threaded code (and all the complexity that entails) even when you have a single-thread. A GC adds an entire dimension to bug fixing and potential failure points. Every bug, multiplied by every possible interaction with the GC. This is something that systems programming usually cannot afford. You need to be able to prove your code won't crash. And that's one more thing. Tons of systems code pre-allocates everything for that crash reason. So what problem is GC actually going to solve when everything is already carefully pre-allocated? It really sounds like people who aren't used to unmanaged languages are simply projecting their fear of the unknown. I use both types on a daily basis, and to me they're just "the right tool for the right job." I would never try to shoehorn the wrong tool into an ill-fitted application just because I like that tool.
- vvanders 9y ago
  Yup, don't forget the fact that you'll end up doing pooling, free lists and the exact same performance tricks you'd need to do if you managed memory explicitly. You're adding a ton of incidental complexity for a benefit that you can't take advantage of(programmer productivity) because you don't have the necessary resources to make it happen(large swaths of memory and > 50ms response times).
  - katastic 9y ago
    I love that nobody actually countered my arguments but I'm still negative karma. Seems to be a trend on HK if you dare mention a "hot topic."
- 9y ago

abiox 9y ago

this is a narrow and arbitrary definition of "systems programming". you seem to be describing something closer to hard realtime computing, which is not the same thing.

dboreham 9y ago
Seriously? He's using the term in exactly the way everyone uses it, even Wikipedia : https://en.wikipedia.org/wiki/System_programming https://en.wikipedia.org/wiki/System_programming
- abiox 9y ago
  if you read your link, even the wikipedia article authors do not restrict the notion to hard realtime computing. it's not really how "everyone" uses it. it's a narrowing that a subset of vocal people have been trying to push, i can only presume for ideological purposes.
vvanders 9y ago
That's one aspect, the other is targets with small(<10mb) footprints where GC falls over spectacularly when you don't have 2x your working set of free memory. These aren't uncommon targets, the PSP traditionally had 8mb of system memory. Lots of embedded routers and "IoT" things, etc. Part of this is confused by everyone having a different definition of "System Programming". In my view if there's a target where hardware constrains prevent suitable performance from a language then that language isn't fit to be considered a "System Programming" language.
- pjmlp 9y ago
  A systems programming language is any language usable to write a full OS with it. http://www.projectoberon.com http://www.projectoberon.com The only thing that Go lacks in regards to Oberon are a few intrisics in the unsafe package, easily doable in Assembly, just like ANSI C requires on its libc for bare metal programming.
  - lodi 9y ago
    By that definition Haskell is a systems programming language: https://en.wikipedia.org/wiki/House_(operating_system) https://en.wikipedia.org/wiki/House_(operating_system)
    - pjmlp 9y ago
      Of course. C gets put into a pedestal, yet it is impossible to write an OS in pure ANSI C, without making use of language extensions or Assembly.

katastic 9y ago

People who are suggesting a GC language for systems programming have literally never tried it. They're just repeating slogans they heard someone else say. Anyone who had wouldn't dare suggest it's easy or a perfect candidate for the job. I've done it and it's a pain in the ass. Why? Because the GC is _non-deterministic_. On many languages it can fire up at any time, freeze your threads at any time, and take however long it wants to. "But it usually doesn't take that long!" And? AND? The problem is, you've immediately added a blackbox thread attached to all your data. Enjoy having your program segfault in areas that are completely unrelated because the GC didn't run the finalizer till later. Enjoy having to fix a bug that doesn't have a repeatable effect. You're automatically writing multi-threaded code (and all the complexity that entails) even when you have a single-thread. A GC adds an entire dimension to bug fixing and potential failure points. Every bug, multiplied by every possible interaction with the GC. This is something that systems programming usually cannot afford. You need to be able to prove your code won't crash. And that's one more thing. Tons of systems code pre-allocates everything for that crash reason. So what problem is GC actually going to solve when everything is already carefully pre-allocated? It really sounds like people who aren't used to unmanaged languages are simply projecting their fear of the unknown. I use both types on a daily basis, and to me they're just "the right tool for the right job." I would never try to shoehorn the wrong tool into an ill-fitted application just because I like that tool.

vvanders 9y ago
Yup, don't forget the fact that you'll end up doing pooling, free lists and the exact same performance tricks you'd need to do if you managed memory explicitly. You're adding a ton of incidental complexity for a benefit that you can't take advantage of(programmer productivity) because you don't have the necessary resources to make it happen(large swaths of memory and > 50ms response times).
- katastic 9y ago
  I love that nobody actually countered my arguments but I'm still negative karma. Seems to be a trend on HK if you dare mention a "hot topic."
9y ago