Live data from Hacker News

Carbon Language: An experimental successor to C++

docs.carbon-lang.dev

171–180 of 200 posts

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

#171

Earlier quoted context omitted.

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.

Float matching in Rust is not supported due to correctness concerns, but due to historical accidents and backwards compatibility. https://github.com/rust-lang/rust/issues/41620#issuecomment-... https://github.com/rust-lang/rust/pull/84045#issuecomment-82...

OK? I don't see how that's connected? It's not controversial that f32 and f64 are partially ordered, the problem in C++ is that the difference between "Partially Ordered" and "Totally Ordered" is semantic not syntactic in their language and all semantic mistakes are just IFNDR so it's a footgun.

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

#173

Earlier quoted context omitted.

Float matching in Rust is not supported due to correctness concerns, but due to historical accidents and backwards compatibility. https://github.com/rust-lang/rust/issues/41620#issuecomment-... https://github.com/rust-lang/rust/pull/84045#issuecomment-82...

OK? I don't see how that's connected? It's not controversial that f32 and f64 are partially ordered, the problem in C++ is that the difference between "Partially Ordered" and "Totally Ordered" is semantic not syntactic in their language and all semantic mistakes are just IFNDR so it's a footgun.

[deleted]

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

#174
post #81

Earlier quoted context omitted.

Eliminating undefined behaviour is a means to an end (reduces problematic bugs, but not all undefined behaviour is equally responsible to such bugs), and it's not a binary thing (virtually all programs need to interact with software written in languages that don't eliminate undefined behaviour, so clearly there's tolerance to the possibility of undefined behaviour). Don't get me wrong - less undefined behaviour is be…

By definition all the C++ Undefined Behaviour is unbounded. You may believe, and even you may have practical evidence for the compilers which happen to exist today, that in some cases the behaviour in fact bounded, but that's not what the language definition says and optimisers have a funny way of making fools of people who mistake Undefined for "Eh, it'll probably do what I meant". It might seem as though incrementi…

Yes, that's what UB means - the program loses all meaning and any effect is possible - but the importance of a bug is much more than just its blast radius. We ultimately care not about the language semantics of a bug but its expected loss of value. This is also dependent on how frequently the bug appears and how easy it is to prevent or find and fix. Not all UBs are equal on that front.

Furthermore, an unbounded blast radius isn't itself the direct problem. A bug that with some probability casues your program to crash and your disk to be deleted is far less dangerous than a bug that allows a remote attacker to relatively easily steal all your secrets. UBs also differ on that front.

And again, virtually all programs are not provably without UB. For example, a Java program still interacts with an OS or with some native library that might suffer from a UB. So clearly we do tolerate some probability of UB, and we clearly do not think that eliminating any possibility of UB is worth any price.

When a program is just code on the screen, it's just a mathematical object, and then it's easy to describe a UB - the loss of all program meaning - as the most catastrophic outcome. But software correctness goes beyond the relatively simple world of programming language semantics, and has to consider what happens when a program is running, at which point it is no longer a mathematical object but a physical one. If a remote attacker steals all our secrets, we don't care if it's a result of some bug in the program itself (due to UB or otherwise), in other software the program interacts with, some fault or weakness in the hardware, or human operator error. The probability of any of these things is never zero, and we have to balance the cost of addressing each of these possibilities.

To give an example in the context of Carbon, we know that old code tends to suffer from fewer severe bugs than new code. So, if we want to reduce the probability of bugs, it is possible that it may be more worthwhile to invest - say, in terms of language complexity budget - in interop with C++ code than in eliminating every possible kind of UB, including those that are less likely to appear, sneak past testing, and cause an easily exploitable vulnerability.

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

#175
post #174

Earlier quoted context omitted.

