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

Carbon Language: An experimental successor to C++

docs.carbon-lang.dev

Post reply on HN
Print view View original

121–130 of 200 posts

Re: Carbon Language: An experimental successor to C++

#121

Post by JonChesterfield »

Gibbon1 wrote: post #102
Buttons840 wrote: post #92

Earlier quoted context omitted.

Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages? A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust. There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common. (Maybe Rust could do this, but they haven't stabiliz…

I remember reading that google tried to impress on WG21 and 14 the need to update the ABI and they were utterly opposed. The result is google is no longer interested in C++. Apple I think is also no longer interested in C++. I think also Swift now has a stable ABI.

A good write up of that is at https://cor3ntin.github.io/posts/abi/

Re: Carbon Language: An experimental successor to C++

#122

Post by [deleted] »

Gibbon1 wrote: post #102
Buttons840 wrote: post #92

Earlier quoted context omitted.

Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages? A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust. There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common. (Maybe Rust could do this, but they haven't stabiliz…

I remember reading that google tried to impress on WG21 and 14 the need to update the ABI and they were utterly opposed. The result is google is no longer interested in C++. Apple I think is also no longer interested in C++. I think also Swift now has a stable ABI.

[deleted]

Re: Carbon Language: An experimental successor to C++

#123

Post by JonChesterfield »

zem wrote: post #80
JonChesterfield wrote: post #75

One could presumably compile arbitrary C++ to rust or D without changing semantics, then slowly go through the result making it look more native to the new language. That would either be a wholesale conversion or emitting a translation shim style thing at the boundary between legacy c++ and the new language. I'm not sure Carbon is necessary to achieve such a conversion.

I would be stunned if you could compile arbitrary c++ to rust or d, unless by "compile" you mean "painfully hand-translate and spend months fixing subtle errors". you are underestimating the sheer complexity of the language.

Implementation would be by modifying clang. Traverse the clang ast emitting the new language instead of llvm IR.

You wouldn't get idiomatic code out but with some effort you'd get rust/d/c/other which clang compiles to the same IR as the original.

How much refactoring is warranted afterwards would depend on how much effort you put in to recreating templates / header files / modules etc on the fly.

I'm not sure I'd choose to do this myself if I was in Google's position but it would be tempting.

Re: Carbon Language: An experimental successor to C++

#124

Post by justcuriousab »

tialaramex wrote: post #70
pjmlp wrote: post #43

Earlier quoted context omitted.

That is what many of us have done moving into managed languages, with native libraries when required to do so. The remaining people driving where the language goes have other priorities in mind like reflection. The profiles that were supposed to be so much better than the Safe C++ proposal, none of them made it into C++26, and it remains to be seen if we ever will see a sensible preview implementation for C++29.

C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture. If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. Beyond that though, the profiles idea is dead in t…

> If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.

But Rust allows pattern matching on floats.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Rust Zulip is C++ WG21 confirmed?

Re: Carbon Language: An experimental successor to C++

#126

Post by gituliar »

dazzawazza wrote: post #118
kjksf wrote: post #50

I think this page describes "what" but not "why" of Carbon. Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally. The most important attribute of Carbon is not the specifics of the syntax but the fact that it's designed to be used in a mixed C++ / Carbon code base and comes with tooling to convert as much of C++ as possible to Carbon. That's wha…

These are strong points and I think the methodology behind Carbon is the correct one. The elephant in the room is that once Google decide to drop Carbon my existing code base will be dependant on a dead technology and then I am screwed. I find it hard to trust Google to maintain any software nor to write software that is maintainable by a community. They write software for themselves and themselves alone.

For me Go is a success story.

Re: Carbon Language: An experimental successor to C++

#127

Post by tialaramex »

justcuriousab wrote: post #124
tialaramex wrote: post #70

Earlier quoted context omitted.

C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture. If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. Beyond that though, the profiles idea is dead in t…

> If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. But Rust allows pattern matching on floats. https://play.rust-lang.org/?version=stable&mode=debug&editio... Rust Zulip is C++ WG21 confirmed?

I'm sure you think this was somehow succinctly making your point, but I can't see any connection at all, so if you did have an actual point you're going to need to explain it.

Re: Carbon Language: An experimental successor to C++

#128

Post by zem »

JonChesterfield wrote: post #123
zem wrote: post #80

Earlier quoted context omitted.

I would be stunned if you could compile arbitrary c++ to rust or d, unless by "compile" you mean "painfully hand-translate and spend months fixing subtle errors". you are underestimating the sheer complexity of the language.

Implementation would be by modifying clang. Traverse the clang ast emitting the new language instead of llvm IR. You wouldn't get idiomatic code out but with some effort you'd get rust/d/c/other which clang compiles to the same IR as the original. How much refactoring is warranted afterwards would depend on how much effort you put in to recreating templates / header files / modules etc on the fly. I'm not sure I'd ch…

you would end up with llvm-ir-like code that was only technically rust/d insofar as the compilers could handle it. it would not be human-readable or maintainable at all; indeed, it would be harder to convert that to idiomatic rust/d than hand-translating the c++ code. and really, all you would gain would be getting rid of the c++ compiler and ending up with worse code.

the point of carbon is that you can incrementally migrate your c++ program to it in place, and the migrated code will end up easier to maintain than the original c++.

Re: Carbon Language: An experimental successor to C++

#129

Post by justcuriousab »

kjksf wrote: post #50

I think this page describes "what" but not "why" of Carbon. Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally. The most important attribute of Carbon is not the specifics of the syntax but the fact that it's designed to be used in a mixed C++ / Carbon code base and comes with tooling to convert as much of C++ as possible to Carbon. That's wha…

> It's not possible to port a millions line C++ code base, like Chrome, to another language so large C++ projects are stuck with objectively pretty bad language and are forced to continue to use C++ even though a better language might exist.

One good aspect about C++ is its backwards compatibility or stability. Also a drawback, but companies not having to spend huge amounts of time, expertise and money rewriting their whole codebases all the time is something they appreciate.

Rust is often somewhat stable, but not always.

https://internals.rust-lang.org/t/type-inference-breakage-in...

https://github.com/rust-lang/rust/issues/127343

300 comments on Github.

https://github.com/NixOS/nixpkgs/pull/332176

Rust has editions, but it's a feature that it will probably take years to really be able to evaluate.

What kind of compatibility story will Carbon have? What features does it have to support compatibility?

Re: Carbon Language: An experimental successor to C++

#130

Post by Ygg2 »

ygritte wrote: post #111

What's the pro of not having a stable ABI?

Being able to change things. It's like all downsides of backwards compatibility but on a binary level

As to things ABI prevents:

- scoped_lock was added to not break ABI by modifying lock_guard

- int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated.

- unique_ptr could fit in register with language modifications, which would be needed to make it zero-overhead, compared to a pointer

- Many changes to error_code were rejected because they would break ABI

- status_code raised ABI concerns

- A proposal to add a filter to recursive_directory_iterator was rejected because it was an ABI break

- A proposal to make most of constexpr (including strlen) will probably die because it would be an ABI break.

- Adding UTF-8 support to regex is an ABI break

- Adding support for realloc or returning the allocated size is an ABI break for polymorphic allocators

- Making destructors implicitly virtual in polymorphic classes

- Return type of push_back could be improved with an ABI break

- Improving shared_ptr would be an ABI break

- [[no_unique_address]] could be inferred by the compiler should we not care at all about ABI

Source: https://cor3ntin.github.io/posts/abi/

Post reply on HN