Rust for audio

Programming applications for making music on Linux.

Moderators: khz, MattKingUSA

User avatar
sadko4u
Established Member
Posts: 797
Joined: Mon Sep 28, 2015 9:03 pm

Re: Rust for audio

Post by sadko4u »

Basslint wrote:
Sat Sep 26, 2020 10:06 am
C++20
I'm still writing code in C++98 standard and don't have REASONABLE arguments to switch to recent C++ standards.
Moreover, I use C++ as "C with classes": I avoid STL, exceptions and other meta-programming if it is possible. Because it:
  • bloats the generated code;
  • extremely raises the compilation time;
  • yields to unpredictable memory allocations;
  • yields to unpredictable spinlocks when working with concurrency;
  • exceptions are unsafe if you're not working under RAII paradigm;
  • STL provides 'average' generalized solutions for data structures which are loosing to specific optimized solutions.
So for that case I've introduced leightweight Low-Level Template Library (LLTL) for C++ which allows to not to bloat the code when using some usual data structures:

https://github.com/sadko4u/lsp-lltl-lib
LSP (Linux Studio Plugins) Developer and Maintainer.

Basslint
Established Member
Posts: 546
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Rust for audio

Post by Basslint »

sadko4u wrote:
Sat Sep 26, 2020 5:04 pm
Basslint wrote:
Sat Sep 26, 2020 10:06 am
C++20
I'm still writing code in C++98 standard and don't have REASONABLE arguments to switch to recent C++ standards.
Moreover, I use C++ as "C with classes": I avoid STL, exceptions and other meta-programming if it is possible. Because it:
  • bloats the generated code;
  • extremely raises the compilation time;
  • yields to unpredictable memory allocations;
  • yields to unpredictable spinlocks when working with concurrency;
  • exceptions are unsafe if you're not working under RAII paradigm;
  • STL provides 'average' generalized solutions for data structures which are loosing to specific optimized solutions.
So for that case I've introduced leightweight Low-Level Template Library (LLTL) for C++ which allows to not to bloat the code when using some usual data structures:

https://github.com/sadko4u/lsp-lltl-lib
Thanks for sharing! I like your approach a lot, I wish I were as good as you at programming :D
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]

Wanna make music on openSUSE? Check out GeekosDAW!

PieterPenninckx
Established Member
Posts: 11
Joined: Sat Jul 04, 2020 1:01 pm

Re: Rust for audio

Post by PieterPenninckx »

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

Basslint
Established Member
Posts: 546
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Rust for audio

Post by Basslint »

PieterPenninckx wrote:
Sun Oct 11, 2020 8:31 am
@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/.
Thank you for your thoughtful post. You sold me on Rust a bit more, at the same time what you said about memory allocation pushed me toward D :lol:

I delved a bit more into C++20 since my OP and I really can't say I like it. The syntax is very hard to read sometimes and there are some language-specific concepts (pun intended) which I find hard adapting to, despite the fact that I know my way around C++11. It's true that I am not fully committing my time to it (and maybe I am just a bad coder as well) but I think that some of the criticism toward Rust (that it's too different from existing languages) can apply to C++20 as well, so it is not valid.

The option to write C++ like @sadko4u does I think is still a sustainable choice. The problem is that the language does not enforce that in any way - you have to use a lint tool I suppose to enforce a particular coding style. Which FLOSS program would you use for that, clang-format? Is it powerful enough to prevent complex constructs from being used?

Also, what about GUIs? Gtk-rs seems to be working and Azul seems interesting, is it suited for plugins?

(sorry for the questions after your great post but you seem a lot more knowledgeable than I am :D)
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]

Wanna make music on openSUSE? Check out GeekosDAW!

PieterPenninckx
Established Member
Posts: 11
Joined: Sat Jul 04, 2020 1:01 pm

Re: Rust for audio

Post by PieterPenninckx »

(sorry for the questions after your great post but you seem a lot more knowledgeable than I am :D)
No problem at all, a forum is for asking and answering questions.

