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

[Sergey Podobry]

You often don't even need unsafe. Depending on what you're doing, you can often achieve the same performance by using either use Rc<T>/Arc<T> with Weak<T> for the parent pointers or something like Vec<T> and indexes akin to mmap(2) and pointers, but with protections against escaping that particular data structure's arena.

The optimizers can do some pretty impressive things if you use the abstractions well and some of the best safety-dance security audit outcomes I've seen have been about rewriting code to remove unsafe that turned out to be unnecessary to get the performance.

I asked about linked lists (trees, graphs, ...) without overhead. Reference counted pointers have overhead as they need to stall execution on all CPUs for their atomic counters. Also inserting a list item is allocation free in Linux kernel. It's possible in C and C++ and not possible in Rust. It doesn't make Rust a bad language. But it has its own pitfalls.

[Anux]

Your joke detector must be broken.

Yeah my detector is in the maintenance workshop and I have to use my brain to do the job. That's actually pretty hard since I don't know you and you left no smiley indicating a joke. People in the internet have the strangest opinions and mean it, so you can't ever be sure.

[ssokolow]

Rust has a lot of buzz in the internet. But in real life I visit a job board and see the following numbers:
c++ - 138
python - 182
java - 235
c# - 199
golang - 52
rust - 5

Who in sane mind wants to get 5 job proposals instead of hundreds? So almost none will invest time into learning Rust. The same goes from the company perspective: do you want your product to get locked with a not widespread technology and hard to find developers?

According to people who are paid to work on Rust, companies are currently in a mindset of "Evaluate and hire people based on the languages used in our existing codebase, then train them as necessary for our experiments in moving things to Rust". That'll change over time.

[ssokolow]

I asked about linked lists (trees, graphs, ...) without overhead. Reference counted pointers have overhead as they need to stall execution on all CPUs for their atomic counters. Also inserting a list item is allocation free in Linux kernel. It's possible in C and C++ and not possible in Rust. It doesn't make Rust a bad language. But it has its own pitfalls.

True. My point was more that people tend to overestimate how often unsafe is necessary to achieve a given level of performance. Also, Rc<T> isn't atomic. That's Arc<T>. Rc<T> is instead prevented from being sent to another thread at compile time.

[sinepgib]

Yeah my detector is in the maintenance workshop and I have to use my brain to do the job. That's actually pretty hard since I don't know you and you left no smiley indicating a joke. People in the internet have the strangest opinions and mean it, so you can't ever be sure.

It depended on some missed assumptions on my side, namely:
- That everyone around here knows Donald Knuth is an extreme;
- That naming a single individual kinda proved the point that it isn't common.
But yeah, a smiley would have helped.

[dekernel]

Uh, Microsoft and Amazon are pushing heavily for Rust, and Rust is being included in Linux, the first language besides C to be.

Look, I can appreciate your zeal for the language and the possible impact it might have, but you should also appreciate where many of us are coming from which are typically based upon years of experience. In the last 30 years, I can’t tell you how many languages that were going to revolution development have come and gone and the number of frameworks that were based upon those revolutionary languages that just withered away. Whether you like it or not, Rust is just now moving out of it’s tech infancy and just starting to stretch it’s legs. If I had to give a number, I would say that it took C++ almost 20 before it came a true force within the industry, and as far I can tell, v1.0 of Rust is only around 8 years old.

Does Rust have potential….yup, for sure, but I don’t see a need to throw out all of tooling and time for C++ with the hope that Rust does get to a point where it is true tech force. If you think it is currently a true force then I am sorry to say that you are deluding yourself. If you are using the promises from organizations like Microsoft, Google, Amazon, IBM and such then you really might want to go back into the time vault to see just how many of those promises from those organizations have actually produced new and “revolutionary” tech when it comes to languages and tooling around those languages.

Regarding your statement with Rust and the Linux kernel:
1) When it does happen, it will be flagged as EXPERIMENTAL, and since Linus is quite practical, I would bet that if there is not big improvement (performance, ease of maintence and such) and he will require demonstrative proof, that it very well might just get dropped to reduce the overall complexity of the development system which is pretty keen on if I am reading between the lines of his statements.
2) Though the use of the kernel itself is big, the number of developers doing core development including drivers is quite small in the overall headcount within the industry so again the impact is not as big as you seem to think.

Nobody is saying you are wasting your time with Rust, but there are many of us that as we get up in years have learned that our time is quite valuable and just don’t want to waste CPU cycles jumping on the next big thing until it can prove itself for which Rust just hasn’t done as of yet.

[piotrj3]

According to people who are paid to work on Rust, companies are currently in a mindset of "Evaluate and hire people based on the languages used in our existing codebase, then train them as necessary for our experiments in moving things to Rust". That'll change over time.

Seen similar thing.

I seen plenty of C/C++ job offers that added it is great bonus if you know Rust.

[sinepgib]

Seen similar thing.

I seen plenty of C/C++ job offers that added it is great bonus if you know Rust.

I can attest that when I was interviewing for my team I made a point to recruiters that while they should of course send me people who already knew Rust, the real focus was understanding low level, so C and C++ were just as good. It's still a "young" language and not many people have real world experience with it. But in my experience Rust is not that hard to learn for people coming from C++, the real problem is when you come from higher level languages.

[ferry]

Probably just a bit more sugar on the syntax without solving any real problem, like most of the languages that are coming out.

... that make it in the press. I'm sure you haven't seen SAC (Single Assignment C) https://www.sac-home.org/about:sac. This is a functional language that looks like C (thank god) and is in principle suitable for auto-parallelizing. The focus is on high-performance numerical processing. But I am hoping this or similar language will finally auto-parallelize ordinary code to make use of our exploding number of cores.

[ssokolow]

... that make it in the press. I'm sure you haven't seen SAC (Single Assignment C) https://www.sac-home.org/about:sac. This is a functional language that looks like C (thank god) and is in principle suitable for auto-parallelizing. The focus is on high-performance numerical processing. But I am hoping this or similar language will finally auto-parallelize ordinary code to make use of our exploding number of cores.

ISPC is also good for that niche. I can't remember where, but I remember at least one Phoronix article mentioning something that used ISPC-based components in an otherwise C or C++ codebase to boost performance.