April 06

On Saturday, 6 April 2024 at 14:40:04 UTC, Paulo Pinto wrote:

>

Indeed, I would rather choose Java, Go, Oberon and C# for embedded development, as there is already several companies selling hardware and compiler toolchains, with companies paying real money for them.

Something that D has been missing out, by being stuck onto this kind of discussions.

You seem to be saying that speaking of the strategic future of D has stopped useful things from happening. Seems unlikely.

Let's speak of the present discussion instead of the nebulous "this kind of discussions".

Specifically what about it will stop what specific useful things from happening?

April 06

On Saturday, 6 April 2024 at 14:53:09 UTC, Sergey wrote:

>

On Saturday, 6 April 2024 at 10:52:04 UTC, Ogi wrote:

>

I wrote a small script that simulates a video game. A game scene contains around ten thousand objects, and on every update it creates some new objects and destroys some old ones. It runs for 36,000 iterations (simulating 10 minutes of exciting 60 FPS gameplay) and measures minimum, mean and maximum time per update. One version uses GC, the other uses malloc/free.

Very similar test..
D with LDC showed more FPS than Rust and C++ :P
https://github.com/NCrashed/asteroids-arena

This is all very well, but this side thread is conflating the existing GC with the one we are postulating for D that would be the game changer, with performance as per the article linked when this thread was started.

April 06

On Friday, 5 April 2024 at 16:40:06 UTC, Carl Sturtivant wrote:

>

What we see in the dlang forums related to the above group are such soft-real-time programmers who have labored and successfully overcome or bypassed these difficulties with D's GC in one way or another for their situation.

This is a biased sample! The presence of these successes strongly suggests a larger group who failed to go to D, with the successes the minority who got in. Those that penetrated the armor and those who were deflected. It takes something extra to penetrate the armor, so we might reasonably think that the deflected are in the majority, with the successes being the tip of the iceberg.

D is deterring a class of people that are very much operating in the spirit of D from joining the D community and creating new things that in turn widen positive attitudes to the language out there.

Imagine this: what if D had such an ace GC for the last decade? Perception and use of D would be entirely different to its present state; soft-real-time applications would abound, with a wide community of pro-D game programmers talking in the forums.

Just like ImportC being a game changer, ace GC is a game(!) changer. It's just harder to see this, but it is so.

Unfortunately the people I allude to above are not a part of the D community because the STW GC is not good enough for their purposes --- or they were convinced by the anti-GC crowd that this is the case.

So the D community is therefore host to a bunch of the anti-GC crowd without pushback from them. Instead they have done their soft-real-time work in Java, C#, ... with ace GC, and their successes are not presented here to bolster the strategic argument that a new ace GC of that variety is a necessary game-changer for D. It's catch-22.

Anti-GC crowd:
Don't straw-man this: none of this says that you HAVE to use GC in D. There is no reason to oppose an ace GC for D on those grounds.

April 06

On Saturday, 6 April 2024 at 15:52:21 UTC, Carl Sturtivant wrote:

> >

Very similar test..
D with LDC showed more FPS than Rust and C++ :P
https://github.com/NCrashed/asteroids-arena

This is all very well, but this side thread is conflating the existing GC with the one we are postulating for D that would be the game changer, with performance as per the article linked when this thread was started.

I've just shared with Ogi some other tests showing that everything not that bad as in tests Ogi mentioned)

That article is not new and was discussed previously. Moreover at D Discord several discussions about improvements of GC were taken.
But I can't see any real points from topic starter or you. Maybe you can help me with that.

Let me briefly summarize some things to be on the same page:

  • have "better" GC will be good for D (kinda obviously, but even "better" could mean different things for different people)
  • but it is very hard and expensive research (Google made some for Go)
  • GC overall is not simple thing, and you need someone who will be able to spend significant resources on it
  • Rikki has some ideas for improvements, that related to barriers, but afaic there is no consensus about it
  • Walter previously on Dconf was mentioning, that some metaprog features of D are available only because we have current GC approach, and they could not working with another architecture
  • even C# (if we trust to Mono's creater Miguel https://www.youtube.com/watch?v=tzt36EGKEZo) has not very good GC
  • One of the state of the art Azul's "pauseless" GC is a result of hard work the whole company, which is impossible for the current state of the D

So what is the point then you wanted to discuss in this thread?

April 06

On Saturday, 6 April 2024 at 00:29:04 UTC, H. S. Teoh wrote:

>

Walter himself used to say in the old days that it's better to cater to existing, enthusiastic customers who are already here, than to chase would-be customers who claim that if only feature X were implemented, they'd adopt D instantly. Because once you implement X, said would-be customers would start clamoring for Y instead. And when you implement Y they would start clamoring for Z. The truth is that they will never become real customers; X, Y and Z are merely convenient excuses. In the meantime, so much effort is being put towards features that in the long run doesn't draw in the promised rush of new customers (and probably never will), while quality-of-life changes for existing customers are being neglected.

