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

481–490 of 521 posts

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

#481

Post by jstimpfle »

ncmncm wrote: post #470
tempest_ wrote: post #263

Earlier quoted context omitted.

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.

In fact there is plenty that can be expressed only in C++. A person making effective use of the power of the language finds anything else a huge step down. Anyone not having fun when coding C++ is doing it wrong.

Example of some well-written code that expresses things that can only be expressed in C++?

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

#482

Post by pjmlp »

kllrnohj wrote: post #479
pjmlp wrote: post #468

Earlier quoted context omitted.

They haven't gotten along with that just fine, that GCC case is exactly what gets brought up when discussing ABI breaks, because it caused a Python 2/3 like experience around the GCC and GNU/Linux communities.

And yet everyone is successfully on C++11 & newer, and that transition still happened in a fraction of the time of the Python 2/3 transition. Nobody even mentions that when discussing modern C++, it's that much of an "everyone got over it" thing.

Apparently you aren't much into the C++ world, I advise hearing the C++ podcasts at very least.

Plenty of people discuss the matter.

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

#483

Post by germandiago »

fancyfredbot wrote: post #475
germandiago wrote: post #305

Earlier quoted context omitted.

My impression is that C++ is used in the real world though. :)

Yes that is true but I'm responding to the up stream comment saying "you are required to learn it if you are studying CS". There is a common perception that computer science degrees are about learning things like C++ but my experience is that most emphasise more abstract skills like data structures, algorithms, complexity, formal program design, etc.

Not at all. Computer science and engineering (I think this is different degrees in US but in Spain it was a BS + Master when I studied) is about algorithms, data structures, big O notation complexity in algorihtms, client/server architecture, hardware and assembly, understanding all the underlying math, networking, even HPC and advanced data structures when you keep choosing specialized subjects, but not learning a single tool for the sake of it for programming.

In fact, it is the least relevant part when you are studying. You learn tools better after you end the degree IMHO.

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

#484

Post by mustache_kimono »

bialpio wrote: post #156
mustache_kimono wrote: post #78

Earlier quoted context omitted.

"I still haven't seen a production level numerical weather prediction app written in Rust. All the time, it is Fortran the government uses for these apps,..." I vacillate as to whether the best response is: "Who cares?" or "give it time"? First, if C++ actually is better for GUI apps, then more power to C++ (do you have some evidence this is the case?). That doesn't mean their aren't other niches to fill for other la…

GP mentioned C++ being replaced by Rust - I'd say that a replacement should be as capable as the thing it replaces, so if that's the claim, then Rust should be at the very least OK for GUI apps. If it's not, then that's also okay, but let's not call it a replacement then. :-) I'm personally excited to see how all those languages will influence each other!

> GP mentioned C++ being replaced by Rust

Then your beef is with the GP?

I'm also pretty certain we shouldn't be that pedantic about the word "replacement". Perhaps it's fine for a thing to be a "replacement for the GP" (which I think he/she is pretty clear about) or a "replacement for many uses" or for "all new uses", without being a "complete replacement"?

What's getting so weird about about the tenor of the current anti-Rust backlash is that 1) when the discussion turns to safety, it's "Hey, dude, don't harsh my buzz", but 2) when the discussion turns on the what the person meant, the Rust community's well-founded enthusiasm is interpreted in the harshest, most uncharitable, light.

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

#485

Post by wtetzner »

mrits wrote: post #75
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…

Designing a language to interop well with a single language is short sighted in my opinion. I want a clean ffi that I know will be able to iterop with Swift, Typescript, C#, C++, C, python etc... In my current project I'm currently using Rust/protobuff to do all of this and it rarely gets in my way of how I want to do things.

C++ itself was a language designed to interop well with a single language.

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

#486

Post by wtetzner »

xigoi wrote: post #254
jimbob45 wrote: post #220

Earlier quoted context omitted.

I can't handle [] syntax for generics. It makes code unreadable as far as I'm concerned because it makes it twice as difficult to know if I'm dealing with an array indexer or a generic. The rest I can excuse but [], I cannot. Same reason I won't touch Nim.

I can't handle syntax for generics. It's impossible to auto-pair and looks ugly. The real solution is [] for generics and something else for indexing.

Using function call syntax for array indexing always made sense to me. Functions are mappings from inputs to outputs, and arrays are mappings from indexes to values.

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

#487

Post by wtetzner »

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…

> (and rust's structure definitions/etc I just find needlessly verbose for the way I use C structures)

Do you have an example? What's verbose about Rust struct syntax?

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

#488

Post by synergy20 »

please at least do what rust|go can: generate multiple platform code easily, i.e. make the build tool cross platform friendly.

one reason I use golang over c++ is the network, for c++ network socket Unix and Windows are totally different(winsock vs bsd socket), while golang works well at both OSes.

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

#489

Post by xigoi »

wtetzner wrote: post #486
xigoi wrote: post #254

Earlier quoted context omitted.

I can't handle syntax for generics. It's impossible to auto-pair and looks ugly. The real solution is [] for generics and something else for indexing.

Using function call syntax for array indexing always made sense to me. Functions are mappings from inputs to outputs, and arrays are mappings from indexes to values.

I agree, but explain that to programmers who think parametric polymorphism is too complex.

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

#490

Post by dw-im-here »

billsnow wrote: post #378

Seems neat, but it looks like the major thing is the syntax. Of course c++ syntax is insane and should be updated, but i cant shake the feeling that c++ developers secretly love it. Scanning c++ code for a seasoned c++ developer is like the bushmen of the kalahari scanning the african savanna.

Because we're scanning for predators?
Post reply on HN