4 ms·

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 tha

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.
  - pjmlp 3y ago
    If you mean by low-level programming, implementing the CPU microcode necessary to have a full graphical workstation implemented in Smalltalk, Interlisp-D, Mesa, Cedar. What is low-level? Coding in C back in the 8 and 16 bit home computer days when C was useless without piles of compiler extensions beyond K&R C, requiring either inline Assembly or an external Assembler, and even BASIC provided better primitives for hardware access?
    - vacuity 3y ago
      I'm not saying C/C++/Rust are the only low level languages. I also did say the existing terminology is bad. When someone says something is the job for C/C++/Rust, there's a certain niche that languages like Go and Python will probably never reach. I don't begrudge that traditionally slower languages are always getting faster, but as far as I can tell, it's ridiculous to say that you can create drop-in replacements for existing high-throughput C++ code in Go. There will be caveats. It seems fair to say that there will always be a need for languages like C that Go can't match. Just because the meaning of "systems programming" has shifted doesn't mean Go suddenly eats Rust's lunch. I'm not trying to gatekeep; I'm just only interested in a niche that I don't realistically see languages like Go breaking into. If performance (and especially memory usage) requirements aren't so strict, Go is perfectly fine, but I don't jibe with that kind of mindset for infrastructure. Seems like an excuse to make everything bloated (Electron being an infamous example).

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.
- pjmlp 3y ago
  If you mean by low-level programming, implementing the CPU microcode necessary to have a full graphical workstation implemented in Smalltalk, Interlisp-D, Mesa, Cedar. What is low-level? Coding in C back in the 8 and 16 bit home computer days when C was useless without piles of compiler extensions beyond K&R C, requiring either inline Assembly or an external Assembler, and even BASIC provided better primitives for hardware access?
  - vacuity 3y ago
    I'm not saying C/C++/Rust are the only low level languages. I also did say the existing terminology is bad. When someone says something is the job for C/C++/Rust, there's a certain niche that languages like Go and Python will probably never reach. I don't begrudge that traditionally slower languages are always getting faster, but as far as I can tell, it's ridiculous to say that you can create drop-in replacements for existing high-throughput C++ code in Go. There will be caveats. It seems fair to say that there will always be a need for languages like C that Go can't match. Just because the meaning of "systems programming" has shifted doesn't mean Go suddenly eats Rust's lunch. I'm not trying to gatekeep; I'm just only interested in a niche that I don't realistically see languages like Go breaking into. If performance (and especially memory usage) requirements aren't so strict, Go is perfectly fine, but I don't jibe with that kind of mindset for infrastructure. Seems like an excuse to make everything bloated (Electron being an infamous example).