Carbon Language: An experimental successor to C++ • Hacker News Board

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

#331

Post by coder543 » Tue, Jul 19, 2022, 9:46 PM UTC

joshuamorton wrote: post #330

coder543 wrote: post #326

Earlier quoted context omitted.

> other than by invoking possible UB I addressed this when I talked about a compiler fork. Google could maintain a patchset against the Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten. Or they could work with the Rust Core Team to address this issue in a way that is favorable to them over the next year or two. Either of these options a…

> Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten To be clear, this is "forever". I don't think anyone involved has an expectation to truly get rid of Google's existing C++ codebase ever. So the question is, do you really want Google to fork rustc to implement some google specific UB handling? Is that good or fair to the rust community…

> To be clear, this is "forever"

I guess I didn't finish my thought in that comment, because it isn't forever... it's only until either the C++ is gone, or the Rust language has developed an equally acceptable alternative (which could be upstreamed by Google, or come from somewhere else).

And realistically, the C++ would never have to go away entirely for this UB handling fork to become unnecessary, depending on the driving factors. Some code paths are more performance sensitive than others, and these tend to represent a small portion of the overall code. Once the performance sensitive code paths are rewritten, it matters less whether there is a small performance penalty for the remaining C++ code that is less sensitive to performance. But, at Google Scale, the cost of the developer-hours to maintain that fork would probably be less than the cost of the small increase in CPU hours that removing the fork would result in, so... yeah, maybe forever or until there is an upstream solution. Maintaining a patchset like this would still cost way less than maintaining an entire compiler and all the language tooling needed to support that language... does anyone really disagree? A new language is far more than just a compiler, let alone a patch for a compiler.

> Would that be a good idea for anyone?

IMHO, it definitely seems better than Carbon.

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

#332

Post by WalterBright » Tue, Jul 19, 2022, 9:48 PM UTC

kinjalkishor wrote: post #320

WalterBright wrote: post #296

Earlier quoted context omitted.

If you use the @nogc attribute, D is fully nogc.

Yes it is very useful addition. Hopefully stdlib will also be fully nogc soon. Of all available options I am most hopeful of dlang. While it doesn't still have taken off it still is improving a lot & has high chances of increased usage. (Python also took years).

It doesn't need to be fully nogc. Not using the parts that use the gc will cripple nothing. You'll know which ones use the gc because they won't compile with @nogc.

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

#333

Post by timsneath » Tue, Jul 19, 2022, 9:51 PM UTC

throwaway03423 wrote: post #290

Carbon Team, thanks for sharing, I will likely use this if I need to bridge with CXX libraries. Also thanks for adding sum types, and pattern matching, is there anyway you could get the dart team on board? They seem to be averse to them and it's a big reason why I don't use the Dart/Flutter ecosystem.

Au contraire! We're actively investigating them here on the Dart team. We're finalizing the spec here: https://github.com/dart-lang/language/blob/98335746fb7f2dedf...

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

#334

Post by spacechild1 » Tue, Jul 19, 2022, 9:52 PM UTC

bestouff wrote: post #41

pipeline_peak wrote: post #36

All these C++ "successors" that do nothing but change the syntax sugar and find ways to operate with C++ are really tiring to read about. I seem to be the only one on the planet that doesn't think the language needs to be replaced.

I'm as tired as you by these cosmetic successors. But for my part I think C++ has already been replaced, and to great benefits. I couldn't thank the people building Rust enough.

> I think C++ has already been replaced

In which world has Rust replaced C++?

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

#335

Post by zozbot234 » Tue, Jul 19, 2022, 9:54 PM UTC

coder543 wrote: post #331

joshuamorton wrote: post #330

Earlier quoted context omitted.

> Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten To be clear, this is "forever". I don't think anyone involved has an expectation to truly get rid of Google's existing C++ codebase ever. So the question is, do you really want Google to fork rustc to implement some google specific UB handling? Is that good or fair to the rust community…

> To be clear, this is "forever" I guess I didn't finish my thought in that comment, because it isn't forever... it's only until either the C++ is gone, or the Rust language has developed an equally acceptable alternative (which could be upstreamed by Google, or come from somewhere else). And realistically, the C++ would never have to go away entirely for this UB handling fork to become unnecessary, depending on the…

But the way the Rust compiler works today is quite acceptable already. This isn't a Rust-the-language problem other than in secondary ways that are hard to address by definition (such as "movable" data being the default and Pin references being special), it's a Rust-the-library-ecosystem (including, but not limited to, std and/or core) issue. It can only be addressed as such.

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

#336

Post by klodolph » Tue, Jul 19, 2022, 10:03 PM UTC

ansible wrote: post #35

From the end of the safety document: > Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. C++ developers must be comfortable migrating their codebases, and able to do so in a largely automated manner. In order to achieve automated migration, Carbon cannot require fundamental redesigns of migrated C++ code. While a migration tool could in theory mark all migrated code as un…

This is also how Meta got Hack.

It's not like PHP is unsafe to begin with like C++, but the language does have a ton of problems, and Meta's massive codebase could only be migrated to another language gradually. Hence, Hack. Better language, better tooling, more productive programmers.

Note that unlike Carbon/C++, Hack is backwards-compatible with PHP. So the migration is somewhat more gradual.

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

#337

Post by Narishma » Tue, Jul 19, 2022, 10:03 PM UTC

zeotroph wrote: post #106

sam0x17 wrote: post #73

why camel-case functions tho :(

Indeed, from Python to Rust and newer C++ codebases you usually see CamelCaseClasses (or structs) and then snake_case for functions methods etc, which improves readability. CamelCaseForEverything is such a waste, maybe they use it for implicit public/private as in Go? And maybe to please existing Go or Java users?

That's PascalCase. camelCase is like this.

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

#338

Post by togs » Tue, Jul 19, 2022, 10:05 PM UTC

I'm surprised C++ is still prominent. I thought Rust would have taken its place by now.

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

#339

Post by munificent » Tue, Jul 19, 2022, 10:05 PM UTC

throwaway03423 wrote: post #290

Carbon Team, thanks for sharing, I will likely use this if I need to bridge with CXX libraries. Also thanks for adding sum types, and pattern matching, is there anyway you could get the dart team on board? They seem to be averse to them and it's a big reason why I don't use the Dart/Flutter ecosystem.

> Also thanks for adding sum types, and pattern matching, is there anyway you could get the dart team on board?

I'm driving the design of pattern matching for Dart. The entire language team is on board with them and we have a design that's pretty far along. It's really hard to integrate pattern matching into a language that wasn't originally designed for it, so it's taken a while to settle on a syntax that makes sense, but I think we're getting close.

If you'd like to be involved, there is a category on the issue tracker for design discussions related to patterns and records:

https://github.com/dart-lang/language/issues?q=is%3Aissue+is...

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

#340

Post by chc » Tue, Jul 19, 2022, 10:06 PM UTC

detaro wrote: post #313

arinlen wrote: post #311

Earlier quoted context omitted.

> 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 ? You're talking about an entirely different thing. While OP was referring to the current state of D's ecosystem and the impact that missing key frameworks have on hindering adoption, you're arguing about the theoretical possibility of writing a framework with a language, which really does no…

No, you are misunderstanding their point. If the problem of using Qt from D is that you need the MOC, then the fact that you can work around the need for MOC and use Qt without it seems quite relevant?

The initial complaint was that it did not have "good support." I think it is fair to say that having to spend a significant amount of effort to work around a lack of support is not "good support."