May 17, 2021
On Monday, 17 May 2021 at 16:56:37 UTC, Ola Fosheim Grostad wrote:
>
> Not impossible, you can do like C++, use smart pointers, but unlike C++ inject a new IR before LLVM IR that does ARC. Also, let the smart pointers use compiler intrinsics for ARC.

That's a possibility, however badging the code similar to unique_ptr and shared_ptr like in C++ is not something I want to do. What if I want to change the GC algorithm suddenly? One possibility is just to have a generic name for the GC type, like GcRef which is an alias for the actual GC type and then you can change it.

Anyone can do this today but still there is the default GC in phobos/druntime. Then we have to go through the entire library and change to the versatile GC alias.
May 17, 2021
On Monday, 17 May 2021 at 19:10:09 UTC, IGotD- wrote:
> That's a possibility, however badging the code similar to unique_ptr and shared_ptr like in C++ is not something I want to do. What if I want to change the GC algorithm suddenly? One possibility is just to have a generic name for the GC type, like GcRef which is an alias for the actual GC type and then you can change it.

Yes, fix type unification first, then do something like that... But you need to deal with finalization issues too. Btw, another advantage with task bound GC is that it could call all missed finalizers at completion, so the impact of not having a fully precise GC would be less also in terms of finalization.

> Then we have to go through the entire library and change to the versatile GC alias.

I guess Phobos alone is not a big issue, we could just fork it. The real issue is when you want to use third party libraries that assume Phobos...





May 17, 2021

On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

>

Question to the core team. Whats the plan and roadmap for D ?
a. are we planning to keep D just as a hobby language or a real contender for industry use. Despite being complex, rust has started to get adopted in industries. Whats our plan ?

