You lean how memory works by creating seg faults, that’s the main feature of c++! come one.
3 Likes
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.
1 Like
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.
3 Likes
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.
2 Likes
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?
1 Like
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.
3 Likes
Zig definitely has nice features, but it is not memory safe (assuming that this is a concern in the first place).
1 Like
I don’t know the deep details, but it certainly tries to fix some memory related problems from C. So I guess it’s safer then C, without having to rewrite all libraries and being more small and simple then Rust. That’s what I’ve learned watching some youtube talks by the creator of Zig. 
2 Likes
Yes, it is safer than C, but it’s not safe (= memory safe)
2 Likes
Generally, I’m not sure if it’s really worthwhile to speculate which language to use for a project (SC4) that at this point is nothing more than vague ideas. The choice of programming language should and will be done by the people who actually try to make the project happen, i.e. not only talk about it, but come up with a clear roadmap and start to write code. They will probably just use what they are already comfortable with.
4 Likes
Yes, of course. I think a few new audio engines will come up, and people will try what they knwo and want to do.
1 Like
In a way it feels like SUCH a minor thing, but it’s v important for usability: zig doesn’t support operator overloading, which makes it a big pain for DSP abstractions (and, for example, template expressions). A core thing that makes a language usable for writing DSP is having an expression like a + b, where that can express an equivalent operation over multiple types - float + float, double + double, vector + vector, etc. Of course it’s always possible to just write your code like add(a, b), but the thought of writing an entire library of basic DSP units with only function-call style math makes my teeth hurt a bit.
2 Likes
(but sometimes I see all the reasons people prefer Lisp, if we didn’t have so many preferences and tastes, it would be the best syntax from a technical point of view)
1 Like
All interested in what SC/rust would look like should look at Lucile’s post just now about Hadron, which is what she is trying to do.
As for Rust/FFI/SC, I got it working here and here. Do I think it’s a good idea? I don’t know! Is this the best way to do this? Most certainly not. But it definitely works (that being said, I still don’t have the ness_stretch working on Windows, but I think this is a Windows Arm problem more than anything - need to try on a real windows machine).
I prefer coding in rust, maybe because I’m not a great coder…and the compiler let’s me know my code is crap until it isn’t. Also, the crate package manager is just amazing. Things just work.
Sam
2 Likes
I think the main interest came mainly from a real-time audio server, not language implementation. It seems there are already some audio engines out there being released.
It’s also a bit of c++ and segfaultphobia maybe ))
But Rust brings a lot of modern language features, you are probably a good coder to like it ))
I confess I have learned a lot with Hlint and tools like that too…
Sam, have you measured the difference in performance?
1 Like
Side note: I have plans to turn the SC plugin API into a pure C API. Then it could be reimplemented in Rust – and other languages – without requiring an intermediate C++ wrapper, i.e. you could write SC plugins purely in Rust, Zig, C, Fortran, etc.
5 Likes
Here’s another proof of concept I made of sclang FFI back in the day: GitHub - supercollider/supercollider at topic/ffi
I think the trick is not so much the raw mechanics of something like dyncall - rather, it’s safely and conveniently exposing C API’s to sclang. At a minimum, you would need to integrate a C header parser to build a representation of an API, and some tricky things for linking to the garbage collector and to, for example, expose structs.
2 Likes
Got it. Everything must be meticulously crafted. But at least the FFI works with C code, not c++. That’s one less layer to hack,
1 Like
Not comparable, but maybe for reasons other than language: 200 RustSaws about 8% cpu, 200 LFSaw about 2%, 200 SawOS with no oversampling about 6.5-7%
So it is comparable to my less-than-optimized C++ code, but not to LFSaw.
One thing I couldn’t figure out was passing a float* pointer to rust and correctly accessing the array on the rust side. So the for loop is in C++, and it gets one value at a time from rust. If anyone understands how to do that, I’m all ears. It would very likely make the whole thing way more efficient.
Sam
1 Like
Did you try this?
1 Like