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

[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.

[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]

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]

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).

[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]

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.

[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.