Carbon Language: An experimental successor to C++ - Chandler Carruth - CppNorth 2022

[@samuelpope7798]

I am not sure what to make of Carbon. I am carbon neutral.

[@ryanwooley4111]

The big question doesn't seem to be why should you choose Carbon over Rust/Go/Nim/Python/etc. The better question is, why should you choose Carbon over modern C++? The main use case for Carbon is that you already have mammoth projects/libraries in C++ (that you are not about to rewrite in a new language) but wish for a better language than C++ to use without introducing interoperability headaches. So the big question then becomes, is introducing Carbon into your existing C++ code a better alternative than sticking with all C++? From what I have seen so far, I am not convinced.

[@vasiliynkudryavtsev]

Exactly. The biggest problem is not the "old fashioned" C++ syntax, but in some parts outdated standard library. No wonder every framework remakes own version of std::string. New syntax will not solve the problem. New syntax + new STL maybe could, but why just not drop the new syntax then?

[@technicholy1299]

I'm a kotlin dev and I can tell you this looks very, very close to kotlin. I would say the argument for this is five years from now when there are plenty of programmers, but the chances of them being proficient in the language you are using is slim. Carbon -> Kotlin or Kotlin -> Carbon is going to be a short bridge outright and much shorter than the bridge to C++.

[@zygimantasbruzgys497]

Isn't the whole purpose of this presentation is to answer your question "why should you choose Carbon over modern C++"?

[@LyubomyrSemkiv]

@@technicholy1299 I’m wondering, if it possible to write kotlin without java knowledge? It seems like if we go this way we need to know both languages.

[@thecollector6746]

For exactly the reasons he laid out. 1. You have a not-insignificant code base in C++ 2. You are tired of C++ 3. Rust C++ interop is basically non-existant and will never be a thing 4. Nim : Nim has no C++ interop. No one cares about Nim 5. GoLang has no C++ interop and typically does is not conscidered for C++ use cases 6. Python...again...that whole thing about C++ interop and we need something that is even remotely as performant as C++ 7. You haven't heard of D(DLang) yet which has had bar none THE BEST C++ interop for the past 20 years, that is battle tested, but doesn't have the marketing arm of some major Tech Company behind it.

[@MatthewChaplain]

24:00 This "impl as" construct reminds me of the concept maps that were proposed for C++0x. I always thought that that was a great idea because it removed a lot of type-erasure noise from the normal implementation of that. I'm happy to see it remembered.

[@0xedb]

"It's a bit rusty..." Rust will always find its way into a C++ talk😁

[@guyarbel2387]

Im going to borrow this joke

[@pmcgee003]

@@guyarbel2387 Make sure you rewind it before you bring it back. 😉

[@bocckoka]

well it's a pretty large elephant in that room

[@sebastiangesemann6775]

@@guyarbel2387 Is that going to be a shared or mutable borrow?

[@maximkovalkov1334]

If you’re interested in Carbon, take a look at Zig: it is a new language still very much in development which tries to do basically the same thing but with respect to C. A lot of the design choices are almost identical to the ones presented here (function and variable decl syntax, immutable parameters, generics as “functions returning a type”, explicit this, no global namespace…). But it is sticking closer to C, so e.g. there’s no inheritance, no (compiler-generated) vtables, no overloading, etc. In a way it ends up having _less_ features than C while being much more expressive… Just something to have on your radar, if you’d like to compare their progress

[@Ehrnsmersh]

Briefly mention Zig at 50:49

[@DerDoMeN]

Funny enough that's the last language before this one where I couldn't understand why it's getting the support... Call me old fashioned but I'd really need somebody to explain to me why making so many new languages with almost no added value is a good idea when compared to adding a new functionality to an existing language? I hear an awful lot about "language complexity" but for me writing in Java/C# is complex because I'm a tourist there and am trying to think and write C++ in those languages. And I thought that that's just my problem but then I saw a really good Java programmer write C++ and stumble on an awful lot of mines that I didn't even know existed because I'd never write such C++ code as simpler/alternative things existed that were more intuitive to me... So yeah... Writing idiomatic style of one language in another is a painful experience and no amount of language simplification will help you there (actually it often does the exact opposite). I'd be honestly really grateful for a good explanation of why this is a good idea.

[@egor_ivkov]

The thing is Rust - the main competitor in this space - already has very good interop with C. But as they mention in this talk the same cannot be said about C++

[@RickeyBowers]

@@DerDoMeN many of these new language seem to be aimed at problem solving at scale: both in terms of team sizes and technology. Old languages were never engineered with this intent and their default semantics make shoe-horning new features problematic. Of course, we can approach a project with our own over-arching rules -- restricting the language to our own utility. I do that in assembly all the time - without creating structure at multiple scales the design is completely amorphous and becomes impossible to communicate. Having a common model from multiple perspectives accelerates understanding of foreign code.

[@drygordspellweaver8761]

@@DerDoMeN You're asking why a new language is better than adding functionality to an existing language then go on to immediately cite an example where a programmer "stumbles on an awful lot of mines". Can you not see that you just answered your own question? It's not hard. There is a tremendous amount of bloat and cruft in these backwards compatible "one language to rule them all" behemoths to make them impossible to traverse. Compile times are horrendous, syntax and semantics is muddled and all over the place. It's better to just start new.

