Carbon Language - Who is it even for?

---

[jeffreyokonkwo]

Employers: "Needs 5+ experience in carbon" lol

[SimGunther]

"Making things so hard for everyone, including yourself"
This rings so true for modern economies and things made by big corporations.

[nickkallen]

It’s obvious who carbon is for — it’s for people like me. I program in c++ because the libraries I’m using are in c++. I had to learn c++ this year, and while I already know dozens of languages, including C, learning to write C++ safely has been a huge time sink. To program well in C++, learning smart pointers and move semantics and rvalues, the weird template language, memorize all the gsl conventions, pick a style guide (like google’s), constantly fight circular references with forward declarations and virtual destructors, decide if I use exceptions ? C++20? Man, now I’m pretty good at the language and even kind of like it! But I WISH I could have skipped this process and just used a better language ! And still use c++ libraries transparently. I wish I could use carbon!

[CountJamesMcGuigan]

What Google seems to be saying is that if you have the ability to do a clean rewrite in Rust, then you do that. The problem is that many companies have large legacy C++ codebases and it's not always seamless to mix Rust and C++ code in a slow incremental manner.

Calling Rust from C++ seems to be fine, but the issue seems to be calling C++ from Rust, which suddenly forces the C++ code to be rewritten to obey the much stricter rules of the Rust borrow checker, else it forces Rust to make all its C++ calls from inside an unsafe block, which negates the main advantages of Rust memory safety.

So Carbon seems to have been designed as a language that can directly transpile to C++. Sort of like how Typescript and Javascript are related, for legacy codebases wanting incremental migration.

[nexovec]

0:28 "It's a big language, and it's a very small language" :D made me laugh

[brendanhansknecht]

I think ffi is nice in theory, but Google has a lot of c++ and it is not written c-style. So when it comes to incrementally changing to another language like rust, you have a big problem. Writing rust code that regularly interacts with non c-style c++ leads to bad rust code. So unless you rewrite in large chunks with clean interfaces, migrating is not reasonable.

I think some language probably could do this better, maybe Odin. But also, could Google realistically contribute to Odin and change it to match their needs. Most likely, you would not want the Google team to suddenly swoop in and want significant sway over your language. As an aside, if they would be doing significant work bootstrapping a language like Odin to their needs, why not just make their own even more targeted language, it isn't that much more work (when thinking in Google scale and timelines).

My hopes for carbon compared to c++ are:
- correct defaults
- less ways to do things
- reasonable safety without the hassles that rust gives you
- amazing interop with c++ so it can be used in more places seamlessly
- more cohesive tooling
- better syntax
- faster build times

Of course the language is super new and just an experiment right now, but a lot of these pieces should be achievable. Then it creates a way to incrementally improve from c++. But for just about everyone who isn't just interested in carbon for the hell of it, the language is not meant to be useful. It is truly just targeted at large corporation who feel stuck with c++. I am hoping it does well enough that I can use it whenever I would have used c++ for something.

[TheSulross]

there's a crowd of people that work in C++ that, since the blizzard of releases and features from C++11 onward, just want something like a compile option --prohibit-legacy-cruft and --use-sane-defaults (C++ has a myriad of keywords that must be sprinkled profusely in the code as noise where should have just been the default case)

Something like Carbon is probably for that crowd, or is at least intended for them. They need to co-exist with C++ and ball and chain legacy code bases

[torarinvik]

Great video!!! Warning this is maybe off-topic.I really like what I have seen of Odin, although Im a fan of C++, and love OOP(not fanatic, but pragmatic OOP) I have to admit that Odin is a fine piece of work from what I've seen. The syntax is clean, easy to read and has the most import tools afaik. What I love about OOP is the ability to raise the level of abstraction, humans are natural classifiers so OOP is in my perspective is a lot about code organization as well as the other benefits. The more procedural data-oriented way is also a very good paradigm for different reasons. The disadvantage to bundling data with code is that you lock you functions into a specific type. This means potentially loss of modularity and ability to make generic reusable code. Sometimes you just need to do transformation on data. All paradigms, languages and tools in general are compromises, so it's just about finding the right tool for the job(cliche I know). Sorry for the off-topic, just been watching a few videos here on Odin and wanting to comment. Once again kudos to gingerBill Odin looks very promising, I think it has a bright future.

[scottmcfarland]

It seem one of the main reasons for creating Carbon is for companies with large code bases and parallel compiling: "Fast and scalable builds that work with your existing C++ build systems"

[diaaway]

