May 16, 2021

On Sunday, 16 May 2021 at 21:24:40 UTC, Paulo Pinto wrote:

>

Let me put it this way, a couple of years ago Facebook played with D, now they have this to tell about Rust.

I disagree with this. Facebook chose it because they want to run a safe stable language for their mercurial clone. There are lot of thoughts, support, ads by mozilla folks for this. Why didnt facebook chose Go for this ? For their case GC was no go. For Remedy did we analyse what went wrong ? Do we know why facebook didnt D after Andrei left ? Did we ask what programming community want. Definitely we cant satisfy everyone for all the feature but atleast we should play with some of our strengths.
Why would someone use D for any with GC.
Go - has GC, easy, good libraries, google backing
Rust - safety, mozilla backing
swift - apple backing, easy

Lets not be in own echo chamber. I feel D can push itself as a simple way of doing memory safety and extension to C/C++/python instead of a rewrite. Let advertize as a language which can be simple like python and fast as C. C++ rust interop doesnt see easy.
a. Safe language
b. Good tooling
c. Good interop with C/C++
d. Flexible to use GC/no GC.

May 16, 2021

On Sunday, 16 May 2021 at 20:33:12 UTC, dogman wrote:

>

On Sunday, 16 May 2021 at 19:46:06 UTC, Imperatorn wrote:

>

On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

>

[...]

There are "GC off" switches.

@nogc, GC.disable and betterC

But then we dont know if all standard library and other modules can be used. We dont even have associate arrays etc. What we want is a pluggable framework where people can use the default GC or their GC

Definitely + for this, providing a set of GCs for different situations is a good thing as severally proven in Java.

>

or manual memory management by registering malloc/free's(like zig). Code is same. I am not sure technically if its possible as I am not an expert in compiler.

I think that's what @russhy also wanted to propose. Providing support for other memory containers/allocators in stdlib.
As much as I like it, I think "the same" code for all kinds of MM is just too beautiful to become true.
Different memory containers will work better for different code or even require code to be rewritten which is often the case with the ownership system in Rust.
Then we are left to overload over any MM container increasing the risk for a state space explosion.

May 16, 2021

On Sunday, 16 May 2021 at 21:38:51 UTC, dogman wrote:

>

On Sunday, 16 May 2021 at 21:24:40 UTC, Paulo Pinto wrote:

>

Let me put it this way, a couple of years ago Facebook played with D, now they have this to tell about Rust.

I disagree with this. Facebook chose it because they want to run a safe stable language for their mercurial clone. There are lot of thoughts, support, ads by mozilla folks for this. Why didnt facebook chose Go for this ? For their case GC was no go. For Remedy did we analyse what went wrong ? Do we know why facebook didnt D after Andrei left ? Did we ask what programming community want. Definitely we cant satisfy everyone for all the feature but atleast we should play with some of our strengths.
Why would someone use D for any with GC.
Go - has GC, easy, good libraries, google backing
Rust - safety, mozilla backing
swift - apple backing, easy

Lets not be in own echo chamber. I feel D can push itself as a simple way of doing memory safety and extension to C/C++/python instead of a rewrite. Let advertize as a language which can be simple like python and fast as C. C++ rust interop doesnt see easy.
a. Safe language
b. Good tooling
c. Good interop with C/C++
d. Flexible to use GC/no GC.

To the community, sorry am not trying to a$$hole. I just want this language and community to grow and flourish. I wish Andrei, Walter come up with Q&A to do a postmortem of the issues they faced and what we can do for it. I wish to help on small tasks whatever I can. I used to do lot of c++ and python and thought of a language somewhat like D. Then I saw D and always wished, if I could write in D daily. D on android, D on linux kernel/EBPF, D with WASM.

May 16, 2021

On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

>

community is let D be good at both. With a switch of GC=off, people should be able to use manual memory management and also able to use stdlib and lot of libraries. Not sure if its technically possible. Most people will use D with GC on. I know we can turn off GC and mix manual memory management.

It takes discipline to mix. Libraries would need to:

  1. Be written for RC, transition to GC becomes free.
  2. Written for finalizers, getting basic cleanup
  3. Test for various mixes of RC/GC... How?
    But you also need a fully precise GC to get proper finalzation...

Probably not worth it, easier to have GC only libs...

I am arguing in favour of task bound GC, which can b extended to task-group GC. The latter should roughly cover existing code bases that dont do anything fancy...

The key point however is that DMD ought to use the recommened sytem programming MM idiom (whatever it ends up being), then it is possible to argue pro et contra with some level of objectivity.

With no common ground, nothing will move...

May 16, 2021

On Sunday, 16 May 2021 at 22:02:29 UTC, Ola Fosheim Grostad wrote:

>

On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

>

community is let D be good at both. With a switch of GC=off, people should be able to use manual memory management and also able to use stdlib and lot of libraries. Not sure if its technically possible. Most people will use D with GC on. I know we can turn off GC and mix manual memory management.

It takes discipline to mix. Libraries would need to:

  1. Be written for RC, transition to GC becomes free.
  2. Written for finalizers, getting basic cleanup
  3. Test for various mixes of RC/GC... How?
    But you also need a fully precise GC to get proper finalzation...
    ...
    With no common ground, nothing will move...

This is what I was going on about in terms of "We want to be everything yet end up as nothing" and "We expect everything to be perfect in every possible use case, but ends up in impossible situations where nothing happens since no one will compromise".

Ultimately the fate of this thread is that everything posted here will just turn to dust overtime, as no one with the power to move things forward will even take things into consideration.

May 16, 2021

