9 ms·

Carbon’s most exciting feature is its calling convention

243 points by obl 4y ago

oneplane 4y ago
At first I thought this was about Mac OS around the 9 and 10 times... but I suppose not everyone is going to make that link with this name.
- mathgeek 4y ago
  You’re certainly not the only one. It’s a confusing choice of naming.
  - cflewis 4y ago
    I think the statute of limitations on “confusing name” when Mac OS Carbon was removed from OS X 10 years ago has passed.
    - morelisp 4y ago
      Carbon was removed two years ago.
      - astrange 4y ago
        Well, the API was. There's still bits of it internally driving the menu and event systems, and a lot of app/icon/Finder behaviors.
    - oneplane 4y ago
      Since those old operating systems are now vintage or retro, there have been a few people porting things like Rust, Go and Swift to older Mac OS versions (the ones that use the Toolbox ROM) which was also in the news here. There is of course no 'registry of allowed names that have aged-out' but there are probably other creative names one could come up with.
    - olliej 4y ago
      Yeah, I was confused by the name carbon, but am able to recognize that what I think of by default is not relevant anymore.
  - Someone 4y ago
    I hope they picked that name for the same reason Apple picked it: because all life is built on carbon.
    - oneplane 4y ago
      Or because Carbon as an element is "C" and "C" is also the language the framework was built for.
      - Maursault 4y ago
        Well, Apple was a little clever with Carbon for this reason, because it was a C based API. I'm not sure how you get Carbon from C++.
        tambourine_man 4y ago
        Also, the UI was called Aqua. So Aqua + Carbon is an interesting metaphor for an OS ecosystem.
        schoen 4y ago
        Apparently, although it's not likely to occur under most conditions, you can form a monatomic carbon C²⁺ ion by shooting a laser into very high-temperature carbon: https://sciencetrends.com/the-charge-of-a-carbon-ion/ https://sciencetrends.com/the-charge-of-a-carbon-ion/ https://aip.scitation.org/doi/10.1063/1.4966987 https://aip.scitation.org/doi/10.1063/1.4966987 "Up to C⁴⁺ ions are observed." And I guess you could also write the C²⁺ ion as "C⁺⁺" if you wanted. :-)
        Dylan16807 4y ago
        That just makes the comparison worse, if it's difficult and unstable and almost immediately sheds the +s.
- rgovostes 4y ago
  Apple's Cocoa framework itself reused the name of a 90's visual programming language for kids developed by its own Advanced Technology Group. It was certainly a play on "java for kids." https://en.wikipedia.org/wiki/Stagecast_Creator https://en.wikipedia.org/wiki/Stagecast_Creator
  - lioeters 4y ago
    That's the first time I heard of Cocoa as "Java for kids". How cute!
- sedatk 4y ago
  I mean, it's at least a bit less ambiguous than Go.
- hinkley 4y ago
  I got as far as “surely they can’t be talking about OS 9, someone must have recycled the name”
ArrayBoundCheck 4y ago
Calling convention? That's the most exciting feature? It doesn't boost productivity, reduce compile times, offer a larger standard library or create a boost a reasonable language would provide? No thanks google. I've been saying that for years now. You jumped the shark
- flumpcakes 4y ago
  The author has expertise in C++ and is excited about a C++-like language that addresses the pain point of C++'s calling convention which will _never_ be fixed by the standards committee due to their commitment on backwards compatibility. This was not an overview of the language, so this comment seems a little uncharitable to the author.
  - ArrayBoundCheck 4y ago
    Having slightly better optimizations due to changing ABI doesn't sound worth the friction of having another language in the codebase. Especially when the guys who invented it (google) is famous for sunsetting things and couldn't get their peers to use bazel, the other thing google invented I don't care if this sounds uncharitable, I see the pitfalls and I seen so many people get sucked in to prior pitfalls
fourthark 4y ago
This is mostly a Google project? Unclear from the repo who is sponsoring it.
- bardworx 4y ago
  Microsoft. - don’t listen to me, it’s Google.
  - moralestapia 4y ago
    It's Google but yes, another instance of Embrace, Extend and Extinguish. I hope this doesn't take off, with my sincere apologies to the ones who have been working hard on this. The last thing the C/C++ ecosystem needs is becoming de facto owned by a private company.
    - bardworx 4y ago
      Sorry, not in the ecosystem (clearly). Why not? Just curious.
      - moralestapia 4y ago
        No problem, here's some context, https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
    - olliej 4y ago
      In fairness this is as opposed to Go? Swift? Rust? Java? C#? Then C and C++ are defacto controlled by private companies: Google+Apple do pretty much all the clang development, MS does MSVC - if they choose not to implement a feature that’s approved, or implement one that isn’t, that is the de facto standard. You can argue it would require all three to agree on something, but that’s still essentially making WG21 somewhat irrelevant.
      - spookie 4y ago
rgovostes 4y ago
I was very confused by what the author is pointing out in the opening Point / Print example. ("[T]he compiler is allowed to convert that to a T" -> wait, why did the compiler change a struct to an int32?) I think this boils down to: Carbon defaults to passing parameters that fit in a single register by value, and all others by const reference. This affects a few things you might take for granted in C++, like whether you can take a reference to a parameter. The opening example is showing two samples of Carbon and the equivalent C++ code, noting that the "undecorated" parameter `p : Point` is equivalent to `const Point& p` (pass by const reference to a struct) and `x : i32` is equivalent to `std::int32_t x` (pass by value).
- mgaunard 4y ago
  What's weird is that Point would fit in a register as well.
