Could we finally ditch C++ for VSTs?

[Super Piano Hater 64]

why Rust is taken seriously even though Haskell already exists

They aren't really comparable. I'm not sure what you're thinking here.

Haskell was one possible example, but it did have enormous influence on Rust (most notably, the trait system was consciously based on Haskell's typeclasses) so I singled it out as a representative of the class of pre-Rust languages that were both memory safe and highly expressive, but ultimately didn't take over the world even after being hyped to the moon. I'm sure anyone could supply other examples.

[syntonica]

why Rust is taken seriously even though Haskell already exists

They aren't really comparable. I'm not sure what you're thinking here.

Haskell was one possible example, but it did have enormous influence on Rust (most notably, the trait system was consciously based on Haskell's typeclasses) so I singled it out as a representative of the class of pre-Rust languages that were both memory safe and highly expressive, but ultimately didn't take over the world even after being hyped to the moon. I'm sure anyone could supply other examples.

Oh okay. It's just that Haskell is purely functional with immutable data structures, so it's pretty brutal on memory, IIRC. And even with Rust, you may have to break the rules and do unsafe memory management for optimal speed. The only up-and-coming languages I can think of that give you explicit control over memory is Zig. Maybe Odin. Possibly Jai, if it ever gets here.

[llze]

Did anyone give Carbon a go and test it for DSP? Would it be a good idea to start learning that as a beginner instead of C++?

https://github.com/carbon-language/carbon-lang

[Super Piano Hater 64]

Did anyone give Carbon a go and test it for DSP? Would it be a good idea to start learning that as a beginner instead of C++?

https://github.com/carbon-language/carbon-lang

The main purpose of Carbon is to gradually migrate existing C++ codebases away from C++. If you don't have a pile of existing C++ code, they recommend using other languages. Even if you do, you can't do much with Carbon right now, because it's still in the very early stages of development.

[Super Piano Hater 64]

Oh okay. It's just that Haskell is purely functional with immutable data structures, so it's pretty brutal on memory, IIRC. And even with Rust, you may have to break the rules and do unsafe memory management for optimal speed. The only up-and-coming languages I can think of that give you explicit control over memory is Zig. Maybe Odin. Possibly Jai, if it ever gets here.

I wouldn't count on Jai or Odin to solve any of the modern problems facing audio software developers. Zig will likely enjoy much more widespread adoption (once it's stable), and if nothing else it has the cool origin story of "the developer wanted to write a new DAW."

As for Rust, you have a lot of control over memory layout even if you only write safe code. In GC languages, one of the biggest performance penalties comes from not being able to store a piece of data "inline" alongside other struct/class fields or local stack variables. Thus, any time you create nested structs, you have to do a bunch of allocations, and any time you read from them, the CPU is forced to chase pointers all over the address space, as if following a linked list. Haskell and C# have some ways around this problem (and Java is... working on it) but they come with major tradeoffs. In Rust, storing data inline is just the default, and its temporary references follow refreshingly simple and consistent rules. Like, okay, people hide in dark alleys to speak in hushed whispers of "fighting the borrow checker," but I'd take that any day over having to go behind the garbage collector's back to do some fast computation while it's hopefully looking the other way.

[syntonica]

Regarding GC, it's not the end of the world for most use cases. It just isn't well suited for real-time critical applications like a DAW.

I believe Odin has custom memory allocators. I'm not keen on its Pascally roots, though, and so I haven't looked at the compiler in depth to see how it handles. Jai is meant for game dev, which is indeed a close cousin of DSP, so I'm hopeful it will be a contender. However, Zig, with all its fussiness, appears to be the best of breed so far with its interoperability with C. If there's any other languages you'd like to nominate, I'd love to hear about them.

For now, I'm just sticking with C with Classes (very basic C++11 ). I really have no issues with its memory management. I'd be even happier with plain C if they'd just let me stick a method in my struct so I can cut down on long, ugly names.

I'm pretty much convinced that Gödel had programming in mind with his theorem. Maybe it's time to design a language specifically for real-time DSP?

[S0lo]

sorry. deleted post

[Super Piano Hater 64]

Regarding GC, it's not the end of the world for most use cases. It just isn't well suited for real-time critical applications like a DAW.

Well yeah. I said as much in an earlier post. I guess I could have also pointed out that D and Nim (as much as I don't like either of them) have ways of suspending the garbage collector in hot functions. Punk Labs' own Simian plugin was written in D using this technique (though they later switched to Rust).

Regarding the Jai/Odin/Zig trio, it might be worth pointing out that the latter two are both strongly influenced by Jai, to the extent that you could accuse them of being clones. They all share design goals, but the creator of Jai is a special kind of paranoid and does not welcome contributions from outsiders. Thus, numerous ideas about how to improve Jai have instead ended up in Zig or Odin.

If there's any other languages you'd like to nominate, I'd love to hear about them.

I guess Ada is worth mentioning; it's enjoying quite the resurgence on the coattails of crab hype.

Austral is still in its infancy, but might be worth keeping an eye on.

Swift has many things going for it, but portability is not among them despite years and years of efforts in that direction.

Maybe it's time to design a language specifically for real-time DSP?

Pure Data? Faust?

[syntonica]

Well yeah. I said as much in an earlier post. I guess I could have also pointed out that D and Nim (as much as I don't like either of them) have ways of suspending the garbage collector in hot functions. Punk Labs' own Simian plugin was written in D using this technique (though they later switched to Rust).

There's actually a whole framework in D for plugins, but I don't immediately recall the name or the author's name. Maybe he'll chime in?

Regarding the Jai/Odin/Zig trio, it might be worth pointing out that the latter two are both strongly influenced by Jai, to the extent that you could accuse them of being clones. They all share design goals, but the creator of Jai is a special kind of paranoid and does not welcome contributions from outsiders. Thus, numerous ideas about how to improve Jai have instead ended up in Zig or Odin.

There's something to be said about the whole auteur thing when it comes to language design. I know Jai is in beta with a small group of testers I'm sure he's accepting feedback from. Perhaps it will be good, perhaps not. The positive here is that he seems to put his main focus on data structures and speed, while Odin tries to be "fun" and oh it has some features. Zig seems focused on speed and safety, probably overly so on the safety part.

I guess Ada is worth mentioning; it's enjoying quite the resurgence on the coattails of crab hype.

Does the USDOD still even used ADA? I've always found it rather pedantic. Not so ironically.

Austral is still in its infancy, but might be worth keeping an eye on.

Never heard of this one. I'll have to check it out. The one that intrigues me that I think I've mentioned before is Pony with its concurrency system. Sadly, it's never really left it's experimental stage, but some great ideas in there.

Swift has many things going for it, but portability is not among them despite years and years of efforts in that direction.

I've had high hopes for this one, considering on who's on the design team. However, I've just never cottoned to it. The design is so desperate to replace Apple's version of Obj-C within their frameworks that it's starting to collapse under its own weight.

Pure Data? Faust?

They're great, but are probably too high-level for what I'm thinking. Pure Data was made for teaching, IIRC, and was not built for speed and concurrency. I'm not real familiar with Faust, other than knowing about it and the pact you sign with the Devil when you accept the EULA.

[mystran]

Regarding GC, it's not the end of the world for most use cases. It just isn't well suited for real-time critical applications like a DAW.

Well yeah. I said as much in an earlier post. I guess I could have also pointed out that D and Nim (as much as I don't like either of them) have ways of suspending the garbage collector in hot functions. Punk Labs' own Simian plugin was written in D using this technique (though they later switched to Rust).

Switching GC off in hot functions doesn't help with realtime though... 'cos you gotta switch GC off from the realtime threads and then those threads can't really access anything in the GC heap that isn't pinned down, which is less than ideal from the GC point of view.

A dual environment setup is possible though, for example writing the GUI in a managed language and the DSP code in an unmanaged language... but then you need to deal with two languages.

[resynthesis]

Ada is still widely used in safety critical industries. There's a lot of tool support for proof of correctness, V&V and hard real-time which make it popular.

[deskew]

Pure Data was made for teaching

No, it wasn't.

[syntonica]

Pure Data was made for teaching

No, it wasn't.

I was thinking Miller Puckette is a teacher and researcher... I did say IIRC.

[Guillaume Piolat]

Maybe he'll chime in?

Hello We've been using D for the last 8 years without big issues.
It's not "GC is disabled for hot functions", there is no GC at all, we completely disabled the GC because macOS.
Which is not the big win it's supposed to be, unless for controllability and memory overhead it could have.
Our UI styling language is a Wren fork who does have a GC ^^ (optional) that lives in a separate small VM just for scripting. Well the VM runs only on UI resize.

Codegen with D is through LLVM with a single front-end and backend for all 3 desktop OS.
So there is nothing that other native languages couldn't do that C++ magically could.
You can try https://dplug.org/ and see for yourself. Lots of new conference slides to get up to speed.

I believe Punk Labs went to nih-plug rather for the multi-out? You can always ask them what to think of both languages, since it's the one developer that used both D and Rust for commercial apps. Personally they haven't asked for anything particular in Dplug so I don't know. Open-source plugin framework is not making much money for anyone imo so it's not like I can support everyone's wish especially if they don't plan to contribute.

Dplug is super conservative with features, to lower the bug exposure surface (hence, no OpenGL). Sure, the initial product may cost $22000 as per the nearby PDF in the other thread, but the maintenance cost will kill you if you're not careful.

If you want to push a new language, you need to make a plugin framework in Odin or Jai or whatever, else it won't really happen. Jai, Zig, and Odin have a "context" feature (inspired from Scala implicits?) that could be interesting for stuff like allocators.

[syntonica]

Hello

Thanks, Guillaume!

Sorry I couldn't remember your name.

A couple of quick questions regarding D:

Which varieties of GC are available in D? I tend to avoid languages that use them since they do tend to grab more memory over time than is needed. (If you've ever seen the memory requirements of a Java program, they are shockingly huge!)

And very, very quickly, why D over C++, its kissing cousin? I've tried reading the manual, but it puts me to sleep every time!