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

441–450 of 521 posts

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

#441

Post by woodruffw »

Asm2D wrote: post #419
flohofwoe wrote: post #407

Earlier quoted context omitted.

The problem isn't that Conan exists, but that other competing solutions are just as popular which results in fragmentation (for instance vcpkg, and cmake can also directly pull in external dependencies now). In the Rust world there's just Cargo.

Competing solutions are great for innovation.

In the world of build systems, I think most people want a little more consistency and a little less innovation. Sometimes a tool should just do its job and broadly resemble other tools in the space.

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

#442

Post by gulbanana »

zozbot234 wrote: post #420
lenkite wrote: post #411

Earlier quoted context omitted.

> Carbon is not trying to be 100% interoperable with C++ It's trying for some fuzzy notion of "good enough" No, it's clearly not a "fuzzy" notion of interop even in the most uncharitable interpretation. Your assertion is mis-information. "Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest." Support mixing Carbon and C++ to…

And that's still not 100%. The Carbon devs are very clear that there will be some C++ code that Carbon is unable to interoperate with.

Like the standard library - they don't plan to support exceptions.

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

#443

Post by ModernMech »

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…

C++++ is C# (notice how the four pluses can be arranged to form a #)

C#++ would be the next one, but I'd pull what Microsoft did to Windows 9 and skip right to C##.

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

#445

Post by tialaramex »

coder543 wrote: post #268
Jabbles wrote: post #194

Earlier quoted context omitted.

(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, C…

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

I doubt that Chandler would lose his job if this project is abandoned. In fact, I'd say chances it is abandoned (at least, mothballed, never to be revived) are significant so if Chandler's job does hang on this work that was a bad idea. It's an experiment, I personally think it's looking in the wrong place, but of course the point of experiments is that you don't know what the results will be. I doubt that Chandler has labelled this an experiment without knowing that.

So, my expectation is that probably Carbon won't even complete design, but if Chandler leaves Google that won't be why.

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

#446

Post by moltonel3x »

slingnow wrote: post #301
mtlmtlmtlmtl wrote: post #278

Earlier quoted context omitted.

GP said the standard low-level language. Low-level code will always be a much smaller percentage of all code than the heaps of web apps our industry is shitting out on a daily basis. Thus it would be completely reasonable for the de facto sysdev language to have a small market share overall(unless like for C/C++ there is a lot of legacy stuff to maintain) . Your sources don't shine any light on this at all.

You don't think comparing the current defacto standard low-level languages (C/C++) to Rust shines any light on the issue you raised? [1] C/C++ : 6.17% Rust : 0.29% This was addressed in one of the linked sources. What would you accept as evidence, then? 1: https://www.devjobsscanner.com/blog/top-8-most-demanded-lang...

Different metrics tell a different story. For example GitHub pull requests [1] are C++: 2.60%, Rust: 2.09%, C: 1.43%, with a clear trend showing Rust ahead of C++ next year. Or you could look at the Stackoverflow survey of languages used among professionals [2], which gives C++: 20.17%, C: 16.7%, Rust: 8.8%, with rust gaining 1-2% each year.

There's no best metric, they're all biased, you need to consider a few different ones. Otherwise you won't notice when you've stumbled upon one with with an extreme view.

Combining C and C++ in language stats is debatable, they should IMHO be measured separately. When grouped as a language category, "C/C++/Rust" is slowly becoming more common.

1: https://tjpalmer.github.io/languish/#y=pulls&names=c%2B%2B%2...

2: https://survey.stackoverflow.co/2022/#most-popular-technolog...

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

#447

Post by Tyr42 »

ModernMech wrote: post #443
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…

C++++ is C# (notice how the four pluses can be arranged to form a #) C#++ would be the next one, but I'd pull what Microsoft did to Windows 9 and skip right to C##.

Knowing my music theory though, C## is just D.

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

#448

Post by N1H1L »

cogman10 wrote: post #237
pron wrote: post #226

Earlier quoted context omitted.

> 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 Notable exceptions from the links you've provided: C#, Java, Go, PHP. All appear to have an upward trajectory today. Javascript has also seen a similar penetration boost when nodejs came on the scene. With rust looking to get integration both into the Linux kernel and GCC,…

Yep. In fact Python really started taking off almost 20 years after its' release. People forget that Python turned 31 a few months back.

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

#450

Post by dataangel »

mhh__ wrote: post #403
dymk wrote: post #400

Earlier quoted context omitted.

Probably not, or they'd just be written in Java.

There is more to performance than allocating memory. In fact some very performance-centric codebases do use a GC like unreal engine. On the subject of games it always makes me chuckle when I see people complaining about garbage collection but then having 20 calls to malloc in their hot loop. All memory allocation is slow and not necessarily bounded. I have written code that uses SoA, cache aware metaprogramming, inli…

Unreal Engine mostly uses GC for game world objects. Only C++ classes that inherit from a special base class and opt-in are subject to GC. If they used GC for everything the performance would be much worse.
Post reply on HN