This is, obviously, a very opinionated opinion.
If I was going to be forced to do it, this is how I'd want to do it.
I write software in probably a dozen languages, including C++, and using the features/STL in C++17/C++20 in no way makes using C++ a "pleasure", it simply makes using C++ "less painful".
If I want to present information processing applications to users, it's C#/Java (or Kotlin, or Scala, or F#) with some Typescript front-end and likely some form of SQL simply because those are the tools that enable me to accomplish the job the fastest with the highest quality. If I need software to work in or with embedded systems then I grab C simply because it's the tool that enables me to accomplish the job the fastest with the highest quality. If I need some software to bridge those two worlds then I reach for C++ because it's the only tool that efficiently bridges the gap.
And C++ sucks, even with C++17/C++20/STL because I can't tell from the STL documentation which pieces manage memory for me and which I have to remove on my own and when this memory management (sometimes) magically occurs. I know what it is with C, because it's all malloc()/free(), and I know what it is with JVM/C#, because it's managed for me, but with C++ it's an incomprehensible mess. Don't even get me started on the half-assed implementation of lambdas vs. function pointers vs. std::function and which can be used where and where the const/reference operators have to go.
I know C++ memory management like the back of my hand and much of the STL (with some C++17+ exceptions) by heart. But even though I’ve used both C# and Java in the past and could jump back in, my working knowledge of those languages right now is near zero.
Polyglots truly are jacks of all trades and masters of none.
Modern "pleasant" C++ is a subset of all of C++. In the realm of all C++, you can get into some REALLY bad code. That includes terse C.
I work in the NYC market, and have bounced between finance and tech. The quality of C++ at a tech company, even legacy code, is magnitudes better than the stuff in finance.
I’m lucky ;)
If you care about it, it can and will be done. Same, all warnings enabled, compiles and runs in both AMD and ARM processors, it is just 20 to 40 times faster than the thing it replaced, I really can't complain.
C++ gets underserved hate by people who don't care about doing a good job anyway.
C++ today is like Cobol in 2010. yes, there are reasons for them to exist, people tell your the good old days, probably some fresh good recent experience. but come on, there is a much better place for C++ -
Gaming has Unreal but surely you could use another game engine without C++?
For most software, the hardware has already run away to the point where you can just sort of tell the machine roughly what to do and it will do it for you in a way that doesn't affect your task, so you don't have to fiddle with minutiae like where exactly to place a thing in memory.
bumpalo doesn't cut it. Funny thing is that boring and sensible Go just came out with arenas support.
I use C and Rust for such serious stuff as I don't have free time to waste to just entertain those over designed concepts like OO or STL. you need to be honest - the stdlib of C++ is not on par with the ones in rust or golang. It is more like stone age tools compared with starlink.
I sincerely hope that all C++ users will be able to benefit from the networking addition to the C++ stdlib before their retirement - you know after 40 years waiting not all C++ developers had such pleasure.
that would the starlink whose performance slowly, inexorably degrades as more and more of my neighbors start to use it?
We release the same plugins on Windows, macOS and iOS so we get great coverage with compilers too. I should set up a build for Linux with gcc but haven’t had the time yet.
to give you some example - using the exact same toolchain on amd64/macos, I can build my golang code to run natively on risc-v/linux or arm64/windows. everything happens within seconds as I just need to override two environmental variables.
there is no "haven't had the time yet" problem in such modern languages. it is by design, in the very core of the language and its native toolchain.
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 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.
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.
I may have exaggerated with the “nearly every” sorry!
But we do use sufficiently enough tools to avoid most of the pain of c++