November 08, 2021
On Sunday, 7 November 2021 at 06:36:48 UTC, arco wrote:
> Many people have forgotten it now but at one point, Rust had classes with inheritance as well as a GC. It was concluded that those features didn't belong in a systems language and were removed. This is probably Rust's greatest strength over D: its consistency, the follow through to ensure that features that are declared stable are really rock solid and make sense within the language's general philosophy.
I agree.

Go still doesn't even have generics in stable and
> it hasn't slowed down its adoption.
I have noticed Go adoption has slowed down a lot. I wanted to love Go... but it was too slow to get anything done besides a hello world type program. Since you said this, I decided to double check and the tiobe index seems to agree, as does google trends. I think Go's decline in popularity is an example of all the problems D doesn't have. It's mild success includes all the things D lacks: standard tools, corporate backing, tutorials, etc..

> Regarding Python, its biggest advantage (other than its outstanding ecosystem) is that it's a dynamic language. Prototyping, testing, customising etc will always be easier and more flexible in Python than in any compiled language. Plus its conscious focus on a simple syntax makes it in my opinion the modern day heir to the BASIC of the 80s in terms of universal applicability and a kind of immediacy.

I agree that that is the appeal of python. It's dynamic but also has languages. What other languages is like that? Javascript is kind of like that, but it's such a horrible language anyway.

> D's general approach has been to always try to have its cake and eat it too. It wants a GC but at the same time wants to pretend that it doesn't need a GC, it wants to support OOP (with inheritance etc) and at the same time tries to downplay it, etc. Ultimately in each of these cases it fails to provide the advantages of either of the valid choices while retaining the disadvantages of both.

I have experienced this phenomenon a lot in my career, but I think D is pretty good at having more than one way of doing things. I like not having to have classes, but I like having them available. The way I feel about frameworks is how I feel about languages like python. You have to do it their way even though you know a better way. With D, I do feel like . This is one of it's strongest advantages. If I want to do string handling in a pointer-based way, I can! If I want to use normal methods, the language supports that. Arrays are a great example. You get most of, if not all of, the power of a list in another language, but you get all the power of arrays. I'd like to see an example that shows you get the worst of both! I have relied on that heavily this weekend.


> This is a hard lesson that D desperately doesn't want to learn. By trying to appease everyone it ultimately doesn't win for anyone in particular.

Although I agree with pretty much everything you have written, I think that is one of D's strengths. That was reiterated this weekend. I got a call for a job and they said the next interview would be on codesignal.com. I did about 100 practice problems and I found myself reaching for D a lot. There were some problems where I pretty much had to go to C# if I wanted to do it in 5 minutes (most things Linq related or string related. I don't know what D's equivalents are.)

I don't think D needs to stick to one way to do everything. I think Python is popular almost in spite of that because it's easy to start and it has good libraries. You get that constant success metric where you write something and it works right away and you tweak it and get little wins along the way. D is similar except for some safety stuff that I have ideas about (immutable, const, etc.)

There are two effects I see where being opinionated is VERY helpful - maybe essential - to a language.
1. Documentation and tutorials
Tutorials need to be opinionated. People need to see ONE way to do things when they learn. Once they understand, they can take advantage of all the different ways, but they need to see a path to success.
2. Whatever you expect people to do with the language, it needs to be designed so there is at LEAST one way to do the above things that is elegant. For example, web servers usually allow some kind of annotation-based routing system. If you use Jetty and you do your own routing, that is fairly confusing and time-consuming. That is something where the annotation-based method is a simple solution and allows you to not have to discuss much about routing and that part of the framework to a new user. It allows you to streamline. However, for Jetty (and technically others), you don't HAVE to do it that way. It's just the default way. Someone once said something like allow endless configuration but provide sensible defaults. That's what the D language is good at.

I would like to read your response to this.


 Then they can take advantage of the rest. It needs to provide a vision when teaching. I don't think the language needs to be opinionated, but the tutorials need to be. Also, they need to have a succe
