New competitor to D

[H. S. Teoh]

On Tue, Jul 19, 2022 at 04:27:25PM +0000, Tejas via Digitalmars-d wrote:
> There is a new language that claims to be the successor to C++ in
> town, and it's got Google's funding 😥
> 
> It's called carbon
> 
> https://github.com/carbon-language/carbon-lang
> 
> 
> What do you folk think?
[...]

Seems it has quite a few of D's good ideas:
- Integer types have specific widths.
- UTF8 by default.
- Slices.
- Type inference, auto return types, et al.
- Single inheritance.  Good that they recognize the problems with
  multiple inheritance.
- Module system.
- Signature constraints.

In some areas it even excels over D:
- Treating bool as its own distinct type rather than a 1-bit integer.
- Treating types as 1st class citizen compile-time values and using
  expressions to form them.
- Built-in tuples with built-in syntax and destructuring.
- Compile-time generic code type-checking. Eliminates the problems
  caused by templates not being type-checked until instantiation.

Other interesting features:
- No null pointers. Trying to fix the billion-dollar mistake, I suppose;
  but it remains to be seen how this will actually pan out.
- Explicit assignment to return value instead of relying on NRVO. Seems
  like a nice thing, but hard to tell at a glance how it plays out.
- No constructors, only factory functions. May not necessarily be a bad
  thing, seems like an exploratory feature. Interesting to see how it
  pans out.
- Explicit move operators.
- Built-in tagged unions (choice types) that unify C/D unions with
  enums. Interesting design.
- `observe` declarations to provide case-specific knowledge to compiler
  where a generic type inference would be undecidable.
- Fluid ABI except at explicit ABI boundaries.  Interesting idea that
  could allow more optimizations.

A few bad ideas, however, it continues to promulgate from C++:
- Forward declarations.  Ick.  Triple ick.
- Class friends. Ugh.
- Separate API file from implementation files: reminiscient of the bad
  ole .h / .cc split, ugh. Can't say it's necessarily bad, but I've a
  bad feeling about this. Would lead to boilerplate. I hate boilerplate.
- Namespaces. Ugh.

Also, the generics system uses type erasure, which could be problematic
in some use cases. But it's hard to judge this without more details
about how it would be implemented.

Currently, metaprogramming is still unspecified, there's only some
initial sketch.  Just based on this alone, Carbon wouldn't be on my
radar; I can't live without metaprogramming. :-D

Also wannabe- at safe, and currently undecided error-handling system,
though leaning towards choice types.


T

-- 
By understanding a machine-oriented language, the programmer will tend
to use a much more efficient method; it is much closer to reality. -- D.
Knuth