Do you ever think of developing in other languages than C++?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

helium wrote: Mon Apr 18, 2016 3:50 pm Rust would be my first choice. D and Nim would be two further candidates for plugin development. I think at least one person on this forum actually developes his plugins in D.
C# is interpreted (not compiled).
Unlike Java C# always gets compiled before execution. (C# code gets compiled into il, il gets compiled into native machine code before execution.)
I would suggest look at Rust too. I think I saw that Elektron make some of their products based on it. I am also seeing some rumblings that *might* get used in other stuff that is closer to what my day job is.
🌐 Spotify 🔵 Soundcloud 🌀 Soundclick

Gear & Setup: Windows 10, Dual Xeon, 32GB RAM, Cubase 10.5/9.5, NI Komplete Audio 6, NI Maschine, NI Jam, NI Kontakt

Post

The OP was saying that C++ is complicated. Rust has exactly the same problem.

I personally want things like Zig and Nim to succeed. At my age and having mastered C++ I have no need to burn braincells fighting a different compiler and to get even slower compile times.

Post

I was looking forward to Rust and took a detailed look a couple of years ago. Was a huge disappointment. I'm a big fan of intrusive data structures, they are indispensable for (a bit complex) data management tasks in realtime (and also non realtime, YMMV) contexts. Unfortunately they seem to be a nightmare to implement in Rust (I tried to implement my own and also was looking to an available implementation of an intrusive list for Rust). Lifetimes are important, but look overcomplicated (although maybe they needed more time to be properly understood). One of the reasons I wanted to flee from C++ was the all-penetrating UB. With Rust I even couldn't find out what is UB and what isn't.

I also don't like that fundamental library features such as Box, weren't directly implemented as library code, but instead "overridden" by a compiler (compare to unique_ptr in C++, which can be fully implemented as library code). Furthermore, they are getting "unfair benefits" from the compiler, making it impossible to implement custom features of comparable functionality.

They biggest problem of the language however seems to me that it is fundamentally based on moveable semantics. So deeply, that it doesn't seem possible to block it. At least some people in the Rust community are aware of the problem and even try to address the issue (in particular, the introduction of the Pin feature), but this looks to me very far from desired state, moves forward slowly, and I'm not sure whether I'm gonna like the final result.

Post

No, you won't, it will end up as C++, where each feature added is a fix for another previously added feature.

https://scattered-thoughts.net/writing/ ... -and-rust/

Post

rafa1981 wrote: Thu Mar 18, 2021 6:27 pm The OP was saying that C++ is complicated. Rust has exactly the same problem.

I personally want things like Zig and Nim to succeed. At my age and having mastered C++ I have no need to burn braincells fighting a different compiler and to get even slower compile times.
i am not really an expert on C or C++. i started looking at rust. to me, rust seems like a newer and more user firendly version of C++. i dont know. but i saw a bunch of talks about it at the Juice web conference from last year. So it's possibly it's picking up a bit of momentum.
🌐 Spotify 🔵 Soundcloud 🌀 Soundclick

Gear & Setup: Windows 10, Dual Xeon, 32GB RAM, Cubase 10.5/9.5, NI Komplete Audio 6, NI Maschine, NI Jam, NI Kontakt

Post

I agree that C++ is "unnecessarily complicated" due to it's huge partially redundant, non-orthogonal feature set it has collected over the years due to its strong commitment towards backwards compatibility.

Here, I see Rust as a promising alternative for the future as it had the chance to learn from C++'s design mistakes. I don't believe Rust is over complicated in general, it mostly just forces you to think more rigorously about your design and prove its soundness to the compiler. That said, there are a couple of cases were provable safe code is not accepted by the compiler so you need to re-work it to express its soundness with the available "vocabulary". Such situations can indeed be annoying at times. I'm certain the language designers are well aware of those issues and will work to improve on them on the long term. A good example where this happened in the past is the introduction of "Nonlexical lifetimes".