[@flpshmn]

And here comes the tech recruiters today with "Job Experience requirement: 4+ years in Carbon"

[@tacokoneko]

truest comment i began learning C++ in 2010 and i still have not anywhere near finished, not even close. and in that time they invented 3 whole other replacements Rust Zig and Carbon and i am expected to know all???

[@TheMR-777]

I love the way slides are colored in KZbin's Dark Color. It felt so natural on KZbin, that I was wondering why it's feeling so soothing :), then I observed the coloring. That was a Great idea in my opinion!

[@frydac]

the white and red bands at the top and bottom don't bother you?

[@MrAcuriteOf1337]

Google couldn't go four years (2015 to 2019) without critically breaking Tensorflow. In what universe would anyone want to build up a serious codebase, when the underlying language was subject to the whims of the most capricious corporation besides Tesla?

[@Chalisque]

Experiments need to be done. Stuff needs to be tried out. If Carbon doesn't work well, it doesn't work well. But if we don't try stuff out...

[@TheSulross]

Zig, Odin, Vale are the most interesting new languages (that don't have integral garbage collection), which each one is very interesting in it's own right - worth looking at and being aware of each of these particular new languages. Three things - perhaps I missed: 1) Is the C preprocessor banished in Carbon? 2) Does Carbon follow the exception throwing of C++ or will it have a different approach? 3) Will there be implict type conversions or will conversion need to be explicitly handled?

[@WouterStudioHD]

Rust is the most interesting new language.

[@ViktorFerenczi]

@@WouterStudioHD I agree. Just use Rust and Zig and avoid C++ at all costs.

[@llothar68]

@@WouterStudioHD Rust is ugly and the borrow checker is getting more often in your way than helping you, unless you are a real beginner with no self disciplin and memory handling/MT experience.

[@drygordspellweaver8761]

JAI is the only one im waiting for.

[@antonw8134]

I will continue to use c++ as c (with templates). Best of luck on your new language adventures!

[@vladimirkraus1438]

You do not even use namespaces? Oh no... what a shame. And no function or operator overloading?

[@EdgarVillegasG]

Best wisdom advice a have read in year. 🙂👍

[@solhsa]

See also: orthodox c++

[@radarsmutny8462]

hi Anton, do you have some tutorial for this?

[@2002budokan]

I played around this idea awhile and then I falled in love with Rust.

[@galchinsky]

18:55 the moment where the developers became so deep in the game of the "language developmemt" and forgot about ergonomics. [addr me: Self*] to determine a non static method, does the rest of the language has the same mindset of descisions?

[@DerDoMeN]

I'm quite skeptical atm regarding this project... Then again I'm also the one that rants every time somebody makes a new "better" language because they had one good idea that would be much better served if added to one of the existing languages so yeah... The thing that pains my eyes the most is the "modern" and "non cryptic" syntax that I already dislike from all the other languages that tried to look like this... I understand that it's easier to parse for a compiler but it's torture for my eyes (and fingers in case I have to constantly write private in front of each function/variable). I might be a minority but for me after reading the github stuff and watching this video, I can't really see this as the future of C++. Then again... I'm also the one that can't wrap his head around "bad defaults in C++" as they never bothered me enough to care about them... So maybe I really am a minority?

[@gtdcoder]

17:37 C++ structs are also public by default. C++ classes are private by default, so both approaches are available. And backwards compatibility is not the only reason C++ is harder to modernize. It’s the design principle of “you don’t pay for what you don’t use”. Seems like Carbon is just trying to add a lot of new syntactic sugar to C++ but unless it can also adhere to the same principle, all that sugar will have a performance penalty and C++ will continue to be favored.

[@dynfoxx]

Just an FYI C++ had many features that you have to pay for when you don't use them. Carbon may add more but it has the option to fix a lot of these issue. To make C++ more in line with what its trying to be. Will it work, who knows but C++ does not fallow its own rules perfectly either.

[@ciberman]

That external interface implementation looks amazing. I hope we would have this in C#.

[@solhsa]

Check out ruby's FFI. Really simple.

[@yznaiber7598]

extension methods do the same thing in c#

[@msclrhd]

@@yznaiber7598 Extension methods are powerful, but sometimes it would be useful to implement an interface on an existing class. An example of this is for the adapter pattern, such as when interoperating with other libraries.

[@deNudge]

I would propose a function return type declaration syntax with a colon, like "fn someFunction(): i32", just to be consistent with the "var area: i32" syntax.

[@luciascarlet]

Swift and Rust both use -> *only* for return types, so I can see why that was done, but honestly I never really understood why those languages chose to do it that way to begin with. Maybe it's just to make it a bit more clear that it's a function returning something and not a regular variable? I do agree that : would be more consistent, but I'm just pointing out that that's not uncommon at all.

[@Henry-fv3bc]

