I believe there are already some rust audio engines being released now. we can just take a look at those projects.
Some people say rust is “functional”, it’s not quite that but there are a lot of things from the functional world, but inside an imperative framework. It’s quite interesting.
Maybe that’s because everything audi-related is in c++ already?
Yeah. C++ has been the Nr. 1 language for audio development for decades now. Most audio developers know it. Rust adoption is certainly growing, but there’s a long way to catch up.
It is not only a technical choice, but also a pragmatic one: you need enough people who already know Rust or are willing to learn it.
I believe there are already some rust audio engines being released now
One example I know is GitHub - chaosprint/glicol: Graph-oriented live coding language and music/audio DSP library written in Rust
And an FFI will always compromise performance, in principle?
And an FFI will always compromise performance, in principle?
Both Rust and C++ can directly call C functions, there shouldn’t be a performance penality compared to native (non-inline) functions.
A person was just testing a Rust FFI in Haskell but was not ready yet. I’m just curious about the real results one can get with this. But right now, it is experimental. Rust code compilation, triggered by Haskell code compilation.
That would be great because Haskell GC, as expected, makes real-time audio just to achieve a hobbyist level.
But you’re right, I wonder about the complexity of this hack… I’m just observing.
That would be great because Haskell GC, as expected, makes real-time audio just to achieve a hobbyist level.
This is something I’ve been curious about lately. (And maybe it should be split into its own thread?)
Back in 1996, real-time code that didn’t even call malloc was absolutely essential for real-time music performance.
…Is that still true today?
This chart is 4 years old and it indicates a roughly 10,000x transistor count compared to when SC was first released:
Anecdotally, I’ve written lots of didn’t-even-try-to-optimize Haskell code which plays music in real time without hiccups.
Could that scale up? I know in theory worst-case performance could cause xruns, but how much is this an actual worry?
(Note I’m not arguing we should rewrite SC in a garbage-collecting language! I’m just curious how limited by real time we still are as computer musicians.)
Rust was only mentioned as an example just because Rust seems to be best for cross-platform SC in the following list:
NSA Suggested Memory-Safe Programming Languages
However, I am not a developer and have very limited programming experience. Just opened this thread to know what advanced users and developers think about it.
I just hope that SC4 will have many of the advantages of modern programming languages with user-friendly features, and not just be stuck in the past technologies.
I guess there would be a lot of resistance to the idea of C++ as a past technology among C++ developers – so the White House announcement is interesting at least as a warning to companies who stand to lose a lot of revenue from government contracts if they insist on C++.
From this outsider’s perspective, C++ is horribly messy (e.g. #pragma once is hilarious 
). That was the reason for my question – is there a reason other than inertia why C++ hasn’t already been replaced by Rust?
That is… C++ is still entrenched enough that the WH announcement is newsworthy. I can think of a couple reasons. One is inertia: the industry has invested a lot in the C++ ecosystem and it’s painful to think of dropping it in favor of something that’s less familiar. Another could be some practical benefit that you can get only from C++, which makes the messiness worth it. I was wondering what that is.
hjh
Adapting to Rust involves a significant mental shift, though not as extensive as the transition to Haskell or logic-based programming. The challenge of developing a large system and moving away from familiar practices is considerable. Historically, even SC transitioned from Csound’s C-based code, it was all there
It’s through the hands-on experience of executing a substantial project that developers can truly discern the nuances—identifying what aspects become more accessible, which require a shift in thinking, and maybe some elements the new language complicates (you need to follow a different paradigm to achieve safety, which can be annoying maybe)
Although listening to C++ DSP devs talking about code, it’s clear that’s a great mess…
This month, Google also donated some millions to Rust development
This is still true today. At least in my own professional work, pretty rigorous real-time guarantees are still common, and e.g. my pull request with an alloc on a realtime thread would get flagged immediately.
I think there’s a conceptual challenge: simple audio stuff can probably get away with looser memory behavior and softer real-time just fine these days (people have been building simple synths in JavaScript for years). But, even in contemporary C++, building anything interesting - a wavetable synth, additive, physical modelling, virtual analog stuff, etc - still requires a ton of care in optimizing to get it to perform in a way that’s usable and at all powerful.
So, the problem is really with more generalized systems, and relates to headroom: if you were building a straightforward 2-osc subtractive synth and that was all your code was ever doing, you’d probably have a lot of flexibility over languages and tooling. But, if you were building a synthesis toolkit or library that was flexible and could scale to more sophisticated things in predictable ways, even small-ish real-time issues could severely limit this.
Very concretely: C++ has language features that rust doesn’t have that can be critical some some kinds of code. Specifically, template meta-programming in C++ (as clunky as it often is) is far ahead of Rust. This isn’t any kind of dis to Rust, C++ has had decades of head start on some language design things that are are very hard to get right.
An example: I really wanted to use Rust to build a DSP library I’ve been poking at as a back-burner project for a while. After some prototyping and research, it became clear that I simply couldn’t write the code I needed to write - Rust doesn’t support some kinds of specialization yet, and it’s ability to implement template expressions is pretty severely limited. Template expressions are the core of, for example the math library eigen, and are super important for writing performant DSP code that is even remotely re-usable. As far as I know, C++ concepts (which are one of the biggest moves forward the language has made) are not anywhere close to being implemented in Rust (Rust has traits, which overlap with concepts but I think solve different problems in different ways). This is stuff that lots of projects would never need, but some kinds of projects need very badly.
I have seen Rust have a huge impact on C++ though - I’m not so immersed in C++ as a culture, but I do get a sense that it helped light a fire in that community to move the language forward. Lots and lots of Rust-isms can be implemented in C++ now, and I think sharing concepts back and forth between those languages has had a positive impact and will continue to. The major piece that’s missing in C++ compilers - and it represents a big gap! - is Rust’s borrow checker, which allows a whole class of compile-time checks that C++ either can’t do, or can only sort of do. I suspect that the best possible world is one where Rust and C++ are in light competition with each other indefinitely.
C++ developers don’t need to worry, here is a really useful crate that implements memory bugs in safe rust
TLDR: it isn’t possible to express lifetime ordering in higher-rank trait bounds and therefore pretty simple (if esoteric) to sidestep the borrow checker, though it is unlikely (not impossible) for this to arise in real code.
I have a theory that everyone just wants good old MACROS (rust, haskell, etc) but they don’t know it. Eventually, they will realize it. Haskell is trying, but it’s more complicated then it should be.
You lean how memory works by creating seg faults, that’s the main feature of c++! come one.
One things I’ve been reading about is how to implement a garbage collector in rust, which doesn’t seem possible without unsafe, sort of mitigating the whole point of using rust there. I haven’t seen any benchmarks yet, but it would be interesting to compare the sc one to a ‘safer’ implementation in rust.
Eigen is a good example! C++ templates enable some really powerful libraries. One personally favourite of mine is sol2 (GitHub - ThePhD/sol2: Sol3 (sol2 v3.0) - a C++ <-> Lua API wrapper with advanced features and top notch performance - is here, and it's great! Documentation:); I haven’t seen a Rust equivalent that comes even close.
which doesn’t seem possible without unsafe, sort of mitigating the whole point of using rust there.
To be fair, many low level operations – in particular, anything interfacing with C libraries – requires unsafe code, but Rust libraries try to expose safe interfaces to the user. So as along as the library author does not screw up, you don’t have to worry 
There will never be 100% safety in a low level language, but Rust is tremendously safer than C++ by default.
This glicol rust audio engine is not fucking around, it works. Would something like this scale to the level of scsynth with groups, buses, everything?
Maybe Zig is a good option. With Zig it’s possible to use C libraries, lot’s of audio libraries are in C. It’s author started it because he wanted to write a DAW. Rust has it’s complexities it seems. Zig tries to be simple, small and safe. There was a Go / golang attempt GitHub - scgolang/sc: Go client for SuperCollider
Problem with Go is that’s it’s not perfectly suitable for low latency audio (garbage collector and some other thread/memory related things). Here is where Zig comes in I guess.
Zig definitely has nice features, but it is not memory safe (assuming that this is a concern in the first place).