July 19, 2022
On Tuesday, 19 July 2022 at 17:40:45 UTC, H. S. Teoh wrote:
> 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:
> [snip]

Thanks for the summary. It feels like a big language, at least from what I've read so far.

The generics system looks like two things: interfaces with type erasure plus a templates system comparable to C++'s. Interfaces come across as an alternative to Concepts and wouldn't be consistent with how Andrei has pushed Design by Introspection. Regardless I can think of where that would be useful. Particularly on the type erasure side of things. Some consistent way to handle that type of behavior would have been nice. inout feels bolted on.
July 19, 2022
On 19.07.22 19:40, H. S. Teoh wrote:
> 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

Well, it seems they are on track: https://github.com/carbon-language/carbon-lang/blob/99c568e66300dd90526f706634dfdf640e051c29/docs/design/metaprogramming.md

No string mixins so far, though. ;)
July 19, 2022

On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas 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?

If this succeeds, then Google will have the advantage in cross platform code (with Dart) as well as high performance code(Carbon)

It looks more like a Rust replacement to me. Nothing is written about the memory management but they hint that they want to use some kind of life time annotation like Rust. That is enough for me wanting to avoid it.

Since there are no plans for full meta programming, then it is no D or C++ replacement. Rust replacement maybe.

It's another me too Rust language. Good, then D can let other language imitate Rust instead.

July 19, 2022

On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

>

What do you folk think?

From the code examples, It looks like a mixture of golang and typescript to me - which is what I like to see.

July 19, 2022

On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas 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?

If this succeeds, then Google will have the advantage in cross platform code (with Dart) as well as high performance code(Carbon)

Carbon is nicely discussed on hackernews https://news.ycombinator.com/item?id=32151609

In summary it seems to be a language customized to Google needs, Google uses C++ extensively and have their own C++ style guide

Rust was too safe for them, so a migration to Rust seem to have been too much work

This is doesn't seem like competitor to D or even Rust, this is a custom language for Google

I don't think D should even try to compete or compare with it, you can't compete with a custom language and you should not

July 20, 2022

On Tuesday, 19 July 2022 at 22:46:47 UTC, Ali wrote:

>

This is doesn't seem like competitor to D or even Rust, this is a custom language for Google

They currently label it as being an experiment. I am not sure it will take over C++ for cultural reason, but if they go through with it then they will displace other system level languages without a doubt.

>

I don't think D should even try to compete or compare with it, you can't compete with a custom language and you should not

Their goal is that no organization should have more than 50% influence.

D would be better off taking actors seriously, start giving ‘shared’ meaning and find a real alternative to the current GC.

A language like Carbon would be disruptive in this space as it would be the first alternative for people who find C++ to be complicated.

July 20, 2022

On Wednesday, 20 July 2022 at 04:02:46 UTC, Ola Fosheim Grøstad wrote:

>

D would be better off taking actors seriously, start giving ‘shared’ meaning

There's a preview flag for that! Maybe its time to start looking into making it set by default?

>

and find a real alternative to the current GC.

We have multiple GC's, there is also std.experimental.allocator.
I feel it should probably be moved out of std.experimental at some point.

July 20, 2022

On Wednesday, 20 July 2022 at 07:23:04 UTC, Nicholas Wilson wrote:

>

We have multiple GC's

Do we really have multiple GCs though? How do you we use them, what are the advantages / disadvantages of each one?

>

there is also std.experimental.allocator

Which is useless until Phobos data types are refactored to use that as a parameter.


If you ask me, D is better than most languages out there and it should be the default way of migrating out of C++. But that's not gonna happen until at least multiple of the following happens:

  • The runtime gets leaner and more configurable, gotta have that wasm support.
  • Modern features such as sum types & pattern matching, nullables & tuples in the language (not as libraries).
  • Allocators passed into functions (+ a "garbage collecting allocator" like we have now)

Right now D is trying to compete with Java / Go and C++ / Rust and failing at both. Just choose to compete with the lower level ones and then higher-level stuff can be added later.

July 20, 2022

On Wednesday, 20 July 2022 at 07:23:04 UTC, Nicholas Wilson wrote:

>

On Wednesday, 20 July 2022 at 04:02:46 UTC, Ola Fosheim Grøstad wrote:

>

D would be better off taking actors seriously, start giving ‘shared’ meaning

There's a preview flag for that! Maybe its time to start looking into making it set by default?

>

and find a real alternative to the current GC.

We have multiple GC's, there is also std.experimental.allocator.
I feel it should probably be moved out of std.experimental at some point.

I still believe that the easiest way to give D a better chance is:

  1. Clean up syntax and enable precise collection by getting rid of type punning of pointers (C union), tagged unions is the easiest way to do it (but other alternatives are possible).

  2. Formalize execution contexts (Task/Actor/GPUCompute) that manage their own memory (GC, Arena, whatever) independent of other contexts.

  3. Require shared for items that are accessible from multiple contexts.

July 20, 2022

On Wednesday, 20 July 2022 at 09:35:14 UTC, Templated Person wrote:

>
  • The runtime gets leaner and more configurable, gotta have that wasm support.

Yes, I think leaner runtime is on the plan?

Memory management is still a big question mark with no clear resolution.

>
  • Modern features such as sum types & pattern matching, nullables & tuples in the language (not as libraries).
  • Allocators passed into functions (+ a "garbage collecting allocator" like we have now)

This is the tricky bit, this should be thought through from scratch. None of the current directions can converge on something that fits well together, but with better move semantics you can at least implement decent ref-counting schemes where shared is used to good effect. E.g. ref counting of objects that are shared across execution contexts, ref counted arenas. And what about local GCs that are dropped in O(1) when the execution context is pulled down?

Quite a bit of language tuning has to be done to get there. Like, if you allow the entire GC pool to be dropped, then you need to distinguish between destructors that manage external resources from destructors that has no consequences outside the context. So you need a finalizer scheme or a resource manager scheme to make arena-like allocation pleasant and performant.