2 ms·

Frankly, I've had to maintain a huge C++-only codebase, and that's why I hope to never write another app in C++. Yours is an argument for a high-level, typesaf

Frankly, I've had to maintain a huge C++-only codebase, and that's why I hope to never write another app in C++. Yours is an argument for a high-level, typesafe, compiled-to-native and compiled-to-javascript language. But IMO the argument falls down when applied to C++, because it is not high-level, it is only marginally typesafe, and it doesn't compile to javascript well at all (tradeoff of either massive performance, or missing basic functionality like 64 bit ints). It is very possible that no language will fit this role exactly for some time to come. But, to me at least, it is very clear that C++ is NOT the language for the job.

flohofwoe 13y ago
Yes I see your point to a degree, in a way we're working in a sort of "highlevel C++" most of the time at some performance cost: We have strict coding conventions in place which forbid low-level C/C++ stuff in high-level code (no raw pointers, no C-style arrays, no pointer arithmetics, no C library functions, etc...). Plus static code analysis and tons of runtime asserts. I can't remember the last time we had a buffer overflow or pointer-gone-wild. The performance hit of C++ compiled to JS is surprisingly small (1.5x native performance in Firefox, a bit slower in Chrome, but the gap is getting smaller, this is in the same ballpark as strongly typed bytecode languages like C# or Java).