Idk if Carbon has lambdas yet (haven't watched the full talk), but a benefit of -> is that (a) allows a natural lambda syntax that matches the function syntax, (b) allows a natural function type syntax that matches the function syntax. (A, A) -> B as the type of a function that accepts two arguments of type A and returns an argument of type B is a little more readable (imo) than (A, A): A. Again - no clue if Carbon already has alternative syntaxes for these.

[@benfrantzdale9231]

Yes. I like the C syntax for "int foo();" means "foo()" is an int (and "foo" is an "int()" too, I guess). If we are going to put the types to the right, then I agree that `fn foo() : i32` makes sense.

[@Bobbias]

@@luciascarlet I believe the use of the arrow digraph comes from mathematical notation/terminology, possibly via ML, or Haskell or something. A function is a morphism, represented as an arrow.

[@vladimirkraus1438]

`fn someFunction(): i32` is NOT consistent with `var area: i32` because in the latter case the type is `i32`. While in the former case the type is not `i32`. It may look consistent at the very first sight, but in fact it is not at all. If the function syntax should be consistent it would look like this:`fn someFunction: ()->i32` because the whole `()->i32` thing, meaning function with no args returning `i32`, is actually the type of `someFunc`. But such a syntax would be ugly and totally unfamiliar.

[@dariusduesentrieb]

I really like the way Nim allows for domain specific languages, maybe you can take a look into their macro system.

[@HermanWillems]

Yeah you can like build whole domain stuff like webserver libraries that are super easy to use with a very good macro system. I already see this also in rust that those libraries are easy to use compared to other webserver libs on C and C++. They more are like GC based languages and easier to use.

[@vasiliynkudryavtsev]

@@HermanWillems Personally, I do not find GC based languages easier to use. You pay with loss of control and loss of performance. Achieving the performance of non-GC languages is much more difficult.

[@YoloMonstaaa]

@@vasiliynkudryavtsev you find achieving performance harder in languages without G garbage collection?

[@llothar68]

@@YoloMonstaaa Yes it is, especially when you have lots of data it gets so much worse. Why you think that servers now have in average 256 GB RAM? Not because your process is having a 50 MB dataset.

[@Harold046]

@@llothar68 Isn't the biggest user of RAM in a server typically the database, which is typically implemented in C or Cpp ? I'm not sure I get your point: are you implying it'd be easier for those database to use less memory if they were written in a garbage collected language ?

[@aahlala]

One of the great things about being private by default in Rust is that you can very quickly find and identify the public interface by searching for "pub". You're also less likely to accidentally make something public. I hope you reconsider public by default.

[@embedded_software]

Agreed. My jaw dropped when I saw that in the video.

[@gtdcoder]

C++ classes are private by default

[@superscatboy]

I agree. IMO everything within an API should be inaccessible from outside unless *explicitly* made accessible. It's one of the main reasons I can't wait for C++ modules to be adopted everywhere.

[@Silencer1337]

The only things I ever hated about C++ is that there is no centralized dependency management solution and that you spend more time trying to get your code to compile than you do writing it, and these two issues are usually related. I don't understand why you would want to focus on anything else when trying to make a successor to it.

[@SimGunther]

Even the definition of "dependency" feels off in the modern context of software. We ought to think of "dependencies" more like depending on hardware components. How many people would actually go for "cellular" programming where libraries were actually propagator cells that we could add onto existing programs?

[@hugomartinezf]

Try Makeven

[@isodoubIet]

" there is no centralized dependency management solution " That is a legitimate pain point. " you spend more time trying to get your code to compile than you do writing it, " Horrid error messages/template spew aside, if the code compiles you have a pretty decent chance that it works, especially so now that we have concepts.

[@ryansynk7088]

57:23 “our goal is to meet people where they are with their build systems” but unfortunately we’re in hell please don’t meet us there

[@petermuller608]

This looks like modern C++ which a much nicer syntax. Getting the interoperability right will be tricky part. Really looking forward to this!

[@rostislavstelmach9168]

I don’t think the syntax is that nice at all!

[@monsieurouxx]

@@rostislavstelmach9168 me neither. I mean, not the syntax per se, but none of the symbols resemble other languages. For example, parenthesis instead of for a generic type/template is peculiar. And _everything_ is like that!

[@aaardvaaark]

@@rostislavstelmach9168 IMO they picked the wrong bits of pascal syntax to mimic.

[@Elite7555]

@@monsieurouxx There is a good reason for that to make parsing simpler.

[@luciascarlet]

​@@rostislavstelmach9168 Personally, I'm a very big fan of the introducer keywords largely, as a lot of the time I get confused when there is a type before a declaration. Is it a function? Is it a field/variable? You have to read all the way to the end to find that out, and if there's a bunch of declarations in a row, their names won't align so that's also more difficult to read at a glance. Besides that, it's fairly standard to me, but I think introducer keywords for functions and variable declarations should be the standard approach honestly.

[@YourCRTube]

Explicit object pointer *by default* is Wrong. Instance methods are more common in a class so you end up making the language more verbose then C++ for normal day-to-day usage. One look at 20:30 and it's obvious, the C++ code would be way more clean.

[@vasiliynkudryavtsev]

15:32 the input variable to function is circle of type Circle. But in the code he uses c.r * c.r. I very dislike people who show the code which would fail to compile.

[@MrAbrazildo]

6:00, how much is this cost, on an average basis? 12:35, why types at right side? [...] Don't say you want to kill the 'auto' keyword... 15:38, does that means the compiler will decide which kind of "vector-32-bits" it will allow you to use? 17:00, so there won't be a 'using Math', to dismiss the annoying 'Math.'everything? 17:47, all this section seems to be a bad idea. You are discussing about putting a private before each f()/var, when C++ already does the best and cleanest syntax, by dividing it into sections. And where's the 'auto' keyword? Should we go back in time, specifying the returning type for each f()? I'm starting to think that C++ will be the Carbon successor! 20:00, so before we had const or not, and now we have this me/Self syntax noise? Awful! 20:34, for an inheritance coming from an interface, it's acceptable to has abstract and base keywords. But for normal classes, it's just annoying. 20:45, nooo! We type too much, which is implicitly tiresome. So shorter syntax is almost always better, like the ':'. 36:09, finally the 'auto' keyword! But having to specify the returning value seems to be a step backwards. C++14 was a relief to me, getting rid of this thing. 37:39, tiresome... I can feel it from here! 40:33, no!

[@farqueueman]

Found a few jobs for junior carbon developer. Requires 10 years experience in developing in carbon 🥴

[@treyquattro]

I'm assuming that at 12:59 someone decided to change the argument list from c to circle to make it more readable but then forgot to change the identifier in the body of the function. Either that or carbon somehow knows to abbreviate identifiers to one (or the most significant leading) letter? If I were redesigning C++ I'd get rid of pointers and just make everything use references (which would be reassignable), like every other modern language (maybe you keep pointers for specifically low-level, machine-specific code, or maybe you just defer that via interop to C or C++)

[@lepidoptera9337]

A reassigned reference is a pointer, isn't it? Pointers can not be avoided in computer science. Why? Because moving the mountain to you and moving you to the mountain are not equivalent operations. Anybody who wants to pretend that the difference doesn't exist is simply intellectually lazy at the lowest level of abstraction. It also doesn't increase code quality to get rid of pointers. Why? Because we aren't trying to get rid of pointers. We are trying to get rid of junior developers who don't know how to use pointers correctly. Do you really believe that this upgrade in coder (rather than code) quality can be achieved by changing the language? :-)

[@mypointofview5400]

I've heard some parts of Linux will be "oxidized" next year. Now when are they gonna "burn" some parts of it?

[@khazixfangirl6087]

Only drivers are going to be written in Rust, the Kernel code itself is going to be C. C is more portable and by using LLVM you limit the platforms you can be ported to. Is the Linux Kernel being "Oxidized"? The answer is yes, but Rust likely wont get to any level as serious as C in the Kernel any time soon

[@encapsulatio]

Hopefully once Zig gets to 1.0 .

[@frydac]

Thanks very much for adding actual useful links, wrt the video content, in the video description. Hardly any other (cpp) conference does this.

[@petersilva037]

Great talk. love brigning in the namespacing in a similar way to the way python does it. while I get the interop idea of being able to call things between the two languages... I would think it would be more fun... in the sense of providing a lot more trouble and validation, to make an idiomatic cross-compiler/translator that would take C++ in a spit Carbon out. That would give you a huge corpus to evaluate the tool chain, and provide an option for a fully carbon binary route... might be, long term easier than trying to use raw C++ libraries forever. I am looking forward to watching Carbon mature. Quibble: I take issue with the idea that C++ is a successor to C, if successor is meant to be a total replacement where the ancestors were formerly used. C is still around and used in domains where C++ doesn't work. The most famous example is systems programming where transitioning the linux kernel to C++ famously failed. C++ is great for complex, performant applications, but for low-level, limited complexity but performance sensitive work, C still rules. C++ is a child of C... but it never really replaced it.

[@lepidoptera9337]

There are fundamental problems with language to language translation unless all types mean exactly the same, which one can not rely on in C/C++ because of int being either two or four bytes. Everything one can do on C can also be done in C++ without performance loss. I would have to conclude that you have no experience in either. ;-)

