I'm happier now that I moved to Rust from C++. No need for the interoperativity.
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
awwastor
the word you were looking for is "triumvirate" :D
VirtuousSaint
What? You don't like having incompatible C++ classes and Obj-C classes in the same language?
grimfang
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.
vladimirkraus
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.
phirenz
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
youtubehandlesux
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 😭 😂
alexitosworld
Hey ginger Bill, could you make a video giving us your thoughts on the Herb Sutter's Cpp Front (cpp2)?
Jacob
google: hit with go. miss with dart. looks like a miss with carbon.
androth
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. :)
tubeincompetence
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.
kimandre
Instructions unclear, rewriting my c++ in ALGOL 68
_supervolcano
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.
guillaumewenzek
Since you mentioned Compiler explorer. Are there any plans to have Odin in there?
arashirobana
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?
kennythegamer
Interop 2ways is ansolutely needed. Your entire OOP design falls apart otherwise.
jojje-
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.
pbholmen
I would be interested in your detailed opinion about Crystal!
fritzcobus
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
