Hacker News Reader

Comment by pjmlp | Hacker News Reader

Thankfully some folks completly ignored whatever the rest of the world thinks system programming is all about and created:

- TinyGo (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-...)

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-f...

[1]-https://twitter.com/ArmSoftwareDev/status/131680481331796787...

View on HN

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.

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.

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.

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.

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.

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?

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).

Reply on news.ycombinator.com