bbkane 4y ago
I really think the most exciting feature of Carbon (indeed, it's justification for existence) is its backwards compatibility with C++, followed closely by it's more modern and flexible governance structure. Even the docs in the repo say you should avoid Carbon unless you have lots of C++ code you need to interact with.
- usrnm 4y ago
  Some of the biggest problems with C++ come from its backwards compatibility with C. Yes, it wins you users in the short term, but it's a pain to support as both languages evolve
  - olliej 4y ago
    The binary compatibility is the big deal. The other safe languages have explicitly taken the view the interop with C++ is bad, and so we should instead do interop with the significantly less safe C instead. The real killer is that the lack of any interaction with C++ means that you can’t do any real incremental adoption of one of those safe languages in any big security critical projects. Saying that the solution to C++ is to just not use it ignores the reality that C++ exists, and large projects in C++ exist. It doesn’t matter if you don’t like C++. The final problem with the safe languages - with the exception of swift - is that they are all hell bent on not providing even just basic ABI stability. It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. So I can have two libraries both written in rust, and the entire safety of it is contingent on each library talking to the other through a C API.
    - pjmlp 4y ago
      .NET has always supported interop with C++, first with Managed C++, then C++/CLI, and nowadays via Windows Runtime (C++/CX and C++/WinRT). Likewise JNI has always had support for COM like models, and the C API is written in such way that the struct layouts can be used as C++ classes instead, with implicit this on method calls.
    - 4y ago
Animats 4y ago
That's been done before. The original Modula 1 compiler had that. In a language where the default parameter mode is a read-only reference, it's an obvious optimization. The reverse is true. Anything passed by value can be treated as const reference by the compiler if the compiler knows enough about access and lifetime. The compiler must be able to determine that the parameter is neither deallocated nor modified while the function is using it. Rust compilers should be able to do that.
- mhh__ 4y ago
  D and I think Fortran can also do this
- dfawcus 4y ago
  The MIPS NUBI ABI from 2005 also proposed this for C: ftp://ftp.linux-mips.org//pub/linux/mips/doc/NUBI/MD00438-2C-NUBIDESC-SPC-00.20.pdf Section 3.4, page 21: "Arguments: [...] Derived types (structures etc) and non-standard scalar types are passed in a register if and only if their memory- stored image is register-size aligned and fits into a register. [...] All other arguments are passed by reference. The callee must copy the argument if it writes it or takes its address."
NonNefarious 4y ago
An old Apple UI kit has an "exciting" feature?
- olliej 4y ago
  Someone didn’t read the article :)
  - NonNefarious 4y ago
    You shouldn't have to. The headline should tell you what it's about.
- zascrash 4y ago
  It's about Carbon Language (from google) not the framework. https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang
Denvercoder9 4y ago
Maybe I'm missing something, but I don't see what's special about Carbon here. In C++ the compiler can also optimize pass-by-const-reference to pass-by-value, and they do. It just can't do it across an ABI boundary, but that should only be an issue with dynamic libraries, and Carbon has to follow the standard ABI there as well. Just make sure the compiler knows it doesn't have to follow the standard ABI for every symbol in your program, e.g. by enabling LTO and setting -fvisibility=hidden. See what happens `add` is made static: https://godbolt.org/z/KsqxP5Pxh https://godbolt.org/z/KsqxP5Pxh (I also had to change foo() to avoid the compiler hardcoding the result of the single call in `add`).
- moralestapia 4y ago
  >Maybe I'm missing something, but I don't see what's special about Carbon here. It's nothing really out of the ordinary ... also that particular optimization is meager in practice (on the order of 1%?). I know everything improvement adds up, but the author talks about it as if it was a game changer. I like the enthusiasm, though :D.
  - kllrnohj 4y ago
    The "ABI now or never" paper suggests somewhere on the order of 5-10%, and that's without considering the escape pessimization. Especially with the rapid expansion of smart pointer usage (and for good reason!). Given the major selling point of C/C++ is performance, that's not an insignificant amount.
- olliej 4y ago
  I think the alias analysis “pro” is overblown, it’s UB to take the address of a parameter via any mechanism other than explicitly taking the address - which a compiler obviously sees, and because it’s UB the compiler optimizes is free to assume no one is taking the address. Then for any parameters that are passed by reference the compiler has to assume there are other references so there’s no gain. Honestly the only thing that really stood out as nice is the default pass by word-sized value, in the context of templates - it’s a thing that is achievable in C++, but requires a bunch of obnoxious additional templates that aren’t even part of the standard library so everyone ends up reimplementing the same cruft. Happily I believe there’s a proposal to add this exact functionality. I also loathe their desire to listen to the BNF maximalists insistence on not having any “ambiguity” from <>s. I’m sorry it’s clearly parseable, and <>s are the standard token for decades. Switching to []s doesn’t make it less conceptually ambiguous, if anything it makes it more ambiguous to a human reader. The only people who don’t want <>s are PLT academics obsessed with forcing their dragon book idea of what a grammar should be. You can’t argue you’re doing it because the ambiguity in a grammar or lexer is bad, because then you would also drop infix operators. Then in carbon the more reasonable adoption of pascal’s : notation for typing a variable or parameter removes the most common case of the supposedly terrible ambiguity anyway.
booleandilemma 4y ago
I get the impression this guy just wanted something to blog about.
- saagarjha 4y ago
  Is that not why everyone blogs?
tialaramex 4y ago
C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your program won't work. Carbon is still far from finished, but if objects needn't have addresses it can do the same as Rust here, and cheerfully handle A, B and C as merely counters, counting 1.6 billion, 1.4 billion and 1.8 billion respectively is fine. Empty tuples are indistinguishable, so I needn't worry about giving you back the "wrong" empty tuple when you remove one, I can just give you a fresh one each time and decrement the counter.
- Someone 4y ago
  I may be overlooking something, but I don’t see a realistic use case for having multiple empty tuples without an address. If you have those, I don’t see any way to discriminate between them. If so, why would you ever want to have more than one of a given type? Is there some template code that might accidentally try to create them?
  - _nhynes 4y ago
    Rust `Set<T>` is implemented as `Map<T, ()>`. Go is similar, but you have to do it manually. Zero-sized types mainly have use in generics (so yes-ish by templates, but not accidental).
    - Someone 4y ago
      Still, why would you ever have multiple, if there’s no way to discriminate between them because you can’t mutate them or obtain their address?
- zeusk 4y ago
  Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?
