Carbon Language: An experimental successor to C++ - Chandler Carruth - CppNorth 2022
Vložit
- čas přidán 14. 05. 2024
- CppNorth Twitter: / cppnorth
CppNorth Website: cppnorth.ca/
---
Carbon Language: An experimental successor to C++
Project details: github.com/carbon-language/ca...
C++: What Comes Next? (Announcing the Carbon Language experiment) - Chandler Carruth -CppNorth 2022
CppNorth 2022 video sponsors:
think-cell: www.think-cell.com/en/
Adobe: cppatadobe.splashthat.com/
C++ remains the dominant programming language for performance-critical software, with massive and growing codebases and investments. However, it is struggling to improve and meet developers' needs, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. We think the best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like a modern generics system, modular code organization, and consistent, simple syntax.
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many others. Developers that can use one of these existing languages should. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++. These barriers range from changes in the idiomatic design of software to performance overhead.
We decided to experiment with a different direction: a successor language approach. It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers.
So we've started building the Carbon Language: an experimental successor to C++.
That said, we really don't know what comes next for C++. We don't even know whether Carbon should be part of what comes next. We're just getting started with the long process of designing this kind of successor, and haven't even finished a compiler. We still need to finish the design, implement it, see if it works, and see if the C++ community is interested in this direction.
This is why we're here. We need you and the rest of the C++ community to help us build and shape Carbon into something that addresses all of our needs. And we need all of you to help evaluate whether it is the right direction. We're here to ask you to join us as we get started on an exciting experiment, and a long journey.
To find out more, check out our project: github.com/carbon-language/ca...
---
Chandler Carruth
Chandler Carruth is the technical lead for Google's programming languages and software foundations. He has worked extensively on the C++ programming language and the Clang and LLVM compiler infrastructure. Previously, he worked on several pieces of Google's distributed build system and made guest appearances helping maintain a few core C++ libraries across Google's codebase. He received his M.S. and B.S. in Computer Science from Wake Forest University, but disavows all knowledge of the contents of his Master’s thesis. When not hammering away on a weirdly shaped keyboard, he enjoys sushi, fine dining, brown spirits, and everything about wine.
---
CZcams Channel Managed By Digital Medium Ltd: events.digital-medium.co.uk
---
#CarbonLang #google #programminglanguage - Věda a technologie
I am not sure what to make of Carbon. I am carbon neutral.
"It's a bit rusty..." Rust will always find its way into a C++ talk😁
Im going to borrow this joke
@@guyarbel2387 Make sure you rewind it before you bring it back. 😉
well it's a pretty large elephant in that room
@@guyarbel2387 Is that going to be a shared or mutable borrow?
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.
And here comes the tech recruiters today with "Job Experience requirement: 4+ years in Carbon"
Thanks very much for adding actual useful links, wrt the video content, in the video description. Hardly any other (cpp) conference does this.
I love the way slides are colored in CZcams's Dark Color. It felt so natural on CZcams, that I was wondering why it's feeling so soothing :), then I observed the coloring.
That was a Great idea in my opinion!
the white and red bands at the top and bottom don't bother you?
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.
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?
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++.
Isn't the whole purpose of this presentation is to answer your question "why should you choose Carbon over modern C++"?
@@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.
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.
What a beginning if a new channel!
What a riveting action packed video!
That external interface implementation looks amazing. I hope we would have this in C#.
Check out ruby's FFI. Really simple.
extension methods do the same thing in c#
@@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.
I really like the way Nim allows for domain specific languages, maybe you can take a look into their macro system.
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.
@@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.
@@vasiliynkudryavtsev you find achieving performance harder in languages without G garbage collection?
@@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.
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
Briefly mention Zig at 50:49
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.
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++
@@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.
@@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.
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?
Rust is the most interesting new language.
@@WouterStudioHD I agree. Just use Rust and Zig and avoid C++ at all costs.
@@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.
JAI is the only one im waiting for.
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?
I will continue to use c++ as c (with templates). Best of luck on your new language adventures!
You do not even use namespaces? Oh no... what a shame. And no function or operator overloading?
Best wisdom advice a have read in year.
🙂👍
See also: orthodox c++
hi Anton, do you have some tutorial for this?
I played around this idea awhile and then I falled in love with Rust.
I wish the best for this new programming language. ;)
I'm so excited for this
Great talk
Way to the future. Excited. Site note, a bit better recording quality could help a broader range of audiences.
Cool stuff!
Found a few jobs for junior carbon developer. Requires 10 years experience in developing in carbon 🥴
This looks like modern C++ which a much nicer syntax. Getting the interoperability right will be tricky part.
Really looking forward to this!
I don’t think the syntax is that nice at all!
@@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!
@@rostislavstelmach9168 IMO they picked the wrong bits of pascal syntax to mimic.
@@monsieurouxx There is a good reason for that to make parsing simpler.
@@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.
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.
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. ;-)
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.
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.
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.
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.
@@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.
`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.
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...
nah after I finished rust tutorials,... you release this,... :D :D
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.
Agreed. My jaw dropped when I saw that in the video.
C++ classes are private by default
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.
Evolution, interoperability, migration: Evil is in the details when c++ is in the loop..
Nice introduction though. Looks promising.
Great talk. Interested in how this effort shapes!
I tried it, things still don't work as expected by the documentation but I think it's a cool language to know
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!
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.
Hey there. You might like my new language over at princess.sh
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.
@@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.
Why can't you return a struct?
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?
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++
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?
Will carbon have 1 implementation of the compiler ?
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++)
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? :-)
The future is 'The Universal Software Model'!
Nice language for Google problems. I am not so sure about other people problems. Googles setup is quite unique.
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.
@@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.
There are lots of companies out there with huge C++ codebases where development is extremely difficult because of technical debt.
@@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.
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?
Will it work with CMake?
July 2022, learning rust
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.
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?
Try Makeven
" 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.
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
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.
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?
If you're looking for a language designed to simplify desktop GUI programming, you're in the wrong place.
almost none of the symbols in the syntax resemble other languages. For example, parentheses instead of for a generic type/template looks pretty bad
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.
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.
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`.
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
00:00:12 Rust foundation be like: "What did you just say??? I haven't heard you ask for permission"
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?
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!
I've heard some parts of Linux will be "oxidized" next year. Now when are they gonna "burn" some parts of it?
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
Hopefully once Zig gets to 1.0 .
Up until interoperability, this language looks a lot like Rust, but some of the defaults are still backwards, like in C++ (constness for example).
Carbon will be another go language
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?
Looks like a mix of java, python and scala.
Why does let represent an immutable declaration when in javascript let is the mutable while const is the immutable. that just causes confusion :(
definitely would like to see `const`
This might be inspired by Swift, right?
@@Oohio2 probably
SWIFT use let as immutable value
Yeah, weird stuff
Hell, I'm just happy it's not using white space as a parsing parameter and delimiter (e.g. Python).😆
25:10 beautiful
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. ?
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?
@@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).
@@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.
Yay
What is a CLA?
The intent is noble, but the syntax is more Kotlin than Kotlin itself is.
I actually... don't like this syntax for class methods.
The answer is: JAI comes next.
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?
He names Rust a lot, but many of these ideas seem to be taken from Go.
carbon looks like 'golang + rust'
Playing fast and loose with type casting gets you in all sorts of nasty trouble.
Does it address the c++ problem of not beeing at BNF language? Does carbon BNF (backus naur form) grammar?
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?
32:23 👏👏👏
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 :(
Isn't that what D was supposed to do?
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.
This is an experimental, incomplete project. It's not close to the point where standardization would be appropriate.
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...
@@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).
Successor successor: Pascal -> Modula-2 -> Oberon
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 ... :(
Language should be readable also. Seems Carbon has just minimized all naming and very difficult to understand code by reading now.
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
I find it very readable. Unlike rust...
Also, weird symbols compared to other languages. Who writes "Circle(i32)" instead of "Circle" ?
@@petermuller608 Beauty of a syntax is in the eyes of the beholder...
I was thinking... "erlang -> elixir"?
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.
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.
Erlang -> elixir
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 :)
no comments... :(
at least they could use javascript's var/let/const functionality.... they reversed it... WTF!
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 ;)
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?
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.
Only certain people contemplate "going on leave for 6 months" 🙂
Surely Swift showed the way: smash all the horrible interop complexity into a bridge, and then keep the new language clean.
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.
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++.
@@vladimirkraus1438 what does it need to have better interop ?
I dont understand the point of this syntax "var NAME: type" when "type NAME" is more readable...
Easier parsing. Hopefully ":type" can be omitted and type deduced.
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.
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.
whut? they removed multiple inheritance !!
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?
You mean, like we did with Fortran, Agol, BCPL, B, C,...? It's called evolution and is a good thing ;)
@@petermuller608 Where is the evolution? It looks like the designers didn't bother learning from anything besides the mainstream languages.
but why not just c+++
Kotlin will not replace Java. It's just another Scala.
Android app devs would disagree...
I doubt there are new projects done purely in Java...
@@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.
@@vladimirkraus1438 gluon/graalvm javafx AOT native even on android/ios? its at least interesting
I can actually see why a CPPer would find that intersting. Overall the language looks very interesting. I am not sure though rather this one can stand up to the promises of Rust and the underlying question would be: shouldn't we not waste our time for intermediate solutions and strive to learn and adapt the best ones from the beginning?
Yes, adapting Rust isn't straight forward, that's because they introduced ideas never seen before by the vest majority of people, to solve complex problems. So it's a no-brainer saying that Rust isn't a straight adaption. But it can work with C/CPP and other languages. So shouldn't we invest our time and energy there?
is it camelcase or snakecase
Yes
reminds me a lot of golang
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?
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++.
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.
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.