Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Launches Carbon, an Experimental Replacement for C++

thenewstack.io

Post reply on HN
Print view View original

171–180 of 243 posts

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

#171

Post by pipeline_peak »

hiq wrote: post #52
pipeline_peak wrote: post #35

Earlier quoted context omitted.

You didn't appear to read my comment, I'm talking about compatibility with Rust and all these other look alike languages. Also your Vala comparison would imply this language compiles to C++.

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.

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

#172

Post by emehex »

BitwiseFool wrote: post #141
emehex wrote: post #121

Earlier quoted context omitted.

This is a horribly misguided take. According to the latest S/O Developer Survey [1], Swift is used by 4.91% of respondents, while Objective-C is only used by 2.39%. Additionally, Swift is loved, and wanted by 62.88% and 4.3% of respondents, respectively. Objective-C is no where close by comparison... [1] https://survey.stackoverflow.co/2022/#technology-most-popula...

Swift isn't bad, and I actually enjoyed using it. What I didn't enjoy was XCode, which is a shame because they're basically inseparable.

I love Swift. And Xcode 14 is great! What don't you like about it?

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

#173

Post by deusum »

kps wrote: post #169
Hasnep wrote: post #161

Earlier quoted context omitted.

The pun is that C is the chemical symbol for carbon.

But it's a C++ replacement, not a C replacement, so they should have named it Nitrogen. Edit: it appears that Nitrogen and Phosphorus are already used by Lisp dialects.

Or a 'D' element, I believe Dubnium is still available.

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

#174

Post by fooker »

pkolaczk wrote: post #25
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…

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

“Make things as simple as possible, but not simpler.”

Rust lacking some of these makes it a somewhat unfriendly language to write libraries in.

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

#175

Post by robmccoll »

fractalb wrote: post #155
BitwiseFool wrote: post #137

Earlier quoted context omitted.

Isn't the 'kitchen sink' approach what ended up causing Perl to fade from relevance? I am only casually aware of this, and I may be totally misremembering things, but Perl used to be seen as a swiss army chainsaw but people eventually came to realize that maintenance was a nightmare.

Perl faded away because there was an alternative (Python) and it was not a kitchen sink. For C++, there's no alternative at all. People have to bear with it.

I think Python's original take on kitchen sink was relatively small language with large "batteries included" standard library.

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

#176

Post by trasz »

jsnell wrote: post #133
rajman187 wrote: post #96

While I have not had time to check this out, more generally whenever I read “Google launches…” I wonder how long until it makes it into the ever-growing graveyard? [1] https://killedbygoogle.com/ [2] https://gcemetery.co/

This is an experimental project, being very clearly pitched as such, and with the documentation being really clear about how if you can use any other language you should. They're bending over backwards to make the expectations clear. It is being developed in the open, targets a goverance model of an open foundation not controlled by any company, and has a goal that no more than half the contributors to the language s…

>not controlled by any company, and has a goal that no more than half the contributors to the language should be from any one company

Not controlled by Google in that Google literally owns at most half of it?

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

#177

Post by beached_whale »

hbossy wrote: post #34
beached_whale wrote: post #13

Earlier quoted context omitted.

It is easier to parse. Less ambiguity with something like int32_t r(); what is that?

I would argue that convenience of users is more important than easy of parsing.

Ask a non programmer what each means or measure the time newer devs take to understand it. On its own maybe its easier but I suspect for people its the same or saying var is easier.

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

#178

Post by zozbot234 »

hnav wrote: post #87
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…

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.

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

#179

Post by jsnell »

trasz wrote: post #176
jsnell wrote: post #133

Earlier quoted context omitted.

This is an experimental project, being very clearly pitched as such, and with the documentation being really clear about how if you can use any other language you should. They're bending over backwards to make the expectations clear. It is being developed in the open, targets a goverance model of an open foundation not controlled by any company, and has a goal that no more than half the contributors to the language s…

>not controlled by any company, and has a goal that no more than half the contributors to the language should be from any one company Not controlled by Google in that Google literally owns at most half of it?

No, those are two separate things which is why I listed them separately. There is the question of the governance / ownership model is (independent foundation), and the question of having a broad base of contributors to the design / implementation.

What, exactly, would they need to do to satisfy you?

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

#180

Post by moomin »

htyden wrote: post #131
epicide wrote: post #45

Earlier quoted context omitted.

In general, I think it's easy to conflate simplicity with ease. Ease is always a matter of context and what one is familiar with. I agree that Rust is simpler than C++ and I think a lot of people mean that Rust isn't easier (up front). Given how new and different it can be, that makes sense.

Obligatory Rich Hickey plug: https://m.youtube.com/watch?v=SxdOUGdseq4

That’s a great talk, but you have to wonder what that era Hickey would have made of overloading arity on list operations the way modern Clojure does.
Post reply on HN