pyjarrett 4y ago
It's a bit early in its lifecycle to get too excited for features which already exist in other languages. Carbon is exciting because of C++ interoperability, but I already get this behavior today in Ada. type Point is record x, y, z : Interfaces.Integer_64; end record; procedure Print(p : Point); Is `p` passed by reference or value? The compiler chooses what it thinks is best--all parameters are considered `const` unless they're `out` parameters. There's some rules for classes (tagged types), uncopyable (limited) objects, and `aliased` parameters which are always passed by reference. I can't get a pointer type (access) out of the parameter to the function, since the accessibility rules prevent it: -- "constant" since we don't know if it is writable type Point_Access is access constant Point; Last_Printed : Point_Access := null; procedure Print(P : Point) is begin -- P'Access is sort of like C++ std::addressof(P) to get a "pointer" -- There's also P'Address to get the actual address, but then requires conversion to a pointer-like "access" type to be used. -- -- Compiler Error: "non-local pointer cannot point to local object" since Point_Access type is declared at a higher level Last_Printed := P'Access; -- If we really, really, want to do it, "I'm smarter than the compiler", you can force it... -- Think of "Unrestricted" and "Unchecked" as grep-able warnings signs of "this is potentially very dangerous" Last_Access := P'Unrestricted_Access; -- ... end Last_Printed; What about making and then trying to use a local pointer-like type? This doesn't work because you can only create pointer-like accesses to types which have been marked as `aliased`, since you don't know if there's a location you can point to which has the value. procedure Print (P : Point) is type Local_Access is access constant Point; -- Compiler Error: prefix of "Access" attribute must be aliased Ptr_Like : Local_Access := P'Access; -- Similar, "I am smarter than compiler" trick works here too... Ptr_Like : Local_Access := P'Unrestricted_Access; You can allow passing any arbitrary pointer into a function by providing `access`, but you're not allowed to store it, since you don't know which flavor of the pointer type it could be, e.g. if it points to something on the stack, or on the heap: type Point_Access is access constant Point; Last_Printed : Point_Access := null; -- Allow printing any pointer-like (access) to a point. procedure Print (P : access constant Point) is begin -- Compile Error: implicit conversion of anonymous access parameter not allowed Last_Printed := P; -- If we really, really want to do this, we can force it with a cast... Last_Printed := Point_Access (P); -- ... end Print;
ISL 4y ago
I'm sure the ship has sailed on Carbon's naming convention, but darn if that isn't a confusing article-title. It is interesting to contemplate the most-ambiguous and least-comprehensible/googleable name one might be able to give to a piece of software. "the"? "Biden"? "Russia"? "water"? "air"? "dog"? "person"? "!"? "?"? " "?
- labrador 4y ago
  Google engineers: "Let's make our languages hard to Google!" Google managers: "Whatever floats your boat. How about Go, Dart and Carbon?"
  - serial_dev 4y ago
    I've been a Dart developer for three years and had zero issues finding anything Dart related. I also had to write some Go, that was actually pretty bad in terms of searchability.
    - nathanlied 4y ago
      For me it has helped to write it as "golang"; usually Google seems to understand what I want and show me relevant results.
    - labrador 4y ago
      Now, but in the early days a Dart search was likely to bring up info about the Irish transportation system https://www.irishrail.ie/en-ie/about-us/iarnrod-eireann-services/dart-commuter https://www.irishrail.ie/en-ie/about-us/iarnrod-eireann-serv...
  - Cyberdog 4y ago
    Swift was annoying in the early days since searches would bring up info on the international payment system. Lua and PHP have nice searchability. At least, it's fairly easy to weed out results on the Portuguese moon and the Philippine peso.
    - 4y ago
glouwbug 4y ago
Aren't we just reinventing the wheel over and over at this point? Sure could us another Go, C wasn't doing functions well at all /s
axegon_ 4y ago
Dunno about the most exciting but the most irritating so far is seeing it up. Admittedly I didn't spent a lot of time trying(I didn't have all that much time today) but in the 40 minutes or so, I was unable to get it going. I'll go back to attempting tomorrow and make sense of the errors.
- TillE 4y ago
  I mean there's not even a toolchain yet, it's just an interpreter to play with, and you can use it on godbolt.org I'd only worry about compiling it yourself if you intend to participate in Carbon's development in the near future.
funstuff007 4y ago
> It has the usual cool features you expect from a modern language: useful generics Are they trolling Go here?
spullara 4y ago
Just like Java?
JadeNB 4y ago
I'm sure the name has been discussed endlessly already, but I was quite surprised to see a discussion of the exciting feature of a deprecated API! https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API)
nyanpasu64 4y ago
If you call a function with `f(large_struct, &large_struct)` and f() mutates through the second/pointer argument before reading the first/value argument, will its value change even though the function signature looks like a pass-by-value?
- nyanpasu64 4y ago
  Too late to edit, but related: https://news.ycombinator.com/item?id=27089184 https://news.ycombinator.com/item?id=27089184, immutable pointer aliasing, https://github.com/ziglang/zig/issues/4021 https://github.com/ziglang/zig/issues/4021.
lifeplusplus 4y ago
It's fair to say carbon shouldn't be the starter language that people should be learning
inoyau 4y ago
If this is the most exciting feature - Carbon is not that much exciting at all!
matrix_overload 4y ago
Spent a terrible amount of time hunting down C++ bottlenecks. It has almost never been about unintended copying of structs or classes. It usually boils down to someone assuming that a particular collection or algorithm won't be on the critical path, and using a lazy O(N^2) solution. Then the codebase grows, use cases shift, someone puts another O(N^2) algorithm around an existing O(N^2) and the whole thing explodes. Adding proper caching and switching to N*log(N) algorithms usually brings a DRAMATIC improvement (like 100x faster), while trying to squeeze out every unnecessary copy will only squeeze out about 10% of complexity.
- dthul 4y ago
  To chime in with my personal experience, I did actually lose almost two days on hunting down an unintended copy constructor call. The method expected a "const B&" but was called with a "const A&". It also happened to be called a lot. The actual type names were longer and very similar, and looking at the code it was hard to see they were different. Type B had a copy/conversion constructor from type A so every time the method was called all of the data contained in A would be cloned. I was very relieved when I finally found the issue but also wished that C++ wouldn't call (possibly expensive) constructors so hiddenly, even going so far as to not only do that for value types but even for reference types.
  - JonChesterfield 4y ago
    Implicit type conversions are a hazard. Iirc the constructor can be marked explicit to make call sites more obviously expensive.
