Live data from Hacker News

Carbon Language: An experimental successor to C++

docs.carbon-lang.dev

181–190 of 200 posts

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

#181

Earlier quoted context omitted.

Swift seems to be doing a decent job of this (and C++ interop for that matter)

> Swift seems to be doing a decent job of this It keeps adding keywords and it has become way harder to keep it in your head. It’s over 220 at this point. Don’t take my word for it, Swift creator doesn’t agree with its current direction either.

I'm not sure why I should take the word of the guy who added a bunch of these keywords so he could use Swift for AI

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

#182

Earlier quoted context omitted.

> Swift seems to be doing a decent job of this It keeps adding keywords and it has become way harder to keep it in your head. It’s over 220 at this point. Don’t take my word for it, Swift creator doesn’t agree with its current direction either.

I'm not sure why I should take the word of the guy who added a bunch of these keywords so he could use Swift for AI

Curious, what keywords were those? I think Chris Lattner was not involved with Swift after version 3

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

#183
Chandler Carruth and his Carbon team might be both incompetent and dishonest. Is he and his team just scamming Google while working effectively without accountability, racking in money? How have they not gotten further? Why does the language seem so incompetently and carelessly designed? Do they put any effort or thought into it?

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

#184

Earlier quoted context omitted.

In which way is C++ an "objectively pretty bad language"? I have done C++ for a living and it is not the easiest but there is tooling and warnings as errors that catch a lot of the errors before even you make a mistake. It is true that packaging is more challenging but it is also true that it is very configurable ro squeeze performance as much as possible (which is on of C++'s niches). And by squeezing I mean beyond…

Explicitly and between the lines, Carruth and Google have made it clear that the “bad” part of C++ from their perspective is the standards committee. In particular, the committee’s unwillingness to make ABI-breaking changes to the language, or more abstractly, to consider the needs of organizations with huge active code bases at least as seriously as those with huge legacy code bases.

I understand but there are trade-offs there.

Maybe a hybrid approach should be done byt breaking ABI in a so Core-supported language can cascade into so many places.

People say that Rust is great bc of that but that is just a trade-off and anyway there are olenty of dependencies like Boost, Abseil or others that can play that role anyways

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

#185

Earlier quoted context omitted.

I'm not sure why I should take the word of the guy who added a bunch of these keywords so he could use Swift for AI

Curious, what keywords were those? I think Chris Lattner was not involved with Swift after version 3

https://github.com/swiftlang/swift/blob/main/docs/Differenti...

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

#186
post #178

Earlier quoted context omitted.

> the most catastrophic outcome Nah, this is in the context of C++ so UB isn't the most catastrophic situation. Undefined Behaviour is a behaviour, which means we might well be able to avoid invoking the behaviour and then it's fine. For example if your C++ program has a use-after-free in the code invoked only by the "Add file" feature but otherwise works fine, we can just ensure operators never use "Add file" and th…

As I said, UB means that a program has no meaning in the source language. That doesn't change anything I wrote above about the impact of UB. A hardware fault may also make a program meaningless, BTW, yet we all accept that every program written in any language is currently susceptible to UB or to a hardware fault. If you want, you can think of UB like a mathematical singularity in some physical theory. The theory of…

This seems like it missed the point entirely?

UB is a behaviour, it's unbounded, so it's an immediate disaster, and "time travel" UB can make this harder to reason about, because the as-if rule can mean that although it didn't in some sense "happen" yet the behaviour has consequences earlier. But if we avert the behaviour it won't happen. It is not correct to say that UB means the entire program had no meaning.

You give the "mathematical singularity" analogy, consider division. We doubtless agree than 6 divided by 3 is 2. And 6 divided by 2 is 3. But how about 6 divided by 0? This is not defined, we cannot perform such an operation. But division is not as a result somehow entirely without meaning, it just has this well understood limitation. Likewise for software with UB that we can avert.

IFNDR is a catastrophe because it truly does render the entire software without meaning.

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

#187

Earlier quoted context omitted.

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.

Is there a compiler, maybe an online one, for Carbon, or some way to compile and run Carbon code? And if not, what are the plans for that?

The nightly release of the Carbon compiler can be used via https://carbon.compiler-explorer.com/ . Note that it is definitely a work in progress, it hasn't even reached our v0.1 goals yet, but a good chunk of important functionality is working.

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

#188

Earlier quoted context omitted.

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.

I am trying to run Carbon in Godbolt. Printing as in the example from Carbon's Github repository, does not work. 'Print("Test");' gives a complaint about not finding 'Print'.

That is correct. Strings and I/O both have a bunch of work to be done. Printing currently requires workarounds like https://godbolt.org/z/MP4164f7s

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

#189

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…

Carbon is performance-first, so ABI instability is the default. We plan to have opt-in ABI stability, but that story is not well developed yet. Replacing C as the lingua franca is not a goal, at least not yet.

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

#190

Earlier quoted context omitted.

But Safe C++ and Circle are different languages, right? And Circle is not the same as the Safe C++ proposal that was submitted, right? There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere. I cannot find any occurrences of "reference implementation" in the Safe C++ draft.

> But Safe C++ and Circle are different languages, right? Eh, bit of a mixed bag, I think, depending on the context in which the words are used. "Circle" can refer to the compiler/toolchain or the set of C++ extensions the compiler implements, whereas Safe C++ is either the proposal or the extensions the proposal describe. As a result, you can say that you can compile Safe C++ using Circle, and you can also describe…

If they're the same language, then I think it's a fair objection that it's closed-source, as some people might find using a closed-source compiler to be unsuitable as a replacement for the existing open source C++ ones. If it's not the same language, then it's not clear that Safe C++ actually exists today, so it also seems fair that people might be interested in alternatives that they expect might be available sooner.
Post reply on HN