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

[Z1202]

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.

IIRC I was using exactly this as a hint source when trying to do my own intrusive lists.

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.

Rust modules is one thing which I unquestionably liked. Cryptic syntax - are you telling me that Rust macros are less cryptic? Or, for that matter, complex lifetime specs (I know, one needs to get used to that, but the same argument can be held for the "cryptic syntax" of C++ )

[0degree]

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.

IIRC I was using exactly this as a hint source when trying to do my own intrusive lists.

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.

Rust modules is one thing which I unquestionably liked. Cryptic syntax - are you telling me that Rust macros are less cryptic? Or, for that matter, complex lifetime specs (I know, one needs to get used to that, but the same argument can be held for the "cryptic syntax" of C++ )

Again fair points. I don't think Rust macros have bad syntax, I prefer them to template metaprogramming because I can actually see them expanded. But yeah, lifetime specs complicate things because it's yet another thing to look at and understand.
I'll spend more time with Rust in context of VST plugs and see where can I get

[Z1202]

I don't think Rust macros have bad syntax, I prefer them to template metaprogramming because I can actually see them expanded.

So, once C++ templates get expanded (which wouldn't surprise me, considering the direction in which C++ tools are moving), would that make C++ immediately look way better in your opinion?

[0degree]

I don't think Rust macros have bad syntax, I prefer them to template metaprogramming because I can actually see them expanded.

So, once C++ templates get expanded (which wouldn't surprise me, considering the direction in which C++ tools are moving), would that make C++ immediately look way better in your opinion?

Haha, never said C++ is not an option, it's just a more painful one so far. But of course given market adoption and huge existing codebases C++ seems like a better idea.
Btw. - what kind of instrusive structures you'd like to use in DSP context?

[Z1202]

Haha, never said C++ is not an option, it's just a more painful one so far. But of course given market adoption and huge existing codebases C++ seems like a better idea.
Btw. - what kind of instrusive structures you'd like to use in DSP context?

I prefer to use them in any context (other things being equal, they are just simpler to use, IMHO), but immediate RT candidates would be voice management and event queues.

[0degree]

Haha, never said C++ is not an option, it's just a more painful one so far. But of course given market adoption and huge existing codebases C++ seems like a better idea.
Btw. - what kind of instrusive structures you'd like to use in DSP context?

I prefer to use them in any context (other things being equal, they are just simpler to use, IMHO), but immediate RT candidates would be voice management and event queues.

[mystran]

I don't think Rust macros have bad syntax, I prefer them to template metaprogramming because I can actually see them expanded.

So, once C++ templates get expanded (which wouldn't surprise me, considering the direction in which C++ tools are moving), would that make C++ immediately look way better in your opinion?

Haha, never said C++ is not an option, it's just a more painful one so far.

For what it's worth, I tend to write most of my code (audio or not) in C++ because I find that more often than not it's actually the least painful option. There are a few things I don't like about C++ (too much UB being one of them), but for the most part I don't think anything else is really even a serious contender.

ps. For small things a language like Python can be nice too, but even then once such things grow past a certain point it's usually less painful to just convert the whole thing into C++ instead.

[rafa1981]

To me Rust feels like a fresh air compared to c++, but maybe I haven't hit a big, hard wall yet

Not a very high bar... Hell is Fresh air compared to C++.

To me they repeated the biggest mistake of C++. A big clever language that doesn’t easily fit on one’s head.

Rust augments (wrt to anything but C++) the cognitive load and forces some programming models to decrease one type of bugs, but there are no studies saying that by doing so the overall amount of bugs will be reduced. What matters is the total bug count, not only memory bugs.

It could pretty perfectly be that a language that catches 80% of those bugs but is extremely lightweight on dev mental resources ends up being safer overall.

[Z1202]

To me they repeated the biggest mistake of C++. A big clever language that doesn’t easily fit on one’s head.

FWIW, IMHO C++ could have fit into one's head if it wasn't for its irregularities and exceptions (such as UB). It is tempting to think of C++ as a high-level assembler (wasn't C initially intended to be like that?), in which case most of the features have easy intuitive understandings... Except that these understandings are no longer valid, thanks to the irregularities and UB.

[rafa1981]

There are hundreds of gotchas and conflicting features, for me it’s not about UB only. Lots of rules, lots of WTFs, especially on big codebases.

And you get hit by one gotcha, but at a low enough frequency to forget and do the same mistake again after 1 year. Lots of subtleties going on.

Example:
https://en.cppreference.com/w/cpp/langu ... resolution

[rafa1981]

The best viable funktion section is pure crazyness...

[0degree]

For what it's worth, I tend to write most of my code (audio or not) in C++ because I find that more often than not it's actually the least painful option. There are a few things I don't like about C++ (too much UB being one of them), but for the most part I don't think anything else is really even a serious contender.

That's why I recalled the failed coup attempt by D lang

To me they repeated the biggest mistake of C++. A big clever language that doesn’t easily fit on one’s head.

Hence I was referring to Zig because Rust has in fact a lot of accidental complexities (at least from my limited experience)

Rust augments (wrt to anything but C++) the cognitive load and forces some programming models to decrease one type of bugs, but there are no studies saying that by doing so the overall amount of bugs will be reduced. What matters is the total bug count, not only memory bugs.

There are also no studies stating the opposite. According to MS security team most of the security issues stem from buffers under/overflows. But maybe it's not a biggest issue in case of audio programming

FWIW, IMHO C++ could have fit into one's head if it wasn't for its irregularities and exceptions (such as UB). It is tempting to think of C++ as a high-level assembler (wasn't C initially intended to be like that?), in which case most of the features have easy intuitive understandings... Except that these understandings are no longer valid, thanks to the irregularities and UB.

But that's exactly the state of the c++, isn't it? Most c++ devs will tell you to not use exeptions (making STL unsuable), disable RTTI, UB here, UB there.
Add to it concepts, couroutines and 2000 pages of the language spec (or maybe even more these days?). Surely won't fit into one's hand or even dozen of them

[rafa1981]

There are also no studies stating the opposite. According to MS security team most of the security issues stem from buffers under/overflows. But maybe it's not a biggest issue in case of audio programming

Exactly, it was done to fix Mozilla’s problems. What is a borrow checker good for on the average non-modular audio plugin were mostly everything except the audio buffers can be statically allocated?

As there are no studies or enough evidence yet on what this brings, I’m not bullish on what Rust has to offer suits me.

On the other hand both Nim and Zig seem much more sound to me: a crazy fast compiled typed python that compiles to C (portable) (for replacing C++ for things like e.g. GUI) and an real update on old and trusty C. Both with a good FFI to C.

[0degree]

Agreed, that's why I'm not so sure Rust is the answer. But regarding Nim and Zig they feel so niche and fragment the market even more. But surely c++ needs some retirement

[Z1202]

FWIW, IMHO C++ could have fit into one's head if it wasn't for its irregularities and exceptions (such as UB). It is tempting to think of C++ as a high-level assembler (wasn't C initially intended to be like that?), in which case most of the features have easy intuitive understandings... Except that these understandings are no longer valid, thanks to the irregularities and UB.

But that's exactly the state of the c++, isn't it? Most c++ devs will tell you to not use exeptions (making STL unsuable), disable RTTI, UB here, UB there.
Add to it concepts, couroutines and 2000 pages of the language spec (or maybe even more these days?). Surely won't fit into one's hand or even dozen of them

I think a half if not more of these 2000 pages are due to irregularities and UB. So the language could still have been saved, if they are removed And then, what I'd expect from a language specified in a regular manner, is that I don't need to learn those remaining 1000 pages, because they are just formal expressions of what's intuitively clear anyway and fits into some 10-100 pages giving the main idea.
I've been playing around with concepts, they are a huge step forward in making metaprogramming way more accessible and getting intelligible error messages