chubs 4y ago
I searched on several sites to find out what their memory management strategy is but couldn’t figure it out. GC? ARC? Whatever Rust does? Would love to see where this fits. Exciting to see a neat new language though! Also my second favourite feature of rust and swift is Enums with associated values, I can’t see any info on this but I saw a blog mention they have it.
- markmark 4y ago
  I think it's manual memory management, but with effort made to make that easier to handle and easier for tooling to check. With a plan to have a memory safe subset at some time in the future but not as part of the 0.1 designs.
- mgaunard 4y ago
  Scope-bound resource management, like C++. GC and ARC are for people that need shared ownership, which is pretty much always a bad idea.
  - mihaigalos 4y ago
    So how do you implement multithreading if the above are a bad idea?
    - JonChesterfield 4y ago
      Deep copy on passing between threads. Interesting pros and cons to the performance of that vs sharing pointers.
      - mgaunard 4y ago
        There is no need to copy objects for multiple threads to refer to them. It's just that there is a single owner, and the other threads have a non-owning view only. You need strict control on the thread lifetime, which is enforced through the same single ownership system, in order to enforce this.
    - 4y ago
oxff 4y ago
Rust seems to have failed to be a drop-in replacement for C++.
- labrador 4y ago
  I thought D was the drop-in replacement for C++
- maxbond 4y ago
  It has interoperability with C++, but it hasn't ever been a drop-in replacement. They have different value propositons. There's room in this world for both Carbon and Rust to succeed and interoperate.
IIsi50MHz 4y ago
I really thought this was gonna be about carbon atoms and molecular interactions, in some kind of geeky, programmer-friendly analogy.
- vitiral 4y ago
  Me too, and I even already knew that Cabon the language exists!
mgaunard 4y ago
Advantage #3 is false. C++ already does this. The standard explicitly states that a parameter taken by value and initialized from an prvalue of the same type may elide the move constructor (which all implementations do).
tmpz22 4y ago
Language ecosystems for general purpose programming languages takes a long time to grow. We all know this. And yet here we are making college plans in the birthing room.
fwsgonzo 4y ago
I have to say, and pardon me for saying so, but Carbon seems to be utterly uninteresting to me. They are not solving any interesting problems that shows me that they are creating a modern language. As an example, look at this issue from the mold linker: https://github.com/rui314/mold/issues/584 https://github.com/rui314/mold/issues/584 They are looking at creating an embeddable custom dynamic linker in order to greatly reduce loading times, by fixing locations as the file gets loaded in. The equivalent in Carbon would (for example) be to create a new type of exception handling that changes how we think about exceptions, performance and their cost. Perhaps something like the static exceptions that Herb Sutter has been working on. Instead, they are not adding exceptions at all. You will have to excuse my disappointment.
- colesantiago 4y ago
  what sort of interesting problems do you want Carbon to solve for you?
- pjmlp 4y ago
  Carbon solves a very important problem, to realize Google's vision for C++ which they lost trying to make through ISO. That is all.
girvo 4y ago
My one annoyance with Carbon’s promise is the lack of ABI stability; I know why they are doing that, and I know that C++ has the same downside, but as someone who binds C libraries constantly in other languages and finds the pain of C++ and now likely Carbon frustrating, it makes me a little sad to see the same mistake repeated. A C++ replacement that is just as difficult to bind/link/work with in other languages as C++ itself just seems like a missed mark, despite the fact I know this is not on their priority list at all. I hope my read of this is wrong, and it will be easy to bind and link to from other languages after all.
- JonChesterfield 4y ago
  It's pretty much the reason for it to exist I think. C++ has painted itself into a corner wrt ABI, leaving space for a faster language to replace it.
t6jvcereio 4y ago
> Passing things by const T& is always good, right? After all, you’re avoiding a copy! I find the tone strange. I understand that the author doesn't believe the statement. But I've never met anyone for whom performance matters and believes this. So, who's the audience here?
titzer 4y ago
Carbon is what happens when you have a ton of experience programming in C++ and nothing else whatsoever. It is absolutely littered with joyful declarations of "hooray, we fixed this thing in C++", when in reality it absolutely bathed in the utter fictions of C++ and has no perspective on the entire universe of other things that we could base languages on. I give it a -1 on innovation, it's so obviously stuck in a cul-de-sac in the design space that I see no hope for it. "We'll get around to memory safety eventually". Riiight. That said, I'm glad they at least made the leap to, "Hey, we could actually use something other than C++?"
- cassepipe 4y ago
  This is just so unfair to a project whose explicitly stated purpose is to be a better C++ and just that to ease the transition and porting of code from one to the other. Even they say, if you are not working with a C++ codebase, don't bother using Carbon, use something else. Great shot but make sure to aim at the target next time.
  - titzer 4y ago
    Unsafe languages are fossil fuels and Carbon is natural gas. Yeah, a small improvement over coal, but an incrementalist addition that only reduces the magnitude, not the direction. Still digging in the wrong direction, IMHO. And I standby my original assessment that the design is very obviously lacking in long-term experience in another language.
- Shorel 4y ago
  I wish it was D.
- alrlroipsp 4y ago
  I suppose that's what you end up with if your stated goal is to replace C++. There already were several options instead of using C++, but some minds are wired in that way after many years of training.
- returningfory2 4y ago
  Carbon being "absolutely bathed in the utter fictions of C++" is a feature not a bug. The goal of Carbon is explicitly _not_ to be a new general purpose programming language. In the docs, the authors even advise people to use Rust instead for greenfield projects. The goal of Carbon is to support migrating existing C++ codebases to some new safer language.
