Carbon Language - Final Conclusions (It's Probably Not For You)

Carbon Language - First Impressions: • Carbon Language - Firs...
Carbon Language - Who is it even for?: • Carbon Language - Who ...
Chandler Carruth - CppNorth 2022: • Carbon Language: An ex...
Carbon GitHub: github.com/carbon-language/ca...
Email: [e-mail]
GitHub: github.com/odin-lang/Odin
Patreon: / gingerbill
Twitter: / thegingerbill
KZbin: / gingergames

[@brendanhansknecht4650]

This was a really good summary!

I'm happier now that I moved to Rust from C++. No need for the interoperativity.

[@VirtuousSaint]

the word you were looking for is "triumvirate" :D

[@sickpilot]

Or trifecta

[@dawnadmin8119]

@@sickpilot A trifecta is picking the horses in first, second and third, or when the same party controls three branches of government. Here, he wanted the word for a committee of three people.

[@ska4dragons]

Triumvirate if you want people to think highly of your sophistication or intellect. Triarchy is the more effective word.

[@awwastor]

Rust is using a formalised system with RFCs for its contributions and at least for now it hasn’t turned into a comittee. Although, Rust’s 1.0 version was 7 years ago and the language is over a decade old, while Carbon is a way from being production-ready enough to have a 1.0 version

[@GingerGames]

Rust was initially designed by a small team still and didn't have the fully formalized system with RFCs until much later on.

[@arashirobana1549]

I don't know much about how pre-1.0 Rust was actually developed, but what I do know is, that they first implemented a working compiler, then started using it for Firefox and then did some significant changes to the language (including throwing out painstakingly developed parts of code). What has been always important is, that RFCs are only one step in the process. I feel like Carbon would be better of, if the core team would just implement whatever design they have for the language and allow people to try it out and then point out the rough edges and things they want to change. I looked at some discussions and it mostly went like this: Somebody presents some often extremely weird, but sometimes very reasonable idea, in both cases there is then some abstract discussion and finally some core team member concludes that sticking to the status quo is the best solution. That said Carbon will certainly become influential -- but maybe more in an Algol 60 kind of fashion.

[@awwastor]

@@arashirobana1549 I /think/ early on rust was used more for Servo than Firefox. And I was trying to communicate (although I did so badly) that the RFC style system may be more appropriate for a language that’s already quite developed with my remark about how old rust is.

[@nickskywalker2568]

Rust and Carbon have a different purpose. Rust puts memory safety first while Carbon puts C++ codebase integration first

[@stevenhe3462]

They have very different goals. Carbon is created to interface to C++ and not suck, which means it should please people (the committee). Rust is created to be funny (safe) so they already naturally piss many people off.

[@Jacob011]

Hey ginger Bill, could you make a video giving us your thoughts on the Herb Sutter's Cpp Front (cpp2)?

[@tubeincompetence]

Will be interesting to see where this goes in the future, but as said in the video, probably not the language for me. I can try some other languages. :)

[@soupertonic3579]

Liked that smash button!

[@alexitosworld]

I actually find extending existing types to retroactively conform to interfaces a very nice thing for API design, at least in the Swift ecosystem :) You made me laugh with the Objective-C++ comment, well no, you brought back nightmares 😭 😂

[@llothar68]

I still love Objective-C++ much more then Swift. I find Swift just like Kotlin almost unreadable and very complicated if you try to use it outside of very simple GUI layer programming tasks. Nobody would write hard algorithmitic code with them but for a GUI you need flexibility over everything else.

[@alexitosworld]

@@llothar68 As much as people loves to pretend this are just tools they are not, people likes one or another for multitude of personal reasons. I loved Objective-C, I found Objective-C++ an abomination, then felt in love with Swift like never before and consider Kotlin a "Swift without adult supervision". So is all question of taste and preferences ^^ everybody has their own

[@GingerGames]

First!

[@_supervolcano]

