On Monday, 30 September 2019 at 10:14:52 UTC, JN wrote:

>
> I think Kotlin's dependency on Java/JVM is actually a benefit, because they know what worked and didn't work in Java and could work on improving that. Also, they are 100% behind the OOP paradigm, so they can introduce most features that benefit that. For example features like data classes or singleton objects are very useful, even if they are mostly a language syntax sugar for certain design patterns.

Yeah, I agree, Kotlin has done a great job on that. Kotlin has added a lot of nice features to the old Java/JVM world. Data classes are very useful, and it's really easy to use Singletons. My point was, that the authors of Kotlin cannot do whatever they want due to Java/JVM, and still they managed to come up with a sound language.

On Monday, 30 September 2019 at 10:25:56 UTC, nkm1 wrote:
> That seems more like tactical or operational goal to me... What do you think of Haskell's "avoid success at all costs" or Lua's constant breakage?

Haskell is very successful. It completely dominates the niche it was aiming for, a shared language for functional programming researchers. Sure, it lacks some namespace capabilities needed for writing large programs, but that is not needed for research...

I am not particularly fond of Lua, but I am not sure that breakage is a problem for an embedded scripting language as you can just stay with a particular version and even fork the language with low cost. You don't need to focus on interop outside your own application.
Lua and Python are the two dominating contenders in that niche (embedded scripting engines).

On Monday, 30 September 2019 at 10:13:13 UTC, Ola Fosheim Grøstad wrote:
> It won't happen, and it would only succeed if you focus on a carefully selected set of use cases. Which basically has been D's main problem since D2. D1 had the advantage of being a simple upcoming alternative to C++, which at that point was a niche with no contenders.

D1 wasn't simple, but it had a good set of features. It was a language that felt like C#, yet was native and had pointers. Like the best of two worlds of unmanaged and managed. And compared to C++ it looked amazing.

> Go is a very good example of this. They kept the language small. And the "owner" Google decided that it was primarily good for writing web services and put a lot of resources into the runtime, not the language.  The Go language is not a lot better for writing web services than other languages. The runtime and ecosystem in combination with the basic language is what makes it a strong contender in that space.

And yet people now use it for other things they'd use C/C++ for, because the language and ecosystem is good enough.

> TypeScript, same story.

Good timing and easy transition story. Most people were frustrated with Javascript for a long time and the ECMAScript committee took ages to add new features such as classes, which people were asking from.

On Monday, 30 September 2019 at 10:47:14 UTC, JN wrote:
> D1 wasn't simple, but it had a good set of features. It was a language that felt like C#, yet was native and had pointers. Like the best of two worlds of unmanaged and managed. And compared to C++ it looked amazing.

I meant that it was simple compared to C++ and D2. D1 was clearly more complex than Pascal! More importantly, one could prototype things faster in D1 than in C++98, which made it a promising newcomer.

Although, I gave up on the first releases of D1 for pragmatic reasons: compiler quality, error messages, code gen, underperforming GC, no real alternative to the GC that improves on C memory management.

Yet, at that point that could be seen as baby-illnesses and developers would come back every once in a while to see if D1 was maturing. Unfortunately, the key issues with D1 wasn't fixed and new features was added instead of making the foundation really solid before adding more features.  As a result D2 become more like C++, without being compatible and still having the baby-illnesses.

I personally think that the D1 feature set was good enough for embedded and simple audio/graphics programming if the rest had been polished thoroughly. There was a lot of enthusiasm for D1 that you don't see for D2, IMHO.

> And yet people now use it for other things they'd use C/C++ for, because the language and ecosystem is good enough.

Yes, but only because hardware has more speed/memory today than when those programs were written in C/C++. So, this is what has been going on for the past 50 years. Code that was written in machine language could be implemented in C, then in Java, then in Python or TypeScript. Some software go from C to Go as well, true, but mostly because that software didn't really require the C feature set.


>> TypeScript, same story.
>
> Good timing and easy transition story. Most people were frustrated with Javascript for a long time and the ECMAScript committee took ages to add new features such as classes, which people were asking from.

Right, so I guess we have these "parasitic" transitions for both C++, Kotlin and TypeScript.