DeathMetal3000 4y ago
I realize this is unrelated to the blog post but it is related to Carbon… If you are creating an off-ramp language from C++ wouldn’t you keep the syntax as close to C++ as possible? The syntax looks like it would be more familiar to a Rust developer than a C++ developer.

243 points by obl 4y ago

At first I thought this was about Mac OS around the 9 and 10 times... but I suppose not everyone is going to make that link with this name.

mathgeek 4y ago
You’re certainly not the only one. It’s a confusing choice of naming.
- cflewis 4y ago
  I think the statute of limitations on “confusing name” when Mac OS Carbon was removed from OS X 10 years ago has passed.
  - morelisp 4y ago
    Carbon was removed two years ago.
    - astrange 4y ago
      Well, the API was. There's still bits of it internally driving the menu and event systems, and a lot of app/icon/Finder behaviors.
  - oneplane 4y ago
    Since those old operating systems are now vintage or retro, there have been a few people porting things like Rust, Go and Swift to older Mac OS versions (the ones that use the Toolbox ROM) which was also in the news here. There is of course no 'registry of allowed names that have aged-out' but there are probably other creative names one could come up with.
  - olliej 4y ago
    Yeah, I was confused by the name carbon, but am able to recognize that what I think of by default is not relevant anymore.
- Someone 4y ago
  I hope they picked that name for the same reason Apple picked it: because all life is built on carbon.
  - oneplane 4y ago
    Or because Carbon as an element is "C" and "C" is also the language the framework was built for.
    - Maursault 4y ago
      Well, Apple was a little clever with Carbon for this reason, because it was a C based API. I'm not sure how you get Carbon from C++.
      - tambourine_man 4y ago
        Also, the UI was called Aqua. So Aqua + Carbon is an interesting metaphor for an OS ecosystem.
      - schoen 4y ago
        Apparently, although it's not likely to occur under most conditions, you can form a monatomic carbon C²⁺ ion by shooting a laser into very high-temperature carbon: https://sciencetrends.com/the-charge-of-a-carbon-ion/ https://sciencetrends.com/the-charge-of-a-carbon-ion/ https://aip.scitation.org/doi/10.1063/1.4966987 https://aip.scitation.org/doi/10.1063/1.4966987 "Up to C⁴⁺ ions are observed." And I guess you could also write the C²⁺ ion as "C⁺⁺" if you wanted. :-)
        Dylan16807 4y ago
        That just makes the comparison worse, if it's difficult and unstable and almost immediately sheds the +s.
rgovostes 4y ago
Apple's Cocoa framework itself reused the name of a 90's visual programming language for kids developed by its own Advanced Technology Group. It was certainly a play on "java for kids." https://en.wikipedia.org/wiki/Stagecast_Creator https://en.wikipedia.org/wiki/Stagecast_Creator
- lioeters 4y ago
  That's the first time I heard of Cocoa as "Java for kids". How cute!
sedatk 4y ago
I mean, it's at least a bit less ambiguous than Go.
hinkley 4y ago
I got as far as “surely they can’t be talking about OS 9, someone must have recycled the name”

ArrayBoundCheck 4y ago

Calling convention? That's the most exciting feature? It doesn't boost productivity, reduce compile times, offer a larger standard library or create a boost a reasonable language would provide? No thanks google. I've been saying that for years now. You jumped the shark

flumpcakes 4y ago
The author has expertise in C++ and is excited about a C++-like language that addresses the pain point of C++'s calling convention which will _never_ be fixed by the standards committee due to their commitment on backwards compatibility. This was not an overview of the language, so this comment seems a little uncharitable to the author.
- ArrayBoundCheck 4y ago
  Having slightly better optimizations due to changing ABI doesn't sound worth the friction of having another language in the codebase. Especially when the guys who invented it (google) is famous for sunsetting things and couldn't get their peers to use bazel, the other thing google invented I don't care if this sounds uncharitable, I see the pitfalls and I seen so many people get sucked in to prior pitfalls

fourthark 4y ago

This is mostly a Google project? Unclear from the repo who is sponsoring it.

bardworx 4y ago
Microsoft. - don’t listen to me, it’s Google.
- moralestapia 4y ago
  It's Google but yes, another instance of Embrace, Extend and Extinguish. I hope this doesn't take off, with my sincere apologies to the ones who have been working hard on this. The last thing the C/C++ ecosystem needs is becoming de facto owned by a private company.
  - bardworx 4y ago
    Sorry, not in the ecosystem (clearly). Why not? Just curious.
    - moralestapia 4y ago
      No problem, here's some context, https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
  - olliej 4y ago
    In fairness this is as opposed to Go? Swift? Rust? Java? C#? Then C and C++ are defacto controlled by private companies: Google+Apple do pretty much all the clang development, MS does MSVC - if they choose not to implement a feature that’s approved, or implement one that isn’t, that is the de facto standard. You can argue it would require all three to agree on something, but that’s still essentially making WG21 somewhat irrelevant.
    - spookie 4y ago

rgovostes 4y ago

I was very confused by what the author is pointing out in the opening Point / Print example. ("[T]he compiler is allowed to convert that to a T" -> wait, why did the compiler change a struct to an int32?) I think this boils down to: Carbon defaults to passing parameters that fit in a single register by value, and all others by const reference. This affects a few things you might take for granted in C++, like whether you can take a reference to a parameter. The opening example is showing two samples of Carbon and the equivalent C++ code, noting that the "undecorated" parameter `p : Point` is equivalent to `const Point& p` (pass by const reference to a struct) and `x : i32` is equivalent to `std::int32_t x` (pass by value).

mgaunard 4y ago
What's weird is that Point would fit in a register as well.

bbkane 4y ago

