Google Launches Carbon, an Experimental Replacement for C++ • Hacker News Board

Re: Google Launches Carbon, an Experimental Replacement for C++

#201

Post by hiq » Mon, Jul 25, 2022, 9:01 PM UTC

pipeline_peak wrote: post #171

hiq wrote: post #52

Earlier quoted context omitted.

If they manage to make Carbon highly compatible with C++ (which is one of the design goals IIUC), then a C++/Rust compatibility layer should work fine with Carbon/Rust, or am I missing something? That's a big "if" of course, and time will tell whether they manage to pull it off, but at least that seems to be where they want to go.

Rust is already in production, I don’t think they take a different approach to compatibility.

The same approach to compatibility with C++? Can you use Rust as successor language in a C++ codebase, just like Typescript in a Javascript codebase? From my (limited) understanding that's not as straightforward, and other sources online seem to agree with this (e.g. see comments in https://old.reddit.com/r/rust/comments/w2tygg/carbon_languag...).

The way I see it, Carbon has C++ compatibility as a requirement, adding as much safety, performance etc. as possible on top, while Rust seems to start from a safe-by-default approach and building its way from there.

Re: Google Launches Carbon, an Experimental Replacement for C++

#202

Post by shagie » Mon, Jul 25, 2022, 9:02 PM UTC

Optimal_Persona wrote: post #182

scotty79 wrote: post #142

Earlier quoted context omitted.

Don't forget they named language go, while language named Go! already existed. They just don't care. https://en.m.wikipedia.org/wiki/Go!_(programming_language)

At least they didn't name it after a very popular existing language and then tack "script" on the end...

In defense of the name... it's how an applet could interact with the page surrounding it (and vice versa)

https://docs.oracle.com/javase/tutorial/deployment/applet/in...

Re: Google Launches Carbon, an Experimental Replacement for C++

#203

Post by shagie » Mon, Jul 25, 2022, 9:11 PM UTC

pipeline_peak wrote: post #196

shagie wrote: post #42

Earlier quoted context omitted.

The "slow" isn't the performance of the application, but rather the ability to make changes to the language. As it is, Google can't make changes to C++ that it wants in a timely manner (if at all). Having a C++g edition where there are slight changes to the language for the Google flavor rather than the latest standard makes things even worse. From Google's perspective, the same can be said of Rust. What Google does…

I meant slow as in the time it takes for the committees approval. What exactly does this language solve in Google’s problem domain that can’t be enforced through guidelines?

