January 18, 2021
On Monday, 18 January 2021 at 13:14:16 UTC, Arafel wrote:
> On 18/1/21 13:41, Ola Fosheim Grøstad wrote:
>> Yes, it is natural that the current D population don't mind the current GC. Otherwise they would be gone... but then you have to factor in all the people that go through the revolving door and does not stay. If they stayed the eco system would be better. So the fact that they don't... is effecting everyone in a negative way (also those that har happy with the runtime).
>
> I must be in the minority here because one of the reasons why I started using D was precisely because it HAS a GC with full support. I wouldn't even have considered it if it hadn't.
>
> For what I usually do (non-critical server-side unattended processing) latency is most obviously not an issue, and I for me not having to worry about memory management and being able to focus on the task at hand is a requirement.

1). You're not a minority at all. System programming is also vast so having a GC (especially D's special kind of GC) is nothing alien in System programming. If you look out there, you'd see most of the very important software (for the lack of a better word) written uses some form of GC.

2). I'm not sure anyone really know how many people use D, stay with D after first encounter or leave. So we're all guessing our biases. And I wouldn't look at just the core language as why someone will move to D or not.

From my experiencing freelancing, I've come to see that a large portion of clients' decision stems from other things like familiarity and ecosystem (packages, frameworks, vendor/cloud support, engineering hiring pool, consultants/support availability, tooling, marketing/popularity/fomo/community, etc)... including things that usually comes from the community and stakeholders. For D we don't really have any measure of community size. Only looking at the forum can be misleading.

3). Using GC doesn't mean you're writing scripts. A significant amonnt of very large D code I've read (including those from long time users) use GC... sometimes partially. So to think or assume GC is hurting D is an unmeasured bias.

I'm not saying those who are looking for nogc don't really matter (even though I hold the opinion that one can write nogc code in D just fine). dplug is written in D. What else couldn't?

Also maybe the GC and other complaints (genuine or not), which I'm also a culprit, might actually be a contributing to people's first impression of D when they visit the forums. I have a strongly suspicious of this.
January 19, 2021
On Monday, 18 January 2021 at 15:18:40 UTC, aberba wrote:
> 1). You're not a minority at all. System programming is also vast so having a GC (especially D's special kind of GC) is nothing alien in System programming. If you look out there,

This is not true, and you know it.

There is nothing special about D's GC. It is just very basic.

GC is not usual in system level programming. Not at all usual. It happens, but it is not the usual.


January 19, 2021
On Monday, 18 January 2021 at 12:41:31 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 18 January 2021 at 12:17:24 UTC, aberba wrote:
>> [...]
>
> Not fighting the GC, but the whole argument about improving it, or mix or match, does not work for most developers looking for a new language. So either there has to be something else or the language semantics will have to be adjusted to get a better GC. That is the crux, the GC cannot be significantly improved without some minor adjustment to the language (with some breaking changes).
>
> [...]

What adjustments to the language would be needed in your opinion?
January 19, 2021
On Tuesday, 19 January 2021 at 06:14:52 UTC, Imperatorn wrote:
> What adjustments to the language would be needed in your opinion?

I've mentioned them in connection with various approaches I've suggested. Depends on what area you want to improve.

In short (off the top of my head, maybe more is needed):

Precise tracing:

- The compiler currently cannot know what a tracing pointer points to: unions, casts.

- The GC traces many paths that never leads to ownership. Non-tracing pointer needed.

ARC:

- There is no knowledge of ownership, so ARC cannot be added. Compiler needs to know.

Singled threaded GC:

- The compiler does not know when a thread is created? So what are shared semantics?



January 19, 2021
On Monday, 18 January 2021 at 15:18:40 UTC, aberba wrote:
> From my experiencing freelancing, I've come to see that a large portion of clients' decision stems from other things like familiarity and ecosystem (packages, frameworks, vendor/cloud support, engineering hiring pool, consultants/support availability, tooling, marketing/popularity/fomo/community, etc)... including things that usually comes from the community and stakeholders. For D we don't really have any measure of community size. Only looking at the forum can be misleading.

