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

101–110 of 200 posts

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

#101

Post by troad »

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.

Agreed, but it would be much worse than you suggest. Many meaty C++ projects have an underlying architecture that could not even be expressed in (safe) Rust. The idea of transpiling a major C++ project and getting it running in Rust with only some minimal idiom fiddling seems utterly fantastical.

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

#102

Post by Gibbon1 »

Buttons840 wrote: post #92
JonChesterfield wrote: post #74

Earlier quoted context omitted.

I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability". Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance…

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.

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

#103

Post by marsven_422 »

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…

[dead]

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

#104

Post by troad »

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…

That seems like a really neat idea.

One other use case I could think of is gaming, where there is an incredible amount of load-bearing C++ code that's never realistically going to be rewritten, and strict memory safety is not necessarily a sine qua non in the way it is in other fields.

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

#105

Post by pjmlp »

AnimalMuppet wrote: post #57
pjmlp wrote: post #44

Earlier quoted context omitted.

fun, press tab, modern IDE fills in the remaing function characters. Unfortunately we keep designing languages for people using notepad. Nowadays my editor even writes full blocks at a time.

If "fun" and "func" are already "not great" (because, I presume, they're too long), then "fun[TAB]" is not the solution. Mind you, I'm not saying that your solution doesn't work. Just that it doesn't work for the GP .

It is kind of ironic how people still get stuck discussing syntax to save keystrokes and then write a whole book on the AI chat window.

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

#106

Post by troad »

gilgoomesh wrote: post #96
nielsbot wrote: post #73

Earlier quoted context omitted.

...and Swift w/ Obj-C

Swift can also 2-way operate with C++. Its coverage of the C++ language is incomplete but I suspect it might outpace Carbon.

I really struggle to imagine an organisation that shepherds a large and venerable C++ codebase migrating over to Swift.

For all of C++'s faults, it is an extremely stable and vendor-independent language. The kind of organisation that's running on some C++ monolith from 1995 is not going to voluntarily let Apple become a massive business risk in return for marginally nicer DX.

(Yes, Swift is OSS now, but Apple pays the bills and sets the direction, and no one is seriously going to maintain a fork.)

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

#107

Post by pjmlp »

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…

Yeah, that sums it all quite nicely, see contracts proposal as a good example of that.

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

#108

Post by chandlerc1024 »

cb321 wrote: post #52
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…

Not to disagree, but to amplify - FWIW, most of what you say was also the sales pitch for C++ over ANSI C in the early 90s vs. the "pure Java" mentality that shortly followed in the late 90s (with a megaton of Sun Microsystems marketing to re-write almost everything rather than bridge with JNI). People neglect how practical incrementalism can be. Also, FWIW, it is very ergonomic for Nim to call C (though the reverse…

Source-to-source translation is definitely planned. We've even done some early experiments.

But we need to get the language and interop into good shape to be able to thoroughly test and evaluate the migration.

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

#109

Post by chandlerc1024 »

omoikane wrote: post #97
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…

> I think this page describes "what" but not "why" of Carbon. Maybe the page was updated recently, but there is a "why" link near the top: https://docs.carbon-lang.dev/#why-build-carbon What I would like to see is more documentation on the "why not" that summarizes why other languages and proposals are not sufficient. For example, Safe C++ proposal[1] appears to satisfy all requirements, but I can't find any referenc…

The reason the Safe C++ proposal wasn't mentioned is that it came years later. =] I'll see if it makes sense for us to update that section a bit, this probably isn't the only thing that we should refresh a bit to reflect the last few years of developments.

FWIW, the biggest challenge with Safe C++ is that WG21 rejected[1] that direction. And it was developed without building a governance model or way to evolve outside of WG21, and so doesn't seem to have a credible path forward.

[1]: FWIW, some members of WG21 don't agree with this characterizationp, but both the author's impression and the practical effect was to reject the direction.

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

#110

Post by chandlerc1024 »

nxobject wrote: post #5

If you've seen this before, it's worth looking at the 2025 roadmap – it's long-term work, a full safety story hasn't been quite figured out (TBD end 2025), and 0.1 is TBD end 2026. About the pace of Rust, although without the active forum that Rust had in its early days. https://docs.carbon-lang.dev/docs/project/roadmap.html What _is_ interesting is that I get the impression that Carbon is being workshopped with the…

> What _is_ interesting is that I get the impression that Carbon is being workshopped with the C++ community, rather than the wider PLT community -- I worry that they won't benefit from the broader perspectives that'll help it avoid well-known warts elsewhere.

FWIW, we're working hard whenever looking at an aspect of the language to look at other languages beyond C++ and learn any and everything we can from them. Lots of our design proposals cite Swift, Rust, Go, TypeScript, Python, Kotlin, C#, Java, and even Scala.

Post reply on HN