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

[c117152]

I think the issue comes from what Go intended to replace versus what it actually replaced.
When Rob Pike and company created Go, they meant it as a replacement for C, that's how they marketed at the time. In reality, it ended up being a more suitable replacement for scripting languages used for web development. But because it was intended as a C replacement, Rust advocates tend to think they actually compete in the same space, when they absolutely don't.

Wrong. Rob Pike and co. always intended for Go to replace C++/Java in service backends. They specifically started talking about Go while writing yet-another-C++ backend and realizing it would be simpler to just do their own language instead.

His surprise was that instead of pulling-in the C++ devs from the high-performance end since Go was far easier to develop in without losing too many cycles, it pulled in the python devs from the low-performance end since Go was simple and fast compared to all the other options in that space: https://news.ycombinator.com/item?id=8575038

[Sergey Podobry]

There are few Rust jobs, precisely because they get taken.

Well, we need then number of closed vacancies per month instead of the currently open. I'm assure you that the ratio will not be in favor of Rust. Rust jobs are very rare. So you'd better learn another programming language and leave Rust for hobby.

[mos87]

c++ successor from a hopelessly java crowd? replace the lid please. thx.

[cj.wijtmans]

I would never ever want auto parallelization in my language. Might be good for some cases. Very bad for others.

[arQon]

Nah, this is a good one, we need a real modern alternative to C++ and Rust ain't it

I'm with you so far...

> Carbon seems like Rust but without its borrow checker - exactly what we need.

... and now I'm not.

I came across the Carbon stuff several days ago, so I've got a bit of a head start on the article. I'd say that neither of those last two statements is really correct - but even if they were, by the time you've removed the borrow checker from Rust there isn't really much of value left: just a mediocre language with a "library downloader" built in.

The lifetime hints in Carbon are pretty clunky (and the shorthand forms somehow manage to bo both clunky AND under-informative), and I'd be very reluctant to take working C++ code and convert it to "something that only works with Compiler A". I'd be even less keen on the idea if I knew that Google was the sole sponsor of the project, though admittedly it does seem likely to outlast most of their other efforts, since they'll have a significant dependency on it themselves.

[arQon]

service backends ... His surprise was that instead of pulling-in the C++ devs from the high-performance end since Go was (snip)

Then he was delusional, blinkered, or hadn't actually considered things at all. It's not about *average* performance, it's about *worst case* performance. Go making it easier to write MT code (which it does do very well) with "only" 10% worse throughput is absolutely a fair tradeoff in a majority of cases - but Go stalling a system for at least several hundred ms every few seconds is very much not an acceptable tradeoff for a large number of systems, including all the ones that pay the most, and that kept "real" developers from adopting it.

Given that most of those systems had already rejected Java, this really shouldn't have been a surprise to anyone who was even just paying attention, let alone working in the field.
Like I say, in most cases it's not that it would have "mattered", it's just that between the herd mentality, the lack of an answer to the GC problems, and the ego issues with "stepping down to a language for babies", nobody was willing to adopt it.

[sinepgib]

Then he was delusional, blinkered, or hadn't actually considered things at all. It's not about *average* performance, it's about *worst case* performance. Go making it easier to write MT code (which it does do very well) with "only" 10% worse throughput is absolutely a fair tradeoff in a majority of cases - but Go stalling a system for at least several hundred ms every few seconds is very much not an acceptable tradeoff for a large number of systems, including all the ones that pay the most, and that kept "real" developers from adopting it.

Given that most of those systems had already rejected Java, this really shouldn't have been a surprise to anyone who was even just paying attention, let alone working in the field.
Like I say, in most cases it's not that it would have "mattered", it's just that between the herd mentality, the lack of an answer to the GC problems, and the ego issues with "stepping down to a language for babies", nobody was willing to adopt it.

I thought the Go devs made it a point to keep stop the worlds under 10ms. It's actually something the Java kids use to throw shade at it, that it sacrifices throughput for latency to levels that (to their limited judgement) don't matter anyway.

[tuxayo]

HERE WE GO AGAIN!

I think we need to start addressing the concept of cognitive pollution, that you can make too many ideas and technologies that, because of their abundance, actually stifle the industry rather than propel it. And Google pollutes in this sense like China pollute in the traditional one.

This focus on China polluting doesn't match reality. We must factor the imports and exports and then it's the occident that pollutes way more.
Sure China has a growing middle class that is starting to consume like "us" so it's not like it's nothing.
The issue is consumerism and capitalism no matter if it's made in China or in Occident, the atmosphere doesn't care.

[coder]

Go is not a C++ replacement

A few years after Go's introduction, I read an article about how one of Go's designers was marveling at its failure to grab the interest of the general C++ community. Replacing C++ was one of their explicit aims.

Furthermore, they expected to see it used as a systems programming language, which I can't understand due to its (then) lack of exceptions. IMO, the combination of exceptions and C++'s guarantees about destruction order are precisely what makes it such a powerful tool, in that context.

Anyway, at the time, I'd just been fiddling around with Javascript. As I started to look at Go, the symmetries between them were hard to miss.

From the sound of it, Carbon hits closer to the mark. The key question is whether it adds enough value over simply sticking with C++. If we're talking about legacy codebases, there's a nonzero cost involved in adding Carbon to the mix, so it needs to overcome that deficit.

[coder]

It is cute when kids invent their own languages by putting new syllables to every word they say.

It's cute when old people can't imagine anything new in the world. Instead of looking at what's new & different about a given thing, they focus on all the ways it's similar to what they've seen before.

The question is never as simple as "has this been done, before?". What you ought to be asking is whether it's sufficiently different & better than what's come before. However, that takes actual work. Cynicism is much easier on creaky old brains and safer for your ego than possibly admitting you don't know the answer.