111–120 of 209 posts
I wish there was a clarification of the differences between the “Dart plan” and the “TypeScript plan”. If I had to guess I’d say the Dart approach is a whole new language that transpiles to C++ while the TypeScript plan is one that augments the current language with useful additions.
C+++
Earlier quoted context omitted.
The only problem is you run the risk of implementing a still developing standard that might be vastly different than the finalize version. You then have code and programmers trained in doing something the old "wrong" way. This happened in TypeScript when they added support for an early version of decorators and now the TC39 version (which is still only Stage 3) is just different enough to cause issues.
They have been labeled experimental the entire time and off by default. That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress. In Typescript if you aren’t opting into using decorators through a library that forces you to use them, they’re entirely avoidable (and some would argue, decorators make code worse and this failure to launch is a good thing)…
Earlier quoted context omitted.
No, it says "No one else has tried the TypeScript plan for C++ yet". Which is true; Carbon isn't a compiler/transpiler to C++, it's a whole new language, albeit one with strong C++ interop.
"Strong C++ interop" can also be achieved via libraries from an existing language, as with the Rust "crates" cxx, autocxx, crubit. So the jury is still out as to whether an entirely different language, namely Carbon, will be useful. OTOH, cppfront can be seamlessly transpiled to C++ on a file-by-file basis which can also be a desirable feature wrt. incremental adoption.
Earlier quoted context omitted.
The alternate approach is also popular because there is no success in the typescript model, as in critical deficiencies get unfixed for decades (with some of the same "not fun" challenges )
What hasn't gotten fixed in typescript for "decades"?
Wasn’t C++ the typescript for C ? The title strikes me as ironic that it’s talking about a typescript on top of a typescript.
The article claims nobody’s tried a language natively compatible with C++, but that’s the approach that Google’s Carbon is taking: https://github.com/carbon-language/carbon-lang
Google claims that Carbon is the future internally at Google for a safer C++, and Google never approves Rust for internal usage. Then I see multiple public announcements of Google rewriting something in Rust (such as the recent Binder rewrite). I'm quite confused.
Android, ChromeOS and Fuschia already use Rust, and Chrome is in the process of getting the first Rust libraries integrated.
Earlier quoted context omitted.
C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient. Are you aware of any systematic review that shows evidence that C++ is safer than C? The rate of safety defects between major C and C++ projects appears similar at first glance, and…
> The rate of safety defects between major C and C++ projects appears similar at first glance How come? Surely there would be fewer memory leaks in a code base with proper RAII than in C code with malloc and free all over the place.
Linux kernel (C): https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
Chrome (C++): https://www.cvedetails.com/product/15031/Google-Chrome.html?...
There’s some variability year over year, but if anything C appears to have a slight advantage over C++ in terms of memory corruption (840 vs 1004), with essentially the same number of overflow errors (322 vs 328). There is no comparable rust project, but initial evidence from the asahi gpu drivers hints that memory corruption errors are fundamentally eliminated.
This is obviously not accounting for confounding factors, hence my request for any peer reviewed evidence for the security claim. Until then, the facts don’t seem to be supporting it.
Earlier quoted context omitted.
They have been labeled experimental the entire time and off by default. That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress. In Typescript if you aren’t opting into using decorators through a library that forces you to use them, they’re entirely avoidable (and some would argue, decorators make code worse and this failure to launch is a good thing)…
Why did you mention enum? Is it designed badly?
1. Enums are one of the few TypeScript features that isn't a type annotation that can simply be erased. Enums emit code and don't have an equivalent JS feature.
2. Const enums are unsupported by some bundlers/build tools, and so people try to use them and then got burned at build time.
3. The use cases covered by enums are often better served by union types.
None of the above is necessarily fatal for the feature. Certainly people used to enums in other languages still like them. But all 3 combined and the general recommendation these days ends up being just don't use them.
I'm heartened by the success of the Typescript model of improving things when there's a deficiency/problem. The alternate approach (which is extremely popular unfortunately), is to throw it all out and rebuild everything from scratch. I guess it's fun and exciting, which attracts developers, but it takes a long time to achieve any level of maturity and are hard to sustain (the people who are in it for the fun and exc…
The TS approach is really dumb for C++ and completely unnecessary. Compile times are long enough as it is without another meta compiler on top. You already have a compiler. Just make it emit binary-compatible code for the new dialect. You have modules now so you don't have the problem of supporting mixed-dialect headers.