Yeah, EA open sourced their STL, although now that C++23 is supported (aside from on MSVC? Still not flat_map there?!?) there is some replication in the STL.
Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.
We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons.
That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.
It depends what you want to get out of it, and what you think art itself really is.
If it's nothing but an end product, that needs to fit a specific aesthetic, with a specific sound, then I probably agree. AI is making that "pointless" in a way.
Almost everyone I know who's been an artist for years though, has come to a similar realization: What you set out to create, and what it turns into through the process of creating it are different things. The meaning, truly is found along the way.
You can always be better, there's always more to learn. Nothing is ever truly perfect, or "complete"
If you write harmony, there's always a different way it could be written, that might fit better, or be more interesting. If you do sound design, whether that's with getting different guitar tones, synth programming, unique recording techniques, there's always more to learn, or a different way to approach it.
If the only point is an end result, then AI can deliver a simulacra of that.
For everyone I know that loves music, or working with DAWs, the end result is an ever shifting target as you learn more, and understand music in a different way.
Ultimately, there are no shortcuts to making something new, because the practice of trying to make things is what results in what your art becomes. Tools and technology can shape what that thing ends up being, but they (traditionally) don't replace the process of creating it, and the feedback loop between who you are and the decisions you make along the way.
Stripping all of that out, and jumping to a "finished" product, is, well very product focused, but to me completely devoid of art or musicianship.
Some people seem to compare this to sampling, but anyone who's ever actually worked with sampling in a creative way will realize how hollow that comparison is. Almost all good sampling still requires a good deal of active feedback, between the person working with it and the way THEY hear what's going on.
Remove the person from that loop, replace the decisions with a general vague notion, and you end up with something that sounds "like" music, but that feedback loop is broken.
I see the same thing with all the AI UI design that's coming out. It's all generally quite competent, and exactly the same. Great for a business tool, where maybe the velocity and an acceptable MVP is the only point, but terrible for actual design and novel thought.
TL;dr: Why do it? Because you want to, and you think that with enough time engaging with something you'll change, just as it does, and the result isn't something you could have ever predicted when you started. It changes you, and that's the point. Just like learning an instrument, or learning to code. It's not purely about the produced result, and that very result fundamentally is changed by you actively engaging with whatever the medium is.
This works for simple apps, utilities, and demos/mvps. Not great for actual applications.
What about when you're embedding your GUI into an existing application? or for use on an already taxed system? (Audio plugins come to mind)
What if something is costly, that you need to compute dynamically, but not often, makes it into the frame? Do you separately now create a state flag for that one render object?
I can definitely say I wouldn't know half of what I do and probably wouldn't have kept at it with writing GLSL and learning more about how GPUs really work without a lot of his freely shared knowledge over the years.
His articles on his website are very much worth a deep read too!
Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.