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

[coder]

By the way - what was the reason for Go? I mean, the big thing which is shiny, new and selling ... or is Google just enough so people may think:
"It somes from Google - we should learn it." Don't think that this will work ...

I'm pretty sure it came in the wake of the big Oracle/Java lawsuit. Prior to the arrival of Go, Android was too closely tied to Java.

I don't know if Go might've had deeper roots than that, but I think that's at least why Google was pushing it so hard.

[coder]

C: I do things

C++: I do 100x more things
C++11: I do more things and more modern but also the old things
C++14: I do more more things and more modern but also the old things
C++17: I do more more more things and more modern but also the old things
C++20: I do more more more more things and more modern but also the old things

Heh, C++ has deprecated plenty of things. Not nearly as much as they've added, but enough to block some legacy codebases from upgrading. Here's an incomplete list:

• auto keyword (worse than deprecated, they repurposed it!)
• export keyword
• register keyword
• volatile keyword
• exception specifications
• some uses of the comma operator
• std::auto_ptr<>
• standard library's legacy function adapters
• some standard library type traits adapters

That's not nearly as bad as some of the proposed deprecations that might eventually come to pass. If Carbon helps stem the tide of deprecated features, that might indeed be its most valuable contribution to the C++ community.

The C standards committee, on the other hand, seems to have a better appreciation of C's status a mature language. That said, I do wish C generics worked a little more like C++ function overloads -- not simply switch statements over a parameter type -- as I think that would be enough to enable some meaningful type-safe generic algorithms and datastructures (i.e. like a C version of STL).

[coder]

FF is really a bad written program.
Short on memory - exit FF and restart it - problem gone.

You're thinking about web browsers like it's 1999. Or maybe 1994 is more like it.

You might as well say the same thing about an OS, when people have lots of programs running -- because browser tabs are just that. You should think of each browser tab a program (or set thereof) you're running, that you downloaded off the web.

[coder]

All software eventually needs to be rewritten. Look at Xorg, it's gotten so bad that they had to make a whole new standard entirely.

Did it "get bad", or was it just old technology that failed to keep up with the needs of users? Wayland is not a rewrite of Xorg, it's a new standard to replace X11, which Xorg merely implements. If you're going to use examples to make a point, it helps not to be so sloppy as that can derail the discussion.

Linux has also been gradually completely rewritten since it first began.

Given that it's stayed 100% C (until Rust drivers land), and that there was never a clean break with the past, that's not an apropos example. It would be more accurate to say that Linux has been continually refreshed, top-to-bottom.

[coder]

But C++ is broken. In more than one way.

Examples:

• https://alexgaynor.net/2019/apr/21/m...-wont-save-us/
• https://alexgaynor.net/2020/may/27/s...-and-security/

In the first article, the only good point was about std::string_view. Such mistakes are too easy. As for the others, anyone who actually knows C++ wouldn't have expected such cases would be solved by modern C++ anyhow.

The lambda-capture issue was a real knee-slapper. When you're using a lambda capture-by-reference, making sure the scope of what you're capturing exceeds that of the lambda is a first-order concern. It's on the same level as any other context in which you're using a raw pointer or reference, and thus something C++ programmers will be familiar with.

In the second, he states:

"I’m prepared to conclude that using memory-unsafe programming languages is bad for security."

It's too easy to fault them without considering the tradeoffs involved in any alternative. He never did a comparable analysis of security vulnerabilities in a system built using a memory-safe language. In such systems, I expect memory bloat would simply replace a lot of the dangling-reference and use-after-free bugs. When you trade one class of errors for another, it's not a win.

I'm not saying there's no net advantage to memory-safe languages, but I am saying that simply doing a one-sided analysis is incredibly sloppy and shouldn't be taken seriously.

[coder]

As a professional programmer for a company, I am going to use 1) the language that makes most sense for the problem at hand, 2) that will have long time support down the road, ie. well established, and 3) can be supported by the personal in-house.

Points 1 & 2 basically summarize why I think it's important to have a second implementation of Rust. As for #3, it's important not only to consider in-house expertise, but also what's available in the job market. That's another reason to stay on the trailing edge.