November 08, 2021
On Sunday, 7 November 2021 at 06:36:48 UTC, arco wrote:
> Many people have forgotten it now but at one point, Rust had classes with inheritance as well as a GC. It was concluded that those features didn't belong in a systems language and were removed. This is probably Rust's greatest strength over D: its consistency, the follow through to ensure that features that are declared stable are really rock solid and make sense within the language's general philosophy.

I agree.

> Go still doesn't even have generics in stable and it hasn't slowed down its adoption.

I have noticed Go adoption has slowed down a lot. I wanted to love Go... but it was too slow to get anything done besides a hello world type program. Since you said this, I decided to double check and the tiobe index seems to agree, as does google trends. I think Go's decline in popularity is an example of all the problems D doesn't have. It's mild success includes all the things D lacks: standard tools, corporate backing, tutorials, etc. Maybe not libraries.

> Regarding Python, its biggest advantage (other than its outstanding ecosystem) is that it's a dynamic language. Prototyping, testing, customising etc will always be easier and more flexible in Python than in any compiled language. Plus its conscious focus on a simple syntax makes it in my opinion the modern day heir to the BASIC of the 80s in terms of universal applicability and a kind of immediacy.

I agree that that is the appeal of python. It's dynamic but also has libraries. What other language is like that? Javascript is kind of like that, but it's such a horrible language in comparison (I think).

> D's general approach has been to always try to have its cake and eat it too. It wants a GC but at the same time wants to pretend that it doesn't need a GC, it wants to support OOP (with inheritance etc) and at the same time tries to downplay it, etc. Ultimately in each of these cases it fails to provide the advantages of either of the valid choices while retaining the disadvantages of both.

I have experienced this phenomenon a lot in my career, but I think D is pretty good at having more than one way of doing things. I like not having to have classes, but I like having them available. The way I feel about frameworks is how I feel about languages like python. You have to do it their way even though you know a better way. With D, I feel like a library. I can use it's features if I want and not if I don't. This is one of it's strongest advantages. If I want to do string handling in a pointer-based way, I can! If I want to use normal methods, the language supports that. Arrays are a great example. You get most of, if not all of, the power of a list in another language, but you get all the power of arrays. I'd like to see an example that shows you get the worst of both! I have relied on that heavily this weekend.

> This is a hard lesson that D desperately doesn't want to learn. By trying to appease everyone it ultimately doesn't win for anyone in particular.

Although I agree with pretty much everything you have written, I think that is one of D's strengths. That was reiterated this weekend. I got a call for a job and they said the next interview would be on codesignal.com. I did about 100 practice problems and I found myself reaching for D a lot. There were some problems where I pretty much had to go to C# if I wanted to do it in under 5 minutes (most things Linq related or string related. I don't know what D's equivalents are.)

I don't think D needs to stick to one way to do everything. I think Python is popular almost in spite of it's one-way-only philosophy because it's easy to start and it has good libraries. (Although being easy to get started is probably helped by the one-way-only philosophy for reasons I get to below.) You get that constant success feedback where you write something and it works right away. Then you tweak it and get little wins along the way. D is similar except for some safety stuff that I have ideas about (immutable, const, etc.)

There are two effects I see where being opinionated is VERY helpful - maybe essential - to a language.
1. Documentation and tutorials
Tutorials need to be opinionated. People need to see ONE way to do things when they learn. Once they understand, they can take advantage of all the different ways, but they need to see a path to success.
2. Whatever you expect people to do with the language, it needs to be designed so there is at LEAST one way to do the above things that is elegant. For example, web servers usually allow some kind of annotation-based routing system. If you use Jetty and you do your own routing, that is fairly confusing and time-consuming. That is something where the annotation-based method is a simple solution and allows you to not have to discuss much about routing and that part of the framework to a new user. It allows you to streamline. However, for Jetty (and technically others), you don't HAVE to do it that way. It's just the default way. Someone once said something like allow endless configuration but provide sensible defaults. That's what the D language is good at.

I would like to read your response to this.

I hit send instead of save and preview on the previous post. If someone can delete it, please do.
November 08, 2021

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