Instructions unclear, rewriting my c++ in ALGOL 68

[@arashirobana1549]

Since you mentioned Compiler explorer. Are there any plans to have Odin in there?

[@youtubehandlesux]

I've discovered something that's not related to this video, but kinda related to this channel: in C++23 it's possible to overload the [] operator with multiple arguments, so it's easy to do something like matrix3d[x, y, z] to get an element, which is a thing Odin already does. I'll probably keep using C++ for a little bit longer because of this, yay

[@per.nordlow]

Also possible in D. Since 10 years.

[@vladimirkraus1438]

I am a Qt programmer. I wish to use Qt with some more modern compiled language but all the bindings which I have tried just suck. They are definitely not a seamless programming experience. So I am stuck with C++ (which I like, but you know, it is C++). Unless Carbon succeeds and fulfils its promises. So I would say, that Carbon actually might be the language for me.

[@sacredgeometry]

Why do you need to use it with a more modern compiled language? Just use it with python (pyqt/ pyside). By that I dont mean write your application in it, just the UI. You can write the rest in C++. Thats what plenty of projects seem to do (Ableton I think do that with live, and Autodesk with Maya).

[@vladimirkraus1438]

@@sacredgeometry Of course, I do not NEED to but I WANT to. Python is slow, memory hungry and any refactoring is very error-prone as it is not checked by compiler. Not suitable for a pro-grade software. It is unusable for anything else than prototyping or dynamic plugins. I want my software to be as lean and fast as possible. If you ship Maya or Autodesk, then having a few more MB in memory consumption does not matter. But my software takes about 10 or 20 MBo f RAM (on Windows) and starts within a second. I do not want to wrap it into whole Python runtime which would make it multiple times bigger and slower. Until Carbon is ready (if it will ever be), I will stick with C++ of course.

[@GingerGames]

Have you tried D with Qt? It might actually be what you are looking for. But I'd argue that the problem isn't other compiled languages but rather their wrappers/bindings to Qt are just poorly done and not in keep with the original API nor the language itself.

[@vladimirkraus1438]

@@GingerGames Qt uses some pretty nonstandard ways (MOC, implicitly shared containers, its own string implementation etc.), so making really good bindings is not easy. I actually think these specialties of Qt will be a hard nut to crack for Carbon too.

[@thecollector6746]

@@sacredgeometry Python sucks for anything outside for what it was originally created for...which is low barrier of entry for quick and dirty scripting. People found it incredibly easy to pick up and of course thought that is all you need for writing large, non-trivial code bases and everything else where it is and is not well suited for.

[@kennythegamer1]

You say throughout this tri-part series that you love all the languages that have been popping up lately. As someone who has designed a language (and am finally getting around to developing, fully, my standard library and compiler), what advise would you give to help in gaining traction?

[@lewcreative]

Try taking out the things people aren't enjoying of languages in existence...then you are good to go.but, mind you you can't please everybody so, have a clear target in mind. And adopt features of the languages you love.

[@phirenz]

It's probably not "fair" to compare Carbon to the modern "c-replacement" languages like Odin, Zig, Nim or even Rust. The kind of languages that someone might pick if they had freedom to choose a language. It's not designed to directly compete with them. Carbon has one design goal, to kill c++. Not just at Google, Everywhere. And I'm casually optimistic that it might succeed at that goal. And we should judge it on that criteria. If Carbon hasn't made a massive impact to the number of c++ projects within 5 years (new projects are more likely to be started in Carbon than c++, old projects incorporating Carbon for newer parts of their codebase, if not doing massive rewrites), then we should consider Carbon to be a failure.

[@andrewdunbar828]

The fairest comparison might be to Swift.

[@GingerGames]

I hope "it" doesn't kill C++ and replace it, personally. I think C++ needs to be replaced by something else that doesn't have the baggage of C++, like Odin, Rust, Zig, etc. C++ is a dead-end in my opinion and Carbon will kind of keep it alive for longer rather than kill it.

