Money is a completely abstract thing and at this point says nothing about the material economics. It’s used to manage agency.
Essentially we allowed people $11 billion in human agency to occur for scientific reasons.
Sorry we didn’t put more of it into cars and video games, but your economy surely benefited from people doing the real economic exchange this required.
Personally I’d love to put it into designer drugs we can use to let me hallucinate a reality where miserly bean countering control freaks don’t exist, since we’re all going to die anyway and entropy will erode the universe.
Excepting rules against violence and careless end of the species, why all the rules?
> Sorry we didn’t put more of it into cars and video games
But that's not the alternative here. Cars and video games are created via private investments, by for-profit corporations (and sometimes by volunteering developers). JWST was funded by NASA with public funding. The alternative to JWST was not cars, but rather the other projects that NASA could have funded, but didn't. When NASA made the initial decision to build the JWST, it excluded other projects on the premise that the JWST will cost about $0.5 BN. When later on NASA had to revise upward the cost, it had to either forgo other projects, or ask the Congress for additional funding. Well, the Congress did not provide additional funding [1]. Those with an internal view of NASA know what other projects were dismissed, or canceled because of the perpetual JWST cost revisions. We (the outsiders) will not be privy of these projects, but they certainly existed.
Make no mistake, I consider JWST to be a phenomenal scientific instrument. But when people applaud the launch of JWST, they don't see the non-launch of the multitude of projects that had to be canceled because of the JWST cost overruns.
I’m using it for the first time and have been wondering what all the horror stories are about.
But then realize those horror stories were from 15+ years ago.
Did we need Rust?
Or did we need to build out the C and C++ ecosystems to make them easy and safe?
How many hours spent on all these languages for a few folks to build fiefdoms upon? Every human endeavor has a group of swindlers that tell you they’re helping but in hindsight often looks like they just got in the way.
Under every modern, shiny, abstract, high-level feature of the language or the standard library there are layers and layers of legacy cruft. Every aspect the language has experimented with has to be supported by the new features, making simple things like the Variant type for example, very difficult to implement correctly [1].
C++ is nice and good until you hit a bug that leaks an abstraction and you realise you barely understand 10% of the language, and you'll never understand it completely, because people spend their entire careers trying to track down how language features interact and where they explode, and they're never finished.
Also, I'm fairly convinced that when they chose not to take Epochs for C++ 20 they sealed the long term fate of the language.
Epochs was the only halfway practical way to attempt the ever elusive step B of the "Smaller, better C++" idea, the part where you toss away all the stuff nobody needs. For many years now, the protestation has been that it's a great idea but first a few more things must be added. And then a few more. And a few more. Bjarne himself has a laundry list. Adding things to C++ is extremely ugly but it can be done and is still being done. However removing things is hard, and Epochs proposed a practical way to begin that work. It was shot down and I think years from now a C++ post mortem will pronounce that as at least contributing to the outcome if not outright the primary cause.
Epochs would have been really hard to do in C++ 20. But it isn't getting easier and the will to attempt such a thing seems to me to be finite.
Isn't that the poster-child of template metaprogramming? Being able to choose a different sub-byte layout for your container type depending on the type parameter? What problems are you running into when using std::vector<bool>?
Templating has nothing to do with my hate. It’s the fact that for all other vector types you can assume that index-based access only conflict for the same index. The only exception is…
Of course it’s unlikely for you to know this because who knows all the nuances of C++ so you end up with a race in your code. Those can be very hairy to crash, reproduce, and debug.
Surely shining light on and fixing those issues would have resulted in C/C++ essentially becoming what Rust hopes to be.
But western kids needed to found new big business and institutionalize math.
Seems the west has a real issue with oligarchs needing to manage the masses. No one can be rich unless an institution has decided they are correctly rich.
Multithreaded C++ programming without bugs is still very hard. There was an interview on Mozilla and why they started Rust and everytime they had some path in the code with threads, they found some concurrency issue. I can't find the link right now.
> Multithreaded C++ programming without bugs is still very hard.
Multithreaded programming without bugs is hard in any language, unless the language completely cripples your ability to do certain things that tend to be where the bugs can creep in.
If you religiously stick to the rules (e.g. mutexes around all variable use, mutexes and condition vars used correctly), you will not have bugs. The problems come because people do not religiously stick to the rules, because their language doesn't require them too.
The problem is that if you are forced to follow all the rules, then certain things become impossible, such as lock-free programming (even the simple single-reader, single-writer FIFO). The use of memory barriers to create provably safe lock-free code is outside the scope of regularized multithreaded programming, and since it's very very hard to get that write, but people want to try it anyway, that's where things go wrong.
Just use things the way you're supposed to and you won't have bugs with this.
> Just use things the way you're supposed to and you won't have bugs with this.
If we humans just learned to use things we're supposed to, we would never have null pointer exceptions, issues with use-after-free nor buffer overflows. Heck, we should all just use goto while we're at it, all it takes is to religiously stick to the rules!
Reasoning about null ptr, use after free, buffer overflows is tricky, because you cannot determine whether you've done the right thing by "just reading the code".
If you are doing multithreaded programming, and there's a variable shared among threads, and there's a read or write of the variable without a mutex in sight, you've done it wrong.
Yes, the mutex owner could be a caller several layers up the stack. Sometimes that's a legitimate design, and if you know what you're doing your function/method names will reflect the fact that the lock is already held. If you don't know what you're doing, you should avoid that design and lock the mutex in the same scope as the read/write.
And of course, using RAII with C++ (or anything else that supports it) makes this sort of thing easy to do.
Really? We did not need Rust? Here is what some of the best paid C++ Developers in the world come up with after billions of dollars invested in product development:
You do realize Chrome's code has a lineage that is over 24 year old, based on khtml.
If you are starting a project from scratch with C++, you can avoid a lot of the pitfalls chrome's team has. Additionally Google has an arguably poor C++ coding style that is also completely out of date.
A company that uses C++ more effectively is arguably Adobe, who has the great Sean Parent.
Uh, using Adobe as an argument in favour of C++ as a reliable programming language from a memory safety perspective is not a good argument. Just looking at the CVE count tells a story that cuts across their entire product line, and then we have the long and storied history of Flash and Acrobat vulnerabilities.
Any non-trivial code base in any language will have security issues, but the argument that these security vulnerabilities are a result of using C++ poorly doesn't change the fact that C and C++ have tons of footguns and pitfalls based on both modern and legacy code.
That's the problem with these languages (both C and C++) — it's always the user's fault. The language blows up if you accidentally miss one of the twelve thousand rules? User's fault, PEBCAK. If only the poster X was writing the software in question, these bugs never would have happened. I've seen this argument a million times.
One thing that is still horrific (imho) is unicode support. Last time I found that in order to print unicode strings with cross platform support on a simple way I required a boost library [1]. The dichotomy between standard and "wide" string APIs is kind of a mess.
Also, construction, destruction and move semantics makes everything really complicated and even simple baseline code requires a bunch of boilerplate [2].
Rust does much more to force you to be safe. (Or, to put it differently, C++ still has all the unsafe ways available, and not locked away behind the "unsafe" keyword.)
Note that the unsafe keyword of Rust unlock only few things. But that what makes it powerful.
unsafe mainly allows you to dereference pointers. References are guaranteed to be safe at all time, with an associated lifetime, while pointers can hold any possible memory address, valid or not (like in C++).
unsafe also let you promote a pointer to a reference by assigning a lifetime.
And finally, unsafe allows you to call functions themselves marked unsafe. One notable function is called transmute, and is very similar to how the the C style cast works in C++. It's the one that automatically selects between static_cast and reinterpret_cast depending on the context.
> Or did we need to build out the C and C++ ecosystems to make them easy and safe?
If so, the C++ committee wasn't interested in doing so. Preferring instead to say that new features don't have safety if there was any possibility that doing so might provide opportunity for improved performance.
Don't worry, when inevitably you blow your feet off with any of the new footguns provided, they'll be happy to tell you that it's your fault, a true C++ programmer would have known not to do that. "Git gud" as the gamers say.
Backward compatibility is valuable, but so is letting go of old habits. With C++ and Rust, we can have our cake and eat it too. Plus, arguments about which language is better! ;)
It is insanely complex. Yet modern C++ is easy to use. Just don try to be Alexandrescu. I am very far from being C++ expert yet I have zero problem using it to write stateful multithreaded business servers that run for month at a time (maybe able to run for longer but I update with new features more often).
The challenge with C++ is that unless you are writing something entirely from scratch with very few third party dependencies, it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++. I've worked on projects that have started out small as well as projects that have reached (and passed) the 10M LOC mark, and this is a recurring theme.
I've worked as a developer for about 35 years and I have yet to work on a C++ project where there isn't older code that has to be accommodated.
Being able to write code that doesn't crash after a while isn't really a high bar.
>"Being able to write code that doesn't crash after a while isn't really a high bar."
Totally agree.
>"it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++"
I do not work with the projects (I assume monoliths) of such size so I guess I can count myself lucky. I would guess though that this amount of code accumulates over many years and I suspect that the majority of languages along with libs and other accompanying stuff would change as well over the time. Maybe C++ is not so special in this regard.
I was hired once to fix old PHP application which was insanely giant. The type of code I saw there ranged from beautiful to making me nearly puke. It looks like the situation similar to what you've described but in completely different language. Again the cause here I think is total size, many developers coming and going and their qualifications.
Also for as long as I can remember (40 years) I've almost exclusively worked on creating new products from scratch. Again extremely lucky. For new projects I would definitely advocate C++. But if one wants to do it in Rust / (insert your own favorite) for example I have nothing against it. Seems like a matter of taste to me (assuming compile times are reasonable and do not impede workflow).
I would admit that I would never dare to write / mess with some code I see in system libraries or some other template heavy libraries. It can be extremely complex language wise. But I've already mentioned it in original post. Do not try to be Alexandrescu. Those are special people. And this is also special purpose type of code that is not needed for general application programming.
You make one very important point: code that accumulates over many years. Not least in libraries you depend on (which make up a significant part of a lot of non-trivial code).
This is is bad in every language as it often means you get code that was written for a different version of the language. But for C++ it is particularly bad because C++ has spent so many years not even getting the most basic things right.
And when I say basics, I mean things like a string type that people will consistently use.
I’ve been iterating and abstracting a project layout tool into just the right thing for about a decade.
It’s like remix and all those frontend bootstrap wizards/tools, but it bootstraps projects in any language with my preferences.
It prompts me to ask if it should fetch my favorite deps (Requests for Python, or my own go CLI builder since Cobra is to bloated and complex for my needs) depending on the language I’m using for the project. I don’t always need them but I can get them in place fast.
IMO using everyone else’s tools is boring. I don’t see a blacksmith getting tongs from another blacksmith. I can’t hope to be an expert if I just import experts code. Seeing something like bash and being expected to believe that means anything when I can just write my own; those old guys made syntax art which actually just made “computing” hard. That was job security as much as anything.
Too many people don’t realize listening to others tell you not to do X is just giving them a monopoly.
Essentially we allowed people $11 billion in human agency to occur for scientific reasons.
Sorry we didn’t put more of it into cars and video games, but your economy surely benefited from people doing the real economic exchange this required.
Personally I’d love to put it into designer drugs we can use to let me hallucinate a reality where miserly bean countering control freaks don’t exist, since we’re all going to die anyway and entropy will erode the universe.
Excepting rules against violence and careless end of the species, why all the rules?