All that said, my gut feelings are that languages like Rust are not what the OP is looking for. He is probably better served with languages that are based on a garbage-collected runtime, such as D.
GC largely takes away the burden of memory management from the programmer at the cost of non-deterministic run time behavior which can be critical in real-time code if not careful. It also tends to cause high memory consumption. Or you can trust yourself to handle resource management / concurrency correctly and go for languages like Zig. I don't. So, it's a trade-off, not an obvious choice because one language is necessarily better designed than the other.

Post

karrikuh wrote: Fri Mar 19, 2021 7:20 amA good example where this happened in the past is the introduction of "Nonlexical lifetimes".
This is one example which I'd rather take as a minor negative. I couldn't find any precise documentation on the behavior of nonlexical lifetimes, it's seems to be just "what the compiler finds reasonable". In that sense I a) can't 100% predict the lifetimes and respectively the code that I originally write might even not pass through the compiler b) can't be 100% sure if my code will compile in future, if some internal deduction rules for nonlexical lifetimes change. I agree, nonlexical lifetimes feel much more convenient and less confusing in simple cases, but in the complicated cases I think they only add extra confusion. YMMV.

Post

rafa1981 wrote: Thu Mar 18, 2021 9:33 pm No, you won't, it will end up as C++, where each feature added is a fix for another previously added feature.

https://scattered-thoughts.net/writing/ ... -and-rust/
In regards to movability and intrusive data, I'm not even sure there is a solution without redoing the language fundamentals (which is unlikely an option, that'd be a different language anyway).

Post

Z1202 wrote: Thu Mar 18, 2021 8:44 pm I was looking forward to Rust and took a detailed look a couple of years ago. Was a huge disappointment. I'm a big fan of intrusive data structures, they are indispensable for (a bit complex) data management tasks in realtime (and also non realtime, YMMV) contexts. Unfortunately they seem to be a nightmare to implement in Rust (I tried to implement my own and also was looking to an available implementation of an intrusive list for Rust). Lifetimes are important, but look overcomplicated (although maybe they needed more time to be properly understood). One of the reasons I wanted to flee from C++ was the all-penetrating UB. With Rust I even couldn't find out what is UB and what isn't.

I also don't like that fundamental library features such as Box, weren't directly implemented as library code, but instead "overridden" by a compiler (compare to unique_ptr in C++, which can be fully implemented as library code). Furthermore, they are getting "unfair benefits" from the compiler, making it impossible to implement custom features of comparable functionality.

They biggest problem of the language however seems to me that it is fundamentally based on moveable semantics. So deeply, that it doesn't seem possible to block it. At least some people in the Rust community are aware of the problem and even try to address the issue (in particular, the introduction of the Pin feature), but this looks to me very far from desired state, moves forward slowly, and I'm not sure whether I'm gonna like the final result.
Intrusive data structures are in fact a pain to implement in Rust. Lifetimes could be complicated at first, but then you start get it and just see mistakes immedietaly.

Rust has a steep lerning curve but IMO nowhere compared to C++. C++ is a monstrosity with traps set up everywhere for developers. From my POV the huge mistake of the language is existence of template metaprogramming. It's the biggest nightmare I saw in any programming language so far - almost non debuggable, crypting error messages and so on. When I think about going back to Cmake based builds it literally makes me cry compared to Cargo. When I saw some big c++ codebases I realised it's a miracle that anything can be actually built with this. #ifdefs, macros, some weird, never ending linking issues :scared:

What worries me about Rust when comparing it to Zig is that it's very expressive but probably too compilcated with some not ideal abstractions like Box, Cell, etc. Zig seems to be easier and easier always wins. Also Rust and C FFI integration is not ideal to put it mildly. Zig looks very promising but I don't think it will get the required momentum to be adopted for real (wonder if Rust will become mainstream too).

About moveable semantics - why do you think it's a biggest problem for you?

Post

