Future of Rust in audio development

[jarenas]

Hi everyone, first question here—hope you don't mind a bit of rambling about future planning.
I'm an iOS developer with 10 years of Swift experience and some prior work in other languages. I'm planning a career change into audio development by 2029 (no specific goals yet, but I'd love to work on plugin creation or embedded software for hardware instruments, eurorack modules, etc.). I've been using Max/MSP/RNBO/gen~ for 2-3 years to create my own instruments and FX, mostly at a higher level (not yet creating my own oscillators or filters), while refreshing my math and diving into DSP theory.
I'll also want to slowly learn a new language to make this viable, which is a big investment/bet (specially when you have a full time job and you are already learning dsp, etc.). The obvious choice is C++—lots of resources, libraries, frameworks, tutorials—but I'm also considering Rust because:

- It's more modern and much more aligned with my Swift experience in philosophy and tooling. The little C++ I've studied feels like going back to the past (not saying that's bad, just some cultural shock)
- Adopting Swift when it wasn't popular (in my country, at least) helped me get ahead and differentiate myself, quickly landing freelance jobs. I could see a similar pattern here, though Rust's future may not be as certain as Swift's was back then.

Unfortunately, I don't know anyone in this field, so I'm lacking ways to gauge Rust's presence in the audio industry: are new projects being started with it? Is it viable beyond proof-of-concept plugins? Is interoperability with other languages viable in real cases? Are small businesses or teams really considering migrating from C or C++ to Rust?

I'm really curious about this topic, any info on this would be greatly appreciated, as I want to make an informed decision. Thank you ver much advance!

[BertKoor]

https://github.com/JamesHallowell/cxx-juce

[jupiter8]

I don't have any special insights or anything but i don't see Rust replacing C++ anytime in the foreseeable future if ever.
Basically everything is C++.
But that just like my opinion,man.

[ztp]

I'm not sure how this will affect the audio development in the near future, but here's a pointer:

https://www.techradar.com/computing/clo ... es-by-2030

[signalsmith]

I've personally moved over to CLAP for development, so the two Rust packages I'm aware of are:

• NIH-plug: a framework which builds VST3 and CLAP
• Clack: a low-level way to implement the CLAP API from Rust.

You can turn this CLAP into VST3/AU using the clap-wrapper crate, which wraps around the official CLAP clap-wrapper project. I hear rumours of AAX support soon, but don't take that as gospel.

[BertKoor]

Some insights from the Stack Overflow Developer Survey 2025:

• Rust is with 14.8% far more popular than Swift (5.4%)
• Audio or DSP is not listed as an industry. Closest category is probably 'Entertainment' with 0.6%. This is niche of niche. I get the impression you stumble into a position by accident.

From my own experience, being a professional programmer since 1989:

• I rather have a slightly boring but good paying job and an interesting hobby than a very interesting job but no money.
• Learning new stuff is in principle core business of this job.
• Learning new languages comes with the job. Last time I counted 15, so on average one new language every two year. While I'm doing mainly Java since 2006!
• I have never actively sought for new challenges / opportunities / environments, yet every five years or so I find myself at an entirely different place.

Life is what happens
While you were making other plans

[mystran]

- Adopting Swift when it wasn't popular (in my country, at least) helped me get ahead and differentiate myself, quickly landing freelance jobs. I could see a similar pattern here, though Rust's future may not be as certain as Swift's was back then.

The audio DSP industry is perhaps 99% C++ and if you plan on doing freelancing, people will expect you to know C++ fairly well. Also expect people to place limitations on the use of more modern features in some cases, the audio industry can be quite conservative at times, so it might also be learning exactly what C++ version introduced which particular feature.

Now, there's really two distinct parts to writing plugins and other audio code. On the DSP side, most of your code will tend to be fairly low level and you won't be doing things like dynamic memory allocation or mutexes in actual DSP processing. C++ still provides useful abstractions for this sort of code by means of encapsulating modules into classes and allowing template expansions and such, but for this sort of code you'd ideally want to be aware of what your code is doing down to very the bare machine and in general the less "magic" the programming language does for you, the better. So not only is it necessary to know how to write code in a language, you also want to know how exactly does the compiler implement those features so that you can avoid doing anything that isn't real-time safe!

That said, the DSP side is definitely more about DSP and less about just programming languages. Expect learning C++ (or whatever) to be much easier than learning actual DSP, unless you've got a fairly strong mathematical background. You don't necessarily need to be a mathematician, basic engineering math gets you very far, but if you're scared of greek letters then things will be difficult. If you can setup a few state variables, maybe a few buffers and write conditionals and loops, you've got most of the "programming" side figure out and rest of it tends to be math.

Then there's the GUI side. Here you're mostly writing normal application code, with some special quirks when it comes to talking to the audio thread, but for the most part it's just GUI code. When it comes to GUI code, typically the toolkit used is much more significant than the actual language you use. For freelancing purposes, I'd say your best bet is probably to get familiar with JUCE, since that's probably the most widely used toolkit. C++ actually works quite well for GUIs, the main thing is to just learn good memory management practices. Here you might find Rust challenging, because as far as I'm aware none of the GUI solutions are particularly mature and you really want to be able to throw a bunch of knobs into a window or plot a debug graph without too much effort, or your life will be quite difficult.

[kippertoffee]

I work doing DSP in the loudspeaker industry. Most code is indeed C or C++, so getting-a-job wise it's probably more useful. If you're doing your own thing, no reason not to use rust tho. Some of my colleagues here use it and have produced some blazingly fast DSP code. One nice benefit is that Rust Nightly has a neat cross platform simd library built in. I think to get really fast though you often have to break rust idioms (unsafe code).

[Music Engineer]

Here are some Rust-based open source DAW projects:

https://codeberg.org/Meadowlark/Meadowlark

https://github.com/chipnertkj/chipbox

https://github.com/defuse/DAWr

I don't know anything about their status though (i.e. how active they are being developed, what features they already offer, etc.). I think Rust is an interesting language and if I wouldn't have a largish legacy codebase in C++ and had to start fresh all over again, I might actually seriously consider Rust. But my inertia will for the foreseeable future lock me in to continue using C++.

Maybe if in 5 or 10 years from now Rust will have a (more or less) standardized way and a mature ecosystem of doing GUIs and there will be (presumably AI-assisted) tools for easily(!) and reliably(!!) porting/transpiling (at least parts of) my existing C++ code, I might consider doing so. But at the moment, that seems to be a very very far fetched speculation.

Bottom line: I think, for green field projects, Rust may be a viable choice. The ownership model with the borrow-checker stuff are pretty attractive ideas. (Disclaimer: I never did any projects in Rust, so far. I have only watched a couple of tutorials and happen find them rather convincing about the pros of the language)

[mystran]

I think to get really fast though you often have to break rust idioms (unsafe code).

The big thing to observe is that Rust treats IEEE floating point rules as part of it's safety model.

This has several implications. The first one is that if you want something resembling C++ "fast-math" (which allows the compiler to do all sorts of useful optimizations, from more effective constant folding to fused multiply-adds and any non-trivial case of auto-vectorization) then your DSP code is going to be all unsafe and you'll be using "fast math intrinsics" instead of normal floating point operations (which apparently is a "good thing" but also will make your DSP code fairly unreadable).

The more serious problem though is that denormals are part of IEEE spec, so turning them off is "unsafe" (actually I think it's worse and actually "undefined behaviour" but then again it's probably one of those cases where it's UB in C++ too, but manageable in practice) and anyone who has ever written a recursive filter should probably realize that this is bit of a problem for DSP. So even if you don't care about allowing the compiler to optimize your code, most of it is still going to be "unsafe" just avoid the headaches of spending days to track down denormals that spike your CPU and glitch your audio.

Then there's the more mundane things, like in DSP code you'd seriously rather not waste any CPU cycles for array index bounds checks and such, because it's pure overhead and only really useful during debugging anyway (which you can do in C++ too, if you use suitable array class that can be compiled with or without such checks), since a "panic" is not real-time safe ... so again any DSP code that's going to be indexing arrays is going to be "unsafe."

There might be something else as well... and while having to use "unsafe" is not necessary a case against Rust, just be aware that when it comes to actual DSP code, it's probably all going to be unsafe.

ps. The array bounds checking thing is one of those things where people who want to defend it always keep telling how the performance impact is negligible, or that compilers are super smart and can eliminate it, or that you should rewrite your algorithms to avoid indexing manually... but there's lots of DSP situations where you will be indexing into delay lines or other buffers or lookup tables using computed index and checking every index potentially has a huge CPU cost (on the order of more than the actual algorithm), not just in terms of actually spending the 2-3 cycles to do a comparison and conditional jump, but also in terms of overloading the branch predictor with unnecessary junk.