>

It got asked on reddit sub but for those that aren't active too, I'd like you opinions. Please don't get me wrong, I also love D, I've used it everywhere I can and I'd say it's my favourite language (yes I have one...) but I'm as as the reddit's OP, trying to understand why it's unpopular. Rust and Go seeming to be getting more and more users. I think it's due to large ecosystem and the big corporations with deep pockets that pushes them. But I'd like to know you all opinions

First of all I will separate the language itself from the standard library.

One of the big mistakes - in my opinion - was the involvement of language maintainers in the standard library design which is a very different animal. Language maintainers must provide the minimal blocks in the standard library and let the crowd design the rest of content as they consider. This will allow, for example, the gc crowd to abuse the garbage collector if they want so, but also the !gc crowd to get rid of it. The future will prove if D really needs a garbage collector or not. The language maintainers need just to publish some rules and that's all.

Third party users want to get the job done. Let's do a web server. Let's connect to a database. Let's spawn some window on the screen. What they get instead? 12 sorting methods in std.algorithm. Personally, I really like the arsd libs more than any mambo-jambo written across phobos. If you ask me, I would grant Adam the official position of standard library designer.

Probably you will say that's ok, the crowd is free to design their libraries, just push it on code.dlang.org. In reality this is a graveyard (or the morgue, if we count std.experimental as the graveyard). Why projects are dead, simply because they are not officially blessed by the language maintainers and not included in the standard library.

To reinforce what I said, I will bring on the table the unwanted subject of Tango (yes, you can lie yourself that it was not the official library, but the reality is that it was de facto standard library). When the library design was let in the hands of the crowd, the content exceeded any expectation and consequentely D's popularity flourished, despite the fact that there was only one way to sort things (and by default a correct one, string collation was built-in). Phobos is still struggling after 15 years to match some Tango features.

Now, having the library designed by the crowd, it will put pressure to language maintainers to update D to cope with the library requirements. If ranges are the first class citizens, let's get them some syntactic sugar. If the gc is worthless, let's get rid of it. And so on.

Language maintainers became lazy. Instead of improving the language, it's easy to outsource everything to a library. D was nice and innovative 15 years ago, now it's struggling to keep the pace with new languages by patching missing features with libraries. You want resource counting, here you have 15 libraries to choose from. You want tagged unions, here I give you Algebraic. Wait, let's deprecate this, sumtype sounds better. Tuples, Nullable, Optional? I have another 10 brand new libraries for you. Dependency injection, serializing? Too advanced to be included in the language, here you have another 5 libraries.... Even old languages like C++ embraced new features;

To sum things up, why D became unpopular:

  • because the standard library does not match users' expectations;
  • because the language didn't evolve in the last 13 years;
November 08, 2021
On Monday, 8 November 2021 at 05:20:43 UTC, harakim wrote:


> I have experienced this phenomenon a lot in my career, but I think D is pretty good at having more than one way of doing things. I like not having to have classes, but I like having them available. The way I feel about frameworks is how I feel about languages like python. You have to do it their way even though you know a better way. With D, I feel like a library. I can use it's features if I want and not if I don't. This is one of it's strongest advantages. If I want to do string handling in a pointer-based way, I can! If I want to use normal methods, the language supports that. Arrays are a great example. You get most of, if not all of, the power of a list in another language, but you get all the power of arrays. I'd like to see an example that shows you get the worst of both! I have relied on that heavily this weekend.

This is great if you are an enthusiast who implements stuff this week-end. In large scale projects you unavoidably end up in the situation where you are convinced you know a better solution, and so does your colleague, and another colleague etc. Of course, each of you has a different solution and you all "know" that yours is the best. The bicycle sched fallacy is always lurking at every corner with this type of approach.

The examples to support my point are plenty. The GC to begin with. D relies on a GC so it's not really usable as a systems language. At the same time, since it doesn't want to fully commit to the GC and wear it with pride, it has a mediocre one and is not a good choice for projects where I feel that a GC-based language is the way to go. Developers are permanently wondering what kind of memory management they should use, because they can't see a clear picture or consensus and whichever decision they make, it will unavoidably clash with other parts of the ecosystem or even the same codebase.