[@eleson00]

Short list of things to have: 1. Return more than one variable from a function. This also ease interaction with c++ exceptions by passing those as error return values. 2. struct members should be accessed via a . even when using a reference to a struct. skip the -> . this eases reading and refactoring. (3. Nested Comments) 4. Function Hoisting!

[@eleson00]

Add-on's: Optional keywords comptime and runtime, to explicitly say whether of on a function should be evaluated during compilation or runtime. Default should be that compiler tags functions as eligible for comptime eval or not, and always try to do comptime eval unless 'runtime' is used.

[@VicNightfall]

Hey there. You might like my new language over at princess.sh

[@HellCatLeMaudit]

Returning more than one variable from a function would break those of us who think of functions as mathematical functions. There is no need to do this anyway. Functions can already return structs or classes.

[@isodoubIet]

@@HellCatLeMaudit "Returning more than one variable from a function would break those of us who think of functions as mathematical functions." Why? A function can perfectly well have a cartesian product of two disparate spaces as its codomain. It's trivial to construct functions that do that.

[@masheroz]

Why can't you return a struct?

[@marco21274]

Nice language for Google problems. I am not so sure about other people problems. Googles setup is quite unique.

[@lubricustheslippery5028]

Isn't most bigger companies and projects stuck on C++ and want something better? So something better than C++ that is interoperable with C++ have huge user case. And because it can use C++ there will quickly be lots of packages available.

[@API-Beast]

@@lubricustheslippery5028 there is nothing "better" about this, for every problem it solves it adds new ones. I agree with OP here that it might be good for Googles purposes but is kind of narrow minded in that approach and that fundamentally affects the design.

[@EdouardTavinor]

There are lots of companies out there with huge C++ codebases where development is extremely difficult because of technical debt.

