Dear all,
Have you read this?
Should SC4 be written in Rust for example?
You can mix Rust and C++, no problem. I’ve been told by a Jedi master that each one has its advantages, rust can make it tough to do some things in comparison, although better for most things. I think in the context of audio programming.
But I think we are far from anything like such a big shift right now here.
Although it’s a matter of time before new synthesis engines are written with this technology soon.
1 Like
Should SC4 be written in Rust for example?
If the White House tells us so 
In case this is really a serious question: this is obviously about cyber security, not audio synthesis engines for experimental computer music – which hardly count as “critical systems”.
(I am not saying that SC4 should not be written in Rust, but I also don’t see much compelling reason why it should.)
5 Likes
I think, in the context of audio synthesis, C++ is still relevant and easier in many situations (I believe especially for audio); but one can’t ignore what Rust brings in terms of memory safety and modern concepts, right? And the guys got it right somehow. (That’s not me saying this, but Simon Peyton Jones saying their type system is good… (!))
I know some C++ people enjoy the language as it is, but I personally never understood the feeling. And a collaborative project can benefit from using both languages.
PS: Yes, the White House thing is hilarious.
1 Like
White House aside (I agree there’s not much reason for computer musicians to care what they think)… what are the concrete advantages of C++? Asking as someone who is thoroughly frightened off of C++ in general, except for its most basic feature set.
hjh
2 Likes
Personally, I don’t see a point in mixing both, that would just add lots of extra complexity. You’d either pick one or the other,
2 Likes
JMC mentioned to me recently that was the case, that’s why he uses both languages. Maybe that’s because everything audi-related is in C++ already? I’m not quite sure.
1 Like
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.
1 Like
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
2 Likes
And an FFI will always compromise performance, in principle?
1 Like
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.
2 Likes
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.
1 Like
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.)
3 Likes
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
- Rust
- Go
- C#
- Java
- Swift
- JavaScript
- Ruby
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
2 Likes
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
1 Like
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.
2 Likes
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.
4 Likes
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.
3 Likes
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.
1 Like