first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already.
fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.
> You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
you also need to worry about which stdlib to use in C++ - too bad!
> SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
please stop such nonsense. AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
> the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process
why this is even related to the ongoing C++ discussion? once you have the package, you need to somehow distribute it, app store, http service, bittorrent you name it. but why it is even relate to any programming language since you brought it up here?
you can probably argue that golang's stw isn't going to help when building audio stuff, but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way by rust. audio plugin or not, I don't care, in the end it is just the same machine code.
> AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
Well that's nice. What about ARM SIMD? And the M2 variant? You're suggesting that every SIMD instruction set should be accessible via the same language-invariant syntax or else a language is just broken?
> but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way
the point is that it is NOT done by a legacy language known as C++, and it should not be done by the young languages that go by any other name, contrary to your claim that essentially everything should be a part of the language/compiler/toolchain itself.
first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already.
fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.