[@DerDoMeN]

​@@lubricustheslippery5028 From my experience such bigger companies more often than not sit on something between C with classes and Java++ and cringe when you tell them that writing/maintaining that code base is torture and not what C++ is. I'm quite certain that such companies don't want Carbon.

[@monsieurouxx]

Not too fond of the scope of the endeavour: *making people adopt a superset of c++ is hard enough,* why introduce weird new things at the same time? Stuff like: a syntax that looks like no other language, or this "implicit public" try-hard change, "let" instead of "const", etc. ?

[@notarabbit1752]

I agree with this. a lot of it is just change for the sake of change. lets put fn in front of functions and a little arrow in there for the return type? why?

[@Adowrath]

@@notarabbit1752 There are some precedents for fn + trailing return types by arrow, most notably Rust. In fact a lot of things are taken from other languages - for example Scala is public by default as well, Kotlin uses 'open class' (which is a better name than 'base class' imo).

[@sebastiangesemann6775]

@@notarabbit1752 The little arrow for the trailing return type is actually already valid C++ syntax. There are some real benefits to this beyond just being different: After the -> the function parameters are already in scope which allows you to use them, for example, within the `decltype` operator.

[@Snirokok]

As I've been looking of the features proposed, I was wondering why not just mimic the Kotlin language syntax if c++ minor extensions like addr or pointers. Why an absolutely new syntax is needed?

[@Dexterdevloper]

when will it be ready for production usage?.

[@2lay]

Experimental V0.1 2025, prod-ready after 2027

[@ShaneHou]

interface, abstract class and class reminds me of Java... I never truly understand why we need interface and abstract class the same time. Don't we just need one of them? And if you think you can use interface to solve generic problems, then why did Golang (which has IMPLICIT interface!) still have to deal with endless generics feature requests all these years and finally made it happen?

[@holonaut]

00:00:12 Rust foundation be like: "What did you just say??? I haven't heard you ask for permission"

[@KristofferLie]

Why does let represent an immutable declaration when in javascript let is the mutable while const is the immutable. that just causes confusion :(

[@UrSoMeanBoss]

definitely would like to see `const`

[@Oohio2]

This might be inspired by Swift, right?

[@andreaciccarello]

@@Oohio2 probably

[@andreaciccarello]

SWIFT use let as immutable value

[@monsieurouxx]

Yeah, weird stuff

[@androth1502]

i don't think this offers enough of an improvement over C++ for anyone to actually want to use it. the concept of c++ interop is nice though. but that's about all carbon get's right.

[@avdheshpalliwal]

Language should be readable also. Seems Carbon has just minimized all naming and very difficult to understand code by reading now.

[@petermuller608]

I have to disagree, the code is much easier to read compared to C and C++. Trying to mentally parse types in C is quite hard and the whole most vexing parse fiasco is a nightmare

[@vladimirkraus1438]

I find it very readable. Unlike rust...

[@monsieurouxx]

Also, weird symbols compared to other languages. Who writes "Circle(i32)" instead of "Circle" ?

[@DerDoMeN]

@@petermuller608 Beauty of a syntax is in the eyes of the beholder...

[@myusernameislongerth]

Up until interoperability, this language looks a lot like Rust, but some of the defaults are still backwards, like in C++ (constness for example).

[@AbhinavKulshreshtha]

I will agree that iso process or any other standard body, needs to revamp their standardization process, but replacing it with a body controlled by a corporation, is not a good way to solve it. Kotlin doesn't have official lsp or treesetter, hence, only jetbrains editor offer a good experience with it. Not to mention that both golang and dart suffers from same issues mentioned by speaker regarding their language development.

[@chuckkarish1932]

This is an experimental, incomplete project. It's not close to the point where standardization would be appropriate.

[@DerDoMeN]

From my experience with Kotlin it does a nice job for what is built - create a web view on Android so that I can run my wasm compiled C++ program inside of it :) But it's true that for something like that Java was good enough so why having a new language is a good idea is always hard to explain...

[@Adowrath]

@@DerDoMeN Honestly, if you compare Java and Kotlin, the most immediate difference is that there's a lot less ceremony when using Kotlin, some of which could be or have been added to Java (like top-level definitions, local variable type inference, lambdas and a natural notation for their types, operator overloading, receiver functions) but others which would couldn't really be patched in (different Collection-library with a focus on (Im)mutable destinction) or would require a lot more effort but might come one day (declaration-site variance, infix functions, reified inline Generics, Coroutines).

[@VitalZero]

Why not to focus on D lang? Carbon seems to want to imitate kotlin's syntax (highlight the word seems) Why not try something that feels natural as the successor of c++ like D lang? I don't think digital mars has a problem with that.

[@vladimirkraus1438]

I am pretty sure they have considered using D before launching this... Btw. D is not modern language, it is just a bit better and less-error-prone C++ with GC and not that great interop with C++.

[@michaelwilsonii4085]

@@vladimirkraus1438 what does it need to have better interop ?

[@krofikS4]

What a beginning if a new channel!

[@ignasicr17]

I wish the best for this new programming language. ;)

[@MaitreBart]

Evolution, interoperability, migration: Evil is in the details when c++ is in the loop.. Nice introduction though. Looks promising.

[@alexkizer639]

