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

181–190 of 209 posts

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

#181

Post by chandlerc1024 »

nemetroid wrote: post #175
chandlerc1024 wrote: post #173

Earlier quoted context omitted.

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.

If you're going to create a dichotomy between two languages, I think we're dramatically closer to TypeScript.

The whole point of Carbon is to integrate into and re-use an existing ecosystem of software written in C++. It's as far from the Dart approach as it can get without literally being a TypeScript style approach.

Ultimately, this dichotomy doesn't help discuss Carbon. I think it is useful for looking at Rust (until/unless Crubit or something similar radically changes its interop story), Go, and many other languages. But not Carbon IMO. It loses all of the important nuance. And there are important and meaningful differences from TypeScript's approach that we've talked about since announcing Carbon, but they don't make it anything like Dart's strategy.

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

#182

Post by mike_hock »

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

GCC and Clang are open source, though, and Clang has a sane codebase, so why not implement it in an experimental fork of Clang?

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

#183

Post by cylinder714 »

dazzawazza wrote: post #41
mgaunard wrote: post #16

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

I sort of agree: As a C++ developer I have no idea what TypeScript or Dart really are... but it's Herb Sutter so I'll give him my time. He's surely earned that at the very least?

Definitely watch his video, linked in the OP. All is explained.

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

#184

Post by cylinder714 »

rewmie wrote: post #5

I understand that being a Microsoft employee there's always am incentive to promote Microsoft initiatives, but I feel that it's disingenuous to describe this sort of initiative in C++ circles as "TypeScript for C++" when C++ originated from "C with classes", which is the same transpiling-based approach but without Microsoft marketing attached to it. Also, I think that promoting a new programming language as "TypeScri…

If you watch the video linked in the OP, his reasoning for calling it that becomes clear. It's not a case of "promoting Microsoft initiatives."

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

#185

Post by mgaunard »

tentacleuno wrote: post #132
mgaunard wrote: post #42

Earlier quoted context omitted.

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.

> Type annotations for dynamically-typed languages is just a bad idea. Yet, as with the parent comment, you haven't divulged your reasoning behind this statement. If you're going to make such a broad statement, at least place your rationale beside it. > JavaScript's only reason for existence is web browsers. JavaScript has seen broad adoption throughout the industry, for servers (Node.js, Deno, Bun), IoT (DeviceScrip…

It breaks the whole point of typing being dynamic to begin with.

You don't build static typing on top of dynamic typing; it's silly. You do it the other way around.

If you're going to be outside of the browser, just use Python, which is not only somewhat similar but also the world's most popular programming language.

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

#186

Post by nindalf »

Aeolos wrote: post #180
vanviegen wrote: post #162

Earlier quoted context omitted.

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.

Picking Chrome and Linux as examples is good for a couple of reasons. No one will complain that the codebases are small or were written by “bad” programmers who didn’t take enough care to write good code.

Because that’s the only thing holding back some languages right? If only the programmers using them would get good, use static analysis tools then bugs would be eliminated.

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

#187

Post by tialaramex »

wsve wrote: post #171
IAmLiterallyAB wrote: post #120

Earlier quoted context omitted.

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.

This was dead when I saw it, which is weird because it's factually true. So I vouched for it.

Herb Sutter proposes a bunch of stuff to WG21 (the C++ committee) and most of it goes nowhere. We're not talking about two proposals here, maybe a dozen is closer. Most of that stuff from many years is in Cpp2 because it's Herb's language so they can't stop him.

The one thing Herb proposed in that time which got into C++ was the spaceship operator which is basically like Rust's PartialOrd trait, you write one operator for your type, and for any pair of values (this & that) you decide whether this was Greater, Equal or Less than that -- or none of the above. As a result the compiler can implement all the obvious comparison operators like using that one piece of code you wrote, and it's easily able to be consistent. This is very nice, and it's in C++ today, but it's also in Cpp2 of course.

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

#188

Post by raydev »

mike_hock wrote: post #182
IAmLiterallyAB wrote: post #120

Earlier quoted context omitted.

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

GCC and Clang are open source, though, and Clang has a sane codebase, so why not implement it in an experimental fork of Clang?

I think you're underestimating the amount of work it takes to maintain a fork vs a separate transpiler layer.

Why waste time on forking clang when you can both hash out your language design and have a highly functional prototype right away?

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

#189

Post by tialaramex »

jandrewrogers wrote: post #151
Aeolos wrote: post #100

Earlier quoted context omitted.

C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient. Are you aware of any systematic review that shows evidence that C++ is safer than C? The rate of safety defects between major C and C++ projects appears similar at first glance, and…

I have written a lot of the same kinds of data infrastructure software in both C and C++ and other languages, so comparison is somewhat reasonable (unlike comparing e.g. web browsers and systems software). The rate of defects is much lower in modern C++ versus C, and the types of bugs have changed too, but only part of that can be attributed to safer constructs in C++. C requires many times more lines of code than C+…

> C++20 is remarkably safe and concise if you take full advantage of the type system.

Against what sort of laughably low bar are you measuring to make C++ "remarkably" safe ?

This is a language which delights in deliberately adding more footguns, on the rationale that well, it's less safe so surely it'll be faster right? No need to measure, no need to investigate what actual performance optimisations might somehow be available if we allowed the dangerous behaviour, no, just mandate it and YOLO.

C++ 20 introduces std::span. Now, std::span is basically a slice type, Rust's [T], and to some extent it's remarkable that C++ didn't have a slice type, but that's C++ for you. What's fascinating is that in 2020 I remind you they standardized a type which deliberately has no safe way to use it. It was proposed as a safe type, and WG21 stripped out the safety on the rationale that now it's faster (see above) then rejected all attempts to add the usual half-arsed C++ safety features to the type now that it wasn't safe by default.

Let me quote a C++ proposal paper (this isn't some hit piece from Rust fanatics, it's a serious proposal to the ISO working group) P2821 on std::span:

"Ultimately, this becomes a stereotypical example of how C++ traditionally handles safety. this example gets to be pointed at for years/decades to come. All of this could have been avoided"

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

#190

Post by tialaramex »

pjmlp wrote: post #176
SkiFire13 wrote: post #166

Earlier quoted context omitted.

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.

This is differently bad because it may mean tight loops are enormously slower under debug for no good reason, it's an adverse consequence of the C++ "wrong defaults" problem. Because they're defaults, we can't detect whether they're what was specifically needed or just nobody cared, so we guess nobody cared and act accordingly.
Post reply on HN