I’m not a frontend guy but heard that typescript is already falling off and contentious at this point. Is it truly something that’s going to stay?
Typescript is only becoming more solidified each year.
Cooperative C++ Evolution – Toward a TypeScript for C++
31–40 of 209 posts
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#32The real Typescript for C++ is Circle.
Just like Typescript to JavaScript, the syntax is an evolution of what already exists, not a completely different syntax.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#33Neither TypeScript nor Dart are relevant technologies to people interested in C++. It's weird to refer to these arguably bad web technologies to market an unrelated initiative.
That seems like missing the point of the article. What I understand the author to mean with Dart plan vs Typescript plan is the way these languages approached evolution of the base language (JavaScript).
Dart aimed to replace JavaScript completely and isn’t very compatible with it, leading to issues like not being able to leverage the existing library ecosystem. While the Typescript approach enhances the base language instead of replacing it and is still compatible with existing libraries.
When looking at language adoption, the Typescript approach seems to have worked a lot better than the Dart approach. If it wasn’t for Flutter, Dart would probably be irrelevant by now and Typescript is now pretty much everywhere where JavaScript is.
Another successful-ish example of the Typescript plan is Kotlin, which was originally designed as an improved Java, fully compatible with the existing ecosystem.
So I can see where the author comes from when trying to do the same thing for C++.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#34The 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.
That is completely false, as it ignores Circle and Sean Baxter's efforts.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#35Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#36After the talk, the activity on it is nearly zero since then, in a world where ideas are cheap, show me the code, this does not seem promising to me.
On the other hand, carbon has been very actively developed since its announcement, which also claims to be a typescript-for-c++. Now it also wants to be a memory safe: https://www.youtube.com/watch?v=1ZTJ9omXOQ0
I'm forced to learn rust but I hope carbon will take off ASAP so I can be more productive and my (carbon) code can interface with c/c++ code easier than rust.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#37But C++ already is a typed language confusedsmiley
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#38The 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
The "Dart plan" vs "TypeScript plan" comparison is shown at 1:33:50 in the talk:
> "Dart plan" - Competitive/successor 10x improvement
> New creation
> Limited interop, relies on wrapping/marshaling/thunking...
> Competes with standard (e.g., different modules, different generic constraints)
> Evolves independently of standards committee - far fewer design constraints
> Needs to bootstrap a new ecosystem
> "Typescript plan" - Cooperative/compatible 10x improvement
> Every .js file is a valid .ts file, add 1 class and see benefit
> Lowers to standard .js, 100% seamless compat with all JS libraries
> Cooperates with the standards committee (ECMAScript)
> Brings evolution proposals to standards committee
> Leverages entire existing ecosystem - works with all JS implementations & tools
Carbon is an example of the "Dart plan". Some quotes from Carbon's "Interoperability philosophy and goals" page (my emphasis):
> The C++ interoperability layer of Carbon allows a subset of C++ APIs to be accessed from Carbon code, and similarly a subset of Carbon APIs to be accessed from C++ code.
> The result is that it will often be reasonable to directly expose a C++ data structure to Carbon without converting it to a "native" or "idiomatic" Carbon data structure. Although interfaces may differ, a trivial adapter wrapper should be sufficient.
> There should be support for most idiomatic usage of advanced C++ features. A few examples are templates, overload sets, attributes and ADL.
> Non-goals
> Never require bridge code
> Support for C++ exceptions without bridge code
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#39Earlier quoted context omitted.
The future of JavaScript is in the past. Get rid of all the stupid transpilers and frameworks and just use plain JavaScript in the browser.
Yeah once they implement the proposal to add types we will
The whole point of JavaScript is that it's dynamically-typed. If you want static typing just use C++ or any other established programming language.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#40C++ only needs 4 things: gradually-introducable memory safety, static reflection, first-class compile time string manipulation, and adoption+refinement of its modules feature.