Hacker News Reader

Comment by joobus | Hacker News Reader

I'd like to know what the author considers "systems work"; I don't consider garbage-collected languages (Go, Python) "systems" languages.

View on HN

Then you are ignoring all the great work done at Xerox PARC, DEC/Olivetti, Royal Signals and Radar Establishment, ETHZ, AT&T, Microsoft Research which used garbage-collected system programming languages.

If the whole OS stack can be implemented in the language, ignoring the Assembly help that even C requires, it is a systems language regardless if it has a GC for heap management or not.

By that criteria neither Go nor Python can be considered systems languages. Maybe you could implement some basic code to bootstrap CPython in Cython or RPython, I'm not entirely sure, but neither of those are really Python. The only garbage collected languages that I'm aware of that can implement a full OS stack are LISP, Red and maybe Smalltalk.

I wonder why you are disqualifying Go, given that it is fully boostraped as of version 1.6, yes even the GC is written in Go.

It is also a descendant of Oberon, which was used very much successfully at ETHZ during the 90's.

Every time I have this argument I wish some PhD student bothers to rewrite Native Oberon in Go.

Also you should educate yourself, a small list of GC enabled systems programming language is:

Lisp, Algol-68RS, Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Sing#, SystemC#, D.

There are plenty of ACM, SIGPLAN, digital archive papers from the OS written in those languages.

As pjmlp says, Oberon systems were implemented in a GC language. The latest, A2 Bluebottle, runs fast and light despite being written in a safe, GC, system language. Easily more responsive than my Linux box. There's also GC's that can support latencies good enough for soft, resl-time applications.

Far as Go, it's designed to recreate the Oberon-2 experience of Pike. It's basically a modified Oberon. If Oberon can do OS's, then Go can do OS's with some modifications to runtime or something.

I guess we should start forwarding Go as system language disbelievers to

https://github.com/jjyr/bootgo

http://wiki.osdev.org/Go_Bare_Bones

Although the Wiki author doesn't seem to understand how to use the unsafe.Pointer type, and makes use of external Assembly instead, but the bootgo does it properly.

Great find! It's not quite an OS. It does demonstrate a system booting into kernel-mode, Go code. That's a start. Re-writing... even auto-translating... the Oberon system to Go still seems like best proof.

I just sent the Github author an email suggesting it as his next project. Plus a little praise for giving us the needed ammo. :)

You are probably referring to the sentence "Rust is quickly becoming my favorite language for all systems work (which is most of what I do anyway), and has largely replaced both Go, Python, and C/C++ in my day-to-day."

One could also interpret is as "Rust is quickly becoming my favorite language for all systems work [...], and has __also__ largely replaced both Go, Python, and C/C++ in my day-to-day."

That is indeed how I meant it. That said, Go is certainly being used as a systems language, and especially in the domain of networked services, it is rapidly replacing C/C++.

replacing python is a bit of stretch no? I'm sure you can, but is it practical? like for quickly hacking stuff up.

Actually, no. I've found that I'm maybe even more productive in Rust than I am in Python, even for one-off tasks. The one exception is probably plotting, but I'm sure a Rust library for that isn't far off.

Impressive, I'll have to check it out :)

What's your replacement for Python REPLs like bpython or ptpython?

I barely, if ever, use/need a REPL. The shell has all the tools I need for short, one-off tasks.

Once upon a time I used Python for systems administration tasks and that was a long time ago, around 2003.

Python doesn't offer much against languages that compile to native code, have type inference (if strong typed) and REPL.

The only reason for me, would be if I am required to make use of a framework or library that requires me to use Python.

I find getting stuff up and running with Go is quite easy. Just set up a small package with some quick hacks and then a separate file to run the package functions.

I use Scala for that kind of use case sometimes. If you have a REPL and you have good enough type inference you can pretty much just do what you would do in Python, and as a bonus you can reuse library functions from your real system rather than having to duplicate or shell out to them from your scripts

"and especially in the domain of networked services, it is rapidly replacing C/C++."

Rapidly? Where?

I don't have any numbers to support this claim, but it's certainly true that we are seeing a lot of software being developed in Go, and network software in particular.

Examples of services that typically would have been written in C/C++ but are written in Go: Docker, YouTube Vitess (a MySQL proxy), CockroachDB (a distributed and strongly consistent SQL database).

Other examples of companies using Go for network services: Dropbox (most backend), CloudFlare (Railgun and other things), Uber (geofencing), Bitly (messaging with NSQ), Disqus (realtime commenting), DigitalOcean, Heroku, SoundCloud, Dailymotion.

Thanks to the adoption of Docker, Dropbox and other well known SV companies.

Even Microsoft is now contributing to the eco-system due to their collaboration with Docker. Also Joe Duffy (from MSR Midori) tweets about his Go experiences.

Personally I prefer other languages, but I am surely happy to see more Go and less unsafe languages being used.

Go also has the advantage of a simple syntax like Python. Moving some of our ETL processes to Go from Python has been quite easy.

There is also Netflix using it for a proxy:

> The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.

Source: http://techblog.netflix.com/2016/05/application-data-caching...

Discussion: https://www.reddit.com/r/golang/comments/4l0fv2/the_netflix_...

"Systems" has come to include things like networked services (eg. HTTP and DNS servers), which you can certainly do successfully in GC'd languages in many circumstances. Personally, I'd just like to see a widely agreed upon definition, so that we can all stop being confused when this comes up.

