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

221–230 of 521 posts

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

#221

Post by otabdeveloper4 »

rvz wrote: post #49
bestouff wrote: post #41

Earlier quoted context omitted.

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 still haven't seen a cross-platform production level GUI app written in Rust. All the time, it is C++ these companies use for these apps, especially having millions of users and generating multi-millions or hundreds of millions of dollars.

Remove "cross-platform" and "GUI" and your post would still be correct.

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

#222

Post by xoac »

pjmlp wrote: post #171
mihaigalos wrote: post #165

Earlier quoted context omitted.

.. is it new development?

I guess, unless you're into retro-gaming.

I mean a lot of these things rely on copying old code. AFAIK a lot of new games in bigger studios start by essentially copying the old engine into a new tree.

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

#223

Post by StillBored »

fouronnes3 wrote: post #134
mempko wrote: post #130

Earlier quoted context omitted.

The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it

C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.

"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 convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing.

I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution.

Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code?

Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.

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

#224

Post by LorenDB »

WalterBright wrote: post #198
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…

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.

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

#225

Post by yakubin »

beeforpork wrote: post #50

Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++? This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give r…

Go authors put out a good post explaining the problem with C syntax and contrasting it with Pascal/Go/Rust syntax: https://go.dev/blog/declaration-syntax>

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

#226

Post by pron »

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.

> 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 languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10, and Rust is already 7. Any language could, of course, be an exception to historical trends, but there's nothing to suggest that is the case.

More anecdotal adoption stories are just as bleak. Even at this relatively advanced age, many companies dabble in Rust — as they did in, say, Haskell — but not many established companies have yet to really bet big on it.

The only positive is that among the low-level languages discussed on aspirational sites, Rust is, indeed, the most talked-about language, but history also suggests that that is a very bad predictor of long-term market success.

[1]: https://www.devjobsscanner.com/blog/top-8-most-demanded-lang...

[2]: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/

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

#227

Post by fluoridation »

yakubin wrote: post #215
fluoridation wrote: post #199

Earlier quoted context omitted.

1. That doesn't make it not-a-vector. It just means there isn't a one-to-one correspondence between std::vector and T^n. However, a particular instance x of std::vector is still a T^x.size(). 2. Operations are not intrinsic to a set, but to an algebra. Why would there need to be any correspondence between the operations of linear algebra and those of banking algebra in order to call an std::vector a vector?

2. I'm not sure I understand you here. A vector is defined by those operations. A set without those operations, even if it has the same elements, is not a set of vectors anymore. I don't understand your remark about sets here. The correspondence is necessary, because those operations on vectors are induced from the operations of the relevant field of scalars. The operation of adding vectors of bank numbers would be i…

A vector is defined as I did above. It's a homogeneous tuple, i.e. the Cartesian product of n sets, where all sets are the same. Vector addition plus scalar multiplication are not part of the set. Usually they're part of the definition of a vector space. E.g. (R^2, +, ⋅). But you can construct a vector space out of a set of non-vectors (such as matrices), or out of operations other than vector addition and scalar multiplication, and you can use vectors for purposes other than constructing vector spaces, also without involving either of those operations. For example, to store sequential information.

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

#228

Post by twen_ty »

No. No. No.

This reminds me of Dart - another big company thinking they can invent a new language to tackle old language problems.

This is not the way to improve C++ - because this path already exists, either as D or if compatibility or OO model isn't an issue, Rust.

C++ has been improving slowly but surely - just remember that 90% (heck even more) of C++ issues stem from the hell that's compatibility with C and that's both a blessing and a curse.

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

#229

Post by spacechild1 »

fsloth wrote: post #150
mempko wrote: post #130

Earlier quoted context omitted.

The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it

Regarding C++. IMHO - it’s not getting intrinsically better. More complex. Easy things become a bit less verbose, but the hardest things remain as hard and the compiler is as unhelpful as before. I agree C++11 and it’s successors are sugaring the language to be a lot nicer but fundamentally nothing has changed. Rust is fundamentally better in it’s compiler warnings (they are actually helpful), and contains specific s…

> but fundamentally nothing has changed.

IMO, move semantics and lambda functions have fundamentally changed the way we write C++.

Also, let's not forget that C++11 introduced a formal memory model with cross-platform atomic operations and multi-threading primitives.

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

#230

Post by StillBored »

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 I use C structures).

C is nice because its fairly easy to mentally parse (C++ less so) vs some of the alternatives, while still being extremely concise.

Post reply on HN