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

Carbon Language: An experimental successor to C++

github.com

Post reply on HN
Print view View original

261–270 of 521 posts

Re: Carbon Language: An experimental successor to C++

#261

Post by StillBored »

xigoi wrote: post #249
StillBored wrote: post #230

I've seen this fn/var argument a few times, but its a really that much harder to write a parser that can intuit the difference between a function/variable/statement without explicitly putting function/var/let/etc all over the place? I like the verbosity of a language like pascal, but I just find it jarring in a C replacement these days. (and rust's structure definitions/etc I just find needlessly verbose for the way…

The C way makes it hard to find the name of the function (or even tell that it's a function declaration) when the return type is long. std::vector >> foo(std::vector > x, std::unordered_map y);

I said C++ was diff, but how about:

  using namespace std;
  typedef vector> foo_bar_xref;

  foo_bar_xref foo( vector> x, unordered_map y);
not sprinkling std:: everywhere helps with readability, but so does defining a couple types used frequently, especially if they are particularly verbose. And of course the parser doesn't really have a problem with this, so your editor should be able to find it with its 'goto declaration' function. I don't feel pity for people who chose to use editors/IDEs that make this difficult.

Re: Carbon Language: An experimental successor to C++

#262

Post by nemothekid »

pron wrote: post #226
Sebb767 wrote: post #72

Earlier quoted context omitted.

The syntax looks a lot like Rust, though. I'm surprised they made such a break when there explicit goal is to make migration from C++ as easy as possible. Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language, so I'm not too confident that Rust-but-with-OO is enough of a selling point.

> Rust (from my biased point of view) is currently on its way to become the standard low-level language The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming langu…

>programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10

How are you coming to this conclusion? I can think of more counter examples than actual examples (Almost every language on the top 10 aside from PHP where close to peak market penetration at age 10).

Re: Carbon Language: An experimental successor to C++

#263

Post by tempest_ »

fancyfredbot wrote: post #185
mihaigalos wrote: post #153

Earlier quoted context omitted.

As far as I'm concerned, C++ is there for legacy purposes only. There are some nice frameworks and tools using it, sure. Yes, you are required to learn it if you are studying CS. Any serious new development today is done using more modern languages such as Rust (i.e.: the linkerd service mesh proxy [1] for encrypted pod communication in a k8s cluster). As even the Linux kernel is slowly transitioning to using Rust [2…

My impression as a CS grad is that very few computer science courses require you to learn C++.

It really depends on what bit of computer science you are learning.

C++ is definitely past its prime and has been surpassed in many areas by other languages but there are still a bunch of domains where it is the primary language.

Re: Carbon Language: An experimental successor to C++

#264

Post by JonChesterfield »

AndruLuvisi wrote: post #102

Why do so many new and improved languages still lack tail calls?

It's moderately annoying to implement because it messes with the calling convention in architecture dependent ways. So it isn't an IR transform, it's N lowerings for N architectures.

Clang and llvm understand them, and you can require them from the front end, but the cost is some backends will hard error on them as unimplemented.

Re: Carbon Language: An experimental successor to C++

#266

Post by jcelerier »

LorenDB wrote: post #224
WalterBright wrote: post #198

Earlier quoted context omitted.

Which is what D can do. D can (and does) interact successfully with C++ classes and member functions. Even templates!

Honestly, the only thing lacking with D (for me) is the lack of good support from Qt (which I think is something Qt should tackle by making the moc multilingual). But I agree with Walter. D already did what Carbon is trying to do, but the syntax is easy enough to pick up in a weekend.

> Honestly, the only thing lacking with D (for me) is the lack of good support from Qt (which I think is something Qt should tackle by making the moc multilingual)

it's possible to do Qt without moc even in C++ with https://github.com/woboq/verdigris/, why wouldn't it be possible from D ? it should be even easier considering that D traits allow reflection of member and function names, etc.

Re: Carbon Language: An experimental successor to C++

#267

Post by aaaaaaaaaaab »

Sebb767 wrote: post #72
cogman10 wrote: post #21

If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including…

The syntax looks a lot like Rust, though. I'm surprised they made such a break when there explicit goal is to make migration from C++ as easy as possible. Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language, so I'm not too confident that Rust-but-with-OO is enough of a selling point.

>Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language

Lol. Gave me a good chuckle!

Re: Carbon Language: An experimental successor to C++

#268

Post by coder543 »

Jabbles wrote: post #194
saagarjha wrote: post #109

(Speaking only for myself, I just watch from the sidelines and have no involvement) This seems like Google’s response to 1. Rust not being sufficiently “Go-like” (in the sense of the “The key point here is our programmers are Googlers, they're not researchers” quote) where C++ lets a bunch of people who are not really experts in the language write footguns that Google has to deal with when they cause problems at scal…

(1) does not seem true, they have documented some seemingly detailed reasons why Rust is not always the right choice, and acknowledge that in many cases it is: https://github.com/carbon-language/carbon-lang/blob/trunk/do...

> Seamless interop where existing, unmodified C++ APIs are made callable from safe Rust requires the C++ code to follow borrow checking rules at the API boundary.

> Seamless interop where safe Rust APIs are made callable from C++ requires C++ users to follow Rust borrow checking rules.

Their complaints about borrow checking rules at the interop layer ring hollow to me. Whether the new code is being written in Rust, Carbon, or C++... the lifetime of shared memory must be well-understood by the developer writing the code. Rust just makes this problem explicit and enforceable. Sweeping the problem under the rug isn't a better option.

> However Rust imposes stricter rules than C++, disallowing some design choices that were valid in C++.

The word "valid" is doing a lot of heavy lifting here, and I'm generally skeptical of these "valid" architectures. If it is so easy to know that these architectures are valid, why do we still see so many memory safety issues in Google's C++ code? Incrementally restructuring C++ code to be more provably correct doesn't sound like a terrible thing... in fact, it sounds like exactly what they should be doing.

> However, we are not certain that [C++ can be migrated to Rust incrementally]

Firefox is a large, historically C++ codebase that has undergone incremental rewrite into Rust for years now. It seems quite certain that this is both possible and practical! Where is the uncertainty? Of course, Mozilla's budget pales in comparison to Google's.

Rust is an extremely extensible language, and it is absolutely possible for Google to build their own version of `rust-bindgen` that suits their particular C++ codebase's idioms. That would be a much simpler undertaking that achieves their goal of incrementally adopting memory safety.

I hate to disparage new languages, but this feels like Swift all over again... it's just NIH. At this point, the die has been cast, and I'm sure it would be career suicide in Google for anyone behind the Carbon project to admit at this stage that "actually, the project turned out to be unnecessary after a discussion on HN!", so I don't expect to change anyone's mind. I'm just wasting my breath making obvious counterarguments that I'm sure have already been considered and ignored.

To be extra clear, I would love to see a company like Google take on the challenge of building an ergonomic language that exceeds Rust in terms of safety, but Carbon is a half-measure that doesn't pretend otherwise. If all of Google's C++ code is magically rewritten in Carbon, they will still apparently have memory safety problems based on what Carbon's README says... and then it'll be time once again to consider "maybe we should have ported to Rust after all". It just feels like such a waste.

Re: Carbon Language: An experimental successor to C++

#269

Post by ridiculous_fish »

formerly_proven wrote: post #145
cogman10 wrote: post #21

If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including…

> In otherwords, what carbon can do that Rust can't do, is take a C++ class with a `foo` method and call that method. Or create a class with a `foo` method and call that method from C++. Probably one of the biggest hurdles to get over in C++ interopt. Most don't do that, instead you'd make a C function binding and struct and move data/invoke functions through that. https://cxx.rs

I tried cxx and walked away somewhat disappointed.

One problem is that it's hard to understand the code. The whole thing is one giant proc macro, which is by itself tricky to run and debug. Also it uses techniques like implementing Deref to simulate inheritance which makes it even more confusing.

The main problem is the difficulty in extending it. Support for std::string and std::vector are "baked in" in a way that does not generalize. I tried to add support for std::wstring and it is quite non-trivial.

Because it is a proc macro it's also tricky to integrate into a build system.

To me it seems like Cxx is "purpose built" which is fine. But after working with it, I longed for a Python script that just populates a template string or something.

Re: Carbon Language: An experimental successor to C++

#270

Post by StillBored »

boardwaalk wrote: post #251
StillBored wrote: post #223

Earlier quoted context omitted.

"C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinc…

You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all. Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the…

The problem is that cargo gets in the way (as does rustc) if you try and use it in anything other than the simple import this dependency mode. I spent a hell hole of a day or two, trying to pick up a dependency outside cargo because it didn't behave in a way that meshed with the rest of my build environment.

So, yes it handles a couple of the basic cases, but then your out of luck, stuck in a version hell/etc because rustc and cargo are so tightly integrated and the flags needed to emulate some of the behavior with just the compiler are poorly documented and/or version dependent.

It dictates, you conform (which is basically the rust way).

Post reply on HN