Hacker News Reader

Comment by chaoky | Hacker News Reader

the article brings up a good point with 'systems language'. What is a systems language anyways? I guess C is, but whats the definition? Is common lisp a 'systems language'? After all, a good number of operating systems have been written in common lisp, but is it too freewheeling and high level to be considered a 'systems language'? Is java a systems language?

View on HN

It is an interesting question and one that's quite debatable. I enjoyed the discussion in [0] the panel "Systems Programming in 2014 and Beyond" from 2014 with panel members Bjarne Stroustrup (C++), Niko Matsakis (Rust), Andrei Alexandrescu (D) and Rob Pike (Go).

Have to say I agree with Bjarne and Niko on most points discussed.

[0] https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa...

Implicitly, the most important feature of a 'systems language' is predictability: how easily can you predict how much memory or time a program will use when running?

If we take that seriously, I wonder if we should look at something that isn't turing complete.

That's a good thought, but you'd probably need to know the problem domain in advance to do that. The reason we use Turing complete languages is because you can't predict what solutions need to be expressed, so you err on the side of allowing them all.

Except we don't allow them all; we allow that subset that will run within the memory we make available to the process, in the time before we get fed up waiting and kill the process... There is likely valuable design space between that and current (or at least common) explicitly non-TC languages.

You can write a program that doesn't terminate, consumes ever increasing amounts of memory, and can perform arbitrary arithmetical calculations in just about any language. Any language that can do that is Turing complete.

About the only non-Turing complete languages in wide use today are basic dialects of SQL, Regex, and some layout engines. Every non-Turing complete language we've invented has a very specific domain of application, and none of them are suitable for writing low-level systems.

I think you missed my point, which I admit is rather subtle. I mean that there are already restrictions which we place on programs in practice; if we make those explicitly part of the language rather than implicitly part of the environment, the resulting language is not Turing complete but might still be comparably useful. The trick is in doing this in a way that practically (instead of just theoretically) improves our ability to reason about the programs, and in building it into a language that's actually usable.

Edited to add: Note that I'm not saying this is a trivial engineering exercise.

My understanding is that 'systems languages' run without a runtime and are therefore good for writing low level programs for embedded and operating systems.

I could be wrong...

Pedantry: Even C++ has a runtime (so does Rust); they're just tiny and I think can be disabled.

A language that accesses the hardware (OS, drivers...). Java is definitively not a system language unlike C++. I an not sure Rust have to be a system language.

Reply on news.ycombinator.com