I really think the most exciting feature of Carbon (indeed, it's justification for existence) is its backwards compatibility with C++, followed closely by it's more modern and flexible governance structure. Even the docs in the repo say you should avoid Carbon unless you have lots of C++ code you need to interact with.

usrnm 4y ago
Some of the biggest problems with C++ come from its backwards compatibility with C. Yes, it wins you users in the short term, but it's a pain to support as both languages evolve
- olliej 4y ago
  The binary compatibility is the big deal. The other safe languages have explicitly taken the view the interop with C++ is bad, and so we should instead do interop with the significantly less safe C instead. The real killer is that the lack of any interaction with C++ means that you can’t do any real incremental adoption of one of those safe languages in any big security critical projects. Saying that the solution to C++ is to just not use it ignores the reality that C++ exists, and large projects in C++ exist. It doesn’t matter if you don’t like C++. The final problem with the safe languages - with the exception of swift - is that they are all hell bent on not providing even just basic ABI stability. It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. So I can have two libraries both written in rust, and the entire safety of it is contingent on each library talking to the other through a C API.
  - pjmlp 4y ago
    .NET has always supported interop with C++, first with Managed C++, then C++/CLI, and nowadays via Windows Runtime (C++/CX and C++/WinRT). Likewise JNI has always had support for COM like models, and the C API is written in such way that the struct layouts can be used as C++ classes instead, with implicit this on method calls.
  - 4y ago

Animats 4y ago

That's been done before. The original Modula 1 compiler had that. In a language where the default parameter mode is a read-only reference, it's an obvious optimization. The reverse is true. Anything passed by value can be treated as const reference by the compiler if the compiler knows enough about access and lifetime. The compiler must be able to determine that the parameter is neither deallocated nor modified while the function is using it. Rust compilers should be able to do that.

mhh__ 4y ago
D and I think Fortran can also do this
dfawcus 4y ago
The MIPS NUBI ABI from 2005 also proposed this for C: ftp://ftp.linux-mips.org//pub/linux/mips/doc/NUBI/MD00438-2C-NUBIDESC-SPC-00.20.pdf Section 3.4, page 21: "Arguments: [...] Derived types (structures etc) and non-standard scalar types are passed in a register if and only if their memory- stored image is register-size aligned and fits into a register. [...] All other arguments are passed by reference. The callee must copy the argument if it writes it or takes its address."

NonNefarious 4y ago

An old Apple UI kit has an "exciting" feature?

olliej 4y ago
Someone didn’t read the article :)
- NonNefarious 4y ago
  You shouldn't have to. The headline should tell you what it's about.
zascrash 4y ago
It's about Carbon Language (from google) not the framework. https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang

Denvercoder9 4y ago

Maybe I'm missing something, but I don't see what's special about Carbon here. In C++ the compiler can also optimize pass-by-const-reference to pass-by-value, and they do. It just can't do it across an ABI boundary, but that should only be an issue with dynamic libraries, and Carbon has to follow the standard ABI there as well. Just make sure the compiler knows it doesn't have to follow the standard ABI for every symbol in your program, e.g. by enabling LTO and setting -fvisibility=hidden. See what happens `add` is made static: https://godbolt.org/z/KsqxP5Pxh https://godbolt.org/z/KsqxP5Pxh (I also had to change foo() to avoid the compiler hardcoding the result of the single call in `add`).

moralestapia 4y ago
>Maybe I'm missing something, but I don't see what's special about Carbon here. It's nothing really out of the ordinary ... also that particular optimization is meager in practice (on the order of 1%?). I know everything improvement adds up, but the author talks about it as if it was a game changer. I like the enthusiasm, though :D.
- kllrnohj 4y ago
  The "ABI now or never" paper suggests somewhere on the order of 5-10%, and that's without considering the escape pessimization. Especially with the rapid expansion of smart pointer usage (and for good reason!). Given the major selling point of C/C++ is performance, that's not an insignificant amount.
olliej 4y ago
I think the alias analysis “pro” is overblown, it’s UB to take the address of a parameter via any mechanism other than explicitly taking the address - which a compiler obviously sees, and because it’s UB the compiler optimizes is free to assume no one is taking the address. Then for any parameters that are passed by reference the compiler has to assume there are other references so there’s no gain. Honestly the only thing that really stood out as nice is the default pass by word-sized value, in the context of templates - it’s a thing that is achievable in C++, but requires a bunch of obnoxious additional templates that aren’t even part of the standard library so everyone ends up reimplementing the same cruft. Happily I believe there’s a proposal to add this exact functionality. I also loathe their desire to listen to the BNF maximalists insistence on not having any “ambiguity” from <>s. I’m sorry it’s clearly parseable, and <>s are the standard token for decades. Switching to []s doesn’t make it less conceptually ambiguous, if anything it makes it more ambiguous to a human reader. The only people who don’t want <>s are PLT academics obsessed with forcing their dragon book idea of what a grammar should be. You can’t argue you’re doing it because the ambiguity in a grammar or lexer is bad, because then you would also drop infix operators. Then in carbon the more reasonable adoption of pascal’s : notation for typing a variable or parameter removes the most common case of the supposedly terrible ambiguity anyway.

booleandilemma 4y ago

I get the impression this guy just wanted something to blog about.

saagarjha 4y ago
Is that not why everyone blogs?

tialaramex 4y ago

C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your program won't work. Carbon is still far from finished, but if objects needn't have addresses it can do the same as Rust here, and cheerfully handle A, B and C as merely counters, counting 1.6 billion, 1.4 billion and 1.8 billion respectively is fine. Empty tuples are indistinguishable, so I needn't worry about giving you back the "wrong" empty tuple when you remove one, I can just give you a fresh one each time and decrement the counter.

Someone 4y ago
I may be overlooking something, but I don’t see a realistic use case for having multiple empty tuples without an address. If you have those, I don’t see any way to discriminate between them. If so, why would you ever want to have more than one of a given type? Is there some template code that might accidentally try to create them?
- _nhynes 4y ago
  Rust `Set<T>` is implemented as `Map<T, ()>`. Go is similar, but you have to do it manually. Zero-sized types mainly have use in generics (so yes-ish by templates, but not accidental).
  - Someone 4y ago
    Still, why would you ever have multiple, if there’s no way to discriminate between them because you can’t mutate them or obtain their address?
zeusk 4y ago
Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?

pyjarrett 4y ago

