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

Yes, there is the standard (conservative) GC, there is a Precise GC (which is really the same as the standard GC but with a precise sweep), and there is a fork GC (which is only for linux) which is different to the other two.
I believe you can choose which one with a --DRT flag, and I think you can set some config at runtime in druntime somewhere, but I'm not sure. I've not bothered to change it.

The standard GC is a stop the world, conservative mark and sweep. It treats any value that looks like it could point to valid objects to be pointers (called false pointers). False pointers are only really a problem on 32-bit, which unless you are writing for microcontrollers are going the way of the dodo.
The precise GC is a stop the world, precise mark and sweep. Advantage: should not ever get confused by false pointers. Disadvantage often slower than the conservative GC.
Fork GC forks the current process and uses linux's cheap copy on write pages to mark dead objects asynchronously and then reap them. Advantages: not stop the world, asynchronous, usable in soft (and probably hard) realtime. Disadvantages: Linux only.

Theres not really that many "data" types in the standard library. We should have a better container library that should be parameterised by the allocator that backs it, but the advantages of ranges is most of the code doing computation doesn't care what the memory is that backs it.

LDC has (some?) support for WASM, and the runtime is becoming less reliant on TypeInfo, by becoming templated to what is actually used. I'm not sure how far away we are from a no typeinfo runtime being usable.

Good tuples would be very nice to have.

There is nothing stopping you from doing that now. I'm not sure what you mean here.

On Wednesday, 20 July 2022 at 12:27:07 UTC, Nicholas Wilson wrote:

I think he meant in the standard library. One thing that might be interesting is a blog post that just summarizes some basic information on what in the standard library is compatible with @nogc and what currently isn't usable with @nogc.

On Tuesday, 19 July 2022 at 16:57:29 UTC, Ola Fosheim Grøstad wrote:

It's clearly Rust--.

https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types

They got tagged union built in! as well as .Enum and pattern matching!

What are we waiting for? We failing behind

On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

We're waiting for someone with the skills and motivation to add all that to dmd while ensuring it doesn't break the compiler in subtle ways, and is willing to go to through the DIP process

Basically, we lack the $$$

On Wednesday, 20 July 2022 at 13:46:25 UTC, Kagamin wrote:

They already have a bunch of fans that defends poorly thought out aspects of the syntax that a usability analysis ought to have uncovered. So I think we can expect that Google will move ahead with it… as it is already «popular» on social media…

Reminds me of how Google created Dart as dynamic language, then as an afterthought made a U-turn and redesigned it to become more like Java. Or how Go doesn't have exceptions, then added a hackish «panic» solution . How they didn't have generics, then added a weak generics design many years later. Also the Go dynamic arrays uses slices that will split when you extend it, so that you have two arrays instead of one as a surprise. (D also has this flaw).

Designers are often not good at being objective about their own design, so I would expect a large organisation like Google to use usability experts and make sure to get an external usability evaluation and also an external critical examination of semantics before the design is presented to the world.

Makes you wonder what the internal project management is like?