I agree.  Ecosystem is one of the most important things to take the choice. In particular, when a team of developers need to engage a new project they don't just talk about language:  they talk about process model, frameworks, libraries... and tooling for solving common development/testing/deployment tasks (i.e.:  debugging).

Go and Rust are really clever about its paradigms decisions and no one (as far as I perceive) is discussing if GC must be removed from Go or added to Rust:   developers see what language offers them and they decide.

D toke it's key decisions in the past:  of course it is a "generalist" language trying to convince C or C++ developers, but this is really frustrating when there is no a way to perform decent debugging in linux with vscode (like https://youtu.be/X2tM21nmzfk?t=352) while the community is dedicated to discussing the sex of angels (multiple inheritance, GC/no GC, exceptions/no exceptions, ...).

A good friend developer told me months ago:  "If you are experienced with Node, C# or Scala and you expect to find their functionalities in other language like D, you just will get frustrated:  adapt to what the language offers you or jump to other options".

D is D:  take it or not. This language is not the holy grail.  If D is not C++ and you love to work with C++, just work with C++ (or take a try with Rust and it's Ownership memory model if D pros are not enough for you).  If D is not C and you love to work with C, just work with C (or take a try with Go and it's GC if D is not enough for you), but think about the thousands of experienced developers that where looking for something mature to work with and found that D was not an option.

> Also maybe the GC and other complaints (genuine or not), which I'm also a culprit, might actually be a contributing to people's first impression of D when they visit the forums. I have a strongly suspicious of this.

Me too:  I'm absolutely convinced.





January 19, 2021
On Tuesday, 19 January 2021 at 10:36:13 UTC, ddcovery wrote:
> GC if D is not enough for you), but think about the thousands of experienced developers that where looking for something mature to work with and found that D was not an option.

And that's the point. The vast majority of _experienced_ developers recognize the current GC for what it is: a very basic primitive Boehm-style GC. Which basically is a trip back to the 1990s (or 1970s, whenever they started programming).


January 19, 2021
On Tuesday, 19 January 2021 at 10:43:45 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 19 January 2021 at 10:36:13 UTC, ddcovery wrote:
>> GC if D is not enough for you), but think about the thousands of experienced developers that where looking for something mature to work with and found that D was not an option.
>
> And that's the point. The vast majority of _experienced_ developers recognize the current GC for what it is: a very basic primitive Boehm-style GC. Which basically is a trip back to the 1990s (or 1970s, whenever they started programming).

And if it isn't clear: stuff like that (and bugs in the type system) is what makes _experienced_ developers do exactly what you said. They do go to Rust, Go and C++ (or Nim or Zig).

Go back through the forums and you see plenty of dedicated D users that did exactly that.

Lost opportunities.

And that is why you don't get the eco system you think is needed.

Truly _experienced_ programmers do test a new language before they commit to it. They will recognize the flaws based on prior experience. They do know what typical flaws in language design look like. They have experience with maybe 5-15 languages, so you cannot just throw stupid slogans in their face, they are used to that too.

January 19, 2021
On Tuesday, 19 January 2021 at 11:25:13 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 19 January 2021 at 10:43:45 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 19 January 2021 at 10:36:13 UTC, ddcovery wrote:
>>> GC if D is not enough for you), but think about the thousands of experienced developers that where looking for something mature to work with and found that D was not an option.
>>
>> And that's the point. The vast majority of _experienced_ developers recognize the current GC for what it is: a very basic primitive Boehm-style GC. Which basically is a trip back to the 1990s (or 1970s, whenever they started programming).
>
> And if it isn't clear: stuff like that (and bugs in the type system) is what makes _experienced_ developers do exactly what you said. They do go to Rust, Go and C++ (or Nim or Zig).
>
> Go back through the forums and you see plenty of dedicated D users that did exactly that.
>
> Lost opportunities.
>
> And that is why you don't get the eco system you think is needed.
>
> Truly _experienced_ programmers do test a new language before they commit to it. They will recognize the flaws based on prior experience. They do know what typical flaws in language design look like. They have experience with maybe 5-15 languages, so you cannot just throw stupid slogans in their face, they are used to that too.

