Just how prevalent is Rust in the industry? I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user. A lot of the main "selling points" of Rust are getting introduced in C++. Also, what is it about Rust that gets automatic top view on HN?
>Just how prevalent is Rust in the industry?
It has been picking up a lot lately, Apple, Amazon, and Microsoft are all showing some adoption, for instance.
> I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user
The interest for a Haskell user would be that you have some of the functional programming features you like (such as discriminated unions!) with C/C++ levels of runtime performance/efficiency. For someone who has no need for that level of low level control/performance, Rust is generally not a language you want to use, for sure.
> A lot of the main "selling points" of Rust are getting introduced in C++
It is true that you could, with sufficient coding standards and linters, get something approximately like Rust by using C++, where the linter disallows any non safe pointers, any use of null or nullable types without wrapping it in a variant, disallowing all cases of undefined behavior, and so on. However you would have something a lot less pleasant to use than using Rust in the first place, build times would probably end up worse with those thing enforced as a build step, and setting up such an environment would be non trivial and you basically are just building rust out of C++, twine and gum, so why not just use Rust?
> and you basically are just building rust out of C++, twine and gum, so why not just use Rust?
my 100% honest answer: Rust does not have Qt
As a non-Qt developer: which are the limitations of using Qt bindings?
rust-qt[0] doesn’t support inheritance at all, so you can only connect to things in Qt which accept callbacks using slots. It requires `'static` lifetime on those callbacks, so as far as I can tell you are also forced to use `Rc`s whenever you are doing something with a rust-qt object even if you should be able to use a plain reference. The code is auto-generated, so all APIs are `unsafe`, and no function overloads means names are gross because the function signatures must be expressed in the function name (e.g. the `QMessageBox` constructor[1] becomes `QMessageBox::from_icon2_q_string_q_flags_standard_button_q_widget`). This could be improved by using `Option`s for arguments with defaults, but right now this is what it looks like.
qmetaobject-rs[2] has some support for inheritance but as far as I can tell it’s limited to a couple of base types only. It’s also designed around using QML, so it doesn’t actually expose most of the Qt API. As such I don’t have too much experience with it.
I’m unaware of any other usable Rust Qt bindings right now. I currently make things work by using rust-cpp[3] to create C++ subclasses and smuggle events, but this sucks because it also means the objects on the Rust side need to have the Qt API re-exposed manually since AFAIK there isn’t a way to have Rust handle that without using a code generator. (There might be some hackier ways to make this work, or maybe someone with more Rust experience than me knows of something smarter that could happen, but in any case the ergonomics right now are not good for the average developer.)
[0] https://github.com/rust-qt/ritual
[1] https://doc.qt.io/qt-5/qmessagebox.html#QMessageBox-1