0degree wrote: Fri Mar 19, 2021 10:40 am About moveable semantics - why do you think it's a biggest problem for you?
When working with intrusive data structures, usually you don't expect the objects to be moved. An in Rust it seems so easy to inadvertently move things - that's why they introduced the Pin feature, I guess. But Pin does only a small part of the job and lacks regularity, combined with or compared to other language features (I don't remember details anymore, as it was a couple of years ago, but IIRC one couldn't use Pin for local data, it lacked the same expressibility features that Box or Rc offered, there wasn't a way to require in a struct's API that methods must use pinned objects etc.)
0degree wrote: Fri Mar 19, 2021 10:40 am C++ is a monstrosity with traps set up everywhere for developers. From my POV the huge mistake of the language is existence of template metaprogramming. It's the biggest nightmare I saw in any programming language so far - almost non debuggable, crypting error messages and so on.
Rust already seems to me a similar monstrosity, except that this monstrosity is hidden and only becomes apparent once you try to do advanced and complicated stuff. The biggest monstrosity of C++ for me is not so much in the language itself, but rather in the UB polluting the entire language. I wonder how many C++ developers can really be sure that their code doesn't contain any UB (or how much time can be spent in certain situations to avoid hitting a UB case).

As for the template metaprogramming, I agree, it's a nightmare to debug, but actually I'm missing anything of similar power in Rust. I'd rather have it than not. Error messages depend on the compiler and become better.

Post

Z1202 wrote: Fri Mar 19, 2021 11:17 am When working with intrusive data structures, usually you don't expect the objects to be moved. An in Rust it seems so easy to inadvertently move things - that's why they introduced the Pin feature, I guess. But Pin does only a small part of the job and lacks regularity, combined with or compared to other language features (I don't remember details anymore, as it was a couple of years ago, but IIRC one couldn't use Pin for local data, it lacked the same expressibility features that Box or Rc offered, there wasn't a way to require in a struct's API that methods must use pinned objects etc.)
Maybe unsafe Rust would help here?
Z1202 wrote: As for the template metaprogramming, I agree, it's a nightmare to debug, but actually I'm missing anything of similar power in Rust. I'd rather have it than not. Error messages depend on the compiler and become better.
I heard the argument about better error messages something like 10 years ago :D
In Rust you can have macros which feel to me like a sane way to approach code generation. Macros can be expanded so at least you know what's happening there

But besides that I guess we'll have to wait and see which direction Rust will go. Recently they set up Rust foundation with the support of some big players: https://foundation.rust-lang.org/ so it seems like those companies are thinking seriously about the language.
To me Rust feels like a fresh air compared to c++, but maybe I haven't hit a big, hard wall yet :hihi:

Post

0degree wrote: Fri Mar 19, 2021 11:34 am Maybe unsafe Rust would help here?
Not sure how. Even if I managed to create my own, more powerful version of Pin, how can I require in the struct's API that "self" must be wrapped into a Pin or my version of Pin? The same problem existed for Box and Rc, and IIUC they "solved" it by providing embedded workarounds for those specific wrappers into the language. This, by itself is a sign for me that the language is not flexible enough, and instead of increasing the flexibility of the language they opted for implementing hard-coded workarounds into compiler.

Also, one big problem with unsafe for me is that the language doesn't have an official pointer aliasing model, so it's no clear what is "safe" and what isn't in an unsafe context (pun intended).
0degree wrote: Fri Mar 19, 2021 11:34 am I heard the argument about better error messages something like 10 years ago :D
In Rust you can have macros which feel to me like a sane way to approach code generation. Macros can be expanded so at least you know what's happening there
I played a bit with Rust macros and they seemed to me like a very different language, which is very limited and not easy to read either. Maybe the latter can be addressed by getting used to it, but I'm not sure about the limitations (I don't remember anymore which specific ones, don't ask me ;) ). I wasn't also sure if Rust macros can get anywhere close to replacing template metaprogramming of C++. Also Rust has its own template mechanism, besides macros, bringing up a question, when to use which feature.
0degree wrote: Fri Mar 19, 2021 11:34 am But besides that I guess we'll have to wait and see which direction Rust will go. Recently they set up Rust foundation with the support of some big players: https://foundation.rust-lang.org/ so it seems like those companies are thinking seriously about the language.
To me Rust feels like a fresh air compared to c++, but maybe I haven't hit a big, hard wall yet :hihi:
I guess on the level of detail where intrusive data structures are not needed, Rust could be okay. Difficult for me to judge, as I prefer intrusive data structures almost anytime over non-intrusive ones. Somehow the former are however out of focus of modern development, even C++ doesn't have them in STL, but at least allows a (relatively easy) implementation of those (some language limitations pop up with C++ as well in this case, though).