Similarly you may want to handle your strings as pointers like in C, but Joe's output library expects std.string. What now? As a result, the developer spends time dealing with trivial issues like that instead on focusing on solving the actual problem.

It just keeps coming back to the same issue: the point of software development is not to have fun with the language or be "creative" with it, it's to provide a solution to a problem that other people will be able to use with as little friction as possible.

> Although I agree with pretty much everything you have written, I think that is one of D's strengths. That was reiterated this weekend. I got a call for a job and they said the next interview would be on codesignal.com. I did about 100 practice problems and I found myself reaching for D a lot. There were some problems where I pretty much had to go to C# if I wanted to do it in under 5 minutes (most things Linq related or string related. I don't know what D's equivalents are.)

You know D, you like D so it's natural that you would often reach for D to solve a problem. But the point of this thread is not that people who appreciate D can use it to do things, it's why the other people are not showing more interest in D.

>
> I don't think D needs to stick to one way to do everything. I think Python is popular almost in spite of it's one-way-only philosophy because it's easy to start and it has good libraries. (Although being easy to get started is probably helped by the one-way-only philosophy for reasons I get to below.) You get that constant success feedback where you write something and it works right away. Then you tweak it and get little wins along the way. D is similar except for some safety stuff that I have ideas about (immutable, const, etc.)

I think the fact that Python lives by its "one true way only" philosophy is precisely the reason it is so easy to get started with and has such good libraries. It's easy because tutorials make sense, if you are beginning and face a problem, other people can help you easily, and libraries provide APIs with little or no surprise and for the overwhelming part, they work well together. Perl, in contrast, said "there shall be more than one way to do it". Its ecosystem has always been a huge mess.

Now of course D doesn't need to stick to one way for absolutely everything, otherwise it would be a DSL which is obviously not its purpose. But it should at least have a clear and cogent memory management story (and not "you can do it absolutely every way you want and so can everyone else"). It should have a clear position on strings. Autodecoding was a bad idea and maybe it's now stuck with it, or maybe it's possible to introduce a new string type that doesn't autodecode and keep std.string for legacy code, but there should be The D Way of handling strings (and not "ok and you can also use pointers like in C, and by the way you can have an array of dchars" etc.). It should decide once and for all what its pointer aliasing and coercion rules are and not introduce a new function attribute every week on one hand and rely on hacks like "alias this" on the other. And then there is the tooling. D has dub but it's neither fully mature not universally used, which means that adding a 3rd party dependency to a project is much more of a chore than it needs to be (and should be).

>
> There are two effects I see where being opinionated is VERY helpful - maybe essential - to a language.
> 1. Documentation and tutorials
> Tutorials need to be opinionated. People need to see ONE way to do things when they learn. Once they understand, they can take advantage of all the different ways, but they need to see a path to success.
> 2. Whatever you expect people to do with the language, it needs to be designed so there is at LEAST one way to do the above things that is elegant. For example, web servers usually allow some kind of annotation-based routing system. If you use Jetty and you do your own routing, that is fairly confusing and time-consuming. That is something where the annotation-based method is a simple solution and allows you to not have to discuss much about routing and that part of the framework to a new user. It allows you to streamline. However, for Jetty (and technically others), you don't HAVE to do it that way. It's just the default way. Someone once said something like allow endless configuration but provide sensible defaults. That's what the D language is good at.
>
> I would like to read your response to this.

I've never personally used Jetty and admittedly web application development is not one of my areas of interest or expertise so I can't comment on that. On a more general level though, the notion of what is "elegant" is subjective. There should be at least one way that is idiomatic, well supported and proven to work for the proverbial 99% of the common cases. And if there is more than one way, then they should interoperate as easily as possible.
November 08, 2021

On Monday, 8 November 2021 at 01:36:59 UTC, arco wrote:

>

