The Carbon Language: Road to 0.1 - Chandler Carruth - NDC TechTown 2024
ฝัง
- เผยแพร่เมื่อ 9 ก.พ. 2025
- This talk was recorded at NDC TechTown in Kongsberg, Norway. #ndctechtown #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences...
ndctechtown.com/
Subscribe to our TH-cam channel and learn every day:
/ @NDC
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#cplusplus #languages #code
The Carbon Language is an experimental successor to C++. We want to provide significant improvements to developers for whom C++ is currently the best option. We are especially targeting developers with a large existing C++ codebase or large dependencies on existing C++ libraries. This talk will introduce the audience to Carbon's first major milestone: our 0.1 release that will demonstrate our C++ interop. When this is ready, C++ developers can start directly evaluating Carbon.
Beyond introducing Carbon's milestones, we'll share what we expect to get out of this release and what C++ developers can expect when using them. The talk will dive into the specific parts of Carbon's 0.1 milestone that are already shaping up and show how they are working in practice, including demos of the Carbon toolchain and compiling small, early, but working Carbon programs. We will also outline the remaining path to actually completing 0.1 and getting it into the hands of developers. And last but not least, we'll share a preview of the incremental evaluation and adoption workflow we are envisioning for existing C++ developers and codebases.
I appreciate the ambition of this project so much! And the thoughtfulness around bidirectional interop. I wish Chandler had mentioned Scala's absolutely seamless bidirectional interop with Java, which dates back quite awhile now, and truly enabled Scala's industry adoption.
The c carbon project is a great idea because it manages to translate c++ code, which is difficult to read, into readable and easy-to-understand code compared to the mess that c++ code seems to me. So, what I want is for this project to be fully realized, because I will certainly be very pleased to have this language available.
The solution to not being able to read Spanish is not to translate it into English but to learn Spanish.
@@youtubelisk How many years of practice does it take to be able to read C++ and confidently say: "This code doesn't have any UD, no memory leaks, ..."? And what do people do the years until they have enough practice? They write code containing UDs and memory leaks.
Half mastered Spanish isn't dangerous...
@dmdjt how many years does it take to be a master at anything?
@@youtubelisk Mastering anything takes a lot of time... The problem with C++ is, that it's near impossible to master (Even people with decades of practice fail at "spot the UD").
Mastering a language should not include writing safe/correct code, if the language is used in the most vulnerable places. That should be among the absolut basics.
@@dmdjt Be careful, with all that logic, the "Skill issues" folks are going to come here and say that C++ is perfect and easy and that the sole reason why you want another language is because of "Skill issues". When in reality C++ is the absolute worst programming language in existence (in terms of design). It's so bad, that it's a text book example for pl designer of what not to do.
I think the reason so many people are fighting tooth and nails to defend C++ is because of all those years they have invested in learning things that are not transferable to other language. Programming is already hard, but on top of that when you master C++ there is not much you can transfer to another language. Because debugging C++ is 20% debugging your logic, 80% debugging your language knowledge. That's unlike any other language out there.
This is an undeniable proof of poor design, if C++ was correctly designed you would spend most of your time debugging logical errors, but no instead you have to remember that this overload, does this but this one is slightly different, oh and this is not a function but actually a macro, and this template will produce this type, but not if it's a reference, or a universal reference, and the forwarding doesn't work if you do that, which means this template 20 function down the road, uses this overload instead of this one, but now because of the casting rules you get this instead of that, how but this lambda is actually doing that instead of this. It's just an incredible mess, where you are constantly triggering UB if you are not careful, where Error handling is really hard to achieve, and where all the "Zero Cost" abstractions actually have a big cost, outside of the iterator, all those smart-pointers aren't cheap in the slightest. And they also have their own quirks and logic that you have to remember and this creates just an exponential amount of cognitive load, but people will still say "skill issue" but I'm sorry if your language requires 20y of experience, before it becomes easily usable, it's a language problem not a skill problem.
I commend them for identifying that one of their biggest challenges will be getting people believe this project isn't vaporware. I really can't shake that thought and this presentation did not help.
They are trying hard, aren't they? Making a 1-hour talk before v0.1 is out 😂
ill be dead by the time this ish 1.0's
and Rust will be too damn good for it to matter
@@pookiepats the reason why people look into a successor for C++ are all the existing code bases out there. You can't get rid of C++, nor replace it with Rust.
That's an interesting viewpoint. Could you please share more about why you believe the Carbon might not reach version 1.0?
@@pookiepats "If you can use Rust, use Rust. Carbon is for large C++ projects that cannot easily migrate to better alternatives without significant tradeoffs." - The Carbon Team
Rust isn’t necessarily a smooth successor to bring in with large legacy C++ code base - hence the emphasis of Carbon on being a C++ successor language because smooth/seamless interop with C++ is a top goal of the project. The main rival to Carbon will be something like Safe C++ where the seamless integration issue is completely moot because it’s still C++
Why not use all that energy (and money) into Rust and C++ interoperability?
Cause the Rust hype is over?
@@gerritlikestohike What an empty statement! Such a world we are these days :)
@ Hey ofc my answer was only half serious but your questions didnt make any sense either...
This is a great question. The community will probably improve Rust/C++ interop more quickly than this can reach 0.3.
Because the Rust foundation doesn't want that interop, and Rust doesn't belong to Google but Carbon does.
So far, I don't see a single reason for this to exist.
I really appreciate your efforts! Could you help me with something unrelated: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How can I transfer them to Binance?
TS is not a language , for many reasons tucked below; but in short its operational bounds is plain text (Javascript), no native execution platform, "Any", No standard specification other than "we'll always be a superset of this other actual language" - if your "grammar" is predacated on a separate body you have no control over - that is NOT a programming language.
Also - Kotlin is not a successor either, no more than Scala or Clojure... so annoying when they let AI write their slides.
How's having runtime required for a language? Is Rust a language?
A language has a grammer not a runtime. Runtimes are systems things. You getting yourself worked by this language males you say dumb things.
You don’t understand this enough to be so worked up.
@ an unambiguous grammar, which even then TS fails; not a language
@ 1. No, don’t be dense
2. Rust does have a runtime so you should feel silly, it’s small but it’s there
3. The context matters, TS is being asserted as a language (superset of JS) in the video so let’s deduce from there:
-can JS run in the browser? yes.
-- can TS run in the browser? NO
-can JS run on a server? Yes, via a runtime.
--can TS run on a server? NO, it is always transpiled to JS
-does JS have a standardized specification? Yes
--does TS? No
So what have we learned?
A. Typescript has no native runtime
B. Typescript has no standardized specification a la Elm or Purescript or Clojurescript etc
Typescript is NOT a programming language, I’m sorry that you just ingest whatever marketing material Microsoft throws your way, but these are facts; you’re welcome.
TypeScript is a language. It has a grammar. It has numerous compilers with the most used one being a transpiler for JS and a compiler for WASM. Transpilers to other languages exist as well. Even a LLVM compiler is in the works. JavaScript is also a language regardless of ANY runtimes. Golang is a language. There are numerous runtimes that use Golang (gc, gccgo, tinygo, etc).
Languages are not runtimes.