Regularization of syntax is a great idea which is a flaw in most mainstream language in my opinion. You have a syntax for passing an argument; why use angle brackets for type arguments (generics) as shown in the video, for example. I think some programming languages could have ultra-simple grammars if they consolidated and regularized syntax. Something I’m aiming for in a hobby language I’ve started thinking about.

[@carpenecopinum1665]

This struck me as very weird about the examples, too. Generic types have their type arguments just in `()` like regular function arguments, but for generic functions, you suddenly need to add square brackets. Also in one minute he talks about how `public` was made the default and therefore removed to reduce the noise, but then you have to explicitly provide the type for the `me` for every single method. I hope stuff like this will be addressed in future versions. The general ideas of carbon look great, but I feel like there is a lot of "cleaning-up" work left to do.

[@Adowrath]

The big hurdle why generic/type arguments so often have a different syntax is twofold: 1) You generally don't want to pass the type at every call site (as far as I understood, this is not even possible here), so they're inferred. Having them inferred but using the same paren-kind however either leads to you needing an emtpy pair of () everytime you call that function or require the compiler to try and deduce "this parameter value here is not a type, hence the caller wanted the type inferred and this is the second, normal parameter list", and both get real nasty as soon as you get to functions returning callables. 2) You also can't really merge the two argument (generic and normal) lists that well: Otherwise, you'd need to support back-referencing in type annotations ("fn identity(A: Type, a: A) -> A"), you'd need to either explain to users that all type parameters need to come first or you'll also need to support them being in mixed order, and you'd either give up inferring or require a special syntax like _ for inferred parameters. A somewhat elegant solution is found in Idris I would say: In a function type "a -> b -> c" (not that this function could exist), the parameter to the left of an "=>" is inferred, "forall"s are implicit (as in this is _almost_ equivalent to "{a : Type} => {b : Type} => {c : Type} => a -> b -> c", the difference is not really relevant here) but you can supply them either when inferring is ambiguous or just for clarity as `foo {a=Int} {c=Nat} 203 'H' 0`.

[@llothar68]

Lisp is the master example why you shouldn’t simply too much. Templates should not look like normal code at all. But template use should

[@stanislawpalka9015]

After C++ will be Cext/C++ext . Those are small extensions to C. Extansion small but powerful.

[@Eek_The_Cat]

The intent is noble, but the syntax is more Kotlin than Kotlin itself is.

[@insinfo2008]

almost none of the symbols in the syntax resemble other languages. For example, parentheses instead of for a generic type/template looks pretty bad

[@Voltra_]

I don't know how to feel about this, and I don't think it's a good thing for carbon. Does that mean that, in the future, when carbon will fall short in some area we'll branch off again and create yet another language?

[@petermuller608]

You mean, like we did with Fortran, Agol, BCPL, B, C,...? It's called evolution and is a good thing ;)

[@qx-jd9mh]

@@petermuller608 Where is the evolution? It looks like the designers didn't bother learning from anything besides the mainstream languages.

[@Anhar001]

So C++ failure was due ultimately to "backwards compatibility", and yet Carbon's "success" is based on backwards compatibility with C++, is this not just cutting the branch upon which one sits on?

[@YvanDaSilva]

Because it's a different language, you can break language semantic compatibility while remaining interoperable with the C++ eco-system. Those are different things. This is why Carbon has a different AST than C++ one and they are converted both ways when you import C++ into Carbon or Carbon into C++.

[@gmxmatei]

The future is 'The Universal Software Model'!

[@robotustra]

The answer is: JAI comes next.

[@jordanzimmerman7590]

Java -> Kotlin - this is false. Kotlin only replaced Java on Android. In the rest of the world Kotlin is a footnote. I imagine that Carbon may suffer a similar fate - yet-another-boutique-language.

[@aahlala]

Kotlin is also being used for server-side code.

[@henrymerrilees9066]

Carbon isn’t supposed to be widely adopted except for its very specific specified use case. This is precisely the point.

[@monsieurouxx]

If only my programmer dudes could focus on the meaning of things, instead of debating if things are "technically correct". Obviously in this context "replaced" didn't mean "replaced in volume" but just "providing the superset equivalent to the same modern supersets found in other popular languages"

[@vladimirkraus1438]

This is different. Java is ugly and verbose but is is quite easy ty learn. While C++ is basically unlearnable for majority of programmers, it is just too complex, too hard, too confusing, a true minefield. And I am saying this as C++ dev with something like 15+ years of experience.

[@DerDoMeN]

@@henrymerrilees9066 That's what was planned with Java applets but look at the mess it brought after failing in it's niche...

[@hugo-garcia]

Carbon will be another go language

[@broken_abi6973]

I actually... don't like this syntax for class methods.

[@perfectionbox]

I get the feeling that everyone wants programming to be easier but won't accept that, fundamentally, it's hard. Make all the languages you want, but programming will remain hard. Just add first-class delegates and introspection to C++ and I'll be happy.

[@frydac]

Fred Brooks - No silver bullet (1986). Pretty sure all pll involved read this article, and to me it doesn't seem like they are trying to invent a silver bullet, they are trying to reduce accidental complexity.

[@danhoward7697]

Kotlin will not replace Java. It's just another Scala.

[@luciascarlet]

Android app devs would disagree...

[@vladimirkraus1438]

