I've been a professional programmer for ~20 years and worked in a variety of languages on a variety of different types of projects, and Typescript with Bun is mostly just fine. It lacks some low level primitives I'd like to have available for certain projects (e.g. Go channels), and the FFI interface isn't as nice as I'd like, but it's basically serviceable for for a very broad range of problems.
You should still know a language like Rust or Zig for systems work, and if you want to work in ML or data management you probably can't escape Python, but Typescript with Bun provides a really compelling development experience for most stuff outside that.
I agree, nowadays working on mostly TS backend with some parts in JS written before async/await was introduced and I’m inclined to say TS is better than Python at most things bakcendy. I’m missing sqlalchemy and a sane numerical tower pretty much.
Python suffers from the same problems: its type system has many escapes and implicit conversions, making soundness opt-in and impossible to statically verify. Any language with an implicit cast from its bottom type to an upper type is unsuitable for use.
It reminds me of an older dev I met when I was just beginning who had worked even more years and said Fortran 95 was "fine". And he could use it to build pretty much anything. That doesn't mean that more powerful language features couldn't have increased his productivity (if he learned them).
There's something to be said for using the right tool for the job. There's also something to be said for maximizing your ability to hire developers. Software is a game of tradeoffs, and while I can and do still pick up modern hotness when warranted (e.g. Zig), sometimes the path to minimum total software cost (and thus maximum company value) is to take well trodden paths.
As fun side anecdote, if you're doing scientific computing in a variety of fields, Fortran 95 is mostly still fine ;)
No, it’s footgunny and riddled with bugs. Most JS barely works and edge cases just aren’t addressed.
I’ve seen undefined make it all the way to the backend and get persisted in the DB. As a string.
JS as a language just isn’t robust enough and it requires a level of defensive programming that’s inconvenient at best and a productivity sink at worst. Much like C++, it’s doable, but things are bound to slip through the cracks. I would actually say overall C++ is much more reasonable.
You really need to learn a language to use it. As for undefined vs null, I fine it useful. Particularly in a db setting. Was the returned value null? You know because the value is null. Did you actually load it from the database? sure, because the value is not undefined.
> 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?
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.
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.
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.
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.
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.
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.
> 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.
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.
