Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

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 existing libraries & tools rather than blank slate clean language syntax.

Some example domains of libraries & tools where C++ is the 1st class client instead of Rust:

+ deep learning: NVIDIA CUDA api is C++

+ HPC High Perfomance Computing: Intel MKL math library is C++

+ physics engine for video games: Unreal game engine is C++

+ latest cpu chip : ARM Allinea dev tools for the new Neoverse chips (e.g. latest AWS Graviton2 servers) is C++

+ Qt GUI is C++

Because of the extensive C++ ecosystem, you get a non-intuitive situation where programming the latest cutting-edge apps requires a 35-year-old language from 1985 instead of the newer Rust language from 2012. I predict this delta of tools+libraries between C++ and Rust will continue to exist for 10+ years.

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.

> 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

[2] https://www.youtube.com/watch?v=RxtXGeDHu0w

> a non-intuitive situation

35 years of usage means it is a sound language. Nothing non-intuitive there.

> 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.

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".

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.

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++

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.

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.

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++.

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.

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.

What a miss! 10x, I remember when I searched for an http2 / http1.1 Proxygen hadn't HTTP 2 support yet, at least client-side. So I'made a little hack into nghttp2 to fall back for 1.1 connections.

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.

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.

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.

Recent versions of C++ are quite far from the language from 35 years 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.

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.

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.

Reply on news.ycombinator.com