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

191–200 of 200 posts

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

#191

Post by owl_vision »

pjmlp wrote: post #168
owl_vision wrote: post #79

Earlier quoted context omitted.

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

Assuming the right culture, which unfortunately many C++ shops lack, that is why we have things like Orthodox C++ and similar movements.

i always emphasize to new programmers to learn any language and practice it with respect and discipline. All languages have dark corners, the human who can reason which constructs are appropriate.

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

#192

Post by saghm »

owl_vision wrote: post #79
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 fo…

Once you've done this work though, what stops the codebase from slowly drifting back into the less sane realm it previously resided in? It seems pretty reasonable to be concerned that a company that produced a messy codebase once is capable of making it messy again, and given that turnover is inevitable in the long term (which is the timeframe that seems relevant given that long-term compatibility in C++ codebases is kind of the whole reason this discussion is happening), it doesn't seem like relying on an individual to enforce the rules is super viable. The obvious way to enforce this sort of thing is through tooling, and there's no tool more powerful than literally making it impossible to express the undesirable code in the language itself in the first place.

You're right that incrementally rewriting isn't much of an advantage over C++ itself, but I think you're missing the point that the emphasis on "incremental" is to highlight the advantage in rewriting C++ code in Carbon over alternatives that don't provide as much compatibility (with Rust being somewhat notorious for being suggested by outside parties as a target for rewriting in whenever discussions about C++ codebases happen). The argument for Carbon over C++ isn't specifically that it can be rewritten incrementally, but that it's just a better language, which has benefits _after_ the rewrite. To be clear, I'm sure that someone could come up with reasonable objections to that claim as well, but I think it's distinct from the part you're objecting to, and it's worth treating as a separate concern.

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

#193

Post by pron »

tialaramex wrote: post #186
pron wrote: post #178

Earlier quoted context omitted.

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

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

In the language. I.e. the language assigns no meaning to source the program, which is, indeed, the "catastrophic" impact of UB (or IFNDR) within the theory of the language. But since a running program takes the form of an executable, and the executable always has a defined meaning in another language (machine code), while C++ has nothing to say about what such programs do (i.e. that's the end of the helpfulness of that theory) that doesn't mean we can't talk about or care about the meaning of the executable.

An executable that crashes and an executable that leaks all your secrets have very different consequences, and while the C++ spec says absolutely nothing about the relationship between different UBs and these behaviours, that doesn't mean that these relationships don't exist.

A mathematical singularity in a physical theory means that that particular theory has nothing to say about the physics of that situation, not that there's no actual physics going on, and the physics that is actually going on could be more or less "catastrophic" depending on what we mean by that.

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

#194

Post by pron »

pron wrote: post #193
tialaramex wrote: post #186

Earlier quoted context omitted.

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

> IFNDR is a catastrophe because it truly does render the entire software without meaning. In the language . I.e. the language assigns no meaning to source the program, which is, indeed, the "catastrophic" impact of UB (or IFNDR) within the theory of the language. But since a running program takes the form of an executable, and the executable always has a defined meaning in another language (machine code), while C++…

To be more concrete, event though two programs can both be meaningless in C++, i.e. C++ says nothing about what they actually do once compiled and run, we can sometimes say that one of them is much more likely to lead to a security exploit than the other. This is even used in practice in techniques such as this one: https://www.cl.cam.ac.uk/~tmj32/papers/docs/ainsworth20-sp.p...

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

#195

Post by aw1621107 »

saghm wrote: post #190
aw1621107 wrote: post #158

Earlier quoted context omitted.

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

I don't think the objection in the first sentence makes sense because I don't think replacing the existing C++ compilers was ever in the cards. If anything, the fact that the Safe C++ proposal has a section titled "Implementation Guidance" seems to point to precisely the opposite - that the intent was for existing C++ compilers to be updated to add the new features, not that Circle was to replace them.

I'm not sure about the second sentence either? Circle (supposedly?) implements everything in the Safe C++ proposal, so in that respect Safe C++ exists. Alternatively, you can say Safe C++ doesn't exist because major compilers don't implement it, but that's kind of the point of the Safe C++ proposal (and many (most?) other C++ language proposals, for that matter) - it's describing new features that don't currently exist but might be worth adding to the standard.

> people might be interested in alternatives that they expect might be available sooner.

This is also a bit funny because this was one of the more contentious points of debate in the Safe C++ vs. profiles discussion, and the impression I got is that between the two Safe C++ was generally considered to be closer to "might be available sooner" than profiles.

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

#196

Post by samuell »

Imustaskforhelp wrote: post #37
treyd wrote: post #26

Earlier quoted context omitted.

What's wrong with fn? It's perfectly understandable. I don't understand what the bikeshedding about keywords like this is about.

I don't even code in kotlin but I know that kotlin has function as fun :P Such small things as using __ __ in python and small inconveniences (lua's 1 instead of 0) really has a lot of people, what do I say.. yea, polarized on this matter.

fun is the best, as it makes the function name align with the code block indented 4 characters :D

    fun main() {
        println("Hello, world!")
    }
        ^ aligned here! \o/

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

#197

Post by josh11b »

josh11b wrote: post #188
justcuriousab wrote: post #138

Earlier quoted context omitted.

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

Array iteration got checked into the prelude so this is now shorter: https://godbolt.org/z/YYheo19ea

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

#198

Post by saghm »

aw1621107 wrote: post #195
saghm wrote: post #190

Earlier quoted context omitted.

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…

I don't think the objection in the first sentence makes sense because I don't think replacing the existing C++ compilers was ever in the cards. If anything, the fact that the Safe C++ proposal has a section titled "Implementation Guidance" seems to point to precisely the opposite - that the intent was for existing C++ compilers to be updated to add the new features, not that Circle was to replace them. I'm not sure a…

It sounds like the difference of opinion here is around how soon we expect that the major compilers will actually implement the safe features. I tend not to be optimistic that these sorts of changes will be available anytime soon, and I think it would be fair to consider alternatives at this point, but that's obviously a judgment call and not everyone will agree on that.

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

#199

Post by aw1621107 »

saghm wrote: post #198
aw1621107 wrote: post #195

Earlier quoted context omitted.

I don't think the objection in the first sentence makes sense because I don't think replacing the existing C++ compilers was ever in the cards. If anything, the fact that the Safe C++ proposal has a section titled "Implementation Guidance" seems to point to precisely the opposite - that the intent was for existing C++ compilers to be updated to add the new features, not that Circle was to replace them. I'm not sure a…

It sounds like the difference of opinion here is around how soon we expect that the major compilers will actually implement the safe features. I tend not to be optimistic that these sorts of changes will be available anytime soon, and I think it would be fair to consider alternatives at this point, but that's obviously a judgment call and not everyone will agree on that.

As far as Safe C++ vs. profiles specifically, I don't think the conversation really ever got to the point of serious discussions of how soon the features could be implemented. My understanding is that there were bigger hangups about what direction to go in the first place as well as what "profiles" even meant.

> and I think it would be fair to consider alternatives at this point

I would assume those who could consider alternatives already have, and that those (still) interested in safe(r) C++ do so because the alternatives are insufficient for one reason or another.

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

#200

Post by cjj_swe »

benob wrote: post #125

How is it different from mere syntactic sugar over the same programming concepts? What does it bring that C++ cannot do? Isn't it just a way of controlling the language vs using normative bodies?

Well for one, in addition to templates it has definition checked generics. That alone justifies it to me, but it's far from the only improvement.
Post reply on HN