On Wednesday, 2 September 2020 at 09:20:26 UTC, Russel Winder wrote:
> C, C++, and Rust folk (who are the bulk of the anti-GC community) are already firmly anti-D – I suspect no amount of non-GC D is going to change their minds as to what D is as a programming language.

I wouldn't expect people who have invested in Rust to give up on the borrow checker, but many past and current D programmers have one foot in C++ land.

Right now Go is cutting into both C++ and Java for light weight servers. Creating a competing runtime is out of scope for most languages. And heavy weight servers will not be implemented with smaller languages (more likely to go with industry standards). If you want to create a lightweight GC server today the most sane business choice is Go or node.js.

There are also many small languages out there that are trying to be suitable for that space: Crystal, Nim, V... that space is getting crowded.

Zig appears to do a better job of distinguishing itself, e.g. attract authors of emulators, hobby OSes etc.

(shrugs)

On Wednesday, 2 September 2020 at 09:06:16 UTC, IGotD- wrote:

> Either a language is garbage collected which means the runtime/compiler takes care of the memory management or it has manual memory management. Supporting both is in my opinion not realistic because designing libraries than can work in any environment is too complicated. This is an active choice that the library author must take if automatic memory management should be used or not.

But we program in these mixed environments all the time. Garbage collected languages call into C libraries.

Here's how it can work without being complicated, based roughly on my experience with other languages: @nogc library functions can call only std.nogc and other library functions marked @nogc. Any data passed into a @nogc function is protected from being garbage collected. You can use the GC to allocate data in @nogc functions, but only if it's returned to a call that was made from non-@nogc code.

It would require std.nogc but that wouldn't be a monumental task, because you don't need to replicate the full functionality of Phobos, and big parts are already nogc. You'd just need to insert a few restrictions that we already have when doing mixed-language programming.

On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:
> On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:
>> I didn't quite understand that sentence. What is the problem with the current design that prevents D from gaining momentum?
>
> D does have momentum.
>
> Some obstacles as I see them are:
>   * no corporate/government/academic sponsor backing the language
>   * garbage collection
>
> How one courts a sponsor, I do not know.

I think its a mistake to think that a single corporate sponsor is the answer.

Companies have their own distinct interests and values and those arent going to be identical with those of the language ecosystem and community.  Especially for a publicLy-listed company yet those tend to be the ones that have the resources to be a significant sponsor.

whats the use case for D?  well, look at how its uses by organizations that use D today.  it has incredible breadth and there is no single industry that pops out.  its about the kind of people more I think.

Having a single sponsor is quite dangerous too.  what will happen to Rust given the funding problems Mozilla has after their chronic mismanagement?  maybe it will be fine but at least the link with Mozilla is a source of brittleness.

government funding these days has most uncertain benefits in an environment of budgetary constraints and rising geopolitical tension.

I think more funding would be better but would be best for D if it comes from more than one source.  and I think this will naturally happen in time.

On Thursday, 3 September 2020 at 04:17:58 UTC, Laeeth Isharc wrote:
> On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:
>> On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:
>>> I didn't quite understand that sentence. What is the problem with the current design that prevents D from gaining momentum?
>>
>> D does have momentum.
>>
>> Some obstacles as I see them are:
>>   * no corporate/government/academic sponsor backing the language
>>   * garbage collection
>>
>> How one courts a sponsor, I do not know.
>
> I think its a mistake to think that a single corporate sponsor is the answer.
>
> Companies have their own distinct interests and values and those arent going to be identical with those of the language ecosystem and community.  Especially for a publicLy-listed company yet those tend to be the ones that have the resources to be a significant sponsor.
>
> whats the use case for D?  well, look at how its uses by organizations that use D today.  it has incredible breadth and there is no single industry that pops out.  its about the kind of people more I think.
>
> Having a single sponsor is quite dangerous too.  what will happen to Rust given the funding problems Mozilla has after their chronic mismanagement?  maybe it will be fine but at least the link with Mozilla is a source of brittleness.
>
> government funding these days has most uncertain benefits in an environment of budgetary constraints and rising geopolitical tension.
>
> I think more funding would be better but would be best for D if it comes from more than one source.  and I think this will naturally happen in time.

I couldn't say any better than this. The whole Mozilla-rust is clearly an example of cooperate vs community interest.