First of all, nice to read you

That you want GC to work efficiently seems great to me... but at least we agree that D memory management is (and must be) GC based (so I really don't understand your somewhat over-acted answer... maybe I need to read all the threads to understand your discomfort. In any case, accept my forgiveness if I have been able to bother you).

Regarding the experience, do we really have to go into that? In this forum there are more or less many people with university level and between 10 and 30 years of experience ... many (except the youngest) have worked professionally with dozens of programming languages and this is, in my opinion, the reason D attracts us (people with really different profiles and needs but with a lot of experience).

In my case, for example, I have not worked manually with memory for decades (the 90s are a long way off, and my years with C/ASM, Pascal and C++ are long forgotten): VB, C#, Java, Ruby, Groovy, Scala, ObjectiveC, Js/Ts, Kotlin, Dart, ... D seems like a great alternative to me (mainly because the "way" of computational inefficiency that a lot of them and their most used frameworks are taking).

In any case, your point about to be professional when comparing alternatives should always be kept in mind, nothing to add.

Thanks for your tips.


January 19, 2021
On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
> That you want GC to work efficiently seems great to me... but at least we agree that D memory management is (and must be) GC based (so I really don't understand your somewhat over-acted answer... maybe I need to read all the threads to understand your discomfort. In any case, accept my forgiveness if I have been able to bother you).

I think we need to understand the landscape around us. What was possible development directions for D 2-5 years ago are now less viable, because it is now a game of (forever) catching up to the other ones (C++/Rust) rather than being something different. 5 years ago I would argued more for competing with C++/Rust head-to-head. I think that train has left the station. D is on a different track now.

So the possible viable directions has shrunk to improving the GC (by some minor language adjustments), switching to ARC or some other paradigm that give roughly the same programming experience as D users are accustomed to.


> Regarding the experience, do we really have to go into that? In this forum there are more or less many people with university level and between 10 and 30 years of experience ...

Yes, but would most of those have chosen D over Rust, Zig, Nim, C++20 today? We cannot know for sure, but there is clearly a significant uptake for competing languages that did not exist 10 years ago.

So the "recruiting pool" is shrinking, that means losses (people leaving) cost even more today than 10 years ago...

So yes, we should absolutely listen to concerns from experienced developers with Comp.Sci. background if they chose to share them here in the forums. Tooling is a much bigger issue, but language/runtime adjustments are possible if we are willing to take some inconvenience in transition (some breakage).


> In my case, for example, I have not worked manually with memory for decades (the 90s are a long way off, and my years with

Yes, I don't think most people want to work manually with memory, which is why mix-and-match is not sitting well. People who really want to do fully manual stick to C (they don't even want C++, right?).

Anyway, the more cores CPUs get, the more unacceptable blocking threads gets.

But I also suspect thread-pooling will eventually become the only reasonable option as one has to support CPUs with 2-30 cores... difficult to do that with a threading model. So, there are many... issues. Maybe threading is not the best model... Not sure.



January 19, 2021
On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
> (so I really don't understand your somewhat over-acted answer... maybe I need to read all the threads to understand your discomfort. In any case, accept my forgiveness if I have been able to bother you).

Forgot to answer, maybe I misinterpreted your statement, if so I apologise.  I felt you were putting too much emphasis on tooling as the dominant issue. If that becomes an excuse to not make som hard choices then we cannot move. Because everybody has to be on board for D to take a decisive direction. So, yes, I am not happy if we establish excuses as valid arguments against change!

I also don't think tooling or libraries are the core issues.  I think a solid language and a solid runtime is sufficient to get the ball rolling, because then you can retain those highly skilled people that will build the tools (over time). If people do not stay for a long time then you will have 50% of a tool built, then it goes into the graveyard. Then another builds another 50% solution, then it goes into the graveyard... D has a very large graveyard at this point of very interesting projects that only got to the 50-80% mark... then the authors left.

Anyway, commercial quality tooling is expensive. Even Google gave up on building their own IDE for Dart and left it to JetBrains.

1 2 3 4 5 6 7 8 9
Next ›   Last »