On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
> On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
>> D is theoretically in a good position to do a spring cleaning. But then again, I fear this will never happen.
>
> But the big one is @nogc and all its associated machinery. This is the killer, the biggest source of all the mess. And getting rid of that is not going to happen. Instead you'll see more and more stuff designed to support @nogc. Complaining about it is useless. So I personally don't complain, even though I disapprove of this course and consider it the only real strategic mistake in D.
> This is, of course, assuming that maximising the number of users is the strategic goal. OTOH, all these "f... off, don't whine, do it yourself" on the forum suggest that it's not actually such an important goal. As Adam Ruppe mentioned, more users, more problems. Which is fair enough, so indeed why whine? It just annoys people and provokes trolling.

I though this thread was about Nim. Nim hit 1.0 which I think is great because we need alternative systems languages. Instead this thread becomes some kind of panic for the D community because Nim advances and many think D doesn't.

The whining is good because it shows that people use the language. What I think is obvious is that many posts seems to complain about the something undefined or that D hasn't become more popular in general. It would be easier if you were more specific about the the deficiencies of D.

A lot of negativism while C++ is committing harakiri. One obvious future of D is services inside Linux embedded systems. Recently I was working on a project with web client SW inside a Linux system. The project used C++17 and the code was horrible (also from an aesthetic point of view which cannot be solved), unmaintainable with concurrency bugs waiting to happen. Also C++17 doesn't come with any obvious libraries for this so you have to hunt these down too with licenses that fits and these libraries are often horrible.