We need sponsorship as every Open Source initiative at some point does. It doesn't really matter where it comes from (we do appreciate where it comes from though). The opportant things is those sponsors don't influence the direction of the language based solely on their cooperate interest... financially or with their engineering workforce. Talking about engineering, D also need engineers from cooperates...payed or not to contribute to open source. That's something not talked about enough but makes huge difference. Developers, developers, developers. Isn't that part of why we need money?

Unfortunately is very uncommon to get cooperate sponsorship from some known companies without their influence in decision making. I'd rather have a independent language that a cooperate interest driven language.

And D is doing fairly fine and its only getting better. It might not be as fast as you might want it but it's moving... which can be both good and bad. Yeah good as in careful decision making cus some of these decisions Will become a permanent burden if not done right.


The idea that other languages are doing well due to GitHub stars and popularity contest is unfounded. I doesn't meant much. Popular doesn't necessarily mean good or people are ACTUALLY using it for production. Example is Rust being the most Loved language on stackoverflow even though ONLY 3% or so have actually used it. How's that even a statistic? That's what I call hyped. A successful language will MOSTLY have to be useful on its own for those who try it.


The thing about GC vs nogc by default is purely based on what you are used to and there's nothing stopping anyone from doing the other. And the friction is constantly being improved.

Those who say: if X had B instead of A... I would use it are MOSTLY never really interested IMO. Although there's are some very rare exceptions.

There's nothing wrong with D2. And popularity doing mean anything. Improving the current ecosystem and language is what I would consider founded. And there's already lots of people using D BTW. Part of why I try to do my fair share of D promotion.

On Wednesday, 2 September 2020 at 08:40:27 UTC, Russel Winder wrote:
> And D without garbage collection would create a pool of ex-D programmers saying "if only D had stuck to it's guns with garbage collection instead of being bullied into a position by C++ and Rust lovers who aren't going to use D anyway."

Commenting on thread to agree with this.

The only thing I really want as far as GC goes in D is more hooks in to pointer acquire and release. From there, I can get the task-based async collector going that I have in mind. GC is fine, but not when it's unconfigurable for my uses.

(I'm generally against library solutions like refcounted templates, this can 100% be solved with runtime hooks)

On Wednesday, 2 September 2020 at 14:09:12 UTC, bachmeier wrote:
> being garbage collected. You can use the GC to allocate data in @nogc functions, but only if it's returned to a call that was made from non-@nogc code.

So you are thinking about context-aware templates, that can query the properties of the call-chain? That is an interesting idea for static analysis indeed. Many things to consider though, when you have concurrency-mechanisms like coroutines.

There are many interesting things can be done to improve memory management for most languages, but one has to figure out what kind of constraints one are willing to impose on the language! If anything should be possible (on the low level) then that can inhibit some nice optimizations. For a GC-language you want to impose constraints on the language that some might considered inappropriate for writing and operating system kernel (most people don't write those, so it is not unreasonable to define writing kernels as out-of-scope for a language).

E.g. What happens if someone loads the whole file to GC-memory and then retains a pointer to a tiny slice of it. Can the runtime know that only that specific slice is "live"? If it can, then it can release the unused parts surrounding the slice (the big bulk of allocated memory). Can the runtime prove that there is only one reference to the slice? Then it can move it (compaction).

But the language semantics has to be hashed out very clearly and formally to do neat things like that safely (or to do them efficiently).

You basically need a very clear specification of what low level actions are defined as creating "undefined behaviour". You probably also need to introduce some constraints that some users will object to.

On Wed, 2020-09-02 at 09:19 +0000, Ola Fosheim Grøstad via Digitalmars-d wrote:
> 
[…]
> But there is a difference between 1) having an ecosystem where many libraries and frameworks rely on stop-the-world-GC 2) having the option of using GC in application code (or maybe just in unit tests).

My belief is that you end up with two runtime systems and standard libraries: one for GC and the other for non-GC. Certainly doable for a community with lots of people able to contribute, not so viable for a community with strictly limited person effort available.

> It is possible to market a low-level programming GC strategy, if it is geared towards that specific use scenario.
> 
> Especially if you consider mixed use, e.g. where the application use GC during initialization. But in those cases you might want the gaps on the GC heap to be available for malloc, or run compaction after initialization.
> 
> Or just to have GC available for testing frameworks.

I fear that would be the worst of all worlds.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wed, 2020-09-02 at 10:16 +0000, Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Wednesday, 2 September 2020 at 09:20:26 UTC, Russel Winder wrote:
> > C, C++, and Rust folk (who are the bulk of the anti-GC community) are already firmly anti-D – I suspect no amount of non-GC D is going to change their minds as to what D is as a programming language.
> 
> I wouldn't expect people who have invested in Rust to give up on the borrow checker, but many past and current D programmers have one foot in C++ land.

