4 ms·

I've been playing around with Rust because it's a promising low-level systems alternative to C++ but the reality is that many projects are enabled more by exist

• pjmlp 6y ago
  Here are some more: + macOS, iOS and Android drivers are C++ + UWP/WinUI is a mix of .NET and C++ + console SDKs use C++ + Metal shaders and HLSL are C++ dialects + Arduino is C++ + ARM mbed is C++
• mumblemumble 6y ago
  I can't speak to most of them, but I would say that the effort to create a Python wrapper for Intel MKL and deep learning frameworks has proven to be an excellent use of development resources. But that's Python, where the language is slow enough that any marshaling costs can generally be dismissed as a rounding error. The practicalities may be different in a shop that is deciding between Rust and C++.
• zwieback 6y ago
  I don't think there's anything wrong with this situation and in fact it is being actively maintained and extended. We use C# and Python for high level but generally drop down to C++ when needed. It takes us more time to make the C++ code bullet proof but it's generally smaller amounts of code in a very specific style.
• Hokusai 6y ago
  > a non-intuitive situation 35 years of usage means it is a sound language. Nothing non-intuitive there.
• Mailtemi 6y ago
  But still, the most notable library exception is the HTTP library. And nowadays this is the "lingua franca" for most of the internet. There a few such libraries like nghttp2 (but it is version 2 only), boost.beast, and many others, (but they are HTTP 1.1 only). And it is not easy to combine them.
  • benreesman 6y ago
    Proxygen is a great C++ HTTP library. - fully evented with arbitrary number of threads servicing event loops - straightforward API with examples - HTTP 1.1/2/3 out of the box - terminates SSL/TLS out of the box - extremely hardened It’s not tiny and header only or anything trendy like that, but it’s fast as hell, easy to code to, builds with cmake easily, actively developed, and runs one of the biggest sites on the Web. I have yet to find a major downside.
    • RandoHolmes 6y ago
      I avoid header-only libs like the plague and don't really understand why people prefer them. I mean, I get it, I just don't agree with the tradeoffs. header-only slows compilation down just so you can avoid adding in a single line in your build chain of choice. It's just not a trade off worth making imo. So to me, not being header only is a pro, not a con.
      • Mailtemi 6y ago
        Have you tried "explicit template instantiation"? If the library templates have good separation, you can just add a cpp file so the compiler doesn't need to deduce the type each time.
        • RandoHolmes 6y ago
          yep, that's exactly what I do when I really end up having to use a header-only lib that uses templates. It's not that I'll outright refuse to use a header-only lib, only that I very very strongly prefer not using them.
• dgellow 6y ago
  Recent versions of C++ are quite far from the language from 35 years ago.
  • dragontamer 6y ago
    But the language 35 years ago still mostly runs on recent versions of C++. Which is something not even Python accomplished in half that time.
    • nicoburns 6y ago
      You say "not even python". But Python is one of the few languages where that's not true (most haven't been around as long as C++, but e.g. Java, JavaScript have very good backwards compatibility.
    • josefx 6y ago
      Python trying to be backwards compatible is akin to a vegan T-Rex. I don't know if there ever was one, but if there was it died a long time ago.
• DavidVoid 6y ago
  > One could try to write a bunch of Rust wrappers for all the above C++ SDKs but I'm not convinced that's a good use of development resources. Embark Studios in Stockholm did exactly that for their open source NVIDIA PhysX wrapper [1]. I can recommend Tomasz Stachowiak's talk about how it was done and how all the compiler-defined behavior was dealt with [2]. [1] https://github.com/EmbarkStudios/physx-rs https://github.com/EmbarkStudios/physx-rs [2] https://www.youtube.com/watch?v=RxtXGeDHu0w https://www.youtube.com/watch?v=RxtXGeDHu0w
• perryizgr8 6y ago
  > 35-year-old language Modern C++ is actually quite different from the 35 year old version. For example, you basically do not need new and delete if you stick to the core guidelines. That's a paradigm shift.
• yahyaheee 6y ago
  I’ve been using the Rust wrapper over torch-lib for deep learning (tch-rs) and I absolutely love it. It’s way easier to use than torch-lib and you get all the performance. Unless c++ makes some major changes I think Rust will gain steam in all the areas you mentioned.
• pornel 6y ago
  Rust wrappers for C libraries work great. C++ is a bit harder, but tooling is getting better. The fact that Rust has zero-cost FFI and even inlining across LLVM languages allows you to take existing C/C++ project, and start writing new Rust code on top of it. It's like a more performant version of what people do with Python. Nobody says "oh, I can't use Python, because my device drivers aren't written in Python".
  • ncmncm 6y ago
    The better a C++ library is, the less possible it will be to create a Rust wrapper for it. Good C++ libraries depend on language features that are, and will always remain, wholly inaccessible from Rust. Almost every feature of C++ is there to make writing powerful libraries possible. Many uses of such features become part of the library interface, because that enables zero-overhead libraries with semantics intricately integrated into the caller's usage. Rust has a goal of zero-overhead code, but is not designed to minimize the overhead of library usage. That was a choice: it makes the language simpler and easier to learn, but that comes at a cost. You cannot write a Rust library to do what is routinely done in C++ libraries, and a Rust wrapper cannot expose those capabilities to Rust code.