Hi all, Rust developer here.
I'll give my Completely Unbiased and Authoritative opinion (ahem).
@Basslint, concerning the points you raise:
1) The Rust community is a bit like NodeJS' - they use their package manager a lot to provide basic functionalities in small libraries, to the point that a typical program might have dozens of dependencies
As somebody who happily adds another dependency to his Cargo.toml file, thinking "this is less code I have to write and maintain", I can confirm this. Rust's standard library is rather narrow compared to e.g. Java; this also explains why so many dependencies are added. Of course, as a developer, you choose which and how many dependencies you add.
2) Many Rust libraries use "unsafe" and this defeats part of the purpose of using Rust
I would sketch a more nuanced view on this. In Rust, you need unsafe for two things: a) for really low-level stuff like and interfacing with C libraries (obviously) and b) when the automated checks that the language imposes are too strict and you are 100% sure that you are right. For low-level stuff, unsafe is unavoidable (same goes for any language). For point b): you rarely need this. Some Rust developers use unsafe in situations where they shouldn't.
I would not go so far as to say that this defeats part of the purpose of using Rust. About 99% of my code is not unsafe and I've never ever had a memory issue in that code. (I think I've had just one segfault in five years, and that was obviously in unsafe code, so it was easy to find the problem.)
3) Rust has slow compile times (C++ has the same problem, as far as I can remember, also long error messages)
Slow compile times: true. Long error messages: yes, because it includes tips and pointers to the source code etc. Actually, I stopped using C++ after I got two-pages long error messages that pointed to file A because I had forgotten a semicolon in file B (at least, that's how I remember it). The Rust experience is much more pleasant in that regard.
There are some other aspects about Rust that I think are relevant.
Firstly: it's hard to learn as a language, at least in my opinion. Some will claim that it takes just a few weeks to learn it, but this has definitely not been the case for me. Rust is very unforgiving when it comes to making mistakes, refusing to compile your software if it thinks you're doing something wrong. The advantage is that you have fewer bugs, but the disadvantage is that you're now reasoning about code that didn't even compile, so it's all a very theoretical affair and you don't have a crash to make it very clear to you that you are indeed wrong and why. Instead, the compiler gives you an error in its own terminology ("lifetimes", "borrow", ...) and it's up to you as a developer to make sense of it and to figure out if there's a real fundamental issue with your code (90% of the times, that's the case for me), or if you need to "massage" the code a little to make the compiler happy (the remaining 10% of the times for me). It seems that some other developers don't experience it in the same way as I do, so I think it also depends on the type of code you write.
Secondly, when it comes to audio development, the ecosystem is rather immature. The current ecosystem supports some types of audio applications. E.g. a command-line Jack application is something you can easily write (depending on what audio transformations you need, of course), same goes for LV2, I think (I haven't tried it). If you want to go further, you will probably discover that some bits and pieces are missing and you will have to develop some infrastructural code yourself. I don't know how far this differs from e.g. C++ or D since I don't have any worth-mentioning audio development experience in those languages. I can tell however that there's no such thing as JUCE or Dplug for Rust.
Concerning garbage collectors: indeed, Rust does not require the use of a garbage collector. In fact, the only garbage collector that Rust supports is reference counting (if you ignore some experimental third-party garbage collectors). However, I understood that even heap allocation is a no-go in a real-time context (famous blog post:
http://www.rossbencina.com/code/real-ti ... or-nothing ). This also means that even in Rust, in a real-time context, you have to pre-allocate heap memory. Hence in Rust, you're using the same techniques that you would use in say D to avoid needing the Garbage Collector. The big difference in my opinion is that it's easier to work on the stack in Rust. In most languages, objects (as in instance of classes) always live on the heap or there's no way to let the compiler know that this is supposed to only live on the stack (e.g. Go uses escape analysis to determine if objects can live on the stack as an optimization, but as far as I know, there's no way to enforce this). By contrast, in Rust, everything lives on the stack unless you tell it not to (e.g. by putting it in a vector). (Context: Rust is not an object oriented language.) The true power of Rust lies in the fact that the language allows you to hand out references to things on the stack without running into memory bugs.
All in all, I'm satisfied using Rust for audio development and I personally wouldn't look into using another language for it, except maybe for writing a GUI. The reasons I like Rust are pretty much those mentioned by
@Basslint: the compiler prevents me from doing stupid things, there's a nice package manager etc. I would add excellent documentation of the standard library and of most libraries in general, absence of NULL and the presence of algebraic data types (which I now miss in almost any other language).
@Basslint, I very well understand your dilemma: it's indeed a bet on the future of Rust and neither of us can look into the future. There's some discussion about using Rust in the Linux kernel (
https://lwn.net/Articles/829858/) and reading the comments it seems that many are scared of being the first to place a big bet on Rust. Whether Rust is going to gain foot in audio development is a question mark and it's also possible that Rust inspires a new, even better language that then takes over from Rust. However my bet is that Rust is going to stay, at least for programming multi-threaded systems that need to be reliable. In the meanwhile, I can tell that I'm enjoying it. I hope my comments above can help you to figure out in advance if you will enjoy it as well.
Anyway, I also want to mention there's a nice and friendly community around audio development in Rust:
https://rust-audio.discourse.group/.