But C has way more "wat" in it than JS, in a sense. In JS when you make a wat you can generally debug it and fix it incredibly easily. In C when you wat, well, good luck.
A linter and Typescript and the fact that the "wat" stuff is actually almost always marginal and not commonly ran into in practice means you actually almost never are spending time on wat-ness at all in TS, where in C, a huge amount of time is spent there.
There's a vast gulf of productivity between TS and C (the former winning). TS is an incredibly smart choice for many things small and large. But yes, if you need a lot of low level hooks and incredible performance, don't use it.
Why not the best of both worlds? There are other compiled languages than C/C++. Many provide neatly the productivity of dynamic languages but with much better control. Rust & Nim both work well. Maybe Zig one day.
Rust is far slower as a developer to write (far more complex and verbose), Nim has orders of magnitude less ecosystem/docs/community (Rust has much less too), and both have far worse debugging tools, REPL, etc.
Valid points, and the REPL in JS/TS is handy. But it's worth pointing out that when/if a project outgrows JS, there are more options than just C/C++. The smaller community/ecosystem doesn't matter nearly as much in embedded, at least for libraries. I've found all the Nim libraries I've needed or wrapped C SDK ones, and the debugger is the standard C one. Rust is similar, and more productive than C for many people once you get familiar with it. Though yes, you've got to be willing to figure out things in both. Overall it's good to see more options.
I'd love for you to back that up with some kind of logic.
reply