It's a bit early in its lifecycle to get too excited for features which already exist in other languages. Carbon is exciting because of C++ interoperability, but I already get this behavior today in Ada. type Point is record x, y, z : Interfaces.Integer_64; end record; procedure Print(p : Point); Is `p` passed by reference or value? The compiler chooses what it thinks is best--all parameters are considered `const` unless they're `out` parameters. There's some rules for classes (tagged types), uncopyable (limited) objects, and `aliased` parameters which are always passed by reference. I can't get a pointer type (access) out of the parameter to the function, since the accessibility rules prevent it: -- "constant" since we don't know if it is writable type Point_Access is access constant Point; Last_Printed : Point_Access := null; procedure Print(P : Point) is begin -- P'Access is sort of like C++ std::addressof(P) to get a "pointer" -- There's also P'Address to get the actual address, but then requires conversion to a pointer-like "access" type to be used. -- -- Compiler Error: "non-local pointer cannot point to local object" since Point_Access type is declared at a higher level Last_Printed := P'Access; -- If we really, really, want to do it, "I'm smarter than the compiler", you can force it... -- Think of "Unrestricted" and "Unchecked" as grep-able warnings signs of "this is potentially very dangerous" Last_Access := P'Unrestricted_Access; -- ... end Last_Printed; What about making and then trying to use a local pointer-like type? This doesn't work because you can only create pointer-like accesses to types which have been marked as `aliased`, since you don't know if there's a location you can point to which has the value. procedure Print (P : Point) is type Local_Access is access constant Point; -- Compiler Error: prefix of "Access" attribute must be aliased Ptr_Like : Local_Access := P'Access; -- Similar, "I am smarter than compiler" trick works here too... Ptr_Like : Local_Access := P'Unrestricted_Access; You can allow passing any arbitrary pointer into a function by providing `access`, but you're not allowed to store it, since you don't know which flavor of the pointer type it could be, e.g. if it points to something on the stack, or on the heap: type Point_Access is access constant Point; Last_Printed : Point_Access := null; -- Allow printing any pointer-like (access) to a point. procedure Print (P : access constant Point) is begin -- Compile Error: implicit conversion of anonymous access parameter not allowed Last_Printed := P; -- If we really, really want to do this, we can force it with a cast... Last_Printed := Point_Access (P); -- ... end Print;

ISL 4y ago

I'm sure the ship has sailed on Carbon's naming convention, but darn if that isn't a confusing article-title. It is interesting to contemplate the most-ambiguous and least-comprehensible/googleable name one might be able to give to a piece of software. "the"? "Biden"? "Russia"? "water"? "air"? "dog"? "person"? "!"? "?"? " "?

labrador 4y ago
Google engineers: "Let's make our languages hard to Google!" Google managers: "Whatever floats your boat. How about Go, Dart and Carbon?"
- serial_dev 4y ago
  I've been a Dart developer for three years and had zero issues finding anything Dart related. I also had to write some Go, that was actually pretty bad in terms of searchability.
  - nathanlied 4y ago
    For me it has helped to write it as "golang"; usually Google seems to understand what I want and show me relevant results.
  - labrador 4y ago
    Now, but in the early days a Dart search was likely to bring up info about the Irish transportation system https://www.irishrail.ie/en-ie/about-us/iarnrod-eireann-services/dart-commuter https://www.irishrail.ie/en-ie/about-us/iarnrod-eireann-serv...
- Cyberdog 4y ago
  Swift was annoying in the early days since searches would bring up info on the international payment system. Lua and PHP have nice searchability. At least, it's fairly easy to weed out results on the Portuguese moon and the Philippine peso.
  - 4y ago

glouwbug 4y ago

Aren't we just reinventing the wheel over and over at this point? Sure could us another Go, C wasn't doing functions well at all /s

axegon_ 4y ago

Dunno about the most exciting but the most irritating so far is seeing it up. Admittedly I didn't spent a lot of time trying(I didn't have all that much time today) but in the 40 minutes or so, I was unable to get it going. I'll go back to attempting tomorrow and make sense of the errors.

TillE 4y ago
I mean there's not even a toolchain yet, it's just an interpreter to play with, and you can use it on godbolt.org I'd only worry about compiling it yourself if you intend to participate in Carbon's development in the near future.

funstuff007 4y ago

> It has the usual cool features you expect from a modern language: useful generics Are they trolling Go here?

spullara 4y ago

Just like Java?

JadeNB 4y ago

I'm sure the name has been discussed endlessly already, but I was quite surprised to see a discussion of the exciting feature of a deprecated API! https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API)

nyanpasu64 4y ago

If you call a function with `f(large_struct, &large_struct)` and f() mutates through the second/pointer argument before reading the first/value argument, will its value change even though the function signature looks like a pass-by-value?

nyanpasu64 4y ago
Too late to edit, but related: https://news.ycombinator.com/item?id=27089184 https://news.ycombinator.com/item?id=27089184, immutable pointer aliasing, https://github.com/ziglang/zig/issues/4021 https://github.com/ziglang/zig/issues/4021.

lifeplusplus 4y ago

It's fair to say carbon shouldn't be the starter language that people should be learning

inoyau 4y ago

If this is the most exciting feature - Carbon is not that much exciting at all!

matrix_overload 4y ago

Spent a terrible amount of time hunting down C++ bottlenecks. It has almost never been about unintended copying of structs or classes. It usually boils down to someone assuming that a particular collection or algorithm won't be on the critical path, and using a lazy O(N^2) solution. Then the codebase grows, use cases shift, someone puts another O(N^2) algorithm around an existing O(N^2) and the whole thing explodes. Adding proper caching and switching to N*log(N) algorithms usually brings a DRAMATIC improvement (like 100x faster), while trying to squeeze out every unnecessary copy will only squeeze out about 10% of complexity.

dthul 4y ago
To chime in with my personal experience, I did actually lose almost two days on hunting down an unintended copy constructor call. The method expected a "const B&" but was called with a "const A&". It also happened to be called a lot. The actual type names were longer and very similar, and looking at the code it was hard to see they were different. Type B had a copy/conversion constructor from type A so every time the method was called all of the data contained in A would be cloned. I was very relieved when I finally found the issue but also wished that C++ wouldn't call (possibly expensive) constructors so hiddenly, even going so far as to not only do that for value types but even for reference types.
- JonChesterfield 4y ago
  Implicit type conversions are a hazard. Iirc the constructor can be marked explicit to make call sites more obviously expensive.