[@phirenz]

I might be way more pessimistic about c++'s staying power than you. Without something like Carbon, I think c++ will stick around it's dominate position for ages, and nothing will dethrone it. I do agree with your view of "the majority of projects don't need proper inter-op with c++"; Writing c wrappers is usually pretty easy and not really a hindrance to actually programming in a language without inter-op. I think you underestimate just how much of a hindrance the lack of bi-directional c++ interop is to just the decision making process around switching away from c++. Since I do think c++ will stick around, I think the world will be much better off with carbon replacing large chunks of c++.

[@jackmordaunt5410]

@@phirenz Carbon keeps C++ around due to the fact it needs to superset it. Even if everyone wrote pure carbon in the future, C++ would still be haunting us from within carbon’s core design.

[@kuhluhOG]

you shouldn't forget that Zig has nice bi-directional interop with C (not C++ obviously, it doesn't have this as a goal)

[@fritzcobus]

I would be interested in your detailed opinion about Crystal!

[@grimfang4]

What? You don't like having incompatible C++ classes and Obj-C classes in the same language?

[@androth1502]

google: hit with go. miss with dart. looks like a miss with carbon.

[@vladimirkraus1438]

miss with dart? i do not think so. dart is extremely popular for use with flutter.

[@androth1502]

@@vladimirkraus1438 and that's pretty much the only place dart is used. it's a miss.

[@vladimirkraus1438]

@@androth1502 Being the language for the most popular mobile framework today (a maybe the most popular desktop GUI tomorrow) is a miss? Who are you to judge this?

[@GingerGames]

I'd also add that Dart as a language is bananacakes too in its design. It's all over the place and not coherent whatsoever. Go was a hit because, as I've said, it wasn't designed by Google effectively, but the old Bell Labs Plan 9 team.

[@androth1502]

@@GingerGames i've been doing some small projects with Go. i think if Odin had something like fyne, and easy to use, it would take off as a language to use for cross-platform desktop applications.

[@RoamingAdhocrat]

18:00 Kate Gregory! She's one of my favourite conference speakers.

[@philipbotha6718]

@16:10 Triumvirate?

[@random_bit]

final conclusions is an oxymoron 💀

[@kimandre336]

I do programming as a hobbyist and I really see Google trying way too hard to make a successor to C++. I think Google is much better off funding various open source libraries than making a new programming language. Go and Dart are more than enough for the time being.

[@arma5166]

they did a fine job on Go tho. maybe this is actually good for the future

[@FicoosBangaly]

Three people ruling is a triumvirate.

[@guillaumewenzek4210]

TBH Carbon talk was quite bad. Starting by saying "we all know C++ issues" without being more explicit about which issues you want to fix, leads to a lot of confusion/hype. Now everyone can assume that their personal problem with C++ will be fixed by Carbon. My guess is that like for Go they want a language which is easier for new hires that learned Python in school to ramp up, and remove some pitfalls (like having implicit copies, or null pointers). Coming from Chandler, I was hoping compilation speed and debug build performance would be a priority, but they didn't get a mention in the talk.

[@GingerGames]

They (the Carbon team) do actually know C++'s issues because they do work on the compilers BUT I am not sure that their alternatives/solutions are necessarily good ones. Knowing a problem doesn't mean you how to solve it.

[@GingerGames]

@André Marcondes Teixeira respect the developers time; don't waste it. There is little to no excuse to making a new language compile slowly, especially when it can be done extremely fast.

[@nngnnadas]

The word is (benevolent) triumvirate.

[@debugdesperado]

I think if they can bench a bit better (llvm C++ vs llvm Carbon) they may get some traction. Especially if tooling can make conversions straightforward. Part of what was driving this is C++ committee fatigue and their unwillingness to break ABI to improve unique ptr performance.

[@matthewmurrian9584]

