[Capricorn2481]

> I would actually say overall C++ is much more reasonable.

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?

[const_cast]

I haven't seen null make it to the database, I've seen undefined. And here you demonstrate one of many problems - there's multiple null types!

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.

[Capricorn2481]

I am really trying to get on board, but I don't know what you mean. I see your anecdote about two different codebases and you found the C++ one easier, and I'm sure it happens.

> 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.

[const_cast]

C++ is at least somewhat strictly typed and - again - most types cannot be null.

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.

[neonsunset]

C# introduced nullable reference types back in 2019, so it's been some time and now the vast majority of the ecosystem uses null-aware code. The only remaining warts are around a. codebases which refuse to adopt this / opt out of it and b. serialization.

[hombre_fatal]

Yeah, I don't know how someone can say that with a straight face to other engineers.

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.

[const_cast]

It's not a different reality. To give perspective to what JS I've dealt with - I worked a couple years on a legacy webapp. It used vanilla JS and the only library used was jQuery. It heavily used iframes for async functionality in combination with XSLT to translate backend XML apis to HTML.

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.

[sroussey]

> You're allowed to just do whatever the fuck in JS.

I think that’s a feature not a bug.

But then again, I generally like and use Typescript.

[const_cast]

It's definitely a feature when you're starting out. But as the codebase grows and ages, it becomes a bug.

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.

[Capricorn2481]

> 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.

It's clear you've worked on a really bad codebase, but this is totally different from what you were originally suggesting, which was null being a bigger problem in JS than C++.

What you're describing is frontend development with JQuery, not the capabilities of JS. Now, I don't like NextJS for a lot of reasons, but code organization is not one of them. Everything you're complaining about is dead simple in NextJS. Functions are localized, tracking localized state is easy, and even the older React state libraries have lots of support for tracking and visualizing the more global state changes.

I will die on the hill that JQuery, outside of very small interactivity, is fucking bad. People use JQuery terribly and it creates spaghetti code where you can't tell what the execution path is. People don't document QA testing. And JQuery makes you target html attributes to make changes. That's fun if you have to do it once, it's terrible if all of your app interactivity relies on it.

But that's not due to "undefined", and it would be 100x worse in C++. I am assuming the C++ codebase you compared it to was not a DOM manipulating app?

I don't like NextJS for performance and market reasons, but the codebases I've worked on have been very clean.

[const_cast]

IMO jQuery is a symptom, not a cause. It’s the natural end-state of a stringly-typed “do whatever the fuck you want” attitude. You can create just as much spaghetti without jQuery, jQuery just lets you do it with less characters.

The horrors I’ve seen. Constructing a custom string based off of user input and then tacking on () and calling it as a function? We can do that? Apparently yes we can. The most cursed type of polymorphism where nothing makes sense and you’d have more success communing with the dead than deducing the control flow.