Post

Z1202 wrote: Fri Mar 19, 2021 11:54 am Also, one big problem with unsafe for me is that the language doesn't have an official pointer aliasing model, so it's no clear what is "safe" and what isn't in an unsafe context (pun intended).
That's true, but it's also worth noting that c++ is on the other side of the scale where the description of the language sounds like super heavy law document
Z1202 wrote: I guess on the level of detail where intrusive data structures are not needed, Rust could be okay. Difficult for me to judge, as I prefer intrusive data structures almost anytime over non-intrusive ones. Somehow the former are however out of focus of modern development, even C++ doesn't have them in STL, but at least allows a (relatively easy) implementation of those (some language limitations pop up with C++ as well in this case, though).
All fair points, but I think ultimately what will decide whether c++ will die or not is other languages adoption. There are billions of lines of code written in c++ and I can't imagine them rewritten any time soon :D
If I remember correctly D was an attempt to replace c++ and it failed miserably. It's also worth noting that Rust was recently accepted as alternative to C in linux kernel so who knows?

Post

0degree wrote: Fri Mar 19, 2021 12:24 pm
Z1202 wrote: Fri Mar 19, 2021 11:54 am Also, one big problem with unsafe for me is that the language doesn't have an official pointer aliasing model, so it's no clear what is "safe" and what isn't in an unsafe context (pun intended).
That's true, but it's also worth noting that c++ is on the other side of the scale where the description of the language sounds like super heavy law document
True, but can you bet that when the de-facto state of Rust is properly documented it won't be a similar kind of document? ;)
0degree wrote: Fri Mar 19, 2021 12:24 pm
Z1202 wrote: I guess on the level of detail where intrusive data structures are not needed, Rust could be okay. Difficult for me to judge, as I prefer intrusive data structures almost anytime over non-intrusive ones. Somehow the former are however out of focus of modern development, even C++ doesn't have them in STL, but at least allows a (relatively easy) implementation of those (some language limitations pop up with C++ as well in this case, though).
All fair points, but I think ultimately what will decide whether c++ will die or not is other languages adoption. There are billions of lines of code written in c++ and I can't imagine them rewritten any time soon :D
If I remember correctly D was an attempt to replace c++ and it failed miserably. It's also worth noting that Rust was recently accepted as alternative to C in linux kernel so who knows?
That's what surprises me a lot. If there was one area of programming where I'd expect intrusive data structures to be heavily (if not exclusively) used, it is kernel development. Maybe, if I find time, I'd take a look at what kind of Rust code is that.

Post

Z1202 wrote: True, but can you bet that when the de-facto state of Rust is properly documented it won't be a similar kind of document? ;)
Of course! Given that c++ is used in aviation, automotive industry it's not a surprise
Z1202 wrote: That's what surprises me a lot. If there was one area of programming where I'd expect intrusive data structures to be heavily (if not exclusively) used, it is kernel development. Maybe, if I find time, I'd take a look at what kind of Rust code is that.
I found this https://github.com/Amanieu/intrusive-rs so maybe it's a good starting point. But still it sounds like a pain to use with Rust.

I think what really annoys me about c++ these days is cryptic syntax, template horror programming, still have to use headers (I know modules are comming, but something tells me it won't be pretty...) and getting a new dependency is always a pain. Build from source? Use library? Will it run on MinGW? Will it link? And if not how many hours will I have to spend juggling linked dependencies until cmake and linker are happy :dog:
So basically tooling from 1980s
Compare this to Rust - add dependecy, compile, run - done :D

Post Reply

Return to “DSP and Plugin Development”