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

191–200 of 209 posts

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

#191

Post by tialaramex »

bananapub wrote: post #72
bdd8f1df777b wrote: post #69

Earlier quoted context omitted.

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.

Also you'd have to wonder what https://google.github.io/comprehensive-rust/ is for.

Like, if Google "never approves" why are they designing a course to teach this, and paying outsider trainers to teach their staff ?

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

#192

Post by tialaramex »

damagednoob wrote: post #79
magnio wrote: post #64

Earlier quoted context omitted.

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.

It's tricky to compare. Anders is involved in a bunch of important stuff, but it's not as though it's all successes either. He's certainly important, but I don't know how to compare "track records" on "innovation" because that's so vague.

One of his projects at Microsoft was J++ which is basically own-brand Java. Doubtless that's great material for learning to design C# but nobody is going to claim J++ was a success.

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

#193

Post by jandrewrogers »

tialaramex wrote: post #189
jandrewrogers wrote: post #151

Earlier quoted context omitted.

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…

You can replace almost everything in C++ with stricter implementations of your own design if you don't like the behaviors or guarantees of the standard/default implementation. Many people do because the language is very amenable to it and the codegen is usually optimal. Living entirely within the standard library and the constraints it imposes to support backward compatibility is a choice, not a requirement. The standard design is always going to be less than ideal for some subset of applications, it is an unavoidable tradeoff.

The metaprogramming facilities of C++ are strong enough now that there is little that can't be customized without macros in a way that is nearly transparent.

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

#194

Post by celrod »

jandrewrogers wrote: post #193
tialaramex wrote: post #189

Earlier quoted context omitted.

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

You can replace almost everything in C++ with stricter implementations of your own design if you don't like the behaviors or guarantees of the standard/default implementation. Many people do because the language is very amenable to it and the codegen is usually optimal. Living entirely within the standard library and the constraints it imposes to support backward compatibility is a choice, not a requirement. The stan…

Depending on which STL you use, there may also be assertions you can enable, e.g. via defining _GLIBCXX_ASSERTIONS https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...

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

#195

Post by pitaj »

zozbot234 wrote: post #178
tialaramex wrote: post #167

Earlier quoted context omitted.

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 h…

I don't really agree with how you represent the difficulties of unsafe Rust.

First off, unsafe Rust is not meant for writing application logic. It should be isolated within data structures, algorithms, or other abstractions exposing safe APIs.

Secondly, what you say about calling into safe Rust from unsafe contexts just doesn't sound correct. It seems like by "extra preconditions" you're talking about the requirements placed on references: that they must be initialized, non-null, and for &mut, unaliased. But these aren't requirements for calling into safe code, these are requirements for dereferencing raw pointers.

You might also be talking about the issues around moveability and Pin. But these are also not about calling into safe code, but about representing your type correctly (making certain actions only possible when pinned or whatever).

And then you talk about std and view not being practically usable from unsafe Rust, and this just doesn't align with my experience at all.

It's really not that hard to get unsafe code right (Miri is an awesome tool), and it's also not difficult to avoid unsafe code entirely if you're not comfortable with the requirements.

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

#196

Post by pjmlp »

tialaramex wrote: post #190
pjmlp wrote: post #176

Earlier quoted context omitted.

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.

It isn't as if Rust is any different in this regard.

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

#197

Post by pjmlp »

tialaramex wrote: post #192
damagednoob wrote: post #79

Earlier quoted context omitted.

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.

It's tricky to compare. Anders is involved in a bunch of important stuff, but it's not as though it's all successes either. He's certainly important, but I don't know how to compare "track records" on "innovation" because that's so vague. One of his projects at Microsoft was J++ which is basically own-brand Java. Doubtless that's great material for learning to design C# but nobody is going to claim J++ was a success.

Only because Sun's lawsuit, several C# features were already present in J++ as the extensions that caused the lawsuit in first place.

VM integration with host OS, J/Direct (P/Invoke), events, COM integration, WFC (Windows Forms).

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

#198

Post by pjmlp »

c-cube wrote: post #163
tialaramex wrote: post #153

Earlier quoted context omitted.

Herb would like to associate Cpp2 with Typescript (which is generally considered to have succeeded) and other 2022 C++ Successor Languages with Dart (not so much). Herb emphasises the way in which what he's done is like Typescript and de-emphasises ways in which it's entirely unlike Typescript. I guess that's smart positioning. But a big problem Herb has is that the real alternative isn't any of those 2022 C++ Succes…

The problem with your argument is that swift is not, and cannot be, a replacement for C++. At best it can be an alternative for some programs, and on macOS only; for the rest of the world it's not very useful. And rust is great but the thing it lacks here is a great C++ interop story, the way TS has with JS and kotlin has with java. There's not really any language with that today (maybe D?) that also has a compelling…

From point of view from Apple it is, for their own ecosystem.

It is also a reason why if you want modern C++ support on Apple devices, now you need to install clang yourself.

As Apple keeps focusing on Swift, with Objective-C for its companion.

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

#199

Post by wsve »

pjmlp wrote: post #136
cylemons wrote: post #101

Earlier quoted context omitted.

But you can't deny that C++ is a straight upgrade to C. If CppFront becomes this straight upgrade to C++, isn't that a good thing?

C++ extended C syntax, did not introduce a completly different one alongside.

Does that make it not an improvement? There's definitely issues with C++'s syntax...

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

#200

Post by zozbot234 »

pitaj wrote: post #195
zozbot234 wrote: post #178

Earlier quoted context omitted.

> 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 h…

I don't really agree with how you represent the difficulties of unsafe Rust. First off, unsafe Rust is not meant for writing application logic. It should be isolated within data structures, algorithms, or other abstractions exposing safe APIs. Secondly, what you say about calling into safe Rust from unsafe contexts just doesn't sound correct. It seems like by "extra preconditions" you're talking about the requirement…

> these are requirements for dereferencing raw pointers.

You can use the unsafe read() and write() (and similar) functions to do things with raw pointers that would clearly involve dereferencing in C/C++ (including working with aliased pointers or 'pinned' data or writing to uninitialized memory), so I don't think this is correct from a C/C++ point of view. What Rust calls dereferencing is explicitly driven by the requirements placed on safe code; the two are effectively one and the same.

Post reply on HN