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.
Cooperative C++ Evolution – Toward a TypeScript for C++
71–80 of 209 posts
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#72The 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.
deeply incorrect.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#73Earlier quoted context omitted.
Why is TypeScript a "bad web technology"? It's not really a "web technology" at all. It's a language which transpiles to standard JavaScript. The only real web-geared parts of TypeScript are the included (optional) DOM typings.
Type annotations for dynamically-typed languages is just a bad idea. JavaScript's only reason for existence is web browsers. If you're not doing web stuff do yourself a favour and use something else.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#74The title strikes me as ironic that it’s talking about a typescript on top of a typescript.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#75I 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.
> cppfront is on the TypeScript plan:
> full seamless interop compatibility with ISO Standard C++ code and libraries without any wrapping/thunking/marshaling,
> full ecosystem compatibility with all of today’s C++ compilers, IDEs, build systems, and tooling, and
> full standards evolution support with ISO C++, including not creating incompatible features (e.g., a different concepts feature than C++20’s, a different modules system than C++20’s) and bringing all major new pieces to today’s ISO C++ evolution as also incremental proposals for today’s C++.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#76Wasn’t C++ the typescript for C ? The title strikes me as ironic that it’s talking about a typescript on top of a typescript.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#77Wasn’t C++ the typescript for C ? The title strikes me as ironic that it’s talking about a typescript on top of a typescript.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#78The title gives too much credit to TypeScript, that in my experience has been a subpar experience working with types.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#79The 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?
Dart was made by Google as a new language for the web. In the beginning, it was already quite different from JavaScript at the time, and crucially the main way to use it is through the Dart VM (that was embedded into a build of Chromium). It did have compilation to JS, but AFAIK never caught on. In the end, Dart diverges from JS so much so that the split in ecosystem means it's not viable for the web anymore. TypeScr…
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#80I'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…
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.