On Sunday, 16 May 2021 at 09:53:04 UTC, SealabJaster wrote:

>

On Sunday, 16 May 2021 at 09:22:00 UTC, Ola Fosheim Grostad wrote:

>

Is there a plan? No? Will there be a plan? Right now, it does not seem likely. People make suggestions all the time, but there is no signal of a likely path.

On the topic of a plan (just in general, not specifically about DMD's memory usage):

  1. It begs the question of, how is it possible for anyone to even organise a cohesive plan coming forward, since it requires participation from both the leadership, core team, and also D's community (ideally).

I dont know, but it is a historic fact that D's feature set is a result of evolutionary experimentation more than analytical rigour and careful planning.

So, the best option if there is no plan is to make DMD more and more idiomatic and use idiomatic MM, then the weak spots will be exposed and hopefully fixed?

May 16, 2021

On Sunday, 16 May 2021 at 22:11:23 UTC, SealabJaster wrote:

>

On Sunday, 16 May 2021 at 22:02:29 UTC, Ola Fosheim Grostad wrote:
This is what I was going on about in terms of "We want to be everything yet end up as nothing" and "We expect everything to be perfect in every possible use case, but ends up in impossible situations where nothing happens since no one will compromise".

I think it is more a matter of "we know what we have, but not what we get", which tend to lead to stagnation or long tail decay.

>

Ultimately the fate of this thread is that everything posted here will just turn to dust overtime, as no one with the power to move things forward will even take things into consideration.

Most likely. It is a bit more dysfunctional than that as people are willing to put in effort to move things themselves if they knew that the time they put in is a move in a direction that wouldnt be rejected. The real blocker is that there is no format for creating a task force (working group).

May 17, 2021

On Sunday, 16 May 2021 at 22:11:23 UTC, SealabJaster wrote:

>

On Sunday, 16 May 2021 at 22:02:29 UTC, Ola Fosheim Grostad wrote:

>

On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

>

community is let D be good at both. With a switch of GC=off, people should be able to use manual memory management and also able to use stdlib and lot of libraries. Not sure if its technically possible. Most people will use D with GC on. I know we can turn off GC and mix manual memory management.

It takes discipline to mix. Libraries would need to:

  1. Be written for RC, transition to GC becomes free.
  2. Written for finalizers, getting basic cleanup
  3. Test for various mixes of RC/GC... How?
    But you also need a fully precise GC to get proper finalzation...
    ...
    With no common ground, nothing will move...

This is what I was going on about in terms of "We want to be everything yet end up as nothing" and "We expect everything to be perfect in every possible use case, but ends up in impossible situations where nothing happens since no one will compromise".

Ultimately the fate of this thread is that everything posted here will just turn to dust overtime, as no one with the power to move things forward will even take things into consideration.

You do have power, but like anything that involves other people if you have a valid idea for where D should go you need to convince others first. But while trying to do that remember, those others will have to do the actual work to implement and maintain whatever it is you want. So bitching for your pet features is nothing without putting in the work to either a) convince others it is worth doing and where possible b) doing the work, either implementation, writing a DIP etc.

So everyone here has power to do something, just most can't be bothered once the work kicks in. If you have written several books or a compiler or contributed PRs and proven your skills then your power will grow, i.e. you ability to influence the core D devs.

May 17, 2021

On Sunday, 16 May 2021 at 21:38:51 UTC, dogman wrote:

>

On Sunday, 16 May 2021 at 21:24:40 UTC, Paulo Pinto wrote:

>

Let me put it this way, a couple of years ago Facebook played with D, now they have this to tell about Rust.

I disagree with this. Facebook chose it because they want to run a safe stable language for their mercurial clone. There are lot of thoughts, support, ads by mozilla folks for this. Why didnt facebook chose Go for this ? For their case GC was no go. For Remedy did we analyse what went wrong ? Do we know why facebook didnt D after Andrei left ? Did we ask what programming community want. Definitely we cant satisfy everyone for all the feature but atleast we should play with some of our strengths.
Why would someone use D for any with GC.
Go - has GC, easy, good libraries, google backing
Rust - safety, mozilla backing
swift - apple backing, easy

Lets not be in own echo chamber. I feel D can push itself as a simple way of doing memory safety and extension to C/C++/python instead of a rewrite. Let advertize as a language which can be simple like python and fast as C. C++ rust interop doesnt see easy.
a. Safe language
b. Good tooling
c. Good interop with C/C++
d. Flexible to use GC/no GC.

In what concerns Facebook, their GC cases are already covered by Haskell, OCaml and Java based languages, no need for the anemic Go.

Python JITs are enjoying a revival most likely thanks to Julia, now at Pycon 2021 it became official why Guido left his early retirement and went to work for Microsoft.

https://us.pycon.org/2021/schedule/presentation/52/

Instagram is also doing a JIT attempt based on their workloads,

https://us.pycon.org/2021/schedule/presentation/76/

Then there is already Cython, good enough to write NES emulators in Pyhon,

https://us.pycon.org/2021/schedule/presentation/66/

And the endless set of hardware being supported by CircuitPython as the modern BASIC,

https://us.pycon.org/2021/schedule/presentation/69/

Being a glue language for Python isn't any killer application worth pursuing, by the time it finally reaches it, Python won't need it any longer.

May 17, 2021

On Monday, 17 May 2021 at 01:55:14 UTC, norm wrote:

>

So everyone here has power to do something, just most can't be bothered once the work kicks in.

Only on the microscopic level. People who have veto power need to set up working groups, guide them and give them a mandate.

Most cant be bothered to do work that is likely to be binned, because that is extremely wasteful (expensive) and people have a life to attend to.