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

401–410 of 521 posts

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

#401

Post by dymk »

lilulo wrote: post #396

If you enumerate all top level goals of the language, they all are satisfied by just staying with C++: . Performance matching C++, an essential property for our developers. . Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest. . A gentle learning curve with reasonable familiarity for C++ developers. . Comparable expressivi…

Migrating C++ code can be a major pain in the ass "At Scale", and designing C++ templates code that works intuitively but isn't just simple type replacement is an even bigger pain in the ass. Hence, a language that doesn't include things like SFINAE.

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

#402

Post by nextaccountic »

kllrnohj wrote: post #180
usrusr wrote: post #111

Earlier quoted context omitted.

Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were about to give c++ a syntax reboot, why wouldn't you look at what successful other modern syntaxes are doing? "c++, but in a syntax for people accustomed to rust instead of in a syntax for people accustomed to C" sounds like a perfectly reasonable approach. Your…

> I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't" That is in fact explicitly stated on the Carbon introduction: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."

Also on their FAQ https://github.com/carbon-language/carbon-lang/blob/trunk/do...

> If you can use Rust, ignore Carbon

> If you want to use Rust, and it is technically and economically viable for your project, you should use Rust. In fact, if you can use Rust or any other established programming language, you should. Carbon is for organizations and projects that heavily depend on C++; for example, projects that have a lot of C++ code or use many third-party C++ libraries.

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

#403

Post by mhh__ »

dymk wrote: post #400
mhh__ wrote: post #323

Earlier quoted context omitted.

Most C++ codebases would be exactly the same with or without a GC. Probably 90% of collective programmer-intuition about memory allocation is either completely wrong or from thinking about a scaling to a point that most products don't get anywhere near.

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, inline asm, SIMD etc, with a GC because I knew I didn't need to allocate often.

On the subject of Java, I'm no fan of it but lots of projects would probably be fine - probably not quite as fast, but not horrifically so. On hackernews we only discuss extremely careful or expertly written code whereas in real life a lot people use C++ because it's what they got hammered into them at university 20 years ago as the fast language.

For example a lot of engineering and finance codebases are written in a very bad style of C++ code that would be improved by not having the programmers worry about memory too much - infrastructural code is more subtle, but most code serves a direct purpose like implementing some model. In these cases memory allocation is merely a means to an end rather than part of some grand strategy (i.e. it's not like writing a library)

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

#404

Post by qalmakka »

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 and C++ are infamous for being harder to parse than it's reasonable. C has lots instances of context dependent syntax where code changes meaning depending on what a name is.

You can parse Go without a symbol table, but not C, because stuff like

  item *a;
changes completely in meaning depending on the existence of a previous typedef for `item`.

C++ in order to not break compatibility with C has elevated this to insane extremes - there's so much ambiguous syntax in the language.

  x = b.get(r);
This expression can either be a function invocation, if `item` is a type and a template method named `get` exists, or else it's a series of comparisons.

  item f(r, f);
is also ambiguous: if r and f are types, that's a function, otherwise that's a variable declaration. There's no way to know that unless you have a symbol table, which makes separating syntactical and semantic analysis impossibile at best.

The whole C++ language is full of similar ambiguities, and attempts to fix warts that backfired spectacularly. That's also the reason why writing a C++ frontend is a decade long endeavor that takes lots of people and resources. A full time team of 3 people can probably write a C parser in a few weeks in comparison, and C is big mess too, albeit a smaller mess though.

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

#405

Post by fouronnes3 »

adev_ wrote: post #361
fouronnes3 wrote: post #134

Earlier quoted context omitted.

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 and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memt…

Yeah what I meant was build system tooling, sorry for the approximation.

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

#406

Post by ai_ »

zozbot234 wrote: post #366
mihaic wrote: post #364

Earlier quoted context omitted.

Just a lot of small things stand out: - function and variable types are harder to visually parse for me. The keyword to declare a variable and the type put the varible name in the middle for instance. - the "fn" keyword is terrible, just to save on characters. Honestly, any keyword should have vowels and is pronounceable. Python has "def", I would have been fine with "func" as well - type annotation for templatizatio…

It's pronounced "fun", they just didn't want to make it too explicit because coding isn't always fun.

I always thought it was pronounced "ef'in". Like when you have to censor yourself in front of coworkers because of this ef'in code.

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

#407

Post by flohofwoe »

germandiago wrote: post #302
boardwaalk wrote: post #251

Earlier quoted context omitted.

You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all. Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the…

The problem with the typical rants about C++ is that you guys are outdated. With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.

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.

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

#408

Post by flohofwoe »

adev_ wrote: post #361
fouronnes3 wrote: post #134

Earlier quoted context omitted.

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 and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memt…

Most of the tools you mention work below the language level, and thus work automatically for non-C/C++ languages too (or at least LLVM-based languages).

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

#409

Post by flohofwoe »

mbrodersen wrote: post #386
fouronnes3 wrote: post #134

Earlier quoted context omitted.

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.

Hahaha you have zero clue. C++ has the best tooling in the world. From static analysers to best in class debuggers to best in class performance profiling tools etc. No other language comes even close.

Most of the tools you mention are actually language agnostic (debuggers and profilers). And static analyzers are much more important for C and C++ than other languages.

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

#410

Post by wiseowise »

bialpio wrote: post #375
wiseowise wrote: post #288

Earlier quoted context omitted.

You’re comparing framework for one language to another language.

I don't think I understand - where is any kind of framework mentioned? And even if frameworks were mentioned, I think it's a fair comparison to say "language A has battle-proven / easy-to-use / etc. framework to achieve X, but language B doesn't".

Since when is GUI part of language?
Post reply on HN