On Sunday, 7 November 2021 at 09:18:37 UTC, Ola Fosheim Grøstad wrote:
But there are two aspects to this where in my opinion D is currently failing and both are more cultural than technical.

I don't think D is failing, as it does what the creator set out to make it do. That this appeals to a limited audience is not as such a failure. In the context of computer language history, you might argue that some aspects of the semantics and syntax has serious flaws and that the language designers were unwilling or unable to fix them. But failure is not an appropriate word even in that context.

>

The other problem is that D seems deeply allergic to making hard decisions.

Yes, this is also typical for language design processes. It is easier to add new features instead of adjusting what is. You can always say «we a busy adding this new feature that will make all the difference» and thus the focus on streamlining what exists is limited to the most trivial and assert that the price of change is too high.

>

Once again, the two languages somewhat comparable to D that "made it", Go and Rust, are all about enforcing what they deemed to be their way to do things. That doesn't mean it's the only legitimate way, but it means that if you want to do X, this is how you do it in Go (not that there isn't a one true way, but you are free to try to devise 15 different ways).

If there are 15 ways, then there is no real enforcement? I roll my own error-handling using panic. I care more about correctness and maintenance than a slowdown of code paths that are rarely executed. The Go Way does not lead to more correct programs as far as I am concerned.

Most people don't code C++ the way they do at conferences either. That is the power of meta programming too. That is the promise of high powered meta-programming. You can shape the language to the domain.

In fact I think this is a weak spot of D. It should leave more room for shaping the language. This is an area where D should be doing better, but the language designers have put severe constraints on operators that makes it more difficult to create useful types. These constraints are there out of fear of creating a tower of Babel. As such, D has kneecapped what is touted as its strong point. D should also add unicode operators and make it the best language for building frameworks for scientific computing etc.

But there is no strategic thinking or "scientific philosophy", just opinions, that shape the language. As I already have said; too much focus on what other programming languages are doing (replicating) and not enough focus on unused parts of the design space (reinventing/innovation). There should be a balance, but D has not quite found the right mix yet that would set it apart from other languages.

>

And if the Go way doesn't work for you, that's perfectly fine, there are other languages that would be a better fit for your problem. Same for Rust.

Not really. I am only interested in managed autoscaling. So App Engine Standard is my preferred option for now. I have to pick between: Python, Java (JVM), Node.js, PHP, Ruby and Go.

No Rust. No D. No C#. No Swift.

If JVM wasn't more heavy than other options I'd say it is the most attractive one , in addition to Python. But since performance sometimes matter, Go sometimes is the better option. And only because GOOGLE SAYS SO! (they optimize the service for Go?)

This isn't unique. In mobile space you have Swift, Kotlin, Dart, TypeScript, perhaps also C# (but I wouldn't). With a dash of C++. And that is it.

On the browser you have TypeScript and WASM. End of story.

D should not look for areas where there is volume. Too crowded. It should look for areas where metaprogramming could be transformative! The only area where it can be transformative are areas where building your own types has huge impact. Scientific computing, perhaps signal processing, 3D graphics etc…

But to do so it needs to improve on metaprogramming (and memory management). Not because other languages has it, but because metaprogramming is so weak in all languages that very few frameworks make good use of it. Irrespective of language. It is therefore an underutilized language feature (in all languages), but the core D language needs changes so it can blossom. It is great that the standard lib is going to be streamlined, but it won't move the needle as the root cause is in the language.

>

This is a hard lesson that D desperately doesn't want to learn. By trying to appease everyone it ultimately doesn't win for anyone in particular.

Yes, D primarily appeals to those that consider and reject C++ (for various reasons).

>

std::move). I personally dislike C++ with a vengeance, but if you develop in C++, you will never be on your own. Not so with D.

I don't know. Many C++ apps roll their own, all the way. Outside of games C++ applications tend to be very focused and there is limited room for reuse (e.g. a compiler can reuse the LLVM backend, and that is about it).

>

Haskell is a different beast altogether. It's a niche language that knows exactly what it wants to be and especially what it doesn't want.

Yes, it was designed to be an academic language.

