Live data from Hacker News

Carbon Language: An experimental successor to C++

github.com

131–140 of 521 posts

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

#131
post #120

Earlier quoted context omitted.

AIUI, you don't need to use D with a garbage collector. It can be disabled.

The D standard library is heavily tied to the GC. If you want to avoid the GC, you'd have to give up the standard library, and if you do that, you have to give up most of the D ecosystem. As far as I can tell, there hasn't been progress in untying the stdlib from the GC - https://github.com/dlang/projects/issues/56

[deleted]

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

#133
Am I the only one that doesn't like this direction for the syntax? This was the main reason why I never got into Rust, it was just too different without any obvious reason. It's strange that I actually enjoy working with type annotated modern Python though.

I'll now go away for a few years until the dust settles.

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

#134
post #130
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…

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.

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

#135
post #92

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…

A blog post by Roman Elizarov (Kotlin designer) on the observation of types following the variable name [1]. It mostly states that having consistent length prefixes (fn, val/var) makes the code more readable than arbitrarily long type identifiers (in the eye of the beholder). Not scientific, but interesting. [1] https://elizarov.medium.com/types-are-moving-to-the-right-22...

Fixed prefixes also make a codebase significantly more grep-able. Want to find the definition of the function named `foobar`? Search `fn foobar` and that will always match, no regex required.

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

#136

Earlier quoted context omitted.

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

It eliminates the Most Vexing Parse. Consider this C++ code: Foo bar(); A programmer could make simple mistake thinking that is declaring a variable of type Foo. Carbon eliminates this by having explicit keywords for variable and function declaration. (This style is much more Rust based than C++) fn bar() -> Foo; var bar : Foo; It makes parsing easier for both the users and maintainers of the language.

If that's the only criterion then Pascal's syntax, which doesn't have "the most vexing parse" problem either, and for the same reason, is also almost better than anything else.

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

#137
post #75

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.

The major usecase for Carbon is to advance Google's internal, multi-billion line, C++ codebase.

As nice as a greenfield language with a clean ffi would be, "extremely close ties to C++" is Carbon's primary benefit.

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

#138

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…

It's not just Rust syntax. `name: Type` is the syntax used in TypeScript and Python type annotations (also Ocaml, which is probably where Rust got it from). Golang drops the colon, but still keeps the name first. As for what's wrong with `Type name(constructor, args)`? A lot of tooling wants to be able to parse "mostly-valid C++", like IDEs and compiler diagnostics. Sure, once clang's type inference is finished, the…

The syntax `name: Type` is also friendlier to type inference as you generally have a token indicating a declaration. If you have `var x: Type = …` then you can just omit the type and let inference do its job.

Even better, when you start having more complex patterns on the left-hand side of `=`, you can type annotate them as you want. Hypothetical syntax would be:

    var (x: f32, y, [z1,z2,z3]) = SomeExpression(); 
That's harder to do when you have a type declaration on the left imho.

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

#139

Earlier quoted context omitted.

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

It eliminates the Most Vexing Parse. Consider this C++ code: Foo bar(); A programmer could make simple mistake thinking that is declaring a variable of type Foo. Carbon eliminates this by having explicit keywords for variable and function declaration. (This style is much more Rust based than C++) fn bar() -> Foo; var bar : Foo; It makes parsing easier for both the users and maintainers of the language.

There are literally thousands of shipping languages that don't have the most vexing parse problem.

If that is Rust's entire syntax advantage, it isn't a very big one.

Post reply on HN