Naming confusion is completely normal. Even in fields like learning human anatomy you'll learn different words for some things depending on who your teacher is, even though one would think that there should have been sufficient time for such issues to settle and the professionals agree on one word. But naming always is an accident of space and time - where did it happen, when did it happen, and then the path from there. Language is dynamic and a little fuzzy - in the sciences as well. You can define all you want, the problem always is other people, who choose their own definitions. It's fun - it keeps you on your toes :-)

In this context, for example, I don't see a reason for a world government to impose one definition of "systems programming" worldwide by military force (this is what it would take!). Just like in almost everything in human language, you get it from the context. You should try to teach a computer to recognize human speech including the meaning, then you'll realize that almost all of it relies on context and pre-existing knowledge. "Precision" comes from the interpretation - human language communication is the nightmare of people who love functional programming, it's full of hidden state and context and active interpretation.

Which is why it's so easy for this to happen: http://dilbert.com/strip/2015-06-07 If someone wants to argue, there is no way to provide a water-tight human-language text that "Dick from the Internet" can't attack. There always is a way to mis-interpret human language.

Thanks, this is a great response. I shall henceforth embrace the fun and swear to never again be lured by the superficial temptations of naming hegemony!

Here is the Project Oberon source code, implemented in a GC enabled systems programming language.

http://people.inf.ethz.ch/wirth/ProjectOberon/index.html

All the way from the hardware Verilog to the GUI.

This is the 2013 re-edition of the initial project. Later versions of the operating system with its 3D Gadgets framework were quite nice to use.

It doesn't get more systems programming than that.

Oh no, it gets better: FPGA-Oberon uses an Oberon variant to straight-up synthesize hardware.

http://vbn.aau.dk/ws/files/58355126/main.pdf

So, one can do Oberon all thd way down until we need custom cells. ;)

Cool I didn't knew it.

I suspect that "systems" is on the way to meaning "what you'd use to write anything other than CRUD web apps".

One popular, reasonable definition for "systems language" is "used for writing programs that don't have a GUI" (other than web-based ones).

Another popular, reasonable definition for "systems language" is "something one could write an OS in".

I think the latter is a more reasonable definition than the former, since I've written plenty of command line applications in python. And as much as I like python, if it qualifies as a 'system language' than just about anything does.

Perhaps it could be amended "Primarily used for writing programs without a GUI."

I'm slightly hesitant to agree with both of these. The first seems wrong to me, because Bash qualifies, whereas Tcl doesn't. The second is better, though I think it excludes some interesting languages, like Scala, which you probably wouldn't write an operating system in, but that you could certainly build "systems" in (e.g., Spark).

I'd call a systems programming language "something which can use the low level ABI of the underlying platform". So C and e.g. FreePascal would fit the description (for most hardware platforms). And Java, for instance, would not unless the platform runs Java bytecode.

This discussion keeps coming up in the Go world. As with many words "systems" has multiple uses eg operating systems and enterprise systems. I don't understand the confusion.

The author wrote further down in the article under the heading "Performance Without Sacrifice":

>>Unfortunately, higher-level languages are often not a great fit for systems code. Systems code is often performance critical (e.g., kernels, databases), so the developer wants predictable performance, and tight control over memory allocation/de-allocation and data layout. This can be hard to achieve in higher-level languages or when using a garbage collector.

Others don't consider languages which do not handle OS signals a "systems" language: https://github.com/rust-lang/rfcs/issues/1368

Not entirely sure what you mean here? Even Bash can handle (some) OS signals, but I don't think anyone considers that a systems language?

Well, maybe not Bash, but it seems a dozen years ago referring to Perl as a systems language would not have caused anybody to blink ;)

I apologize for how glib my remark above was, it didn't add much to the conversation, and was more a knee jerk response to the notion that "Systems Language" is now, or ever has been, well defined.

I brought up the handling of signals, because process management is, in practice, a pretty big deal in what I would consider systems programming. But I don't think it's important to all systems programming. Much like I don't think avoiding garbage collection is necessary for all systems programming, though it's clearly an issue for some applications.

What I do find odd is the notion that it is necessary to not have garbage collection, but not having a solid story behind handling signals from the OS receives a pass.

Rust can handle signals, but its implementation is very platform specific (even the currently recommended crate lacks Windows support), and ultimately calls out the FFI. So it seems that saying Rust has support for signals is like saying Go supports manual memory management because you can call C.malloc and C.free...

I'm unsure what this is implying. Rust is fully capable of handling signals, it just doesn't provide any nice APIs for such in the standard library.

Is there a roadmap for what is currently planned for the standard library? A lot of language choice these days comes down to what high-quality batteries are included and what will require either trusting some unknown 3rd party's github project or your own homemade version.

The first-party stuff in the pipeline is basically: https://github.com/rust-lang-nursery

Off the top of my head, Time and SIMD are the only two first-party efforts that are missing from there.

Things which will, at this rate, probably never be added -- either because there isn't a "standard" solution to these problems or because it doesn't seem worth it:

* async io

* web framework/http

* numerical hierarchies and bignums

* linear algebra / stats

* GUIs

* "human" time / calendars

Eh, considering that TCP support already exists in the standard library, I could see HTTP also being added someday if there were sufficient demand.

Bignums in general are a bit too open-ended, but I could see bigints at least being added someday.

And as for async io, I think it's the same story as with HTTP: imaginably included contingent on implementation maturity and user demand.

Which also disqualifies C, because many of the language features that the C crowd uses to argue against GC enabled systems programming aren't part of the C standard, but rather compiler extensions.

In a strict ANSI C compliant compiler, signal handling is implemented in Assembly.

A systems programming language is one one can be used to write a full OS stack, regardless how heap management is done and how much Assembly help is needed.

Reply on news.ycombinator.com