This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts.
JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement.
You've "seen null make it to the database," but haven't seen the exact same thing in C++? Worse, seen a corrupted heap?
In C++, there's only one null, nullptr. But most types can never be null. This is actually one area where C++ was ahead of the competition. C# and Java are just now undoing their "everything is nullable" mistakes. JS has that same mistake, but twice.
It's not about complexity, although that matters too. C++ is certainly more complex, I agree, but that doesn't make it a more footgunny language. It's far too easy to make mistakes in JS and propagate them out. It's slightly harder to make mistakes in C++, if you can believe it. From my experience.
> And here you demonstrate one of many problems - there's multiple null types
In JS, null and undefined are not meaningfully different unless you're checking for exactly one or the other. And there's little reason to do that. It has never come up for me that undefined made it through where null wouldn't have. But yes, you need to check if things are defined.
> In C++, there's only one null, nullptr. But most types can never be null
C++ absolutely has undefined, it just doesn't tell you about it. If I make a var with `int myVar;` it's undefined. There's no telling what it points to. But C++ will treat it as `int`. And it can be a lot worse. Vars can be memory represented as the wrong type. They can be truncated memory, dangling pointers, memory freed twice.
But with JS, if I access memory that wasn't explicitly set, it says "that's undefined." That's a good and explicit thing to tell me, and I can actually check for it. And the GC, obviously, avoids a whole class of cases where undefined would come up.
> This is actually one area where C++ was ahead of the competition
For the reasons above, I would say C++ is literally the worst option for null safety. Unless we define safety as "don't tell me this is undefined, even though it is."
> It's far too easy to make mistakes in JS and propagate them out
I'm just not sure why. I would say C++ has absolutely every footgun JS has and more.
Make std::string null. You can’t. Make std::vector null. You can’t. It’s one of the benefits of a value types.
That, alone, eliminates a whole class of bugs that’s JS has. Yes, there’s edge cases in C++ too. The edge cases are the common cases in JS in this regard and that’s why I class them differently. Really, every language can do everything, basically. But how easy is it, and how common is it?
Also, for the record, using an initialized variable will result in a warning or compilation error.
None of this is to say that C++ does not have other glaring problems that JS does not. But, in my experience, it’s slightly more difficult to create logic bugs in C++. I also have worked with PHP - similar situation to JS. Too footgunny that in practice the codebase is riddled with bugs that rarely manifest, but are there. Everything you do has, like, a dozen implications and edge cases you need to consider.
It's like people just talk in memes or something.
This is how a lot of discourse feels these days. People living in very different realities.
Though in this case, seeing the most complex C++ app they've built would illuminate what's going on in theirs.
Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just do whatever the fuck in JS. Bugs where always ephemeral. The behavior of the code was impossible to wrap your head around, and it seemed to change under your feet when you weren't looking.
Now, the backend was written in old C++. And yes, it was easier to understand. At least, I could click and go to definition. At least, I could see what was going in and out of functions. At least, I could read a function and have a decent understanding of what it should be doing, what the author's intention is.
The front end, spread across a good thousand JS files, was nothing of the sort. And it was certainly more buggy. Although, I will concede, bugs in C++ are usually more problematic. In JS usually it would just result in UI jankyness. But not always.
I think that’s a feature not a bug.
But then again, I generally like and use Typescript.
The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky.
At this particular codebase, it was not uncommon to see 3, 4 or 5 functions that do more or less the same thing. Why? Because nobody dared change the behavior of a function, even if it's buggy. Maybe those bugs are the only thing keeping other bugs from cropping up. It's like wack-a-mole. You fix something, and then the downstream effects are completely unpredictable.
It becomes a self-eating snake. Because the codebase is so poor, it ends up growing faster and faster as developers become more risk-averse.
