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

[jacob]

I'm starting to think you're furiously enraged at Rust because you're refusing to sit down and learn how it works.

He's just a notorious "real programmer" kiddie, incapable of understanding neither actual computer science nor software engineering requirements.

[sinepgib]

That's not how it works. Between different universities, C and python are used interchangeably while teaching the relevant math in primary courses. After 2-3 semesters, the people starting with C pick up C++, Java or Python to learn abstract programming concepts (OO, functional...) while the people who started with Python pick up C to learn low-level and system subjects. The gap is closed within another semester or two following. And when you look at total time spent on learning the language, you'll find C is simply not as demanding since it doesn't cover as much material by itself.

1. You're assuming a lot about how different universities teach. For example, where I studied Python is used just in the numeric methods class for some assignments, C is used only a little bit in computer organization and operating systems, they start with Haskell in algebra workshops, use that, prolog and I think smalltalk in programming paradigms, but from the first to the last of algorithms it's all C++.
2. Considering what you see in college as representative of any real use of C is almost a joke. I don't know about your university, but in mine there's seldom any attention to how the language really works.
3. Length of material and ease are not the same thing. Maxwell's laws are rather short to express, and yet...

No it's not. You do need basic arithmetic to learn calculus but Python isn't required to learn C nor does C is required to learn Python.

Wrong comparison here. We're talking about whether you need to understand data structures to be able to work with C, not other languages. I can be confident lots of people can do something with Python without stepping on UB or memory errors even without a solid understanding of computers. Can't say the same about C. But, specifically, the post I quoted it says it's easier because all you need is that.

Undefined behavior and manual memory management are interchangeable since the "undefined" part is simply hardware and OS details that leak behind the data type abstractions when you don't bound check everything.

Not entirely. The issues with negative left shifts have nothing to do with memory management, for example. Did they teach you to be wary of those at college? Or trap representations? Or even comparing the result of realloc with the old pointer? There are too many footguns, and I don't know of any local college that really teach you that. Maybe it's just this is a banana republic.

C's defect rate coef. is 0.11 while python's is 0.08 and C++ is taking the lead in most defect inducing language there is at 0.18: https://cacm.acm.org/magazines/2017/...ithub/fulltext

And both Microsoft, Apple and Google had plenty of internal reports and surveys corroborating those figures which is why they all ended up developing alternative languages to try and reduce their C++ code-base as much as possible.

We're talking about memory issues tho, not defects in general, but fair anyway.

That's generalization since all of the modern programming languages aim at specific domains rather trying to do everything and failing like C++ did. Rust, for instance, aren't too focused on fleshing out many of the abstractions C++ facilitates which is why they're not quite ready for GUI development and the likes. Go too, doesn't intend to replace C in low level as you can plainly tell from their huge run-time and GC dependent stdlib and are only expanding their coverage towards some other use cases.

It's not. You may not replace the whole, but you do intend to replace it for your use case. Also, Rust is quite focused in fleshing out abstractions. But it's also trying to replace C/C++ in the few niches where they still actually make sense, and there are decent enough replacements for GUIs (or well, popular enough at least).

C++ is like the dinosaurs. It will die out in most use-cases, leaving a few gator-like living fossils libraries just like you can still find FORTRAN being used in ML to TK/TCL in python for GUIs. All the new stuff is written for DSLs. And in a DSL eco-system, C++ is just legacy.

