4 ms·

Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the

Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.

Shriken 9y ago
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)
- snakeanus 9y ago
  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/Mazur.pdf https://lirias.kuleuven.be/bitstream/123456789/131304/1/Mazu...
  - Rusky 9y ago
    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.
- mhh__ 9y ago
  These parts are true of D, and C++. IMO Rust's only true advantage over it's direct "competitors" is it's safety guarantees.
SAI_Peregrinus 9y ago
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.
- snakeanus 9y ago
  How about Ada/SPARK then?
  - dikaiosune 9y ago
    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).
    - pcwalton 9y ago
      That is correct. Ada and SPARK do not provide memory safety in the case of dynamic memory allocation without garbage collection.
      - touisteur 9y ago
        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-implementation-of-controlled-types/ 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 https://news.ycombinator.com/item?id=14346032
mamcx 9y ago
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.
- blub 9y ago
  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.
  - mamcx 9y ago
    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...
nine_k 9y ago
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/ http://www.pfq.io/ [2]: https://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has...

Shriken 9y ago

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)

snakeanus 9y ago
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/Mazur.pdf https://lirias.kuleuven.be/bitstream/123456789/131304/1/Mazu...
- Rusky 9y ago
  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.
mhh__ 9y ago
These parts are true of D, and C++. IMO Rust's only true advantage over it's direct "competitors" is it's safety guarantees.

SAI_Peregrinus 9y ago

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.

snakeanus 9y ago
How about Ada/SPARK then?
- dikaiosune 9y ago
  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).
  - pcwalton 9y ago
    That is correct. Ada and SPARK do not provide memory safety in the case of dynamic memory allocation without garbage collection.
    - touisteur 9y ago
      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-implementation-of-controlled-types/ 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 https://news.ycombinator.com/item?id=14346032

mamcx 9y ago

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.

blub 9y ago
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.
- mamcx 9y ago
  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...

nine_k 9y ago

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/ http://www.pfq.io/ [2]: https://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has...