When I say Haskell in this context I mean people who use it in production, like for web solutions. You have to be dedicated to use it. People who do use it, say they are less miserable as programmers. I believe them, but they need to put in extra work initially, for sure. And that is not all that different from what professional D users do and say.

>

In several ways. Rust has proper sum types and a "match" statement that guarantees that all cases are covered (plus it has functional semantics). That alone makes it more general and safer than C++. It also has some syntactic sugar (like the ? operator) and the pseudo-monadic methods and_then etc. that together make it basically as easy to use as exceptions.

Ok, so this is the issue I have with Rust. All the points where Rust claims to have a better solution than C++ are areas where I never experience problems with C++! As far as I am concerned Rust is solving the wrong problems. Maybe Rust is better for bigger teams or bigger projects, but I fail to see how it could improve my programs.

If D was streamlined, cleaned up, with better memory management and improved metaprogramming (without the knee-capping), it could provide a better solution than C++ for writing full applications (like games, audio editors and the like).

Unfortunately the language designers have no interest in these application areas, so D is moving in the right direction, but very slowly. Too slow.

>

Using exceptions in multithreaded code is... no comment.

I don't do fine-grained multithreading, so RAII and exceptions covers me well in C++. Rust provides a solution for a problem I am unlikely to have…

>

It seems that those who use Go, Google to begin with, beg to disagree that it's just for tiny applications. As for whether it scales well, its long term evolution and maintenance... how do you think it compares to D as far as hard data and proof of the pudding are concerned?

D isn't stable. Go, Java and C++ are stable. That is a prerequisite for writing anything larger that is meant to last.

But there is no point in going stable until you have gotten the upper hand on semantics and syntax (or have reached critical mass).

>

still alter classes at runtime, reflect etc. It made that design choice and tries to offer developers all the benefits that go with it. And where it's not suitable, then you simply don't use Python.

Yes, I use Python whenever I can because it is cheaper (less time). But I would have preferred as stronger static type system. I rarely use dynamic features.

>

It needn't be improbable. Kotlin was born as a third party project, like D but smaller. Google saw its benefit for Android development and embraced it wholeheartedly. It could have been D instead (and IMO it would make a nicer Android language than Kotlin). Making D target the JVM shouldn't have been a big problem. What was and still missing is consistency, well

This is apples and oranges. I am pretty sure that Google didn't pick "Kotlin" in isolation, but that they picked JetBrain's Kotlin + JetBrain's IDE. Clearly a strategic partnership that benefits all.

D could not have been Google's choice for the JVM. That is improbable. Quite a few years back Mosync did quite well in providing a cross platform C++ solution (also for JVM), but it failed in the market. Google could have picked them up, if this is what they wanted.

There is no point in dreaming about what is improbable. D could not have been on Google's table for Android. To get there D would have had to be a completely different language.

November 08, 2021

On Monday, 8 November 2021 at 08:07:54 UTC, rumbu wrote:

>

One of the big mistakes - in my opinion - was the involvement of language maintainers in the standard library design which is a very different animal. Language maintainers must provide the minimal blocks in the standard library and let the crowd design the rest of content as they consider. This will allow, for example, the gc crowd to abuse the garbage collector if they want so, but also the !gc crowd to get rid of it. The future will prove if D really needs a garbage collector or not. The language maintainers need just to publish some rules and that's all.

Yes, I think this is correct. I never understand why people claim that Tango was a big issue. I was only interested in low level programming and did not use Tango, it was too high level for me, but I never saw it as a limiting factor.

I was more interested in using C libraries than D libraries.

>

Probably you will say that's ok, the crowd is free to design their libraries, just push it on code.dlang.org. In reality this is a graveyard (or the morgue, if we count std.experimental as the graveyard). Why projects are dead, simply because they are not officially blessed by the language maintainers and not included in the standard library.

I think the idea was to replicate the success of Python, but in Python speed does not matter, it is all about convenience and stability. So that is essentially not possible for D where people have very different requirements (in comparison to Python). Also, developing a standard library like Python has takes a lot of time and effort, and you need critical mass to do it (or financial backing).