Investing in Rust means investing in the non-GC mind-set. It is easily done, and has many benefits in many areas of software development. In many other areas accepting a GC mind-set is also a benefit, witness the rise of Go.

My feeling is that C++20 and C++23 are likely to satisfy C++ addicts such that any thoughts of using D get washed away.

My belief is that programmers now attribute programming languages as no-GC, GC-possible, and GC – with GC-possible being a very small set.

I have no problem iwth D trying to be both GC and non-GC for those D programmers that feel they need it, but D is very much seen fairly widely as a GC language, I see no reason to fight that.

> Right now Go is cutting into both C++ and Java for light weight servers. Creating a competing runtime is out of scope for most languages. And heavy weight servers will not be implemented with smaller languages (more likely to go with industry standards). If you want to create a lightweight GC server today the most sane business choice is Go or node.js.

I am not sure Go is cutting into C++, but I am a bit out of that arena just now with no ACCU conferences this last year. Go is certainly taking some of the old Java stuff, mostly to do with containers, etc.

Do not underestimate Python as a way of developing GC Web servers. Also of course Web servers are just a small bit of the overall programming milieu.

> There are also many small languages out there that are trying to be suitable for that space: Crystal, Nim, V... that space is getting crowded.
> 
> Zig appears to do a better job of distinguishing itself, e.g. attract authors of emulators, hobby OSes etc.

Obviously the set of mainstream programming languages change, but most programmers only even think about alternatives to the current set once a new one is established. I cannot see any of the set you mention breaking through. D on the other hand is already there, just not as used as perhaps it should be.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 4 September 2020 at 07:08:40 UTC, Russel Winder wrote:
> Investing in Rust means investing in the non-GC mind-set. It is easily done, and has many benefits in many areas of software development.

I'm sure their approach works well for larger teams, but when you look closer at what people do to get beyond tree-like structures in Rust they essentially end up using array-indexes as pointers. So technically it is memory-safe, but then you are basically back to square one in terms of correctness and also pay some performance penalty (out-of-bounds checks).

> My feeling is that C++20 and C++23 are likely to satisfy C++ addicts such that any thoughts of using D get washed away.

It does make the languages/standard lib more similar in some ways, I guess.

> I have no problem iwth D trying to be both GC and non-GC for those D programmers that feel they need it, but D is very much seen fairly widely as a GC language, I see no reason to fight that.

Well, but the D language semantics does not provide a lot of room for optimizing a GC runtime. So being competitive in terms of GC capabilities would require a D3.

> I am not sure Go is cutting into C++, but I am a bit out of that arena just now with no ACCU conferences this last year. Go is certainly taking some of the old Java stuff, mostly to do with containers, etc.

You can write a better image-rescaling service in C++ or D, but since Cloud infrastructure makes it easier to deploy managed languages lik Go, then that makes me more likely to pick Go. E.g. you can run Go as a Google Cloud Function, but for C++ you have to set up a docker-thingy.

Also, setting up a web-service with Go is less hassle, as more is available in the standard library/runtime. So even though I might prefer to do it in C++/D it would take twice as much effort, and require somewhat more maintenance. So even though Go loose on performance, it might win on less friction and effort.

Like, with C++/D I will have to figure out which HTTP-server library to use, basically more manual labour and things that could go wrong.

But apparently has become easier to deploy smaller languages with Google Cloud Run. So if someone created a github repo with a ready-made "template" for D, then that would make it more likely that people would use it.

> Do not underestimate Python as a way of developing GC Web servers.

True, and with the "cloud functions" approach you get to use different languages for different requests. So the situation is more flexible than it used to be.

On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:
> What is left to do for D 2.x for it to be declared "done" and in stable/bugfix mode only?
>
> I haven't seen a Vision/20xxHy for a while.
>
> What features (and breaking changes) are on the horizon for when the next generation D 3.x begins?
>
> There are plenty of languages out there that have intriguing features that may (or may not) be good candidates to consider for D 3.x.
>
I just have found this interesting read about Ruby:

   Ruby Creator Yukihiro Matsumoto on the Challenges of Updating a Programming Language[1]

Some general points sound quite familiar.

[1] https://thenewstack.io/ruby-creator-yukihiro-matsumoto-on-the-challenges-of-updating-a-programming-language/