Hacker News new | past | comments | ask | show | jobs | submit login
We Need a Safer Systems Programming Language (microsoft.com)
36 points by steveklabnik 3 months ago | hide | past | web | favorite | 47 comments

I've been playing with Zig. I realize it is not at all ready for big companies, big projects, but it is a lot easier for me than Rust. I am learning SPARK 2014 for my needs instead of Rust. Rust has gained a lot of traction over the past year.

Sebastian from MSRC here. I'll try to answer any questions

As someone in an unsexy safety critical environment, I would really love to work with a popular language that has a critical mass behind it, like in the case of the Rust community.

I would really like to hear your insights about the pros and cons of Ada 2012 and for even more critical contexts SPARK (The Ada subset not the Java framework).

Also from your experience do you have any insights on were would Rust outshine Ada?

Thanks for the article. I know you mentioned at the end of the article that there will be a future article with more details about your recommendation to use Rust. Can you expand on your reasons for this a bit?

The next article will be posted early next week so I'd hate to spoil it for you.

This reminds me of this little gem (pdf):


Related discussion:

Microsoft to Explore Using Rust


The article that is linked to incorrectly says that Microsoft is considering Rust as an alternative to C# when it is C/C++ that Rust is being compared with.

Golang or Rust don’t fit the bill?

Ahh they are looking at Rust next.

The last sentence of the post:

> In our next post, we’ll explore why we think the Rust programming language is currently the best choice for the industry to adopt whenever possible due to its ability to write systems-level programs in a memory-safe way.

Go is not a systems programming language. Rust does fit the bill.

Well... there are different definitions of "systems programming language".

One is a language that you can write an OS kernel in, including the memory management subsystem. Go probably doesn't fit that bill very well. It might be possible, but it probably wouldn't be your first choice.

But there's more to the OS than a kernel. There's drivers, and there's utilities. You can write a lot of the utilities in go. That's another definition of a "systems programming language". You wouldn't write "ls" in Python, but you could write it in Go quite easily.

Finally, people sometimes use "systems programming language" to mean a language that you can write large-scale software in. Is one of Google's services a "system"? Yes, by at least some definitions. A language that lets you write such services (such as go) is a systems programming language by that definition.

IIRC Go was originally designed to be a systems programming language and can technically be used to that effect, even if (relative to Rust) there are few projects using it in that capacity.

Then why does it include a garbage collector? Garbage collection is totally unacceptable for a systems programming language.

D has a garbage collector, and yet you can use it for operating system development: https://dlang.org/areas-of-d-usage.html#operating_systems

Lisp has a garbage collector, and yet you can use it for operating system development: https://github.com/froggey/Mezzano

Go has a garbage collector, and yet you can use it for operating system development: http://lsub.org/ls/clive.html

Because Xerox PARC, MIT, TI, ETHZ, DEC Olivetti and Microsoft Systems Research have proven otherwise.

How have they proven otherwise? I only know of singularity which never went anywhere.

Lisp machines were sold in the market, before UNIX Workstations won over thanks for being based on source code available at a symbolic price, thus cutting down their hardware costs.

ETHZ had their Oberon workstations servicing the complete CS department for around 10 years.

Midori powered part of Bing during its high time.

Don't mix technology capabilities with politics and budgeting.

> Lisp machines were sold in the market, before UNIX Workstations won over thanks for being based on source code available at a symbolic price, thus cutting down their hardware costs.

And yet despite their early popularity they died of.

> ETHZ had their Oberon workstations servicing the complete CS department for around 10 years.

I don't consider something running in a CS department as a success. CS department run all kinds of wacky shit. That's basically why they are there.

> Midori powered part of Bing during its high time.

An OS that runs a single application in the real world. That proves nothing.

You haven't convinced me that a production grade OS implemented with a GC can tick every box an OS which doesn't have a GC can tick.

On the contrary actually. For all the experimentation that has been done not a single one has actually panned out. The possible programs you can create that have a GC is a subset of all possible programs that can be created without a GC.

Java real time deployments used by military prove otherwise.

I guess we always have to wait for them to develop top technology before the masses accept it.

Java real time deployment has nothing to do with whether java can be considered a systems programming language. Why would it?

Because a pretty effective litmus test for whether or not something is usable as a systems programming language is "can a program written in the language run on bare metal?". If even Java can (somehow) tick that box, then so can Go.

That said, you're right that Java itself probably doesn't tick that box (except on hardware specifically designed to emulate the JVM; most "Java" OS projects use a small JVM written in a less-VM-dependent language), but Go provably does.

That's a ridiculous conclusion. ANY language can be ran bare metal with enough effort.

Including C, because ISO C doesn't provide any support for writing kernels.

So with enough effort given external Assembly written functions and compiler specific language extensions and enough market share thanks UNIX clones, many mistake it as the only true way.

yes including C. C is a horrible language but it was the best choice back then. Now we have Rust though. Choosing any other language then Rust to greenfield an OS at this point is stupid.

Thankfully OS researchers decide on their own what makes sense regarding writing OS in memory safe systems languages.

Stupid is not being open minded how the future might look like, how great researchers like Alan Kay envisioned the future of computing without constraining themselves to what others thought of them, we don't need faster horses.

We do need faster horses. Especially now since CPUs we are at the cusp of CPUs no longer in speed.

Thankfully Ford thought otherwise.

A big thanks to all inventors and entrepreneurs (this is HN after all) that were able to build on top of endless failures from previous generations and deliver technological achievements that mankind is now able to enjoy, persisting on their endeavours, while a large majority was downplaying all their efforts.

> Thankfully Ford thought otherwise.

Implying a language with a GC can go 10x as fast as a language without one. What are you smoking man I want some of that stuff.

It is an anti-luddite stuff, which seems not be coming across, nevermind.

So on their best day ever, OSes dependent on GC were running on fewer than 50,000 machines worldwide, which is 5 orders of magnitude less than OSes not dependent on GC.

What I just wrote is not a slam-dunk argument against OSes dependent on GC, but it is at least evidence against them -- even if decisions on which OS to use are usually political decisions.

Well, if you want more examples, Aicas, PTC and Aonix selling real time Java deployments into bare metal, some of which used by US and French military.

Or Astrobe selling Oberon boards for around 15 years now.

Or we can just keeping using UNIX clones, no need to waste money on improving the status quo.

Can you write the GC for go in go?

Go is self-hosting (i.e. Google's Go compiler is written in Go and is able to compile itself). I would assume that includes the garbage collector.

Nope it does not. Writing the compiler self hosting has nothing to do with writing the run time system.


There's some assembly in there, but it seems to be mostly Go.

People have written GCs for lisps in (non-allocating subset of) the target language

Yes they have. It's a great approach. Does Go have a precisely defined subset for this?

Yes, in fact that is the case with the reference compiler.

You need a Go compiler to compile Go, so yes.

https://news.ycombinator.com/item?id=20522115 as I say here, this is unrelated.

Scala native seems promising. Would love to see monad hipsters dancing with bare metal.

You can already do that with OCaml and Haskell.

It exists, it’s called idris

Surprised they don't do a C# flavor with Rust memory shiny.

C# 7.x and 8 haven gotten a few low level features from Midori, you can then combine them with F#.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact