All of your questions are addressed in the article.

> Why Rust? Why not Idris? Why not Haskell?

    it can easily call C code
    it can easily be called by C code (it can export C compatible functions and structures)
    it does not need a garbage collector
    if you want, it does not even need to handle allocations
    the Rust compiler can produce static and dynamic libraries, and even object files
    the Rust compiler avoids most of the memory vulnerabilities you get in C (yes, I had to mention it)

All of these except GC also hold true for the languages that I mentioned.

As for GC, I think that Mercury avoids its use https://lirias.kuleuven.be/bitstream/123456789/131304/1/Mazu...

Nope- C interop is higher on the list for a reason. Idris and Haskell do not produce straightforward, runtime-less binaries that can be easily loaded by e.g. CPython or Node, without any interference with their runtimes.

These parts are true of D, and C++.

IMO Rust's only true advantage over it's direct "competitors" is it's safety guarantees.

Or better, why not pascal?

The HONEST question is because developers hate progress. We could have left in the past C/C++ by now, but not, is better to move forward with the same problems as DECADES ago.

Rust is a potential contender because is not that far from C/C++, and have {}, and the last point is not even a joke.

-----

Is weird to me why a clean fork of C/C++ was not made, if the prospect to move to something else was too much progress for the minds of the industry, the slow progress is a good alternative. You could have C.1, C.2, C.3, etc...

Think how much is about "modern C, modern C++, coding well" and then why not commit all that wisdom as the language?

The creator of Pascal made a point that a new version of a language must remove and correct the mistakes of the precious version, not accumulate problems.

That is fight AGAINST entropy.

Many clean forks of "C/C++" were made and they're all dead because apparently it's not so easy to do as you think.

Is not about being easy to do. Is that developers not accept them if not recreate all the same things that C/C++ have with the same good & bad, defeating the whole purpose.

Plus, this need a serious marketing push, and more than the work a few on them. Is each year harder and harder, similar to Cobol (where each year on drugs make you less likely to quit).

Now, the best hope is a painfully and too long gradual switch to rust or something else...

No GC, higher performance than either. Most other safe languages have more overhead than Rust.

As for why not use sanitizers and such: That's an ongoing cost of using the sanitizer. Rewriting in Rust is a one-time cost, and can be done incrementally.

How about Ada/SPARK then?

Please correct me if I'm wrong, but don't Ada/SPARK's memory safety guarantees only hold when all memory is pre-allocated? My memory is that dynamic allocations aren't visible to the proof system (this may be in plain Ada without SPARK, now that I think of it).

That is correct. Ada and SPARK do not provide memory safety in the case of dynamic memory allocation without garbage collection.

Not as much as rust, but still. I'm not sure whether it qualifies as memory safety for you but using Controlled types alleviates a large part of the problems of dynamic memory allocation. http://www.adacore.com/knowledge/technical-papers/the-gnat-i... might be of interest for the underlying implementation.

I also find that 'not null' access types, typed pointers and in general the in/out/in-out parameter passing mode help making ownership clearer... And there's also the limited types in the toolbox, to 'hide' ugly pointers/resource ids, etc.

Spark2014 still excludes pointers and aliasing, but I think some work is in progress. Previous HN thread : https://news.ycombinator.com/item?id=14346032

The runtime, of course. No GC, etc.

BTW Haskell has been used to write OS kernel modules: [1], [2]. It's still quite a bit cumbersome.

I also wonder why ATS language does not receive enough love in this area.

[1]: http://www.pfq.io/ [2]: https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has...