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

Carbon Language: An experimental successor to C++

github.com

Post reply on HN
Print view View original

411–420 of 521 posts

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

#411

Post by lenkite »

zozbot234 wrote: post #387
mbrodersen wrote: post #384

Earlier quoted context omitted.

> on its way to become the standard low-level language It will take a very long time for Rust to get even close to the huge amount of C++ code out there. There are more than 5 million professional C++ developers employed around the world today. And that number is increasing . Don’t get me wrong: I like Rust and other attempts to move beyond C++. But don’t underestimate how much C++ code has been written the last 30+…

Carbon is not trying to be 100% interoperable with C++. It's trying for some fuzzy notion of "good enough" - that's really not very different from what Rust is trying to do with cxx-rs. Yes there are serious challenges and I've described them here, but they're not impossible to address while staying with Rust.

> Carbon is not trying to be 100% interoperable with C++ It's trying for some fuzzy notion of "good enough"

No, it's clearly not a "fuzzy" notion of interop even in the most uncharitable interpretation. Your assertion is mis-information.

"Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest."

Support mixing Carbon and C++ toolchains

Compatibility with the C++ memory model

Minimize bridge code

Unsurprising mappings between C++ and Carbon types

Allow C++ bridge code in Carbon files

Carbon inheritance from C++ types

Support use of advanced C++ features

Support basic C interoperability

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

#412

Post by lenkite »

chandlerc1024 wrote: post #69
brandmeyer wrote: post #46

Earlier quoted context omitted.

> A key example of this is the committee's struggle to converge on a clear set of high-level and long-term goals and priorities aligned with ours [ https://wg21.link/p2137 ]. I was frankly shocked by that goals and priorities document. The non-goals section reads like an open declaration of war against anyone whose use cases for C++ differ from GOOG and NVDA. My interpretation of Carbon is that since GOOG failed to t…

(one of the Carbon leads) Success for the Carbon Language requires it to successfully be an independent and community driven project. We may not succeed (this really is an experiment), but we're working hard to engage broadly and early in large part because of this being such an important goal and priority for us. Projects like this have to start somewhere, but can grow and become community endeavors. We are also alr…

Will Carbon natively support exceptions or is it solely going the Rust `Result` route ?

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

#413

Post by lenkite »

klodolph wrote: post #243
zozbot234 wrote: post #27

Earlier quoted context omitted.

Sounds a bit like "C++ but we get to change the ABI, and maybe break some old code for the sake of better-enforced safety guidelines".

C++ also has a very hard-line "you don't pay for what you don't use" philosophy, which sometimes lead to standard library APIs or language semantics which are a bit tortured. Compare C++ or against, say, the equivalent functionality in Rust, Go, Java, C#, etc. C++'s APIs are a bit overcomplicated, or at least they look that way if you don't know the various reasons why the C++ standard defined them that way (reasons…

"C++ also has a very hard-line "you don't pay for what you don't use"

This always felt eye-rolling false to me. We can't have a better hashmap since we all need to pay for the std::unordered_map's un-needed features like bucket access. We are certainly paying for what we don't use.

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

#415

Post by jcelerier »

LorenDB wrote: post #381
chc wrote: post #340

Earlier quoted context omitted.

The initial complaint was that it did not have "good support." I think it is fair to say that having to spend a significant amount of effort to work around a lack of support is not "good support."

Indeed, that is what I meant. I would like to see Qt allow some sort of language-abstracted moc so I can just install Qt and a set of Qt bindings and then use them. Just because I can work around the moc doesn't mean that I can easily and productively use Qt from D.

But .. how would that work ? What does "language-abstracted" means for something which is specifically about a language ?

E.g. moc in c++ looks for your classes with a Q_OBJECT macro to generate the matching reflection & metaobject data in a .cpp: how does that work in a language that doesn't have preprocessor macros, or maybe even classes, e.g. Scheme or some BASIC dialect ? In addition, moc is only necessary for languages that do not have proper reflection & code generation facilities - if they do, it's entirely unnecessary as the metaobject code can just be generated in-language as part of the bindings you're mentioning. E.g. consider the python Qt bindings: they don't need a moc. Same for D.

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

#416

Post by bialpio »

wiseowise wrote: post #410
bialpio wrote: post #375

Earlier quoted context omitted.

I don't think I understand - where is any kind of framework mentioned? And even if frameworks were mentioned, I think it's a fair comparison to say "language A has battle-proven / easy-to-use / etc. framework to achieve X, but language B doesn't".

Since when is GUI part of language?

From the moment it can interact with the underlying operating system? C++ doesn't specify any GUI framework as a part of the standard, and yet people manage to write GUI apps. Rust should have the same capabilities of calling into the OS, but GUI apps seem to be slow to appear there - it may be because it's still early days, or because Rust isn't super pleasant to write GUI apps in.

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

#417

Post by WalterBright »

dymk wrote: post #399
WalterBright wrote: post #332

Earlier quoted context omitted.

It doesn't need to be fully nogc. Not using the parts that use the gc will cripple nothing. You'll know which ones use the gc because they won't compile with @nogc.

@nogc is fine, if you're okay with not being able to use large swaths of the standard library, and by extension, most popular D libraries.

Not much of the library is dependent on the GC. For example, only one of the algorithms is.

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

#418

Post by pjmlp »

flohofwoe wrote: post #407
germandiago wrote: post #302

Earlier quoted context omitted.

The problem with the typical rants about C++ is that you guys are outdated. With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.

The problem isn't that Conan exists, but that other competing solutions are just as popular which results in fragmentation (for instance vcpkg, and cmake can also directly pull in external dependencies now). In the Rust world there's just Cargo.

Not really, Android and Fuchsia have their own cargo replacements, that fit better on their OS SDKs.

Either that, or we get a box of surprises in each build.rs script.

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

#419

Post by Asm2D »

flohofwoe wrote: post #407
germandiago wrote: post #302

Earlier quoted context omitted.

The problem with the typical rants about C++ is that you guys are outdated. With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.

The problem isn't that Conan exists, but that other competing solutions are just as popular which results in fragmentation (for instance vcpkg, and cmake can also directly pull in external dependencies now). In the Rust world there's just Cargo.

Competing solutions are great for innovation.

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

#420

Post by zozbot234 »

lenkite wrote: post #411
zozbot234 wrote: post #387

Earlier quoted context omitted.

Carbon is not trying to be 100% interoperable with C++. It's trying for some fuzzy notion of "good enough" - that's really not very different from what Rust is trying to do with cxx-rs. Yes there are serious challenges and I've described them here, but they're not impossible to address while staying with Rust.

> Carbon is not trying to be 100% interoperable with C++ It's trying for some fuzzy notion of "good enough" No, it's clearly not a "fuzzy" notion of interop even in the most uncharitable interpretation. Your assertion is mis-information. "Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest." Support mixing Carbon and C++ to…

And that's still not 100%. The Carbon devs are very clear that there will be some C++ code that Carbon is unable to interoperate with.
Post reply on HN