True. Google can't accept that C++ isn't all about them. Narcissism, in a nutshell.

[@jojje3000-1]

Interop 2ways is ansolutely needed. Your entire OOP design falls apart otherwise.

[@pbholmen]

So, why would you need bidirectionality? Because your project doesn't live in a vacuum. Often it will have to interact with an external framework, like for instance when developing an audio plugin, like I do, pretty much every single usable framework is in c++. Why you would want to extend an already existing class? I don't understand the question. Precisely to keep the core interface slim, and extend it only for your project. If you have an external library or framework, and its functions return some type, having to pack it into your own type (or "embed", as you say) to extend its functionality sounds annoying to me. Why not use the values you receive from the external framework directly? "... it sounds like you're patching old code ...", yes, that's what a lot of us have to do, or rather, extend functionality of code that might be great, but that other people have written. This way you keep the line between the core functionality and your custom functionality clean.

[@TheSulross]

as Carbon is supposed to be to C++ as Swift is to Objective C, it makes sense in that context. The resources devoted to the project are kind of underwhelming at the moment but as the word is getting out about it, rather expect it will start to ramp up But yeah, if not wedded to C++, then other languages are more attractive. Indeed, the Carbon web site strongly encourgaes looking at Rust instead of Carbon if that is a possibility. Ah, one thing worth mentioning that will be different in Carbon vs C++ is that it will use generics instead of templates. This means that a generic class or function will get compiler type checked at its declaration and not at its instantiation (as with C++). This should lead to much improved compiler diagnostics around the use of generics. And can forward declared a generic type signature. (So Go lang has added generics in recent months.) Now as to other possibile languages, the short list looks to be: Zig, Odin, and possibly Vale (at least it has some interesting things going on but doesn't look to be as far along the language trajectory as Zig and Odin) Am thinking there's definitely an interest in a systems programming language successor to C and so far the best contenders for that may be Zig and Odin

[@KGSKGSKGSKGSKGS]

the word is triumvirate

[@SimGunther]

Basically a language of (former) Google (personnel), for Google, by Google, but Google randomly generated the language with its AI Ok I'm being facetious, but it just has that weird feeling despite being designed by actual people and a "community".

[@TheGag96]

I'm not super well-versed in the history of ALGOL and such, but wasn't ALGOL 68 widely considered a failure?? Or are you saying the language was still good, just difficult to implement and overlooked?

[@GingerGames]

ALGOL 68 may have been a failure but it was fundamental to the design of every language that came after it (for imperative and concurrent languages). There were many oddities to it (like with many languages) but when I say it was the best language designed by a committee, it does not mean I think it is a great language in general. There is still a lot to learn from it, even today.

[@sacredgeometry]

12:43 Open source language "design". Swift had so much promise, typescript did too. But like with many things in this world. Lots of highly opinionated people with really awful opinions. Often people who spend most of their time talking about programming not actually writing code professionally (which were probably the only people with enough time to dedicate enough time to contribute significantly or persistently to the language) had far too much opportunity of influence over them. I don't think design by committee is a good idea either. Every single language that has gone that way has gotten demonstrably worse as a result (typescript, C#, swift, python to name just a few). I haven't written in ALGOL so couldn't say.

[@igorfagundes2177]

!First

[@simonclark8290]

I don't think it is reasonable to make 'Final Conclusions' about a new programming language that is still in early development

[@GingerGames]

It's "Final Conclusions" as part of this three part video series; not final conclusions about an unfinished language. BUT I am an very experience language designer and language developer, and I can see where this language is going already.

[@simonclark8290]

@@GingerGames Let's put a pin in that and see where it ends up when 1.0 is released ;-)

[@GingerGames]

@@simonclark8290 I hope it improves! And I wish the best for its development.

[@heavymetalmixer91]

I wsh people could stop with the "it comes from Google so they will drop it after a few years, so it's not worth trying". If the language becomes good for certain purposes ('cause it's clearly not a general-purpose language) then forget it has anything to do with Google and use it. I hope this language succeeds in achieving its goals, but it's so green right now that it still needs several design changes.

[@GingerGames]

To be clear, I did not say nor imply that because it was from Google, it will be certainly dropped. It is true that Google does tend to drop support for many of its products, so I can completely understand why people will assume something like Carbon will be dropped. Go and Dart are exceptions to this rule because other tooling will depend on them, whilst other products they drop support for are not the base of other products (usually). Regarding hoping if this language succeeds or nots for its goals, I'm personally not sure if its goals are a good thing to strive for (even for extremely massive companies like Google).

[@heavymetalmixer91]

@@GingerGames Don't worry, I wasn't talking about you about the Google thing. Regarding the other topic I'm one of those few people who would love to see a real succesor to C++ for the gaming industry, so IMO there's a possibility with Carbon and Odin.

[@bigtymer4862]

Second :D

[@zactron1997]

When the Carbon talk included an off handed comment about not wanting to be so focused on security and safety as Rust, it was DOA for me. Why on Earth would you make a new compiled language designed for mass adoption with a worse compilation system than Rust at this point? IMO, it's the new gold standard other languages should be striving for. Anyway, Carbon will be as dead as AngularJS in a few hours so it's a moot point 😉

[@GingerGames]

Not everyone wants to use Rust because with its model of "safety" comes with many trade-offs which may or may not be useful to certain domains.

[@aperson4051]

Correctness is always a tradeoff I'm willing to make

[@GingerGames]

@@aperson4051 "Correctness" of what? It's quite a vague concept without something to ground it. And with "correctness", you do have costs to it too, and you have to weigh those costs compared to the alternatives.

[@bitskit3476]

...what? There was practically nothing about Carbon in this video at all. Was just 20 minutes of abstract rambling

[@vitalyl1327]

A C++ "successor" without a Turing-complete metaprogramming? Meh.

[@GingerGames]

Reading through the design spec, the metaprogramming language does appear to be Turing-complete already. And that may or may not be a good thing.

[@vitalyl1327]

@@GingerGames They support the current templates, with an intention to keep them only for interop with C++ and not as a first class feature of the language. And languages without a proper fully functional metaprogramming are useless.

[@GingerGames]

@@vitalyl1327 I'd be very cautious making that statement. You'd be heavily surprised how little compile time (not runtime) metaprogramming you need, especially when you have language features to accomplish what you require. Metaprogramming is a very useful tool, but it doesn't necessarily need to be in the language itself, but can be easily done if the compiler is just a package of the core library.

[@vitalyl1327]

@@GingerGames I need as much compile-time metaprogramming as I can get. You'd be surprised to learn what you can do with it, and you cannot do anything comparable with fixed languages. Metaprogramming is absolutely necessary as an easiest tool for constructing *composable* domain-specific languages. With a metaprogramming, I can turn any meta-language into any other language, existing or not yet invented. The other way is not possible. If you have a compiler as a separate tool, you won't get any of this functionality, you won't be able to make your languages composable, you won't get any proper reflection for all your intermediate languages.

[@GingerGames]

@@vitalyl1327 For Domain Specific Languages (DSLs), I have always preferred making a meta-programmer i.e. a compiler/transpiler. It's easier to make, will produce much better code than a _generic_ tool (i.e. generalize metaprogramming in a language), easier to optimize, will be tailored to the SPECIFIC problem, and so much more. To be clear, I am not against metaprogramming (when it's actually required) but I've found the vast majority of GENERIC metaprogramming features in languages are subpar and rarely good enough for my needs. And having a stage before your main language's compilation is rarely an issue, and is usually a hell of a lot faster too (which is unsurprising if you understand how most compilers work). Having a compiler as a separate tool, you get ALL OF THIS FUNCTIONALITY and more. You are completely underestimating what is possible because you already have the tools easily at hand, compared to other languages.