We agree. If it seemed like C++ would die everywhere in my comment then it was poor writing on my side. The point was that you wouldn't need to convert. Just like you don't really need all your Python devs to learn FORTRAN so they can maintain BLAS/ATLAS (it doesn't need that many maintainers) you won't need those Rust programmers to also then learn C to maintain whatever other projects weren't replaced by it.

[c117152]

Those two claims pretty much contradict each other. If you need a lot of math background and formal education then it's not easier.

That's not how it works. Between different universities, C and python are used interchangeably while teaching the relevant math in primary courses. After 2-3 semesters, the people starting with C pick up C++, Java or Python to learn abstract programming concepts (OO, functional...) while the people who started with Python pick up C to learn low-level and system subjects. The gap is closed within another semester or two following. And when you look at total time spent on learning the language, you'll find C is simply not as demanding since it doesn't cover as much material by itself.

It's like claiming advanced calculus is actually easier than basic arithmetic...

No it's not. You do need basic arithmetic to learn calculus but Python isn't required to learn C nor does C is required to learn Python.

Besides, the problem with C is seldom manual memory management. That's a big pain point, and something you can screw up for your whole career, but the real issue is it's hard to always keep in mind all the foot guns in terms of undefined behavior all the time.

Undefined behavior and manual memory management are interchangeable since the "undefined" part is simply hardware and OS details that leak behind the data type abstractions when you don't bound check everything.

In that sense, C and C++ are more or less equally bad, although at least some coding guidelines make it easier to not need the dangerous parts in C++.

C's defect rate coef. is 0.11 while python's is 0.08 and C++ is taking the lead in most defect inducing language there is at 0.18: https://cacm.acm.org/magazines/2017/...ithub/fulltext

And both Microsoft, Apple and Google had plenty of internal reports and surveys corroborating those figures which is why they all ended up developing alternative languages to try and reduce their C++ code-base as much as possible.

That is irrelevant. The point of replacing a language is that you don't need to cover the other way around.

That's generalization since all of the modern programming languages aim at specific domains rather trying to do everything and failing like C++ did. Rust, for instance, aren't too focused on fleshing out many of the abstractions C++ facilitates which is why they're not quite ready for GUI development and the likes. Go too, doesn't intend to replace C in low level as you can plainly tell from their huge run-time and GC dependent stdlib and are only expanding their coverage towards some other use cases.

C++ is like the dinosaurs. It will die out in most use-cases, leaving a few gator-like living fossils libraries just like you can still find FORTRAN being used in ML to TK/TCL in python for GUIs. All the new stuff is written for DSLs. And in a DSL eco-system, C++ is just legacy.

[sinepgib]

The other advantage I just recently realized is that the error message are incredible useful. For example I mistyped a variable name and in the error it suggested that there is another variable with a similar name (see screenshot attached). Note that this is the compiler, not an IDE. It really puts every other compiler I remember to shame. I'm not sure if Rust (or Carbon) are going to be successful in the future but it sure raises the bar for me of how informative a compiler should be to its users.

TBF we do have that with C. The one to raise the bar with this was clang (with help of LLVM). But yeah, Rust is really very useful in terms of the error messages from the compiler, it almost always suggests the right fix (there are situations where it can get confused, of course).

[darkonix]

Both problems are real, but OP states a decent understanding is good enough to catch the memory errors (which seems to not be true, by the cited statistics), while even then it's certainly not enough to be constantly wary of UB in unexpected places.
Besides, UB most often causes memory errors AFAICT. "Oh, this NULL check is in the wrong place, let's erase it", boom, memory error triggered by UB. In fact, almost all memory errors I can think of are either UB or caused by it, with the exception of memory leaks? Accessing uninitialized memory: UB. Dereferencing NULL and freed pointers: UB. Double frees: UB. Out of bounds accesses: UB. Wrong pointer casting: UB. Maybe I'm wrong about it being most, but it surely a lot of it is.

I agree. At the time when I programmed in C/C++ I would not call that undefined behavior specifically. They were simply bugs to me. You should not double free, or use uninitialized memory, etc. The main problem is that it is very difficult to catch *all* these issues just by reviewing the code. Sure, you can catch many and if you are dedicated you can catch a lot. But you never know how many are you missing until they blow.

Thinking back I suspect that more than 90% of the bugs I had back in the day that caused the application to be unstable would have just been impossible to cause using Rust today. It would just not compile. Whatever one feels of the language that is a big advantage.

The other advantage I just recently realized is that the error message are incredible useful. For example I mistyped a variable name and in the error it suggested that there is another variable with a similar name (see screenshot attached). Note that this is the compiler, not an IDE. It really puts every other compiler I remember to shame. I'm not sure if Rust (or Carbon) are going to be successful in the future but it sure raises the bar for me of how informative a compiler should be to its users.

[sinepgib]

It really depends at what problem are you looking at. For an individual programmer you may be very well be right but for the industry in general there are statistics that prove that around 70% of security issues are relate memory related.

Both problems are real, but OP states a decent understanding is good enough to catch the memory errors (which seems to not be true, by the cited statistics), while even then it's certainly not enough to be constantly wary of UB in unexpected places.
Besides, UB most often causes memory errors AFAICT. "Oh, this NULL check is in the wrong place, let's erase it", boom, memory error triggered by UB. In fact, almost all memory errors I can think of are either UB or caused by it, with the exception of memory leaks? Accessing uninitialized memory: UB. Dereferencing NULL and freed pointers: UB. Double frees: UB. Out of bounds accesses: UB. Wrong pointer casting: UB. Maybe I'm wrong about it being most, but it surely a lot of it is.

[darkonix]

Besides, the problem with C is seldom manual memory management. That's a big pain point, and something you can screw up for your whole career, but the real issue is it's hard to always keep in mind all the foot guns in terms of undefined behavior all the time. In that sense, C and C++ are more or less equally bad, although at least some coding guidelines make it easier to not need the dangerous parts in C++. Heck, it's hard enough to make someone understand what UB even means.

It really depends at what problem are you looking at. For an individual programmer you may be very well be right but for the industry in general there are statistics that prove that around 70% of security issues are relate memory related.

[arQon]

That is irrelevant. The point of replacing a language is that you don't need to cover the other way around. If Rust actually becomes mainstream, you simply won't need as many C programmers, so it doesn't matter whether your Rust programmer can gain proficiency in C. But now the industry have "good enough" programmers at cheaper prices.

Right on all counts, but the point is that those "unneeded" C programmers can easily be turned into Rust ones, but the opposite is not true. If you have a pool of 20 "average" C devs and 10 "average" Rust devs, where neither have any experience with the other language, you effectively have 25+ Rust devs a month from now if you want them. OTOH, if your pool is 10 C devs and 20 Rust devs under the same conditions, you effectively still only have 10 C devs a month from now, maybe a dozen or so if you were really lucky.

This is a hugely important difference, because the majority of any given developer's value to you isn't their technical skill, it's their understanding of the company's systems and their business. Being able to keep all of that knowledge makes any sort of transition far more likely to succeed. For a lot of scenarios, Rust's "safety" has a lot more value in terms of development time than it does in any runtime aspects.

[arQon]

I have no substantial experience with garbage collectors or languages that use them, but (snip)

There are a few families of GC, and they're pretty much all worth a read if you have time. You want to do so chronologically, so you can see how they evolved.
Early ones operate pretty much the way you're imagining; later ones are, unsurprisingly, better both in general and with edge cases. Fundamentally though, the problems with them remain unsolved (obviously, or we'd all be using them :P), and they simply aren't functional for certain work.

