61–70 of 209 posts
The article assumes that the reader is familiar with what is meant by the “Dart plan” and the “TypeScript plan”. I only have cursory knowledge of Typescript and know nothing about Dart. Others in this thread already went into more details about this, but it doesn't help me much as long as I don't have an idea what the basic difference between both approaches is. Can someone ELI5 the gist of both approaches?
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 people who are in for the fun won't use the typescript model for long either. If it's optional it will be omitted in the hard parts, for instance if your favorite library doesn't support it.
Visceral disgust reaction.
The article assumes that the reader is familiar with what is meant by the “Dart plan” and the “TypeScript plan”. I only have cursory knowledge of Typescript and know nothing about Dart. Others in this thread already went into more details about this, but it doesn't help me much as long as I don't have an idea what the basic difference between both approaches is. Can someone ELI5 the gist of both approaches?
TypeScript, on the other hand, has always set its goal to be a superset of JS and to transpile to JS only. This means a more familiar syntax, as well as (practical, IMO) design choices that ensure higher compatibility with the existing JS ecosystem. There is no TypeScript without JavaScript. Its development coincided with that of VSCode, and arguably is one the main facilitators for the latter's feasibility.
I have to say Microsoft's grand plan of VSCode and TypeScript has to be one of the most astonishing software revolution in this decade. The foresight and acuity of Erich Gamma and Anders Hejlsberg is just amazing.
Earlier quoted context omitted.
The people who are in for the fun won't use the typescript model for long either. If it's optional it will be omitted in the hard parts, for instance if your favorite library doesn't support it.
That's why incremental adoptability is so powerful. Slightly ironically that's exactly what (AFAIK) made C++ so popular: You can start using it without really giving up anything. And ideally once you see the benefits you'll be hooked and want to (incrementally) use it more and more throughout your code.
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
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.
C++ only needs 4 things: gradually-introducable memory safety, static reflection, first-class compile time string manipulation, and adoption+refinement of its modules feature.
Now, how willing WG21 and the compiler vendors are open to the idea, is anyone's guess.
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
Earlier quoted context omitted.
The people who are in for the fun won't use the typescript model for long either. If it's optional it will be omitted in the hard parts, for instance if your favorite library doesn't support it.
It's still worthwhile even if you have to fudge module boundaries or skip the hard parts. Kind of like having "safe" Rust wrapping "unsafe" C boundaries doesn't make the rest of Rust not worth it. Lying about the type internals of your function is still preferable to the wild-wild west of JS.