Rather than enforcing the style guide ( https://google.github.io/styleguide/cppguide.html ) through code reviews and code review tools, the language itself encourages the developer to write better code than they would have if writing C++.

The Google C++ style guide is longer than the Carbon language design (though I will note a large number of sections that are "TODO").

(working from guesswork here)

Given the codebase that Google currently has in C++, the amount of effort to continue enforcing those style guides through human "this needs to change before I can approve it" to (in Google's eyes) more reasonable code with Carbon ultimately results in less developer time being spent reviewing style guide issues. At that scale, this may become a significant savings even when taking into account creating a new language.

Re: Google Launches Carbon, an Experimental Replacement for C++

#204

Post by ufmace » Mon, Jul 25, 2022, 9:17 PM UTC

DiabloD3 wrote: post #61

I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a better Rust? The linked article generally defines a language that is more of the same, while Google is throwing Go under the bus to make it happen. The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I kno…

I don't really get it either. The article says they want to focus on being a more direct replacement for C++ with easier conversions. I don't see that though - take maybe the most important issue, memory safety. As far as I can tell, they either 1. Take the C++ approach of mostly-manual with lots of inevitable mistakes that result, easy conversion, or 2. Rust approach of strict ownership and borrower checker model, which will almost certainly require substantial reworking, just like if they had used actual Rust, or 3. Golang approach, give up and go GC, in which case they won't touch the performance, low level features, and memory footprint of C++.

So which way is this gonna go? Or do they have some other way to do memory management that nobody's thought of yet? If they had that, it'd be much more impressive than anything else they've said so far.

Re: Google Launches Carbon, an Experimental Replacement for C++

#205

Post by learn-forever » Mon, Jul 25, 2022, 9:23 PM UTC

al_mandi wrote: post #185

pkolaczk wrote: post #25

Earlier quoted context omitted.

> Rust isn't any more complex, but it's not radically simpler either. Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.

Why are classes automatically somehow assumed as complex? Rust's structs are basically classes without class inheritance.

Dealing with inheritance is pretty complex!

Re: Google Launches Carbon, an Experimental Replacement for C++

#206

Post by joshuamorton » Mon, Jul 25, 2022, 9:25 PM UTC

zozbot234 wrote: post #178

hnav wrote: post #87

Earlier quoted context omitted.

Golang and C++ don't serve the same purpose. Google internally sometimes uses both to the same effect but that's because Google internally has a bunch of stuff (including new kernel syscalls) that makes highly concurrent server development in C++ palatable. So why "compete" with Rust? Because C++ compatibility was never a design goal of Rust, so gradual, painless migration from C++ to Rust is a non-starter. The best…

Google is contributing to "gradual migration from C++ to Rust" via autocxx and crubit. This Carbon thing looks more like a side project, and is still quite incomplete in many ways.

Crubit and autocxx have, afaict, less investment than Carbon, and all three are collaborative. There's not certainty that crubit or autocxx will succeed. If they do, awesome. If they can't, Carbon exists. All three are experimental all three are incomplete in many ways. None are side projects.

Re: Google Launches Carbon, an Experimental Replacement for C++

#207

Post by pipeline_peak » Mon, Jul 25, 2022, 9:45 PM UTC

shagie wrote: post #203

pipeline_peak wrote: post #196

Earlier quoted context omitted.

I meant slow as in the time it takes for the committees approval. What exactly does this language solve in Google’s problem domain that can’t be enforced through guidelines?

Rather than enforcing the style guide ( https://google.github.io/styleguide/cppguide.html ) through code reviews and code review tools, the language itself encourages the developer to write better code than they would have if writing C++. The Google C++ style guide is longer than the Carbon language design (though I will note a large number of sections that are "TODO"). (working from guesswork here) Given the codebas…

It’s likely smaller than the style guide because it was just introduced. Either way that’s such a loose comparison.

I’m aware a language that enforces better coding styles is more efficient, I’m asking how and why does Carbon do this.

Re: Google Launches Carbon, an Experimental Replacement for C++

#208

Post by hnav » Mon, Jul 25, 2022, 10:14 PM UTC

collegeburner wrote: post #192

hnav wrote: post #87

Earlier quoted context omitted.

Golang and C++ don't serve the same purpose. Google internally sometimes uses both to the same effect but that's because Google internally has a bunch of stuff (including new kernel syscalls) that makes highly concurrent server development in C++ palatable. So why "compete" with Rust? Because C++ compatibility was never a design goal of Rust, so gradual, painless migration from C++ to Rust is a non-starter. The best…

interesting, what kind of new syscalls are these? any plan to upstream?

Kind of a form of cooperative multitasking: https://news.ycombinator.com/item?id=24688225

Re: Google Launches Carbon, an Experimental Replacement for C++

#209

Post by zahllos » Mon, Jul 25, 2022, 10:47 PM UTC

al_mandi wrote: post #185

pkolaczk wrote: post #25

Earlier quoted context omitted.

> Rust isn't any more complex, but it's not radically simpler either. Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.

Why are classes automatically somehow assumed as complex? Rust's structs are basically classes without class inheritance.

The idea of classes on their own isn't complicated. The problem is that C++ provides an extreme amount of flexibility in how you use them.

You can have multiple inheritance. You can have as many levels of partially implemented, partially abstract classes as you like provided you eventually have a concrete class, and these abstract classes can have member data. You can have static methods, which I've seen abused as namespaces so often. You can have static methods and non static ones in a class hierarchy. Finally you can mix templates into this.

In an ideal world the developers of a project in a company would collaborate to keep this from getting out of control and enforce a relatively consistent philosophy. However in practice people have their quirks and specific not always rational views, and programmers are in general not always the best at dealing with other people, programmers included.

So a strong personality is determined to do it one way and refactors a bunch of code to their liking, and on and on, and now a variety of features have been used in different ways.

No language is immune to this as it is fundamentally a human problem, but taking out features generally helps. Since we can get by without inheritance most of the newer languages have done away with it.

Re: Google Launches Carbon, an Experimental Replacement for C++

#210

Post by flakiness » Tue, Jul 26, 2022, 12:07 AM UTC

jandrewrogers wrote: post #154

robmccoll wrote: post #19

I'm probably just biased, but to me the problem with modern C++ is its complexity. The mental model of the language, its syntax, and the amount of history / number of interfaces a programmer needs to be familiar with to be productive are all too large. Rust isn't any more complex, but it's not radically simpler either. Carbon doesn't look like it solves this problem. It would seem that creating a language that is exp…

It is difficult to tell sometimes due to its religious backward compatibility, but C++ has been becoming significantly less complex over time. I have a large C++ code base (originally hundreds of thousands LoC) that I aggressively modernize, essentially rewriting it idiomatically in new versions of C++. It was originally written in C++0x/C++11, rewritten in C++17, and is currently being rewritten in C++20. You can ba…

I'm not sure your code is simplified either because of the modern features of C++ or because of the rewrite.

That said, I like the idea of rewriting old C++ code with modern C++. That'd be also a good way to learn modern C++ in a practical way and having legacy code serves well for this context ;-)