Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

[Mordrag]

Let me quote someone else: "I've written C and C++ professionally, also used Go and Rust on hobby projects. Rust, by far, was the hardest to learn and get something useable out of it. Because of that, I would never recommend someone put it into production unless they have a very specific use case that Go could not handle. The onboarding costs would be just too much."

Rust is an investment. If you can write good Rust code , you will become a better C++ developer. I would guess it takes between 1 and 2 weeks to become productive in Rust, in what way is that a too high onboarding cost, when we as developers put years of development time in different projects ? Heck even if it would take 2 month to get productive in Rust, the benefits in the long run outweigh the learning cost by a huge margin. I actually have never talked to a person who really! understood how Rust works and said things along the line: "naah those memory safety benefits is just propaganda who needs that anyway". "Borrow checker is just silly, I want those use after free, double free etc. memory errros" "Rust isnt safer as C++ it has also 'unsafe' that disables every safety benefits" (it does not). The majority of people here in the sub that criticize Rust seem to have no or very little experience with Rust but a very strong opinion. And that is especailly sad as there are valid points where Rust falls short: platform support (could be resolved by gcc port), async programming experience (atleast the current state is debatable), modular ABI etc.

[Ironmask]

Let me quote someone else: "I've written C and C++ professionally, also used Go and Rust on hobby projects. Rust, by far, was the hardest to learn and get something useable out of it. Because of that, I would never recommend someone put it into production unless they have a very specific use case that Go could not handle. The onboarding costs would be just too much."

I'll ask you again;
Can you describe why Rust is complex?
I'm not looking for someone else's answer, I'm looking for yours.
Please tell me why, in your infinite wisdom, Rust is "too complex", tell me how you've surmounted this insurmountable obstacle that is learning Rust, the most beloved language on SO for 5 years straight, so that you can tell me your informed critique of Rust's construction and how you might design it better to achieve the same goals it does while being more accessible?

[JMB9]

what's wrong with calling it systemd_carbon ?

systemd is IBM (formerly Red Hat ) ... while Google is Advertisement and Drugs called Smartphones.

[archkde]

Wouldn't a

unsafe {
}

disable the borrow checker?

Not in the slightest, the borrow checker is always active in Rust. Unsafe allows you to perform some extra operations that sidestep the borrow checker. (This distinction is in fact very important, since it makes lifetime inference affecting the surrounding code much more predictable.)

[JMB9]

yes, you're missing a thing or two

Firstable, Java is not slow. It is as fast as C++ and Go (when not even faster);

Second, Go approach to almost everything is the opposite of the one used in Java..
They're so different that Java is often used as an example on how NOT to do thing is Go.

The reasons why Go was created are well illustrated by several talks by Rob Pike (one of its creator) that you can find on YT if really interested, but some key points are:

* simple to write / simple to read (to enable new Google employees to be able to work on big projects from day 1... or almost!)
* simple to deploy
* fast at compile time / fast at runtime
* concurrency made easy: while it's true that every programming language allows some kind of concurrency, the Go model for concurrency is awesome.

Sure, I sure miss a lot of points ...