> I think it's instructive to look at it as a proportion of execution time. That would mean if it runs once per second, that it takes 1% of execution time. Since faster CPUs are faster both at allocating memory and freeing it, an efficient garbage collector could conceivably impose a similar amount of overhead on a fast CPU as a slow one.

Not really, no. "Could conceivably", as you say, and you can certainly create scenarios where it does, but you're missing a critical factor in that train of thought: when the GC completes affects your footprint *and* your performance.

> Hence, the target of 10 ms rather than an absolute percentage, because certain programs might have to run it more frequently than others.

Not sure if what you're suggesting there is really what you meant to say. Regardless, yes: per the parable, there's a big difference between one boulder and many pebbles.

> The other consequence of a 10 ms target is simply that the GC be partitioned into parcels of work small enough that you can always complete useful amounts of work in that amount of time -- even on low-end CPUs.

Not really, which is where I was heading earlier. You can work out why pretty easily (the more recent GC designs *are* a lot better on that front). The guarantees also tend to get a bit unreliable pretty quickly unless the machine is idle, for obvious reasons, but the real problems start when the collection timeslice isn't enough for the GC to complete. It's *really* easy to have something appear to work fine even under "typical" load, but either balloon or stall under heavy load, just like every other GC ever. That leads to either significant extra cost from over-provisioning and/or having to expand the fleet, or a system that just "doesn't work" if you don't have that option (i.e. embedded).
Depending on what the rest of the system is doing and what's waiting on what, you can end up breaking things just because the performance characteristics of a *non-Go* piece of the system have changed, because of additional throughput or buffering, depending on the direction of the change. (Yes, that's a curiously specific example - ask me how I know... :P)

> Perhaps a bigger variable than the CPU type is actually the amount of RAM a garbage collector has to manage.

Less "perhaps" and more "sometimes", really. It's also generally less about the total memory use and more about *how* that memory is used, c.f. the parable again. 120MB of scattered small allocs needs lot more management than a single 200MB chunk, though the allocators tend to be pretty good about drawing from pools, so the smaller case at least doesn't usually also claim more pages than the larger one, though obviously you can still be "unlucky" depending on what else is going on.

[sinepgib]

First off, don't put c and c++ in the same boat. C is easier than python. It just takes a lot of math background and formal education in algorithms and data structures to get comfortable with manual memory management.

Those two claims pretty much contradict each other. If you need a lot of math background and formal education then it's not easier. It's like claiming advanced calculus is actually easier than basic arithmetic, because you just need a strong math background and arithmetic builds on nothing, which makes it harder to exploit those foundations. And yet, everyone else will easily understand it's the other way around and that's why most people "get" basic arithmetic but can't think of multivariate calculus off the top of their head.
Besides, the problem with C is seldom manual memory management. That's a big pain point, and something you can screw up for your whole career, but the real issue is it's hard to always keep in mind all the foot guns in terms of undefined behavior all the time. In that sense, C and C++ are more or less equally bad, although at least some coding guidelines make it easier to not need the dangerous parts in C++. Heck, it's hard enough to make someone understand what UB even means.
Being able to write code that seemingly works is not the same as knowing the language well enough.

1. Even a mediocre English literate can become proficient in *phonetically consistent language script* in a few weeks at most. How many *years* do you think it takes a *phonetically consistent language* literate to become equally capable going in the other direction?

That is irrelevant. The point of replacing a language is that you don't need to cover the other way around. If Rust actually becomes mainstream, you simply won't need as many C programmers, so it doesn't matter whether your Rust programmer can gain proficiency in C. But now the industry have "good enough" programmers at cheaper prices.