Live data from Hacker News

Cooperative C++ Evolution – Toward a TypeScript for C++

herbsutter.com

71–80 of 209 posts

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#71
post #3

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.

Yeah, the whole article rests on this premise, but does not explain it. I guess that's behind the "timewall" of the talk?

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#72
post #7

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.

> Google never approves Rust for internal usage.

deeply incorrect.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#73

Earlier 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.

As far as I recall, all compiled languages use untyped target languages. The only downside with TS/JS is that the JS implementation loses an optimization opportunity by not being aware of the TS-checked types.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#75
post #3

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.

> Both plans have value, but they have different priorities and therefore choose different constraints… most of all, they either embrace up-front the design constraint of perfect C++ interop and ecosystem compatibility, or they forgo it (forever; as I argue in the talk, it can never be achieved retroactively, except by starting over, because it’s a fundamental up-front constraint).

> 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++

#76
post #74

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.

Yep. I don't believe it's mentioned in the linked article, but Herb has mentioned in other articles/talks that cppfront is intentionally named after / following the same model as C++, which originally had a C++ to C transpiler named cfront[0].

[0]: https://en.wikipedia.org/wiki/Cfront

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#78
post #67

The title gives too much credit to TypeScript, that in my experience has been a subpar experience working with types.

It's not about that, it's about the plan towards wide adoption. TypeScript's uncompromising embrace of existing JavaScript semantics, patterns, and quirks has been key to its growing popularity.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#79
post #64

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?

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…

I can't think of anyone besides Anders Hejlsberg that has a better track record with programming language innovation. At least 3 different languages that have all been commercially successful.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#80
post #55

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 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.

Post reply on HN