I doubt there are new projects done purely in Java...

[@DerDoMeN]

@@luciascarlet Well both Java and Kotlin are ok to create a web view on androind and then run wasm C++ program inside... So from my point of view Kotlin wins just because I was fortunate enough to write less code in it.

[@radarsmutny8462]

@@vladimirkraus1438 gluon/graalvm javafx AOT native even on android/ios? its at least interesting

[@AllanOjala]

Can I get a window and a red pixel on screen using carbon without having to write my own platform abstraction layer and implement it for each desktop platform?

[@superscatboy]

If you're looking for a language designed to simplify desktop GUI programming, you're in the wrong place.

[@Herossandro]

I tried it, things still don't work as expected by the documentation but I think it's a cool language to know

[@apivovarov2]

Looks like a mix of java, python and scala.

[@steveholder7289]

Hell, I'm just happy it's not using white space as a parsing parameter and delimiter (e.g. Python).😆

[@DJenriqez]

nah after I finished rust tutorials,... you release this,... :D :D

[@TheBypasser]

Once too high-level IMO, pretty much reminds of Visual Basic which was nice for frontends, but nobody actually used it for anything heavy. Very obscuring syntax (say, Math.Pi at 28:35 is a constant while c.r is a structure member). May be fun for frontends just as well, but mostly working on hardware and driver-level/user low-level codes I don't feel really excited about it :)

[@ziyadkader6767]