IMO, the worst argument for using a language is to "integrate with a legacy codebase", because it means developers not only would need to know Carbon, but they'd also have to know C++ well enough to dive into the legacy code and understand + fix issues. So, if Carbon lacks compelling value outside of integrating with C++, then I think it won't gain traction.

when universities start churning out professional programmers that have used Rust as there primary learning tool during there 4-10 year tenure...

But haven't most universities gotten away from C/C++? At least for undergrad?

Because if someone straight out of uni knows neither C++ nor Rust, I know which has the smaller learning curve.

[coder]

But this Google thing is another example of how the "modern" western societies run out of ideas, just like Hollywood.

Wow, that's quite a reach. Not to defend Hollywood, but to hitch your agenda to this particular example seems like confirmation bias, in the extreme.

I actually will defend Carbon on this point, in that they explicitly acknowledge that it's pragmatically-motivated and not intended to be a cutting-edge innovation. Whether it lives up to its aim is another matter, but it clearly wasn't done for the lack of better ideas.

[coder]

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?

In part, it really depends on which side you're arguing - an employer's decision to use Rust or a professional's decision to learn it. From the employer's side, they'd want to go where the talent is. And that brings me to my the main point...

Maybe the Rust numbers are low because lots of people are learning it, which means jobs tend to get filled faster? So, more analysis would be needed than just looking at a snapshot. We ought to look at the mean time to fill positions for a given language. That also wouldn't be uncorrelated with other factors, but it would be more fair than looking at the number of current listings.

BTW, I talked to someone hiring Rust developers, a few years ago. He said they were absolutely taking C++ developers, as they had little trouble with the transition to Rust. That tells me it's still not a waste of time to invest in good C++ skills, but this tidbit is both second-hand and a little dated.

[coder]

in 50 years we'll be replacing Rust.

I doubt that. C -> C++ is a vastly greater evolution than C++ -> Rust. This means one of two things: either we're converging on the "ideal" programming language (for mainstream uses), or that Rust is much more of an interim evolutionary step than anything wholly new. And for something to have staying power for the next 50 years, I think it needs to do a more comprehensive job of addressing the next 50 years' evolution in computing. I doubt Rust is up to that task, but that's just my opinion.

Rust is in Linux, you don't seem to be able to counter this given not even C++ managed to do that.

I think you lean too heavily on this point. C++ has a lot of baggage, including emotional baggage, cultural, bad press, and historical issues with compiler support. It could have been used in the kernel and could have been done to good effect. The reasons it wasn't weren't purely technical.

Also, they're only enabling Rust for use in drivers. Maybe more, in the future, but even that much hasn't landed in a shipping kernel release.

https://www.phoronix.com/news/Rust-F...-5.20-Possible

And this is the funniest thing about Rust critics.
...
You have psychosis.

Oof. You sure won that argument! The best way to win over the doubters is obviously to call them insane.


If you didn't notice, that post did have some claims of a technical nature that you conveniently ignored. Just because you'd rather talk about its features doesn't mean there aren't other potentially legitimate concerns.

[coder]

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

If Rust's borrow-checker can confer the same benefits as C's restricted pointers, then it could conceivably contend with C & Fortan, on the performance front.

C++ sucks for omitting restricted pointers. I understand they're dangerous, but it tells me C++ isn't truly a performance-first language. Luckily, all major compilers support them, if using nonstandard syntax.

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.

I wouldn't say that's an accurate characterization of Java's origins. At the time of its launch, it was already being positioned for serious client-side programs. In its first months, there were already high-profile announcements by some early adopters like Sega. Within a few short years, people were already using it for serious server-side deployments.

At the time, C++ was far more primitive, making it a much easier target for Java to equal/surpass. Heck, the first ISO standard didn't come until 1998 -- about 3 years after Java's introduction.

Special languages for special tasks are a myth - and this is not new but well known.

Which is why GPU shaders are all written in C++?


Another DSL I've witnessed is a live performance using Sonic Pi.

I'm also rather fond of XSLT. No matter what you think of its syntax, it would be mad to think C++ is a better tool for that.

I've heard of many other examples, such as telco switching gear using a DSL, because it required deterministic timing guarantees.

It's perhaps debatable whether one considers buildsystems a language, but I'd go there.

Domain-specific languages are real, though maybe not in the domains where you play.

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.

Square peg, meet round hole.