By definition all the C++ Undefined Behaviour is unbounded. You may believe, and even you may have practical evidence for the compilers which happen to exist today, that in some cases the behaviour in fact bounded, but that's not what the language definition says and optimisers have a funny way of making fools of people who mistake Undefined for "Eh, it'll probably do what I meant". It might seem as though incrementi…

Yes, that's what UB means - the program loses all meaning and any effect is possible - but the importance of a bug is much more than just its blast radius. We ultimately care not about the language semantics of a bug but its expected loss of value. This is also dependent on how frequently the bug appears and how easy it is to prevent or find and fix. Not all UBs are equal on that front. Furthermore, an unbounded blas…

> 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 the UB, no matter what it might be, won't happen.

C++ has IFNDR, clauses which say this is "Ill-Formed, No Diagnostic Required". The program itself wasn't actually a valid C++ program, it has absolutely no defined meaning, there may be no indication of a problem from your compiler but alas it's entirely meaningless. This isn't behavioural, it's an invisible status of the entire program.

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

#176

Earlier quoted context omitted.

> 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. Lot…

Make sure you're checking out Hylo. I'm not sure that its ideas are right for Carbon, but if you're looking for a credible alternative to Rust's take on safety, I think it's one of the better ones.

We've been watching closely since before the name change. =D Had lots of conversations with several of the folks involved.

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

#177

Earlier quoted context omitted.

> 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. Lot…

Chandler I would love to be involved in Carbon development to shape its development to be usable at my company or alternatively to use it in my own projects. What is the best way to stay involved in Carbon development? Just the discord?

In increasing order of volume of material:

- Our newsletter / announcements via GitHub Discussions[1] email[2] or RSS[3]

- The "Last Week in Carbon" posts via GitHub[4] or RSS[5]

- The Discord server: https://discord.gg/ZjVdShJDAs

[1]: https://github.com/carbon-language/carbon-lang/discussions/c...

[2]: https://groups.google.com/a/carbon-lang.dev/g/announce

[3]: https://github.com/carbon-language/carbon-lang/discussions/c...

[4]: https://github.com/carbon-language/carbon-lang/discussions/c...

[5]: https://github.com/carbon-language/carbon-lang/discussions/c...

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

#178
post #174

Earlier quoted context omitted.

Yes, that's what UB means - the program loses all meaning and any effect is possible - but the importance of a bug is much more than just its blast radius. We ultimately care not about the language semantics of a bug but its expected loss of value. This is also dependent on how frequently the bug appears and how easy it is to prevent or find and fix. Not all UBs are equal on that front. Furthermore, an unbounded blas…

> 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 the language has nothing to say about what happens in such a program. But that doesn't mean that we can't reasonably talk about what happens not using that theory [1]. Indeed, one of the reasons that UB are of concern is that some of them are frequent causes of security exploits - and that's the thing we ultimately care about, not that the program loses its semantics. But again, not all of them are equally common causes of such outcomes, and not all of them are equally hard to avoid in the first place.

[1]: In fact, this is easy to explain in software: the programming language can say nothing about the meaning of a program with UB - indeed, it has no meaning in that language - but because we do have an executable, the program still has a well-defined meaning in the machine language it compiled to (machine language has no UB, or, even if some machine architecture does declare that some instruction stream is UB, most programs with UB in some programming language still do not compile to a program with UB in machine code). So the program that has no meaning in C++ still has meaning in machine code, and as that is the program we ultimately run and care about, we can talk about which UBs are more or less likely to result in which machine code behaviour.

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

#179
post #135

Earlier quoted context omitted.

Maybe not, but an Objective-C++ codebase might be a good candidate.

Do you have projects with huge code bases of Obj-C++ in mind? I guess, some Mac apps? In that case I think most platform independent "guts" would be in C or C++, and the Obj-C++ part is tied to the frameworks, so the devs would have to rewrite it anyway.

Facebook iOS

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

#180
post #106

Earlier quoted context omitted.

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 th…

I think Apple is largely doing this for themselves.
Post reply on HN