Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

herbsutter.com

Post reply on HN
Print view View original

171–180 of 209 posts

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

#171

Post by wsve »

IAmLiterallyAB wrote: post #120
mike_hock wrote: post #107

Earlier quoted context omitted.

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.

The TS approach isn't about having a meta compiler. cppfront is just a temporary stepping stone, just like cfront (the original C++ compiler) was a temporary frontend for C++. Eventually the goal would be to add support for the new syntax to GCC, Clang, MSVC

Not just that, but a big part of Herbs feature set are things that can work as proof of concepts and proof of usefulness that could be presented to the C++ committee as actual features that can be added to C++. Many of the features of cppfront have already been proposed to committee.

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

#173

Post by chandlerc1024 »

nemetroid wrote: post #38
surfmike wrote: 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

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 > "Typescrip…

FWIW, I disagree about Carbon following the Dart plan (Carbon lead here).

Carbon is following a plan much more analogous to Kotlin -- we even say that on our site very explicitly.

The "subset" of C++ APIs you emphasize is only about there existing some long-tail esoteric parts of C++ that may be used rarely enough to not worry about. Everything that people use we'll need to support here. We think about interop constantly and are designing it into every aspect of the language.

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

#175

Post by nemetroid »

chandlerc1024 wrote: post #173
nemetroid wrote: post #38

Earlier quoted context omitted.

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 > "Typescrip…

FWIW, I disagree about Carbon following the Dart plan (Carbon lead here). Carbon is following a plan much more analogous to Kotlin -- we even say that on our site very explicitly. The "subset" of C++ APIs you emphasize is only about there existing some long-tail esoteric parts of C++ that may be used rarely enough to not worry about. Everything that people use we'll need to support here. We think about interop consta…

Sure, there might be other interop stories that are a better fit, and Dart is a pretty unflattering comparison (perhaps chosen intentionally). But within Herb's dichotomy, I think Carbon falls into the "Dart" category, since the "Typescript" category is rather narrow.

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

#176

Post by pjmlp »

SkiFire13 wrote: post #166
chlorion wrote: post #146

Earlier quoted context omitted.

C++ containers such as std::vector and std::array have bounds checking at least, though I have not saw them used very much. Bounds checking instantly eliminates buffer overflow related unsafety, but not having it as the default is not good.

They have bound checking through the `vec.at(index)` method, not through the indexing operator `vec[index]`. Most people won't even look at the `at` method, they will just use the indexing operator since that's supposed to be the "default" .

While true, most compilers do enable bounds checking in debug releases, and there are compiler flags to keep those checks enabled in release builds.

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

#177

Post by leptons »

csjh wrote: post #149
leptons wrote: post #96

Earlier quoted context omitted.

>The only things people don't like about it is that you need some tooling and a build step. Wrong. Many people dislike many things about Typescript. https://levelup.gitconnected.com/the-inevitable-decline-of-t... https://medium.com/codex/why-are-javascript-pros-saying-good... https://gomakethings.com/ditching-typescript-for-javascript/ https://www.reddit.com/r/sveltejs/comments/12cyady/are_you_l... There are plenty m…

Claiming "many people" and proceeding to link to 4 posts that use Svelte as an example is a bit silly considering Rich Harris has said, numerous times, that the decision in Svelte's codebase should NOT be taken as advice for what to do in your codebase, because their decision only pertains to a very specific set of circumstances.

I was countering the previous comments assertion that "the only reason" people don't like typescript was because it has a build step, and your comment doesn't prove me wrong.

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

#178

Post by zozbot234 »

tialaramex wrote: post #167
esrauch wrote: post #158

Earlier quoted context omitted.

I think the reality is that companies like Microsoft, Google, Apple want to write C++ but safer. The reason you're seeing Herb and Google's Carbon on the "ok fine well make a new language which has C++ interop instead of fixing C++" is because the C++ standards have been resistant to evolving the language into something that those companies want, to the degree that they may end up adopting Rust despite the absurdly h…

Carbon's initial announcement was vague about how safety would be achieved. The late 2023 talks are clear that (a) It will be bolted on afterwards rather than foundational, which should be a major red flag and (b) It will not include some key things which Rust makes safe because they can't see how to do that at all in their design. Herb's Cpp2 announcement on the other hand was clear from the outset that Cpp2 is not…

> It will not include some key things which Rust makes safe because they can't see how to do that at all in their design.

To be fair, Rust does have an unsafe superset and the interaction between "safe" Rust and unsafe code is quite non-trivial. It's not safe to call any part of safe Rust from an unsafe context unless the extra preconditions that safe Rust expects (as documented in the 'Rustonomicon') are proven to hold. This means that, e.g. much of the Rust stdlib and 'core' code might not be practically usable from unsafe code written in either Unsafe Rust or C/C++, whereas the idiomatic C++ counterpart might be. There is some effort underway to fix this where it matters, but these are not easy questions to address.

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

#179

Post by Aeolos »

SubjectToChange wrote: post #165
Aeolos wrote: post #118

Earlier quoted context omitted.

Yes, this is a common theory, but I don’t see evidence for it in the hard numbers. Taking two of the most popular projects in each language, with a comparable LOC count, the numbers look surprisingly similar year over year: 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 y…

Chrome is a vastly more complicated program than Linux.

That is very debatable.

Linux compiles and runs on many more architectures and hardware configurations than chrome, and it supports a frankly ridiculous number of peripherals up to and including the most complicated gpu accelerators ever made.

Chrome is indeed complex, but on what do you base your “vastly more” assertion?

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

#180

Post by Aeolos »

vanviegen wrote: post #162
Aeolos wrote: post #118

Earlier quoted context omitted.

Yes, this is a common theory, but I don’t see evidence for it in the hard numbers. Taking two of the most popular projects in each language, with a comparable LOC count, the numbers look surprisingly similar year over year: 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 y…

Are you seriously putting the Linux kernel forward as a typical C code base? Isn't that a bit like selecting the example of an F1 car to show that cars are usually at least as fast as motor cycles?

Neither Chrome nor Linux are “typical” programs for their respective languages, but they are real examples used by hundreds of millions of people.

Feel free to provide evidence for other cross-comparable c & c++ codebases if you have.

Post reply on HN