chubs 4y ago

I searched on several sites to find out what their memory management strategy is but couldn’t figure it out. GC? ARC? Whatever Rust does? Would love to see where this fits. Exciting to see a neat new language though! Also my second favourite feature of rust and swift is Enums with associated values, I can’t see any info on this but I saw a blog mention they have it.

markmark 4y ago
I think it's manual memory management, but with effort made to make that easier to handle and easier for tooling to check. With a plan to have a memory safe subset at some time in the future but not as part of the 0.1 designs.
mgaunard 4y ago
Scope-bound resource management, like C++. GC and ARC are for people that need shared ownership, which is pretty much always a bad idea.
- mihaigalos 4y ago
  So how do you implement multithreading if the above are a bad idea?
  - JonChesterfield 4y ago
    Deep copy on passing between threads. Interesting pros and cons to the performance of that vs sharing pointers.
    - mgaunard 4y ago
      There is no need to copy objects for multiple threads to refer to them. It's just that there is a single owner, and the other threads have a non-owning view only. You need strict control on the thread lifetime, which is enforced through the same single ownership system, in order to enforce this.
  - 4y ago

oxff 4y ago

Rust seems to have failed to be a drop-in replacement for C++.

labrador 4y ago
I thought D was the drop-in replacement for C++
maxbond 4y ago
It has interoperability with C++, but it hasn't ever been a drop-in replacement. They have different value propositons. There's room in this world for both Carbon and Rust to succeed and interoperate.

IIsi50MHz 4y ago

I really thought this was gonna be about carbon atoms and molecular interactions, in some kind of geeky, programmer-friendly analogy.

vitiral 4y ago
Me too, and I even already knew that Cabon the language exists!

mgaunard 4y ago

Advantage #3 is false. C++ already does this. The standard explicitly states that a parameter taken by value and initialized from an prvalue of the same type may elide the move constructor (which all implementations do).

tmpz22 4y ago

Language ecosystems for general purpose programming languages takes a long time to grow. We all know this. And yet here we are making college plans in the birthing room.

fwsgonzo 4y ago

I have to say, and pardon me for saying so, but Carbon seems to be utterly uninteresting to me. They are not solving any interesting problems that shows me that they are creating a modern language. As an example, look at this issue from the mold linker: https://github.com/rui314/mold/issues/584 https://github.com/rui314/mold/issues/584 They are looking at creating an embeddable custom dynamic linker in order to greatly reduce loading times, by fixing locations as the file gets loaded in. The equivalent in Carbon would (for example) be to create a new type of exception handling that changes how we think about exceptions, performance and their cost. Perhaps something like the static exceptions that Herb Sutter has been working on. Instead, they are not adding exceptions at all. You will have to excuse my disappointment.

colesantiago 4y ago
what sort of interesting problems do you want Carbon to solve for you?
pjmlp 4y ago
Carbon solves a very important problem, to realize Google's vision for C++ which they lost trying to make through ISO. That is all.

girvo 4y ago

My one annoyance with Carbon’s promise is the lack of ABI stability; I know why they are doing that, and I know that C++ has the same downside, but as someone who binds C libraries constantly in other languages and finds the pain of C++ and now likely Carbon frustrating, it makes me a little sad to see the same mistake repeated. A C++ replacement that is just as difficult to bind/link/work with in other languages as C++ itself just seems like a missed mark, despite the fact I know this is not on their priority list at all. I hope my read of this is wrong, and it will be easy to bind and link to from other languages after all.

JonChesterfield 4y ago
It's pretty much the reason for it to exist I think. C++ has painted itself into a corner wrt ABI, leaving space for a faster language to replace it.

t6jvcereio 4y ago

> Passing things by const T& is always good, right? After all, you’re avoiding a copy! I find the tone strange. I understand that the author doesn't believe the statement. But I've never met anyone for whom performance matters and believes this. So, who's the audience here?

titzer 4y ago

Carbon is what happens when you have a ton of experience programming in C++ and nothing else whatsoever. It is absolutely littered with joyful declarations of "hooray, we fixed this thing in C++", when in reality it absolutely bathed in the utter fictions of C++ and has no perspective on the entire universe of other things that we could base languages on. I give it a -1 on innovation, it's so obviously stuck in a cul-de-sac in the design space that I see no hope for it. "We'll get around to memory safety eventually". Riiight. That said, I'm glad they at least made the leap to, "Hey, we could actually use something other than C++?"

cassepipe 4y ago
This is just so unfair to a project whose explicitly stated purpose is to be a better C++ and just that to ease the transition and porting of code from one to the other. Even they say, if you are not working with a C++ codebase, don't bother using Carbon, use something else. Great shot but make sure to aim at the target next time.
- titzer 4y ago
  Unsafe languages are fossil fuels and Carbon is natural gas. Yeah, a small improvement over coal, but an incrementalist addition that only reduces the magnitude, not the direction. Still digging in the wrong direction, IMHO. And I standby my original assessment that the design is very obviously lacking in long-term experience in another language.
Shorel 4y ago
I wish it was D.
alrlroipsp 4y ago
I suppose that's what you end up with if your stated goal is to replace C++. There already were several options instead of using C++, but some minds are wired in that way after many years of training.
returningfory2 4y ago
Carbon being "absolutely bathed in the utter fictions of C++" is a feature not a bug. The goal of Carbon is explicitly _not_ to be a new general purpose programming language. In the docs, the authors even advise people to use Rust instead for greenfield projects. The goal of Carbon is to support migrating existing C++ codebases to some new safer language.

DeathMetal3000 4y ago

I realize this is unrelated to the blog post but it is related to Carbon… If you are creating an off-ramp language from C++ wouldn’t you keep the syntax as close to C++ as possible? The syntax looks like it would be more familiar to a Rust developer than a C++ developer.