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

71–80 of 200 posts

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

#71

Post by GuB-42 »

IshKebab wrote: post #28
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…

> being workshopped with the C++ community Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.

I'd say the C++ community is torn.

Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety.

Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project.

Video game companies on the other hand are likely to be in the latter camp. Most of the times, security is not as critical, especially for offline games, and memory corruption usually don't go further than a game crash. Tight memory management however is critical, and it often involves raw pointers and custom allocation schemes.

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

#72

Post by flykespice »

pton_xd wrote: post #24
mihaic wrote: post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

How about "proc"? Too different? I don't like fn either but function is too much. Fun and func aren't great either. I'd go with proc or fn.

Probs too archaic?

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

#73

Post by nielsbot »

philwelch wrote: post #59
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…

Zig is designed to interoperate like this with C, and Kotlin with Java.

...and Swift w/ Obj-C

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

#74

Post by JonChesterfield »

GuB-42 wrote: post #71
IshKebab wrote: post #28

Earlier quoted context omitted.

> being workshopped with the C++ community Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.

I'd say the C++ community is torn. Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety. Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project. Video game companies on the other hand are likely to be in the latter c…

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 on intentionally losing the performance competition.

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

#75

Post by JonChesterfield »

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.

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

#76

Post by Animats »

pron wrote: post #41
Animats wrote: post #34

"Longer term, we will build on this to introduce a safe Carbon subset. This will be a large and complex undertaking, and won’t be in the 0.1 design." If they can't get safety right at the design stage, they'll never get it right. We already have D and Zig in this space.

Given that Carbon's space is "languages with full interoperability with C++," I don't think D and Zig are in that space. As to "getting it right" - things are not so simple. The emphasis on memory-safety soundness is based on some empirical hypotheses, some better founded than others, and it's unclear what "getting it right" means. From a software correctness perspective, the road to sound memory safety is as follows…

> As to "getting it right" - things are not so simple. The emphasis on memory-safety soundness is based on some empirical hypotheses, some better founded than others, and it's unclear what "getting it right" means.

It means eliminating undefined behavior, and unplanned interaction between distant parts of the program.

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

#77

Post by TinkersW »

pjmlp wrote: post #46
gpderetta wrote: post #15

Earlier quoted context omitted.

In C++ you can use indifferently either the class or typename keyword to introduce template arguments (because of course you can). A lot of styleguides suggest using typename because class is slightly misleading (the type could be anything not just a class). In practice everybody just uses class, because who as the time to type the full keyword and signature declarations in C++ are already unwieldy as it is.

Anyone using a proper IDE instead of notepad like editor.

I have that and still prefer class, easier to type(not just shorter, but easier keys) and less to read. Only use typename in the rare case where it is required

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

#78

Post by eric-p7 »

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's what makes Carbon different from any other language: D, Zig, Nim, Rust etc.

I know you can compile C++ files to object files, pass them to the D compiler, and have them call eachothers' functions. I've never tried it though.

--------

g++ -c foo.cpp

dmd bar.d foo.o -L-lstdc++

--------

https://dlang.org/spec/cpp_interface.html

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

#79

Post by owl_vision »

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…

> Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally.

_Incrementally_: a C++ project can be incrementally made more sane also using constructs to avoid and constructs to use once the problem domain is confined. In my past, I had successfully implemented this quest for 3 different fairly large C++ projects. This is not a strong selling point for carbon.

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

#80

Post by zem »

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.
Post reply on HN