I did a small test and wrote a portion of the the service in D and the difference was astonishing. First D offers more and better libraries out of the box and addition to that D has Vibe. The code became much more readable and consistent. Memory leakages are gone because of GC (don't hate GC, it is great for most use cases).

Some language is going to take that place from C++ and it could several and D is placed in a pretty good spot here. Nim terms of libraries Nim is also a C++ replacement for these kind of use cases, however what I've seen is that the libraries/interfaces are more immature. Rust is the most competitive contender but as complicated Rust can be D can really be an option here. Most companies want a solution quickly and with good quality and D could provide this fast path. For my next project, I will suggest using D instead for those kinds of services.

I don't mind GC that much but removing GC from Phobos isn't bad either so the priority is not that high for me. Could someone please explain why @nogc is a priority. What I think is one high priority is to get reference counted GC in D because that opens up D for the performance crowd who do not want stop the world GC.

Look at the possibilities instead.

On Monday, 30 September 2019 at 10:14:52 UTC, JN wrote:
> On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
>> Atm, I'm mainly using Kotlin and I have to say that a small set of clever and well thought-out features can get you a long way. Do I miss some of D's features? Not really, because Kotlin provides enough useful and battle-tested features that you need 90% of the time [1]. Once I missed `static if`, but I could live without it.
>>
>> Mind you, Kotlin has some restrictions due to the fact that it has to be a 100% compatible with Java/JVM. But even when you use Kotlin/Native (without the Java universe, i.e. modules and libraries) you can get quite far. I think D should aim at that.
>>
>
> I think Kotlin's dependency on Java/JVM is actually a benefit, because they know what worked and didn't work in Java and could work on improving that. Also, they are 100% behind the OOP paradigm, so they can introduce most features that benefit that. For example features like data classes or singleton objects are very useful, even if they are mostly a language syntax sugar for certain design patterns.

If Kotlin wants to stay relevant on the Java/JVM platform (Android is another matter), they cannot come up with incompatible designs that force FFI jumps between platform semantics and whatever they come up with in Kotlin land.

Some examples of these impedance mistmatch are already visible, namely memory semantics between Kotlin/JVM and Kotlin/Native, sequences vs JVM streams, Kotlin lambdas vs JVM SAM types.

Same applies to whatever reboot might happen with D.

On Monday, 30 September 2019 at 11:05:58 UTC, IGotD- wrote:
> A lot of negativism while C++ is committing harakiri. One obvious future of D is services inside Linux embedded systems.

That is certainly an option, you might be able build a community around the Linux embedded niche.

> Vibe. The code became much more readable and consistent. Memory leakages are gone because of GC (don't hate GC, it is great for most use cases).

But you can not rely on GC on small embedded systems. Even allocators that doesn't combat fragmentation is a relevant issue.

So if embedded is a target niche then such runtime features must be addressed.

If not, why would a project manager pick D over Go (beyond syntax preferences)?


> libraries/interfaces are more immature. Rust is the most competitive contender but as complicated Rust can be D can really be an option here.

But D does not provide the same memory management capabilities of Rust. Rust would be the stronger contender if GC isn't an option, and in that case D does not have a comparable memory management solution.


> What I think is one high priority is to get reference counted GC in D because that opens up D for the performance crowd who do not want stop the world GC.

Well, ref counting is too slow for the performance crowd, but it is better for predictable execution and limited memory usage than a GC. Which in some embedded contexts might be sufficient.

If embedded is the main target niche then you would want clean and flexible features related to stack allocation and automatic proving upper bounds on stack size. Such features could make any reasonable language a strong contender in this niche.

Being generic isn't sufficient to be a strong contender in specialized niches.

On Sunday, 29 September 2019 at 01:29:59 UTC, Benjiro wrote:
> On Friday, 27 September 2019 at 15:11:26 UTC, GreatSam4sure wrote:
>> The biggest problem to D adoption is this community IMHO. Almost everything here is negative. The community is 95% negative to the language. There are people here that never see anything good about D yet they are here. The community is damaging to D image.
>>
>> It is a community that is out to destroy the language. All the hope of me using D has been almost destroyed.
>
> As one of these negative people that from time to time reads up on multiple languages forums.
>
> D was one of the first languages after moving away from Web dev, that i liked from structure point. Even got the book from Ali.
>
> But ... the more i worked with it, the more frustration, upon frustration, upon ... kept creeping in with constant issues.
>
> * Not user friendly tooling ( somewhat improved, took only a few years )
>
> * Compiler bugs. O those bugs ...
>
> * Upgrading the compiler resulting in packages ( like vibe.d going broke )
>
> * Lacking IDE support ( somewhat improved on Visual Studio Code )
>
> * Lacking in packages to easily get going.
>
> * Constant and frustrating changing direction. BetterC? First get BetterD doing and when your a big boy, then do this.
>
> * The feeling off being looked down when suggestion that D is not user friendly. Especially in the past you constantly got this as a answer: "you have a issue, fix it yourself". Yes, this was the constant answer from everybody.
>
> * The snarky and frankly poison comments from regular members. Some of those now seem to have left but D really has some members that got under anybody their skin for daring to mention a issue.
>
> * Focus upon C++ crowd, when very few C++ developers have any interest in D. Hell, if a C++ developer wants to switch, they have better alternatives with bigger or better growing communities.
>
> * A leadership that seems to be stuck in the 1990's mentality. The world has moved on, people expect more these days, they have choices most old timers did not have. So they are more spoiled with those choices and are not going to put in the time. But when you ignore those "spoiled" people, you never build up a loyal base and you will never motivate them to help out with code or money.
>
> You can not run anything worth while with D unless you plan on spending a lot of time writing supporting code yourself. Some companies have no issue with this but little old me can not be bothered with it, when there are plenty of good alternatives that get the job done as good.
>
> * I know one of the posters on this forum a bit more personal. We have had some discussions about the different compilers. Just as he used Go for his personal project, i used Crystal for mine. We both found D too much trouble for the advantages it gave.
>
> Its a vicious circle and i know it.
>
> Lack in people / contributors => No Packaging / Bugs / Issues => New people scared away => Lack in people / contributors ....
>
> * D just is not sexy. I know D now from 10/2016 ( when i got Ali's book. Programming in D ). Loved the book and language syntax ( especially if you come from PHP ) but it was all the rest that ruined it for me. And over the years D seems to have been going down a direction that i hated. New features that had no meaning for me, code breaking issues and resources being put in features like BetterC, when all i wanted was a god darn simple HTTP server that worked and kept working on release updates. And more active packages.
>
> * On the subject of Programming in D, i noticed a lot of books are old. BetterC, the feature where a lot of resources have gone into, seems to be ignored in every book on the market.
>
> ------------------------------
>
> To give you a nice example how much of a irritation D can be even today. Just right now, i tried to install D on Ubuntu because i want to time the current D compile speed, vs a few other languages. And i am following the official order ( https://dlang.org/download.html ):
>
> 1. sudo wget http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O /etc/apt/sources.list.d/d-apt.list
> 2. sudo apt-get update && sudo apt-get -y --allow-unauthenticated install --reinstall d-apt-keyring
> 3. sudo apt-get update && sudo apt-get install dmd-compiler dub
>
> Guess what happens on Step 2.
>
>> Err:7 https://netcologne.dl.sourceforge.net/project/d-apt d-apt InRelease
>   The following signatures couldn't be verified because the public key is not available:  NO_PUBKEY EBCF975E5BA24D5E
>
> And this issue was posted a LONG time ago.
>
> Yep ... Now try Go, Crystal, Nim, Rust, ... and a lot of other languages. I have installed all those dozens of times and a issue like simply do not show up or are fixed so fast, that it never hits "me". But whenever it involves D, its always one thing or another.
>
> ------------------------------
>
> Hopefully this explains things from my point of view, where D simply fails me personally. Its late so i am off to bed.


I can reckon with you in your paid and frustration. It is real. My personal frustration with D is that the language is too good to be where it is today. To me D is the best language I ever known of.I am not in any way ignorant of the languages out there.

D packages don't work out of the box. They throw errors here and there. The tooling sets is also weak and little tutorial. Many aspects of D are known to only a few. But the Languages is truly elegant. I also see the leaders have not been able to work with the community coherently. There is too much dichotomy in the forum. Some people have even decided to keep quiet and just observed the trends of things. I really did not blame them. Some have left, like the android guy.


It is time to change our attitudes and begin to look for the way forward. Negativity is obviously not the solution. Insult and yelling are out of point. Ways is the way forward a change of philosophy and mindset. A critical examination of why we are the way we are, like a survey that will be back by implementations. Working coherently together as against working individually.

I think we need the humility of heart and humbleness of mind to accept that where we are today is far behind. We are behind not much of a cooperate sponsor but of our own making. Harmony is the first step to grow in a community. The division is one major cause of our backwardness and lack of fast progress. We much realize what is against us and correct to move to our desired level.

I am willing to help in any capacity I can but I don't know how since my programming skill is still low. I need to grow more.

If all D packages can work out of the box, the compiler can minimize breakages and the community can unity D will become the best language in the world.

Looking forward to a better D.

On Monday, 30 September 2019 at 11:40:01 UTC, Ola Fosheim Grøstad wrote:
>
> But you can not rely on GC on small embedded systems. Even allocators that doesn't combat fragmentation is a relevant issue.
>
> So if embedded is a target niche then such runtime features must be addressed.
>
> If not, why would a project manager pick D over Go (beyond syntax preferences)?
>

Bare metal or small embedded systems with a limited OS you cannot often use the standard library anyway. That's often the case with C as well unless you port the clib standard calls which is unusual. Often you have to work with proprietary APIs anyway.

For OS agnostic D libraries it makes sense to remove any GC support but for OS related libraries it doesn't matter much as you almost always have some custom API.

Go is probably one of the worst choices for bare metal as it relies on a runtime. D has betterC which makes it more suitable for bare metal. Right now I think betterC is a bit limited and I would actually like to see this part expanded, like full class support for example.

On Monday, 30 September 2019 at 12:25:46 UTC, GreatSam4sure wrote:
> There is too much dichotomy in the forum. Some people have even decided to keep quiet and just observed the trends of things. I really
> did not blame them. Some have left, like the android guy.

To be clear, the "Android Guy", AKA Joakim, left due to having (one or more, can't remember) over-the-line posts deleted. It was a personal problem on his part, not any kind of problem with the D community (which is by no means perfect, obviously).

A better example is Kenji Hara.

> It is time to change our attitudes and begin to look for the way forward. Negativity is obviously not the solution. Insult and yelling are out of point. Ways is the way forward a change of philosophy and mindset. A critical examination of why we are the way we are, like a survey that will be back by implementations. Working coherently together as against working individually.
>
> I think we need the humility of heart and humbleness of mind to accept that where we are today is far behind. We are behind not much of a cooperate sponsor but of our own making. Harmony is the first step to grow in a community. The division is one major cause of our backwardness and lack of fast progress. We much realize what is against us and correct to move to our desired level.

I don't agree that D is "way behind", but its velocity is certainly slower than Go/Rust/C++. I think this comes down to money=acceleration. However, if you look at what's happened even in just the past 7 years, D has "accelerated" dramatically - a yearly conference, real companies successfully using D and even contributing back to D's development, a far more stable compiler and standard library, a thriving package ecosystem... to quote Andrei, it's an "embarassment of riches".