Im not as smart as you guys but there is some questionable design decisions that you made, zig, nim, odin, rust, jai,etc... made progress in some areas, you should have learned from them ... :(

[@Dziaji]

The main problem with garbage collection is that it falls prey to the unstoppable force of compounding negative interest. It would be fine if you were writing a simple program directly on top of the language, because then the performance cost is X%, and that is fine. Now, you decide to use a platform that runs on the language. Your performance cost is now [1 - (1 - X)^2]%, but that's not too bad, because you paid less in absolute performance cost than you paid the first time. But now, you make some in-house tools that all of your code uses, and make an in-house platform with those tools, on top of the 3rd party platform which runs on the garbage collected language, and now you basically have a performance cost of [1 - (1 - X)^4]%. So if your initial performance cost was 5%, which isn't that bad, you now have a performance cost of almost 19%, and that is JUST from the effect of the base language features like garbage collection and dynamic typing. Add all of the other inefficiencies caused by the platforms and tools and you soon realize that massive chunks of your performance are gone and your code runs at 10% of the speed of a c++ app if you are lucky.

[@Megalcristo2]

He names Rust a lot, but many of these ideas seem to be taken from Go.

[@Spongman]

seems like it's changing too much stuff just for the sake of it. why 'let'/'var' and not just 'auto'/'const' ? why the python-like 'me' boilerplate for methods? why '[]' instead of '' for type constraints? why inconsistent declaration of function return types? public by default? nope.

[@luh034]

I'm so excited for this

[@ShanyGolan]

at least they could use javascript's var/let/const functionality.... they reversed it... WTF!

[@petermuller608]

JavaScript's var is function scoped and thus very different from the lexical scope most programming languages use. Using var to declare a mutable value makes sense, even though I would have preferred mut/const or let mut/let to var/let. Nevertheless this language is still very early in the design, I'm sure we'll bikeshed a lot about naming ;)

[@pezalot]

Hey Carbon team I salute you. What do you think about Bjorne. What he think about Carbon. Maybe he can help you for details or some major problems?

[@kevinsucre2746]

Will carbon have 1 implementation of the compiler ?

[@blacky7801]

What about any of this is "experimental"? They just took elements from the most popular langauges and put them into their langauge. Its not even that they took parts from several radically different langauges and the combination of those is a unique product, its just a subset of other popular languages. They only call it "experimental" as to qualify their claim of being a successor to Cpp, as to not sound as arrogant.

[@reinterpret_cast]

Why couldn't they just take Rust and remove the restrictions on aliasing and borrow checking? The language would be "unsafe" of course but the code would be architecturally compatible with C++ and have a nice modern syntax. Both of which appear to be the goals of Carbon.

[@thecollector6746]

Because the entire point of this project(Carbon) is the next stage of C++ where the language radically evolves into a language that is more maintanable while still being able to fully integrate with C++. Rust has no integration worth mentioning with C++ and doesn't typically isn't the best language to use for certain use cases that C++ excels at (writing game engines for example)

[@about2mount]

Same as the new Zig Language you're using the massive LLVM Libraries. An LLVM-only build requires anywhere from 1 to 3 GB of space on any machine. A full build of LLVM and Clang will need around 15 to 20 GB of disk space. The exact space requirements will vary by system but damn. They claim it's so large because of all the debugging information and the fact that the libraries are statically linked into multiple tools. I call that "Organized Despair". No Offence, however just before using Carbon for your own Application Builds, your using a Program that is ten times larger than a Linux Ubuntu OS just to achieve it. You would be much better off to have gone with a Python Like Approach using C++ as a base language with an Interpreter instead right?

[@dexterman6361]

oh great rust syntax again. IMHO the variable declarations of C++ were much easier to read for humans. I have to dig around b/w a line to see what the type of a variable is :(

[@JohnDlugosz]

Isn't that what D was supposed to do?

[@phnxbr]

The question is it will take decades to make shift all legacy from C++ to Carbon

[@georganatoly6646]

life after c++, it's fun to dream, although I'd be happy if there was only C and assembly, have we ever really needed anything else?

[@samuelschlesinger4102]

What is a CLA?

[@mathew3267]

What a riveting action packed video!

[@thecollector6746]

I don't view C++ as having unecessary technical debt...I see C++ as being a superset of C that allows you to go about writing "scalable C" which entails that you are allowed for tools that enable to pretty much do whatever you want.....which was the intent.

[@syntaxed2]

I dont understand the point of this syntax "var NAME: type" when "type NAME" is more readable...

[@YourCRTube]

Easier parsing. Hopefully ":type" can be omitted and type deduced.

[@nicolasjakob2117]

The fact that Generics are using brackets instead of the diamond operator makes it quite hard to read in my opinion. How do you see that?

[@codegodtreviso4448]

Cant wait for it to be production ready :)love your stuff hopefully it can have a build system like zig and easily intergrate with c++

[@alexpyattaev]

It feels like people who really really want to write Rust and are stuck with C++ instead are just looking for an escape hatch. However, instead of actually making an interface from C++ to Rust, they are making a whole new language instead. Also, without any way to operate with unsafe pointers, Carbon will never be able to work with stuff like network packets. You need "unsafe pointers" for many practical tasks in C++ related to binary IO and serialization, and it seems that Carbon will have to handle those in C++, so whoever wants to use it would have to learn two different languages => you are not solving the technical debt problem of C++. What a disaster.

[@angeloceccato]

Erlang -> elixir

[@Adityarm.08]

Great talk. Interested in how this effort shapes!

[@j0seant]

Google wastes too many resources launching new languages instead of collaborating as much as possible to improve the ones that already exist and have millions of libraries... I don't see the point of wasting so much time learning new languages every year that they are then abandoned..

[@lubricustheslippery5028]

If Carbon is interoperatable with C++ the C++ libraries should be able to be used by Carbon. You should definitely wait at least a few years and see what is happening with Carbon before trying using it in a real project or feeling that you need to learn the language. So for now forget that it exists.

[@fernandolener1106]

For google, this is cheap trial. If it works they know they will have a lot to win

[@adrianoemidio7424]

My impression is that Google wants to control the community. It's just the Microsoft with the C# (another supposed C++ sucessor). When Google came with Go Lang they told us the same tale of C++ be old, etc. As Go failed been the C++ sucessor, and with the growth of Rust, they became butthurted and now they are tring again with this Carbon language.

[@monsieurouxx]

The point is in the video underneath which you are currently commenting.

[@EdouardTavinor]

This is a project to improve C++

[@gtdcoder]

13:40 Those are not the only two options you have in C++. You can also use move semantics to avoid copies. Or use constexpr for read-only values. If you are going to do a talk on why Carbon is better than C++ you have to know as much about C++ as possible. Doesn’t seem like he does.

[@Adityarm.08]

If you look at his background, he is a representative on the C++ committee, I find it hard to believe that he doesn't know the language in depth. I'm not good at the language so can't answer your point, but probably good reasons to why the other options weren't considered worth discussing on that thread.

[@dynfoxx]

I think you misunderstand what he is saying. When making a function call you can either pass it by value or pointer. if you take it by pointer then due to calling conventions it will not be placed in a register. This sucks if the item is smaller then a pointer, you waisted space and time since you have to fetch a basic type from the stack. If you pass by value sure you can use move to construct a new one but what if you did not want to give ownership away. How can you ask for it back? What he wants is a way for the compiler to make the correct call in a generic situation.

[@superscatboy]

You might want to read up on Chandler Carruth before accusing him of not knowing as much as possible about C++ 😂

[@PietroBrunetti]

I was thinking... "erlang -> elixir"?

[@joeedh]

Not sure the best way to sell a programming language is to say you're going to radically change the grammar just to make compilers easier to write.

[@bjmaston]

Surely Swift showed the way: smash all the horrible interop complexity into a bridge, and then keep the new language clean.

[@paulfloyd9258]

Successor successor: Pascal -> Modula-2 -> Oberon

[@kunjpatel3636]

carbon looks like 'golang + rust'

[@technicholy1299]

Playing fast and loose with type casting gets you in all sorts of nasty trouble.

[@guillaumewenzek4210]

TBH the 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.

[@pmcgee003]

Only certain people contemplate "going on leave for 6 months" 🙂

[@MrAbrazildo]

Type deduction is not something I'm willing to give up. Syntax sugar is more important than it looks. There's a silent energy draining from the programmer. Code should be concise, and Carbon is currently verbosely ugly, resembling C# ugliness - _and without type deduction, for f()s at least_ . A solution for this may be an IDE that hides this ugliness from the coder. i.e. when you type 'v', the code completion would suggest 'var', and anything else than a keyword like, for instance, backspace, would write the (nowadays) verbose var keyword. So the user types v and the name of the var right away. Once a new line is reached (when user press enter), the var would be hidden by the IDE, resembling C++ conciseness.

[@FedJimSmith]

whut? they removed multiple inheritance !!

[@superscatboy]

"->" is and always has been absurd, and you'll never convince me otherwise.

[@andrewf8366]

I guess the argument I can see is that sometimes you want to use functions on the pointer and other times on the data held by the pointer