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

351–360 of 521 posts

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

#351

Post by pjmlp »

MR4D wrote: post #343
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…

I wonder what would happen if Security became a compiler flag? For instance, just like the -O1 or -O3 flags work for optimization, something like a -S1 or -S3 would be really useful. To me, there are lots of times when I just need to get an idea into code. Then there are times when I need to make sure that code just works™. Having different compiler flags would really make that nice, and for devops, allow anything pu…

You already have them, true it is more than one and isn't bullet proof, still it is way better than not using them.

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

#353

Post by [deleted] »

chc wrote: post #340
detaro wrote: post #313

Earlier quoted context omitted.

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

[deleted]

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

#354

Post by zamalek »

Joker_vD wrote: post #107
zamalek wrote: post #70

Earlier quoted context omitted.

Like every braces language following C is a C rip-off? Rusty syntax is objectively superior to almost everything else we've come up with, there's no reason it shouldn't be copied.

> is objectively superior Those objective criteria of superiority being?..

long long

Templates

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

#356

Post by int0x80 »

xigoi wrote: post #283
StillBored wrote: post #261

Earlier quoted context omitted.

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 declarat…

> not sprinkling std:: everywhere helps with readability I agree, but most C++ programmers don't :/ > 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. C++ syntax is Turing-complete, so due to the halting problem, finding the declaration can take a long time, potentially unlimited in pathological cases.

>C++ syntax is Turing-complete, so due to the halting problem, finding the declaration can take a long time, potentially unlimited in pathological cases.

Absolutely not unlimited time. Once it's parsed and semantically analyzed you can find the declaration in no time. Exactly like the compiler does.

edit: to clarify, I was not taking into account unbounded recursion on template instantiation, which should be limited in any case by the compiler.

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

#357

Post by dxuh »

I just do NOT feel like using a language, that has explicitly stated, that you should not start a new project with it. Very few legacy projects will consider using Carbon, I would assume (If you have worked on one, you probably know that "legacy" is usually more than just the code) and then there are so few projects left that I see no chance of this really taking of. And in that case it will probably die soon as well, like many (most) other Google projects.

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

#358

Post by pkasting »

tialaramex wrote: post #294
nikeee wrote: post #238

Looking at this [0] news from about a month ago, the Chrome team showed that they are trying to bring Rust to the table. However, their wording was: > The Chrome security team is working to make a cross-platform memory safe language available to Chromium developers. This document describes how to use that language in Chromium. The language, at least for now, is Rust. Could this mean that the "at least for now" part m…

Sure, the Chrome security team have got a problem, Rust has a solution, if somebody comes along with a better solution why wouldn't you. But, right now Carbon doesn't have a better solution, it only has an ambition to build an incremental path toward being able to be a solution. Importantly it has an ambition but it has no proposal for how to get there. There are other safe languages, but AFAIK none of them launched…

I work on the Chrome team. Safety is not the only goal for the codebase. There's also things like readability, maintainability, performance, and correctness. Finally, there's the need to chart a course towards how you get there.

Rust provides many of these, but not much of an incremental path there. Carbon aims to provide many of these, but not as much safety as Rust (likely, even in the future). The upshot: there are tradeoffs, and we'll need to watch our options and make continual decisions as to the best courses of action. Such courses may differ by area of the project; it's possible we might choose to write some hardened services in Rust communicating via Mojo with mixed C++/Carbon code.

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

#359

Post by Jensson »

jb1991 wrote: post #315
Jensson wrote: post #314

Earlier quoted context omitted.

For java the virtual machine provides the GC for everything, but then you can only use JVM libraries and not libraries in other languages. The reason C and C++ libraries can easily be included in basically any other language is that they don't have a GC, so there are no such issues, just call the functions and things works fine.

> Major problem with GC languages is that it is horribly to link against libraries that ships with a GC. I'm curious which GC languages do this. The most popular ones that come to mind for me are anything on the JVM, JS, and Go, and I've never heard anyone point this out about them.

Every language with a GC has this problem. If you want a library to be used in both Java and Python you don't write it in either Java nor Python, you write it in C++ or another language without a GC and import that to Java and Python. Trying to import a Java library in Python or vice versa is horrible, since GC's are very hard to work with from outside the language ecosystem.

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

#360

Post by mauvia »

StillBored wrote: post #261
xigoi wrote: post #249

Earlier quoted context omitted.

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 declarat…

You can use using = instead of typedef

  using namespace std;
  using foo_bar_xref = vector>;

  foo_bar_xref foo( vector> x, unordered_map y);
Post reply on HN