Concerning D: I'm one of those who left the ship in favour of Rust. I actually enjoyed programming in D quite a lot and I still have nice memories of using D. Unfortunately I discovered this issue: https://issues.dlang.org/show_bug.cgi?id=1164#c5. I assumed that if you avoid raw pointers etc. in D, then your program would be guaranteed to be memory safe, but that turned out not to be the case. I was disappointed and I moved to Rust. But when I discovered Dplug, I wondered if I should have stayed with D a little longer... D is easier to learn than Rust, so you won't lose that much when you just give it a try.
[D] is a lot more readable than both C++ and Rust
It didn't take me long to learn the concepts that I need to read Rust easily (macros-by-example aside). In my experience, the difficulty lies really in writing Rust.
Also, what about GUIs? Gtk-rs seems to be working and Azul seems interesting, is it suited for plugins?
I have no experience with either, I can only say what I've heard. Gtk-rs works perfectly fine and one developer even said its API is easier to use than the C API (sorry, I forgot who it was). It's a heavy library for the compiler however, so best try to compile a "hello world" to see if compile times are acceptable for you (best compile twice: one initial compile, then make a small change and compile again since the initial compilation is always slower because some set-up needs to be done).
It seems there's no recent development on Azul anymore. I don't think any Rust-native GUI system is going to be mature in the short or medium term.

When you talk about plugins, I assume you mean LV2 under Linux (otherwise it's even harder). This is very much in a prototyping stage: https://rust-audio.discourse.group/t/fi ... lv2-ui/256. This is one of the areas (if not the area) in which you will probably need to work on the infrastructure if you want to be able to use it any time soon. My strategy is to postpone GUIs for plugins as long as possible and wait until others have finished the foundations.

Basslint
Established Member
Posts: 546
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Rust for audio

Post by Basslint »

Well @PieterPenninckx, you sold me on Rust. It will be my next serious time investment. Glad to have met you :D I hope the D devs will focus more on their GC though, now that Rust is stable it makes no sense for D to go GC-less: if they adopted a better, pauseless GC however I can see myself using it even if Rust is around!
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]

Wanna make music on openSUSE? Check out GeekosDAW!

PieterPenninckx
Established Member
Posts: 11
Joined: Sat Jul 04, 2020 1:01 pm

Re: Rust for audio

Post by PieterPenninckx »

You're welcome, @Basslint. If you have questions about Rust for audio, you can find me here or on the discourse instance dedicated to audio development in Rust.

Basslint
Established Member
Posts: 546
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Rust for audio

Post by Basslint »

Nim just got a new release and I feel like it maybe should be discussed as well.

It has many of the good features from languages like Rust, D and Go and it ships with a GC that is deemed suited for hard realtime. As I said before, I am not against GCs, and like in D you can just disable it anyways.

I personally prefer Rust's syntax a bit but I cannot help but feel that Nim is much easier to write and read than Rust. It also has a complete standard library, unlike Rust. I don't get why it isn't more popular, honestly!

Edit: added a link specific to Nim audio -> https://www.youtube.com/watch?v=ruT7sbs5O-Q
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]

Wanna make music on openSUSE? Check out GeekosDAW!

User avatar
mike@overtonedsp
Established Member
Posts: 92
Joined: Mon Apr 24, 2017 5:26 pm
Location: Oxford, England
Contact:

Re: Rust for audio

Post by mike@overtonedsp »

Also, what about GUIs? Gtk-rs seems to be working and Azul seems interesting, is it suited for plugins?
There are many good reasons why GTK is not a good fit for plug-in GUIs on Linux. The problems related to using <some kind of> UI toolkit (which may or may not be the native toolkit used by the host application) have been discussed at length in many other threads - quite often by me. At present the only reliable way to get plug-in UIs to work on Linux, is using X11. The bad news is you have to do a lot of the low level programming yourself, but that's ok because if you know enough about C / C++ to think its not the language you should be using to write plug-ins (despite that the SDKs are written in C / C++) then you must also know enough about it to just write a plugin using it :)

Basslint
Established Member
Posts: 546
Joined: Sun Jan 27, 2019 2:25 pm
Location: Italy

Re: Rust for audio

Post by Basslint »

mike@overtonedsp wrote:
Mon Oct 19, 2020 3:19 pm
Also, what about GUIs? Gtk-rs seems to be working and Azul seems interesting, is it suited for plugins?
There are many good reasons why GTK is not a good fit for plug-in GUIs on Linux. The problems related to using <some kind of> UI toolkit (which may or may not be the native toolkit used by the host application) have been discussed at length in many other threads - quite often by me. At present the only reliable way to get plug-in UIs to work on Linux, is using X11. The bad news is you have to do a lot of the low level programming yourself, but that's ok because if you know enough about C / C++ to think its not the language you should be using to write plug-ins (despite that the SDKs are written in C / C++) then you must also know enough about it to just write a plugin using it :)
I was asking about Azul, I know that GTK cannot be safely used for plugins, but thank you for the reminder :D
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]

Wanna make music on openSUSE? Check out GeekosDAW!

Post Reply