6 ms·

Pike later expressed regret about using the term "systems programming" so loosely. I believe it was during this panel discussion: https://learn.microsoft.com/

by pohl 3y ago

Pike later expressed regret about using the term "systems programming" so loosely. I believe it was during this panel discussion: https://learn.microsoft.com/en-us/events/lang-next-2014/panel-systems-programming-languages-in-2014-beyond https://learn.microsoft.com/en-us/events/lang-next-2014/pane...

capableweb 3y ago
Regardless, I don't think anyone in the first couple of years would describe Golang's goal as to be "designed for cloud infrastructure" like what parent did.
- pohl 3y ago
  Well, except for the context where google's cloud infrastructure code were precisely what they meant by "systems" back then.
- benatkin 3y ago
  I agree with you. To me that sentence broadens its applicability. Systems narrows it a bit, but he didn't intend to so much. People misunderstood this use of the term. In this context, it's more related to systems thinking than operating systems. systems =/= close to the metal
  - yencabulator 3y ago
    "Systems programming" = "programming things that are used by programs, not by end users". https://en.wikipedia.org/wiki/Systems_programming https://en.wikipedia.org/wiki/Systems_programming
pjmlp 3y ago
Thankfully some folks completly ignored whatever the rest of the world thinks system programming is all about and created: - TinyGo (https://tinygo.org/ https://tinygo.org/), which is acknowledged by people in the industry[0][1] - TamaGo unikernel on USB Armory secure key (https://www.withsecure.com/de/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/de/solutions/innovative-security-...) And then there is the question if writing compilers, assemblers, linkers is systems programming or not. [0]-https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-for-microcontrollers-now-works-on-arduino-boards/ https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-f... [1]-https://twitter.com/ArmSoftwareDev/status/1316804813317967875 https://twitter.com/ArmSoftwareDev/status/131680481331796787...
- veber-alex 3y ago
  By that logic Python is a systems programming language because MicroPython exists. Just because you can provide some niche examples where Go is used as a systems programming language doesn't mean it is a general purpose systems programming language. Putting Go in the same category as C/C++/Rust/Zig is ridiculous.
  - pjmlp 3y ago
    When Python manages to bootstrap itself, Lisp Machine or Smalltalk style, yep. Ridiculous is being a gatekeeper lacking imagination. Thankfully for mankind's progress they tend to be a minority, even though they sometimes get into the way.
- vacuity 3y ago
  The term "systems programming" is just way too vague. I imagine most languages could be contorted to write compilers and whatnot. Go doesn't seem special in that regard. However, the popular definition of systems programming, that of performing well in resource-constrained environments (probably butchered that a bit), is where languages like C/C++/Rust shine. For all your shiny high-throughput database, kernel development, bleeding edge graphics needs. I know you're an experienced programmer, so you probably understand this and view the terminology as gatekeeping. I personally don't know of a better term.
  - pjmlp 3y ago
    So just like writing an unikernel for an USB key firmware for example. Yes, it is gatekeeping, back in the 8 and 16 bit home computer days, or even before during the computer revolution, it was anything that could help to develop the whole stack. From the gatekeepers point of view, Xerox PARC never did any systems programming.
    - vacuity 3y ago
      That USB key is listed with "512 MB or 1 GB DDR3 RAM". It seems to be meant for multiple USB "applications" so that's understandable, but it's not exactly minuscule. TinyGo does seem to run on other far more constrained platforms, which is impressive. But like I said, Go doesn't seem fundamentally different than Python when it comes to shoehorning it into embedded systems. Go doesn't seem capable of competing with C/C++/Rust where they really shine ("low-level"). The memory and performance profiles are significantly different. The TinyGo team recognizes the difference between Rust and Go (being two modern "systems languages") and suggests other benefits of Go that aren't efficiency/performance. To each their own, but there's a niche where almost all languages aren't suitable. Like I said, I think the main issue here is terminology, but you brushed that aside. From a cursory glance, Xerox PARC definitely did low-level programming so I'm not sure what "the gatekeepers point of view" is supposed to mean.

by pohl 3y ago

capableweb 3y ago

Regardless, I don't think anyone in the first couple of years would describe Golang's goal as to be "designed for cloud infrastructure" like what parent did.

pohl 3y ago
Well, except for the context where google's cloud infrastructure code were precisely what they meant by "systems" back then.
benatkin 3y ago
I agree with you. To me that sentence broadens its applicability. Systems narrows it a bit, but he didn't intend to so much. People misunderstood this use of the term. In this context, it's more related to systems thinking than operating systems. systems =/= close to the metal
- yencabulator 3y ago
  "Systems programming" = "programming things that are used by programs, not by end users". https://en.wikipedia.org/wiki/Systems_programming https://en.wikipedia.org/wiki/Systems_programming

pjmlp 3y ago

Thankfully some folks completly ignored whatever the rest of the world thinks system programming is all about and created: - TinyGo (https://tinygo.org/ https://tinygo.org/), which is acknowledged by people in the industry[0][1] - TamaGo unikernel on USB Armory secure key (https://www.withsecure.com/de/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/de/solutions/innovative-security-...) And then there is the question if writing compilers, assemblers, linkers is systems programming or not. [0]-https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-for-microcontrollers-now-works-on-arduino-boards/ https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-f... [1]-https://twitter.com/ArmSoftwareDev/status/1316804813317967875 https://twitter.com/ArmSoftwareDev/status/131680481331796787...

veber-alex 3y ago
By that logic Python is a systems programming language because MicroPython exists. Just because you can provide some niche examples where Go is used as a systems programming language doesn't mean it is a general purpose systems programming language. Putting Go in the same category as C/C++/Rust/Zig is ridiculous.
- pjmlp 3y ago
  When Python manages to bootstrap itself, Lisp Machine or Smalltalk style, yep. Ridiculous is being a gatekeeper lacking imagination. Thankfully for mankind's progress they tend to be a minority, even though they sometimes get into the way.
vacuity 3y ago
The term "systems programming" is just way too vague. I imagine most languages could be contorted to write compilers and whatnot. Go doesn't seem special in that regard. However, the popular definition of systems programming, that of performing well in resource-constrained environments (probably butchered that a bit), is where languages like C/C++/Rust shine. For all your shiny high-throughput database, kernel development, bleeding edge graphics needs. I know you're an experienced programmer, so you probably understand this and view the terminology as gatekeeping. I personally don't know of a better term.
- pjmlp 3y ago
  So just like writing an unikernel for an USB key firmware for example. Yes, it is gatekeeping, back in the 8 and 16 bit home computer days, or even before during the computer revolution, it was anything that could help to develop the whole stack. From the gatekeepers point of view, Xerox PARC never did any systems programming.
  - vacuity 3y ago
    That USB key is listed with "512 MB or 1 GB DDR3 RAM". It seems to be meant for multiple USB "applications" so that's understandable, but it's not exactly minuscule. TinyGo does seem to run on other far more constrained platforms, which is impressive. But like I said, Go doesn't seem fundamentally different than Python when it comes to shoehorning it into embedded systems. Go doesn't seem capable of competing with C/C++/Rust where they really shine ("low-level"). The memory and performance profiles are significantly different. The TinyGo team recognizes the difference between Rust and Go (being two modern "systems languages") and suggests other benefits of Go that aren't efficiency/performance. To each their own, but there's a niche where almost all languages aren't suitable. Like I said, I think the main issue here is terminology, but you brushed that aside. From a cursory glance, Xerox PARC definitely did low-level programming so I'm not sure what "the gatekeepers point of view" is supposed to mean.