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
Carbon Language: An experimental successor to C++
131–140 of 521 posts
Re: Carbon Language: An experimental successor to C++
#132We already have this with an open foundation: Rust No thanks
Re: Carbon Language: An experimental successor to C++
#133I'll now go away for a few years until the dust settles.
Re: Carbon Language: An experimental successor to C++
#134Earlier 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
Re: Carbon Language: An experimental successor to C++
#135Why 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...
Re: Carbon Language: An experimental successor to C++
#136Earlier 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.
Re: Carbon Language: An experimental successor to C++
#137If 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.
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++
#138Why 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…
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++
#139Earlier 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 is Rust's entire syntax advantage, it isn't a very big one.