>
  • because the language didn't evolve in the last 13 years;

Yes, it is growing, but not really evolving.

November 08, 2021

On Monday, 8 November 2021 at 10:57:37 UTC, Ola Fosheim Grøstad wrote:

>

Yes, I think this is correct. I never understand why people claim that Tango was a big issue. I was only interested in low level programming and did not use Tango, it was too high level for me, but I never saw it as a limiting factor.

For the record, it is of course a requirement that all frameworks build on top of the same foundational runtime.

So, you can have a core standard library without a GC runtime, and on top of it have an expanded (compatible) runtime with GC.

So you need cooperation on runtime-profiles in addition to having a small focused core standard library.

November 08, 2021

On Monday, 8 November 2021 at 08:07:54 UTC, rumbu wrote:

>

...

To reinforce what I said, I will bring on the table the unwanted subject of Tango (yes, you can lie yourself that it was not the official library, but the reality is that it was de facto standard library). When the library design was let in the hands of the crowd, the content exceeded any expectation and consequentely D's popularity flourished, despite the fact that there was only one way to sort things (and by default a correct one, string collation was built-in). Phobos is still struggling after 15 years to match some Tango features.

Phobos is absolutely "template" oriented: this is a hard decision that, may be, is good for some developers/projects but absolutely bad for others: templates (and mixins, and...) are hard to integrate with debugging/inspecting and intelligence tooling.

Tango was a more standard library from the point of view of how an standard library is (Using the "generic type" way instead "template all").

It is difficult for a team accustomed to the speed of working with other statically typed languages well integrated with VSCode/IntelliJ (java, kotlin, c#, typescript) to change the "way of".

  • If I can't inspect objects and its properties recursively as easy as I can with Java then I really can't debug code.

  • If I can't identify easily a variable type (As a class or interface or whatever) and I need to answer the compiler what "this strange thing" is... then language doesn't describe 100% the model with it's own words: sometimes I wonder if the D team thinks in terms of language or only in terms of compiler.

In my opinion... a "template all" library is an option for some developments, but forcing everybody to work this way is an stopper not only for developers: for D language itself.

The facto, Phobos is what actually defines the D language: Phobos is killing D.

>

Now, having the library designed by the crowd, it will put pressure to language maintainers to update D to cope with the library requirements. If ranges are the first class citizens, let's get them some syntactic sugar. If the gc is worthless, let's get rid of it. And so on.

Absolutely

>

Language maintainers became lazy. Instead of improving the language, it's easy to outsource everything to a library. D was nice and innovative 15 years ago, now it's struggling to keep the pace with new languages by patching missing features with libraries. You want resource counting, here you have 15 libraries to choose from. You want tagged unions, here I give you Algebraic. Wait, let's deprecate this, sumtype sounds better. Tuples, Nullable, Optional? I have another 10 brand new libraries for you. Dependency injection, serializing? Too advanced to be included in the language, here you have another 5 libraries.... Even old languages like C++ embraced new features;

I agree. Optional/Some/None (remove Nullable ASAP) and Pattern matching will be a great adquisition, Union types would be appreciated, powerful type inference (i.e. with Voldemort types): if Typescript can effort some of this features, why not D?

>

To sum things up, why D became unpopular:

  • because the standard library does not match users' expectations;

And doesn't fit developers "normalized" tooling way of working

>
  • because the language didn't evolve in the last 13 years;

Good point.

November 08, 2021

On Sunday, 7 November 2021 at 12:37:44 UTC, zjh wrote:

>

There is a great need for articles for D.

Phobos's idea is wrong in force. It forces you to use GC, forces you to use utf8, and forces you to use auto decoding...
Coercion is not a good thing. Users should be provided with options.
GC is what really hurt d. Why Rust not use GC?
For system language, GC is garbage.

November 08, 2021

On Monday, 8 November 2021 at 12:43:05 UTC, zjh wrote:

>

Phobos's

But metaprogramming is definitely a bonus.
Look at the newly languages. Which one has no generics?