As someone looking into adopting rust for business purposes I look forward to your (hopefully) future video about what its faults are! :)

[blubberwalrus]

Look at this from the perspective of Kotlin vs Java and suddenly Carbon vs C++ makes sense. This is for devs and big orgs who want the power, wisdom, and safety of established C++ libraries with nicer syntax and ecosystem of a modern lang. You talk about performance, but the main draw of Dart and Go is not performance as much as it is readability. It costs a ton to develop in C++. Carbon not there yet, but we can realistically expect that Google will keep pushing.

[kevindelnoye]

sean baxter creator of the circle programming language fully implemented a c++ fronted by himself built on top of llvm. also adds a lot of extensions and proposals from the c++ commitee not part of c++ today

[ratgr]

I think It is a language for people like me, I use C++ in my day to day but work in both huge codebases and embedded systems, wrapping a library is really a pain, and maybe later you are going to switch, and incur the wrapping cost again, the idea is to file by file remove C++ from our codebases, to a richer set of features without a lot of baggage we get from C++, sure not all of it but a lot, the smaller amount the better.

[duke]

It's for people like me who don't want to use C++ cause the hieroglyphics scare me

[janniantic]

I can tell you who is it for: It is for me :)
It took me nearly 20 years to understand C++ and I'm pretty sure after years of debugging and customer support that I would not like to use it anymore for new projects. Especially because there are so many traps where new devs just run into too easily.
Odin an Nim are unfortunately not widely used - which reduces the amount of usable existing code to use and increases the likelyhood to discover new traps :/
Carbon on the other hand is a good candidate to be used widely in some years.
Sometimes it is not the best thing to use the best existing language but just to choose one that solves your problem and might keep solving it a few years later.

[marcsh_dev]

Yeaaaah. Unsure if anyone will read this, but Ill slap down some comments.

So, Im a bit of a weirdo. Come from games (25 years): gameplay, graphics, networking, tools. Ive seen C+ (blessed subsets of C++) work really well for fast dev of fast programs. I like duck typing, and partial template specialization and all those sorts of things

I also love languages, the weirder the better. Smalltalk, Clojure, Scheme, Scala, Idris, Erlang, etc are all awesome and have great things to share.

The rise of the Better C compilers is really neat too. Could talk for hours on those, but for right now, I love seeing folks experimenting in that space.

So, all that to say, I have NO idea who Carbon would be for, or why it is how it is. My approach to the same language (A globally usable C+) would be pretty radically different I think.

Then again, games, and in particular gameplay, has pretty radically different needs than most folks, and nothing EXCEPT The Tomorrow Corporation folks, are really solving our needs.

[nexovec]

So your conclusion is carbon is the wrong step in the right direction?

[alexitosworld]

Those are the same companies that need their own build system because the standard ones don’t work at their scale right?

[GillesLouisReneDeleuze]

8:20 Sean Baxter implemented his own C++ front-end for Circle lang. I think, what's really hard to implement is the back-end. If I not mistaken, Odin also still uses LLVM back-end.

[MrAbrazildo]

0:16, you should really make a small video about Odin. 5-10 minutes just showing its features, 20-30 explaining them a little bit. It's hard to face a playlist of 3 hours videos each, just to take a glance over it. Your language won't ever get popular this way. I'll have the guts to get along with at least 1 of your videos, only because I'm curious about how something could be better than C++ (I lack imagination for that).
3:07, it seems they are too much worried about C++ type deduction. _"Even using (C++20) _*_concepts_*_ you still won't have _*_generics_*_ " (template from Java/C#)_ - Carruth, C++ committee member, working on Carbon. Personally I don't have issues about this, and love C++ fast/concise typing. Changing its features just because "people are not able to manage them properly", unfairly blaming the language, is the same wrong vision that made Java a so bad and ugly language.
8:00, I think it's nice to experiment, and C++ libraries don't interfere in the language, as it has been seen in higher level ones.
11:04, it's too early to be worried about it. It's just in an experimental phase. The language is way easier than C++ for being read by a compiler - _of course, it asks for the programmer's help, by messing the type deduction_ .
14:21, whaaat?! I think C++ is following the leading path. It has plenty of undefined behaviour opportunities, but that is for good reasons. Other than that, some traps. But it's the price for conciliate low and high levels, with all flexibility the language has.
17:25, I can't give thumbs up for this, because I don't agree with your opinion about C++, and because you failed to notice that Carbon already is destined to has its followers: people who are desperate about C++ type deduction.
PS: try to improve your diction. You smash words too much.