7 ms·

Pretty much every con in Rust is some variation of (we | others) don't use Rust enough. Interesting to see! Would have assumed the Kernel would be where Rust t

• kvark 7y ago
  Good to know! I'll look for an OS written in Rust elsewhere then. Fuchsia is interesting, but could be much more so.
  • bluejekyll 7y ago
    If you want to learn to write an OS in Rust, checkout this series: https://os.phil-opp.com/ https://os.phil-opp.com/ For an os project fully in rust and targeting end users, check out: https://www.redox-os.org/ https://www.redox-os.org/
• monocasa 7y ago
  Given that they already have a microkernel written in C++ (zircon is derived from littlekernel), and they're trying to move as much as possible outside the kernel, it makes sense that (for the time being) adding a new kernel language isn't on the table.
• bsder 7y ago
  I'm not very happy to see C++ infecting more and more system software when it STILL IN 2020 doesn't have a stable FFI/ABI. This is going to bite us ALL in the future because it will saddle other languages with a useless set of constraints long after C++ gets removed from a project.
  • monocasa 7y ago
    They don't want to add loadable kernel modules (but instead go pretty strict microkernel), so what would an unstable FFI/ABI really matter?
    • lmm 7y ago
      It's much easier to progressively migrate away from a language if you have a stable ABI.
      • monocasa 7y ago
        The goal is to get it to the size where it can be replaced all at once. For instance sel4 is only 10kloc.
  • jcranmer 7y ago
    With the exception of the change to std::string in C++11, which was very, very carefully worked around so that C++11 code can handle C++03-ABI std::string, there have been no changes to the ABI implementation since the Itanium ABI was adopted by gcc almost two decades ago. How is that not a stable ABI?
    • flukus 7y ago
      > How is that not a stable ABI? Because it's an ABI with several severe constraints, especially around the more OO features and templates, plus the solutions introduce even more abstractions: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B https://community.kde.org/Policies/Binary_Compatibility_Issu...
      • pjmlp 7y ago
        All ABIs define similar set constraints, specially when the programming languages are a bit more expressive that pseudo-assembly.
        • flukus 7y ago
          > specially when the programming languages are a bit more expressive that pseudo-assembly. Most higher level languages (java, c#, python) handle most of those much better, albeit with a different set of trade offs. Things like adding a private field to a class won't break binary compatibility in a c# apllication. C++ is fairly unique in that it tries to be high level and tries to be low level but the cost is it pushes the complexity of this split personality onto the developers.
    • rndgermandude 7y ago
      That's not a C++-ABI but a C++-as-compiled-by-gcc-ABI. C++ itself does not define an ABI and different compilers (sometimes even from the same vendors) will use different incompatible ABIs.
      • gpderetta 7y ago
  • zelly 7y ago
    FFI in C++ is never gonna happen with the preprocessor and templates being there. By design of the language it basically won't ever work. You would need to recompile the world unless you're artificially restricting yourself to the equivalent of extern "C". C++20 modules won't make it better either. I don't think Rust, Dart, or Go are any better. In practice it seems C++'s ABI is called "protocol buffers".
    • dodobirdlord 7y ago
      Basically correct, though in Fuchsia it's called FIDL. It's protocol buffers, but not the specific project that Google refers to as "protocol buffers". https://fuchsia.googlesource.com/fuchsia/+/master/docs/development/languages/fidl/tutorial/README.md https://fuchsia.googlesource.com/fuchsia/+/master/docs/devel...
      • pjmlp 7y ago
        Which is also used by Android.
    • pjmlp 7y ago
      It works perfectly fine with COM, specially after the COM 2.0 (aka UWP/WinRT) improvements.
  • pjmlp 7y ago
    C++ is moderately safe if one doesn't use it as a C compiler, even standard library does bounds checking across all major compilers, during debug builds and specific compilers switches. There is a stable ABI inside some OSes, moreso than any wannabe C++ replacements. Speaking of which, Rust is a very nice language, but still lacks many productive tooling that systems developers came to expect. If anything this rationale is great input for the Rust community, how to improve the ecosystem.
• anp 7y ago
  Rust binary size can be pretty painful, depending on what you're doing. Also, it doesn't look like that document is receiving regular updates, so grain of salt and all.
  • est31 7y ago
    > it doesn't look like that document is receiving regular updates It was checked into git yesterday.
• hu3 7y ago
  It's worth noting that Go and Dart were characterized as "highly productive" whilst Rust wasn't.
  • ShinTakuya 7y ago
    Absolutely, I don't think any sane Rust zealot would argue that Rust can compete with Go/Dart productivity. The argument can be made that Rust code has a lower maintenance cost over time, though, and that productivity may not drop as much as the system becomes more complex. Even with this relative improvement, though, I question if it's enough to overcome the shorter compile and test loop the other languages have, or the mental overhead of managing lifetimes and ownership.