> I personally would rather use either C++ or a safer systems programming language.

Please list said safer systems programming languages.

- Ada

- Spark

- Rust

- D

- Swift (it will eventually cover all use cases with 3.0)

- FreePascal

- Delphi

- ATS

If I would be in an hipster mood and revive old faded ones:

- Dylan

- Modula-2

- Modula-2+

- Modula-3

- Oberon

- Oberon-2

- Active Oberon

- Component Pascal

- Algol

- PL/I

- CPL

- Mesa

- Cedar

- Turbo Pascal

- Apple Pascal

- Quick Pascal

There are a few other others that I certainly forgot.

  > Swift (it will eventually cover all use cases with 3.0)

There's nothing in 3.0 that will make Swift any better at safe systems programming than it is today (last I checked, anyway), and Chris Lattner is on the record as saying that anything akin to Rust-style static analysis is explicitly out-of-scope for 3.0.

From I understood, Swift should be able to cover all Objective-C and C use cases:

"Swift is a successor to both the C and Objective-C languages"

https://developer.apple.com/swift/

And I read somewhere that there are still some fine tuning in regards to covering the C use cases, which should be part of Swift 3.0.

So, effectively Ada and Rust. Which effectively means Rust.

I was really hoping that the list would be longer than that. :(

> Ada

> Spark

> Rust

Ada (Spark is effectively Ada) and Rust

> D

Nope. Garbage collected doesn't work for systems programming.

> Swift

Not sure I buy this. When I see someone chewing on an OS in Swift I might believe it.

> FreePascal

> Delphi

Dunno about FreePascal, but my anecdotal experiences with Delphi programs have left me wishing that their authors had written them in C. It is, of course, possible that the programming teams were bad, but it sure seems like Delphi isn't any better than C in that respect.

>Garbage collected doesn't work for systems programming.

I wonder how Xerox PARC managed to write Interlisp-D, Mesa/Cedar.

I wonder how Symbolics managed to write Lisp Machines OS.

I wonder how ETHZ managed to write Oberon, Oberon System 3,EthOS, AoS 2.

I wonder how Olivetti and Compaq managed to produce SPIN OS.

I wonder how Microsoft was able to produce Singularity and Midori OSes.

Actually I don't need to wonder, plain technical achievements that fail to convice religion against GC systems.

Ah, nice to see such an august set of popular operating systems with GC ... oh, wait ...

All of those operating systems got their ass kicked by a 1970's reject of an operating system rewritten by a college student who didn't know what he was doing.

And, in fact, Symbolics got its ass kicked so badly in terms of performance that they had to port everything to a non-garbage collected OS to even begin to compete.

If you want to try to refute me, choose Erlang. It actually still exists and is in use. It also garbage collects per process and runs down on bare metal levels so its ecosystem could be called an OS.

However, Erlang succeeds in spite of its GC, not because of it. Per process GC combined with "shoot and restart" mentality means that when the GC goes pathological the whole process gets shot and the memory gets released all at once and reallocated.

Of course, if I'm being truly cynical, I would ask why we should do GC at all in Erlang and not just shoot the process regularly.

I don't need to refute, Apple, Microsoft and Google are doing it slowly for those of us that still believe.

After all, RC is usually the first chapter of any CS book about GC algorithms.

I dream of the day when non-believers will be forced to use Swift, .NET Native, C++/CX, Go on their beloved OSes.