LinuxMusicians

I am currently studying Rust and I like it a lot! I like the syntax, not "beautiful" in any sense but it can easily be picked up by people who know C++ and OCaml, Scala or Haskell; I think that Rust is pretty clean and benefited a lot from not having to be backward compatible with C and older versions of C++ and that it has a lot of potential for audio programming, too, since it is a functional language.

I will continue studying Rust because I think I can learn a lot from it. Aside from that, it often leads to cleaner and safer code - C++ has too much stuff and it's very hard to keep up with it, especially since the old ways (from C++03 and C++11) are sometimes radically different from the new ones and template metaprogramming isn't exactly developer-friendly Also, five C++ programmers in the same room would have completely different styles, while Rust has pretty good official documentation that sets a common standard.

Anyway, most of those would be good reasons to switch to Rust, except for these things I have heard:
1) The Rust community is a bit like NodeJS' - they use their package manager a lot to provide basic functionalities in small libraries, to the point that a typical program might have dozens of dependencies
2) Many Rust libraries use "unsafe" and this defeats part of the purpose of using Rust
3) Rust has slow compile times (C++ has the same problem, as far as I can remember, also long error messages)

If those are true, what would be the benefit of using Rust instead of C++20 with the strictest compiler options? Sure, it's harder to write safe C++20, its functional code looks a bit weird and C++ has no packages but I feel like the benefits of learning Rust wouldn't outweigh the costs if most audio libraries are written in C or C++ anyway. Additionally, even if Rust is growing there simple are more C++ programmers around, from my own experience - Rustaceans are aplenty for a new language (pretty vocal too) but it still isn't used in any major FLOSS project except Mozilla's own Servo - so there is a concrete risk of the language losing developers once the hype train slows down (I've seen it happen with many other languages now).

In short, now that C++20 allows memory-safe functional programming, why learn Rust? Above all, pardon my ignorance and please correct my views!

I don't know much about Rust, but I'm curious to hear how it goes for you as you learn more.

Right now I'm experimenting with writing a plugin in D, using Dplug from the Auburn Sounds developer. So far I'm liking D a lot, in that it's a nice system language without all of the historical baggage of C++.

Michael Willis wrote: ↑Tue Sep 22, 2020 7:23 pm I don't know much about Rust, but I'm curious to hear how it goes for you as you learn more.

Right now I'm experimenting with writing a plugin in D, using Dplug from the Auburn Sounds developer. So far I'm liking D a lot, in that it's a nice system language without all of the historical baggage of C++.

I got into D even before Rust - I think it's superior to both C++ and Rust in all regards and I'm really sad that it forces you to use a garbage collector [1]. I understand that it's not a problem for most programs out there but in real-time ones it could be, especially if the GC is not excellent (and from what I understand, D's isn't). D has also a community problem: a lot of people jumped ship (probably to Go and Rust) and this reflects on the available libraries, which are sometimes discontinued.

Aside from those issues, D has a GCC frontend, fast compile times, a nice package manager, readable templates, concurrency primitives, allows functional programming and is a lot more readable than both C++ and Rust: as I said, I would take it over both of then anytime but for the time being, I don't think that D fits in my toolbox right now - I just need a more functional and safer replacement for C++11.

It still makes a great replacement for C via the betterC mode, without any doubt

[1] = I have nothing against GCs, in fact I prefer them to reference counting and except for real-time stuff, I'd always pick a GC'd language over one that isn't.

Basslint wrote: ↑Wed Sep 23, 2020 7:40 amI'm really sad that it forces you to use a garbage collector

D no longer forces you to use the garbage collector. I don't know how long this has been the case, because I just barely started learning it this year, but if you are willing to embrace some constraints, you can optionally compile your code without garbage collection.

Michael Willis wrote: ↑Wed Sep 23, 2020 2:53 pm

Basslint wrote: ↑Wed Sep 23, 2020 7:40 amI'm really sad that it forces you to use a garbage collector

D no longer forces you to use the garbage collector. I don't know how long this has been the case, because I just barely started learning it this year, but if you are willing to embrace some constraints, you can optionally compile your code without garbage collection.

I know about @nogc, I should have worded it better. What I should have said is that its standard library often uses the GC.

I knew about Dplug but I was not aware that it is written to run specifically without the GC. I looked at the link you shared and I have to say that I'm on the fence, because it is pretty usable. My biggest concern is that they pretty much reimplemented primitives:

https://github.com/AuburnSounds/Dplug/t ... dplug/core

As good as they might be as developers, that's a very sensitive part to leave to a third party library! But if you are going to use Dplug only, I suppose it's fine.

What about leaving the GC the way it is but using pre-allocations (pooling, etc.)? Of course, that also implies mutability, because doing purely functional DSP would mean filling the memory pretty fast...

I also wanted to share the Carp language, which is a statically typed Lisp written in Haskell explicitly designed for realtime performance:

https://github.com/carp-lang/Carp

It can seamlessly call C code so it should be ready for real-world LV2 plugins.

Basslint wrote: ↑Wed Sep 23, 2020 3:12 pm What about leaving the GC the way it is but using pre-allocations (pooling, etc.)? Of course, that also implies mutability, because doing purely functional DSP would mean filling the memory pretty fast...

From what I can tell, that would probably work fine. Guillaume Piolat wrote a well reasoned blog post about switching to no garbage collection. He expected it to perform better, but was surprised to find that using @nogc did not actually improve performance. However, it fixed a compatibility problem on MacOS and reduced the memory footprint of the plugins.

As a plugin developer, I'm mostly not interested in a sprawling library ecosystem. I mainly need DSP functions and a rudimentary way to build the GUI, and Dplug already gives me enough of a foundation on both of those.

Basslint wrote: ↑Wed Sep 23, 2020 3:27 pm https://github.com/carp-lang/Carp

Oooh, now that looks like a fun language. For quite a while I was very passionate about trying to get Clojure accepted as a first class language at my day job. I learned a fair amount about lisp-like languages, and that I'm not very persuasive in terms of programming language choice

...which is a statically typed Lisp written in Haskell...

What else is there to say.

Please, for the sake of sanity just use C / C++, as god and nature (and most SDKs) intended

mike@overtonedsp wrote: ↑Thu Sep 24, 2020 3:44 pm

...which is a statically typed Lisp written in Haskell...

What else is there to say.

Please, for the sake of sanity just use C / C++, as god and nature (and most SDKs) intended

Come on, join the revolution.

Michael Willis wrote: ↑Thu Sep 24, 2020 4:16 pm

mike@overtonedsp wrote: ↑Thu Sep 24, 2020 3:44 pm

...which is a statically typed Lisp written in Haskell...

What else is there to say.

Please, for the sake of sanity just use C / C++, as god and nature (and most SDKs) intended

Come on, join the revolution.

Come join the revolution now
And recognize your age it's an Hexage rampage
Turn another page on the bytage rampage now.
So recognize your age it's a double-float rampage

I'll just answer with the quote:

(Lie #3) Code is more important than data

This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data.

https://cellperformance.beyond3d.com/ar ... -lies.html

sadko4u wrote: ↑Fri Sep 25, 2020 9:46 am

(Lie #3) Code is more important than data

The LISPers would argue there is no difference https://en.wikipedia.org/wiki/Code_as_data

raboof wrote: ↑Fri Sep 25, 2020 11:30 am The LISPers would argue there is no difference https://en.wikipedia.org/wiki/Code_as_data

Oh, man... That holy wars just steal our time which we could spend developing the software which solves specific problems. That's why it doesn't matter.

sadko4u wrote: ↑Fri Sep 25, 2020 6:40 pm Oh, man... That holy wars just steal our time which we could spend developing the software which solves specific problems. That's why it doesn't matter.

I agree on principle and for 99% of languages out there, however my thread carefully compared Rust and C++20 for these (I think valid) reasons:
1) C++20 has gotten very big and still carries some cruft from C and previous versions of C++
2) Many programmers coming from languages like Python and Ruby are learning directly Rust and unless forced (for work-related reasons or because of some specific libraries like Qt), I doubt they have a sufficient incentive to switch to C++
3) Likewise, some programmers from the functional world (Haskell, OCaml and I guess Scala, too) are switching to Rust specifically because it's so close to the functional world, they never would have switched to C++ (unless forced) which does not enforce functional programming at all
4) C++20 does not have a single, well-written, comprehensive, gratis learning resource like the Rust book AFAIK and popular C++ resources are by now outdated
5) If strict compiler options and static analysis is not used, it's still pretty easy to make a mess in C++. Also, some of the better static analysis tools are proprietary (AFAIK; I am asking you more experienced C++ programmers to confirm this one)

If data matters more than code then Rust is a better language than C++, because has better typing and a more data-oriented design from the get-go and stops less experienced programmers from making mistakes which would surely affect a program's stability.

The real question is for people (such as myself) who know C++ from earlier versions and are put at a crossroad: to learn a new language which is growing and is already close to C++ in terms of performance or to get up to date with the new languages features of C++, which I honestly find harder than learning Rust. It's a bet on Rust's future, pretty much: C++ is here to stay, that's for sure.