And we are losing potential customers who don't make claims, and just want GC to be a non-issue for their soft-real-time requirements.

>

While there have been improvements in our current GC over the past years, we're running against a brick wall in terms of available GC algorithms, because of the pessimistic situation of no write barriers. That closes the door to many of the major advancements in GC algorithms over the past decade or two. It's time we stop sitting on the fence and commit to a GC-centric language that actually has a competitive GC to speak of, one on the level of Java or C#'s incremental generational GCs.

Yes. There's no downside! Only a chance at a strategic future for D.

Quite aside from technical reasons, I think it is utterly essential and almost too late.

If this isn't embraced and the current tactical compromise is continued, then erosion of D from propaganda from anti-GC zealots will continue. "Maybe you should leave D" being emitted at people in the community who want to use GC and want better GC without getting it. In other words, getting people to join the ones who were deflected from D in the first place and go away to Java, C#, etcetera.

"Want a pure GC language, go away to language blah." "GC is Scripting, go away to GC-only language blah, not real programming", etcetera. We've all encountered this psychological noise that has only emotive basis. And it's been very destructive to D. If GC-centric people are deflected in the first place or pushed out then this serves anti-GC zealotry.

The present state of GC serves anti-GC zealotry. Code can be written to use a lot of time attributable to the GC, and used to shout about GC being bad.

It is a reasonable working hypothesis that without escaping the present situation with a competitive GC for soft-real-time, that D will be lost strategically.

April 07
On 07/04/2024 4:28 AM, Sergey wrote:
> Rikki has some ideas for improvements, that related to barriers, but afaic there is no consensus about it

Its not really an idea on my end.

Modern GC's tend to need write barriers to make them work.

There is no way around it.

We can have as much consensus as we want on the subject, but if we don't have it, we aren't getting anything advanced.
April 06

On Saturday, 6 April 2024 at 16:28:25 UTC, Sergey wrote:

>

So what is the point then you wanted to discuss in this thread?

This is not about what I wanted to discuss in this thread, it's about what IS being discussed in this thread. Finding strategic purpose via the future of GC.

On Saturday, 6 April 2024 at 00:29:04 UTC, H. S. Teoh wrote:

> >

Chasing no-GC as far as we did was a mistake that cost us precious time and scarce resources. We need to be mature enough to admit that it was a mistake and correct our course. Given the lessons and direction of the industry over the intervening years, I would strongly argue that now is the time to return our focus to the GC.
[...]

+100. While there have been improvements in our current GC over the past years, we're running against a brick wall in terms of available GC algorithms, because of the pessimistic situation of no write barriers. That closes the door to many of the major advancements in GC algorithms over the past decade or two. It's time we stop sitting on the fence and commit to a GC-centric language that actually has a competitive GC to speak of, one on the level of Java or C#'s incremental generational GCs.

Let's not confuse requirements with implementation. By muddling in all the ins-and-outs of implementation difficulty you blur the wider picture and make things look more pointless. Should everyone just give up? Your reply suggests that posture.

April 06

On Saturday, 6 April 2024 at 16:59:14 UTC, Carl Sturtivant wrote:

>

On Saturday, 6 April 2024 at 16:28:25 UTC, Sergey wrote:

>

So what is the point then you wanted to discuss in this thread?

Finding strategic purpose via the future of GC.

D doesn't have any strategy. As a samurai D has no goal only path..

But it is easy to get "future GC":
Need a couple of PhD/PostDoc - lock them in a room with coffee and pizza for a couple of years - done

April 06

On Saturday, 6 April 2024 at 16:59:14 UTC, Carl Sturtivant wrote:

>

On Saturday, 6 April 2024 at 16:28:25 UTC, Sergey wrote:
Let's not confuse requirements with implementation. By muddling in all the ins-and-outs of implementation difficulty you blur the wider picture and make things look more pointless. Should everyone just give up? Your reply suggests that posture.

This:

>

On Saturday, 6 April 2024 at 16:28:25 UTC, Sergey wrote:

  • but it is very hard and expensive research (Google made some for Go)
  • GC overall is not simple thing, and you need someone who will be able to spend significant resources on it
  • Rikki has some ideas for improvements, that related to barriers, but afaic there is no consensus about it
  • Walter previously on Dconf was mentioning, that some metaprog features of D are available only because we have current GC approach, and they could not working with another architecture
  • even C# (if we trust to Mono's creater Miguel https://www.youtube.com/watch?v=tzt36EGKEZo) has not very good GC
  • One of the state of the art Azul's "pauseless" GC is a result of hard work the whole company, which is impossible for the current state of the D
April 06

On Saturday, 6 April 2024 at 16:59:14 UTC, Carl Sturtivant wrote:

>

Should everyone just give up?

Just wait for a hero.. some university professor who would guide PhD to do that.

Or a company which would like to sponsor it