Selection bias is in play here too. Rust is getting more popular, previously Go was starting to gain popularity also, but just as many languages succeed, many fail to reach the expectations. You have languages like Nim or Crystal, which have their own fanbases, but are relatively unknown in the general programming population (also, most programmers aren't really familiar with Rust/Go either). D is also in that category. You also have many languages that failed completely to gain attention and are dying away in programming language limbo.

But you also have languages which should succeed by most metrics, and yet they don't. Look at Dart. It's a well designed language (it's one of my favorite languages), it has good IDE support, it has Google behind it, and yet it never reached wide adoption. Outside of Flutter, the usage of Dart is very limited, and TypeScript took most of those usecases instead.

As for Rust, most people aren't flocking to Rust for memory safety or for GC-less memory management. Just like most people aren't flocking away from D because of GC (even if they claim it's because of GC). For many people, unless doing low level programming, memory management is more of an implementation detail.

Borrow checker isn't attracting people to Rust. It's a bonus, catching more bugs during compile time, but it's not the main feature. The main features that attract people to Rust is the cohesive story, good vision and a good ecosystem of tooling, libraries and bindings. Just like people did webdev with Python not because Python is great for webdev, but because it's good enough and easy to get started. With lots of libraries available, you can pip download flask, pip download pandas and make some nice dashboards within hours. Rust is similar to that extent. There are many packages, and you can expect many libraries to be existing, or at least if not existing, then the bindings to C/C++ libraries are available to cover that gap.

Both languages represent somewhat different mentality. Rust has a core team that is paid to work on Rust. These people can work on the design of the language and can force the decision whenever a problematic topic comes. D is mostly a volunteer project and doesn't have that luxury. Every problem that comes up needs a consensus to overcome. And in some cases the consensus is hard to get.

It is a chicken and the egg problem. Because D isn't very popular, it doesn't have the same level of ecosystem, and because it doesn't have the same level of ecosystem, it doesn't get popular. On the other hand, not every language needs to hit it big. I am satisfied with the state of the D and I've seen great improvements over the years. Dub really improved the ergonomics of using D, things like Code-D work fairly well (and get better every year also).

Sure, we can switch the language from garbage collection to manual memory management or reference counting. Will it change much? I doubt it, the people complaining about GC would just complain about RC. We would throw the existing ecosystem through the window, and there would be new bugs that come from the improvements.

Personally, I think what should happen is narrowing the scope of the language. I actually wish D went with GC fully, without giving escape hatches in form of @nogc. We shouldn't be chasing borrowing. Did that ever go anywhere? I don't even know if dip1000 works now, it's all hidden somewhere in spec documents. We don't have dozens of paid developers working on D full time. We have to manage with the resources we have, and spreading them thin over the language is not the optimal usage of such resources.

May 17, 2021

On Monday, 17 May 2021 at 19:32:14 UTC, JN wrote:

>

Selection bias is in play here too. Rust is getting more popular, previously Go was starting to gain popularity also,

Go is far far far more used than Rust will ever be...

>

but just as many languages succeed, many fail to reach the expectations. You have languages like Nim or Crystal, which have their own fanbases, but are relatively unknown in the general programming population (also, most programmers aren't really familiar with Rust/Go either). D is also in that category.

And here is the real trouble, more and more viable hobby languages are emerging, so the hobbyists are split up and eco systems suffer, so language enthusiasts gravitate towards the bigger ones that have polished that one feature they are interested in.

>

But you also have languages which should succeed by most metrics, and yet they don't. Look at Dart. It's a well designed language (it's one of my favorite languages), it has good IDE support, it has Google behind it, and yet it never reached wide adoption. Outside of Flutter, the usage of Dart is very limited, and TypeScript took most of those usecases instead.

This is inaccurate, I was an early Dart adopter. To keep it short, Google has sabbotaged it on numerous occations. First by designing it as a deliberately bland dynamic language (later made more static), then by not supporting it in Chrome as promised, then by having poorer framework support for it than for other web languages, add to this that debugging dart code in browsers was worse tha TypeScript and you have the reason for why I will not use Dart in web apps in the near future. 100% selfinflicted wounds.

>

As for Rust, most people aren't flocking to Rust for memory safety or for GC-less memory management.

That is obviously wrong.

>

Borrow checker isn't attracting people to Rust. It's a bonus, catching more bugs during compile time, but it's not the main feature. The main features that attract people to Rust is the cohesive story, good vision and a good ecosystem of tooling, libraries and binding

The eco system was nonexisting when Rust gained momentum and attention. That attention was 100% driven by safe system programming. Btw, the same was true for Go initially, they later had to admit that they did not offer a proper solution for systems programming...

>

Just like people did webdev with Python not because Python is great for webdev, but because it's good enough and easy to get started.

Python is excellent for web dev. Never found anything that can touch it in that domain (assuming cloud).

>

Sure, we can switch the language from garbage collection to manual memory management or reference counting. Will it change much? I doubt it, the people complaining about GC would just complain about RC.

Without ARC, probably.

>

We don't have dozens of paid developers working on D full time. We have to manage with the resources we have, and spreading them thin over the language is not the optimal usage of such resources.

That's true, the best solution is to reduce the feature set and improve metaprogramming, but nobody wants to see features removed and new features are being cheered on, so D is and is likely to stay a growing language experiment, which is perfectly ok by me as a D hobbyist
... It is what the process is making it to be, which is more one of growth than metamorphosis.

But lets not extrapolate too much from other languages, most of them follow a different process and are driven by other ideas and ideologies.

May 17, 2021

On Monday, 17 May 2021 at 20:06:05 UTC, Ola Fosheim Grostad wrote:

>

That's true, the best solution is to reduce the feature set and improve metaprogramming, but nobody wants to see features removed and new features are being cheered on, so D is and is likely to stay a growing language experiment, which is perfectly ok by me as a D hobbyist
... It is what the process is making it to be, which is more one of growth than metamorphosis.

"replace features with metaprogramming" comes with a cost. When templates break, the error messages are rough enough already. Also, compilation time will go up as the templates get expanded over and over.

Also, high risk of "curse of Lisp" kicking in.

May 17, 2021

On Monday, 17 May 2021 at 22:39:51 UTC, JN wrote:

>

On Monday, 17 May 2021 at 20:06:05 UTC, Ola Fosheim Grostad wrote:
"replace features with metaprogramming" comes with a cost. When templates break, the error messages are rough enough already. Also, compilation time will go up as the templates get expanded over and over.

Error messages is a challenge, but then that would be sn area for impovement. Im sure intersting things could be done with pattern matching.

Caching could fix compilation times.

>

Also, high risk of "curse of Lisp" kicking in.

I dont know, you might say that javascript suffers from it, but it looks like it thrives by it. When you get frameworks that curse becomes an assets. Ive never used Common LISP Music, but Ive heard composers create interesting things with it. When you can create DSLs, you open up new arenas. Kinda like D does for some in scientific computing.

May 18, 2021

The real enemy of the D language is there is too many people misleading.

I kept wondering if they were undercover agents from other languages.

Deliberately, to lead D language astray.

May 18, 2021

On Tuesday, 18 May 2021 at 00:09:19 UTC, zjh wrote:

>

The real enemy of the D language is there is too many people misleading.

I kept wondering if they were undercover agents from other languages.

Deliberately, to lead D language astray.

In a language group, there will be always two groups. No doubt about it. There is no long language which satisfies all.
Question is why D was not considered why GO got successful, is it only the google backing with its money and power or something missing from the language or community. I might be wrong, for D to succeed
it has to be an alternate to rust with safety, option of complete no GC(not by default), easily extensible with C/C++ and easy to read/write. Despite go's disadvantages, people follow hype and will still use it. D should have been where Go is now. I dont think this post will bring a big shift or change in strategy. Anyways good luck to all. Take care.

May 18, 2021

On Tuesday, 18 May 2021 at 00:54:04 UTC, dogman wrote:

+10086.

May 18, 2021

On Tuesday, 18 May 2021 at 00:54:04 UTC, dogman wrote:

>

and easy to read/write. Despite go's disadvantages, people follow hype and will still use it. D should have been where Go is now. I dont think this post will bring a big shift or change in strategy. Anyways good luck to all. Take care.

FWIW, I use Go for tiny web services.

Reasons: polished runtime, focused std lib, limited features, but somewhat consistent, cloud support.