But from your given key points why Go is good the 1st two start with "simple".
I am not a poser who want to say "I managed to program in the worst language ever".
As former scientist I got to the conclusion that if you work hard and need high quality, you have always to aim at higherst efficiency right from the start.
So using mouse, an easy editor or IDE, small variety of possibilities will bite you fast - this leads nowhere.
I could only recommend keyboard for real work on large hi-res screens, using programs with a steep learning curve (you may shout at it, but soon you will
live within such a tool), and accessible or easy are both not on top of my wishlist - the are there - but near the bottom.
C++ or C are both worth learning (high optimizing compilers for all architectures) ... and you can not use toold in development,
i.e. teams my aim at C++17 right now - not C++20 - let alone C++23.
And next to C and C++ - the air is thin - and Fortran may be my 3rd guess.
All old programming languages - why no new language? Are they not more effiecient and thus would take over soon?
Concurrency is extremly important - plenty of multicore systems - or even super computing (HPC/TOP500) ... what is used there ... ???
So we don't need a discussion here ... the answer can be seen - but of cause not in those serveys which claims Java as important.
And no, I have always seen that Java programs are slow - big companies tried to replace C tools by Java tools - there are lots of
Java written games out there - and all feel slow to me ...
If you can not afford using assembler, C and C++ are still the way to go ... we will see if anything can take this place ...
Rust and Go and too new to judge right now, Carbon is a toy project just yet ...
Mixing syntax of different languages is not to my taste ... my 1st question: why using carbon and not C++.
I did not see any convincing point right now ... and if one could ask which language may be used (not saying to dominate like
C and C++ do right now) - maybe Rust. Go and Carbon are not visible ... but as clearly pointed out ... I sure miss several points.
Basic and Java were beginner languages ... would give Python, too - and all have in common that they started more on the
scripting side and not as full fledged programming languages being good for all purposes.
Special languages for special tasks are a myth - and this is not new but well known.
The good programmer makes his language fitting perfect to the problem by his code ... it is not the choice of the language
fitting best to the task.
My 2 ct - but anyone is free to disagree and give arguments ... and arguments are really good to learn new things - or to get curious.

[Anux]

Not in the slightest, the borrow checker is always active in Rust. Unsafe allows you to perform some extra operations that sidestep the borrow checker. (This distinction is in fact very important, since it makes lifetime inference affecting the surrounding code much more predictable.)

THX, honestly I never used unsafe, just a script kiddie trying to get used to rust to the point that I consistently know before the borrow checker if something is safe.

[Raka555]

I'll ask you again;
Can you describe why Rust is complex?
I'm not looking for someone else's answer, I'm looking for yours.
Please tell me why, in your infinite wisdom, Rust is "too complex", tell me how you've surmounted this insurmountable obstacle that is learning Rust, the most beloved language on SO for 5 years straight, so that you can tell me your informed critique of Rust's construction and how you might design it better to achieve the same goals it does while being more accessible?

Fishing for something so you can launch a personal attack ?

[ssokolow]

You can count them on fingers. While there are so many companies using Java, Python or C++ that you couldn't fit them in a single post on this forum.

Just the list of companies who've actively asked to be added to their vanity wall of production users would take fingers and toes to count on seven people.

https://www.rust-lang.org/production/users

[sinepgib]

They never existed in the first place. Or can you show me a project of one of those miracle programmers that never had an error (concurrency, buffer overflow, use after free, ...) thats not possible in rust?

I mean, there's always Donald Knuth.

I have never been able to get that source code to compile properly. Always some incompatibility or version issue.
That shows to me that rust is not ready yet (after 12 years in the making).

That happens with tons of C code you can find for niche but relevant programs and nobody would say it's not ready yet tho.

The borrow checker is its worst feature.

Two questions and an opinion:
1. Why exactly do you consider it its worst feature? Specially compared to some known misfeatures.
2. What is so much better that you suggested you would drop C++ in favor of a Rust with no borrow checker?
3. I think if that's the worst feature, then nothing in Rust is worth the attention. Nobody is migrating away for some syntax sugar. Decades of attempts prove it. The borrow checker is the only thing that is really fundamentally different from C++, everything else is some ergonomics.

[ssokolow]

Wouldn't a

unsafe {
}

disable the borrow checker?

No. Constructs available outside unsafe blocks still function identically within an unsafe block and the LLVM IR annotations like noalias that promise the optimizers that it's undefined behaviour to synthesize a non-exclusive &mut still get added if you do it by casting from & to &mut through a raw pointer.

As https://doc.rust-lang.org/nomicon/what-unsafe-does.html says...

The only things that are different in Unsafe Rust are that you can:

• Dereference raw pointers
• Call unsafe functions (including C functions, compiler intrinsics, and the raw allocator)
• Implement unsafe traits
• Mutate statics
• Access fields of unions

You seem to describe Rust.

It sounds like they want what boats discusses in Notes on a smaller Rust and Revisiting a 'smaller Rust'.