On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
> You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF generation tool last updated 3 years go.
>

While not as trivial as just using a dub package, D easy interop with C means you can use C libraries for PDF like libharu or w/e.

> * Are you targeting C developers?
>
> Sure BetterC is a way towards that but again, what do you offer more then Rust? I see C developers more going for Rust then D on this point. Or hell even Zig or Jai or whatever 3 letter flavor of the month language.
>

The problem with flavor of the month languages is that people switch to them, play with them for a bit and abandon them. To quote Bjarne Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses". Languages like D or Java fall into the "get stuff done" category. They don't try to reinvent programming, they don't use the latest abstract higher order category theory union type lambdas, so they are considered boring by the language-hoppers. That's not a flaw of the language.

Personally I agree that BetterC isn't a good alternative for C programmers. Sure, you get some benefits of D, but you will lose many benefits of C and you'll have to constantly fight "wait, can I use this in BetterC or not" kind of thing.

> * Are you targeting Go, Crystal or new language developers?

The irony is that Crystal is already advertised as basically production ready, but there is zero support on Windows whatsoever. So D has a big advantage here :)

> I am sure there will be lots of opinions regarding this post but its suffice to say that my decision to go with Go ( no pun intended ) is finally. I hope this final post is some indication of the issues that have plagued my decision process.

I think the comparison was too unfair for D in the first place. All languages evolve. Go actually tried to establish itself as a systems programming language, later establishing itself as a webapp programming alnguage. Rust was pushing GC from the start, only later switching to the whole static analysis borrow checker all the way thingy. HTTP servers is kind of Go's niche, so there is an expectation for all the protocols to be supported and libraries readily available. If you were to say do the same comparison for e.g. game development, Go wouldn't look as favourably.

On Sunday, 4 February 2018 at 10:31:17 UTC, Dgame wrote:
> On Sunday, 4 February 2018 at 01:46:34 UTC, psychoticRabbit wrote:
>> Your suggestions are welcome. Just don't tell people that if they don't listen to them, then their community is bad. That's not how an open source community works.
>
> I've never said that the community is bad. :)

ok.. I stand corrected.

In any case, the problem is not with the community, but your expectations of the community.

Once you realise this, you can change your expectations.. and then you'll have a much happier time :)

On Sunday, 4 February 2018 at 11:14:43 UTC, JN wrote:
> On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
>> You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF generation tool last updated 3 years go.
>>
>
> While not as trivial as just using a dub package, D easy interop with C means you can use C libraries for PDF like libharu or w/e.
>
>> * Are you targeting C developers?
>>
>> Sure BetterC is a way towards that but again, what do you offer more then Rust?

Overloading, templates, compile time features are arguably "more than Rust".

>> I see C developers more going for Rust then D on this point.

Maybe, Rust is a decent language, and it appears to be getting better faster than D is. I recall the announcement of an experimental precise GC for D in 2013 or so, and Andrei at the time made it clear that a precise GC would be worth it even at some cost in performance. I don't think D will ever get a precise GC. Maybe the Rust and "Modern C++" guys are right and it's not worth it in a systems programming language?

> Personally I agree that BetterC isn't a good alternative for C programmers. Sure, you get some benefits of D, but you will lose many benefits of C

Which benefits of C are lost?

> and you'll have to constantly fight "wait, can I use this in BetterC or not" kind of thing.

Fair point, but that's a quality of implementation thing. I can imagine that in 6 months betterC is better supported on all platforms, and better documented.

On Sunday, 4 February 2018 at 12:02:25 UTC, psychoticRabbit wrote:
> On Sunday, 4 February 2018 at 10:31:17 UTC, Dgame wrote:
>> On Sunday, 4 February 2018 at 01:46:34 UTC, psychoticRabbit wrote:
>>> Your suggestions are welcome. Just don't tell people that if they don't listen to them, then their community is bad. That's not how an open source community works.
>>
>> I've never said that the community is bad. :)
>
> ok.. I stand corrected.
>
> In any case, the problem is not with the community, but your expectations of the community.
>
> Once you realise this, you can change your expectations.. and then you'll have a much happier time :)

No, I have no expectations, I simply stated the facts about what I've seen so far. I do not want to live a happy live in a community, why should I? I want to use a language and if I see problems which are ignored I move on. That is how it is, no offense.

On Sunday, 4 February 2018 at 20:15:47 UTC, bpr wrote:
>
> Which benefits of C are lost?
>

Ability to interface with C using C header files of a target library\executable as-is. Being able to understand the interfaces your operating system provides, described on the language it uses, is a huge criteria to pick C for your particular task.

Close-to-OS\Kernel-space\embedded seems to me as the main use case for C. It is the main C's benefit - you can interact with huge code blobs that you cannot rewrite, because you speak the same language. D does not, AFAIK, offer C header parsing.

Stuff like https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html ... It all takes years to build all these tools and gimmicks. If you can't use\reuse them from D, you'd beter be off writing in C imo.

On 2/4/2018 12:15 PM, bpr wrote:
>> Personally I agree that BetterC isn't a good alternative for C programmers. Sure, you get some benefits of D, but you will lose many benefits of C
> 
> Which benefits of C are lost?

I'll chime in a bit on that. I recently converted the Digital Mars C++ front end from C to D. Using BetterC, I was able to do it one function at a time. I.e. I'd convert one function, run the test suite to ensure I didn't make a mistake, rinse, repeat.

I didn't see any benefits lost.

The main downside was that I had to have two sets of headers (.h and .di) until the conversion was complete, and the .h files could be deleted.

On Sunday, 4 February 2018 at 22:05:45 UTC, Dgame wrote:
> I want to use a language and if I see problems which are ignored I move on. That is how it is, no offense.

So you see a problem and do not work on fixing it then complain that other people do the same. Ok.

On Sunday, 4 February 2018 at 20:15:47 UTC, bpr wrote:
>
> Which benefits of C are lost?
>

The ability to program on 16-bit platforms (yeah.. they still exist ;-)

16bit doesn't matter? .. it matters to me.

On 2/4/2018 2:27 PM, Boris-Barboris wrote:
> Ability to interface with C using C header files of a target library\executable as-is. Being able to understand the interfaces your operating system provides, described on the language it uses, is a huge criteria to pick C for your particular task.

BetterC is close enough to D that understanding the C API docs is not much of any issue.


> Close-to-OS\Kernel-space\embedded seems to me as the main use case for C. It is the main C's benefit - you can interact with huge code blobs that you cannot rewrite, because you speak the same language. D does not, AFAIK, offer C header parsing.

True, D cannot directly read .h files. There are tools, though, to convert C .h files to D.

I have thought about building this into D many times, especially since the Digital Mars C compiler is now available since it is Boost licensed.


> Stuff like https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html ... It all takes years to build all these tools and gimmicks. If you can't use\reuse them from D, you'd beter be off writing in C imo.

D has a pretty good chunk of those already built in. The others don't come up very often, and can be done using D's inline assembler.

On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:

> You want to produce Excel's? Excel-d but it faces the same issue as being the only native project. What if the author ...

Since you mention this, there isn't just single author of excel-d.  If something happened to me, most likely Atila would want to and continue to be paid to work on it.  If Atila decided he wanted to work from an office and write modern C++ instead of D (approximately snowball hell survival chance), we would certainly have someone else take over.  And Ilya Yaroshenko understands at least enough of it to have made pull requests (and I imagine he understands it all rather well, but limiting myself to saying what I am certain of). It's also not rocket science, the Excel API, and Microsoft can't afford to move quickly and break the API given their user base.

> What is D even targeting?

You’re attributing an intent and plan to a decentralised open source project.  It doesn't work like that.  It's like saying who should Britain target in trading post Brexit.  There's no central plan, because in Britain we don't have central planning that much for such things.  Who we end up trading with will be the result of many dispersed decisions made by people acting on the basis of local knowledge.

Well at least our Prime Minister can pretend that she is directing things in that way.  Andrei and Walter can't order anyone to do anything, for the most part.  They have significant influence, and can attract people to work on things but I don't see why you think there is a central plan for D.

These categories you mention, they don't capture real world organising principles from what I've seen.  When you don't have an enormous market share it's pretty easy to grow it.  You don't need to have a high appeal to everyone.  You just have to have a high enough appeal to just incrementally  more people wherever they may be found.

So it's not relevant whether most C++ developers are receptive to D or not (Ethan Watson says the games industry is an industry in search of salvation... from C++, and if every thing were hunky dory why the excitement about Jai, for example).  You don't need to appeal to most people to grow, just a few more.

Read the Innovators Dilemma if you are serious about understanding how this works.

" It feels like D does not even know who its targeting."
How can it? Why should it? At this point all that's necessary is to do more of what's working, which is something that's happening with the passage of time.  The way to grow is to appeal a bit more to your best customers or to those who are really close, using your for some things but are held back by some small impediments.  For example Remedy Games with Quantum Break.

"In my opinion the focus
> seems to be with C++ developers with most not giving a darn about D."

If most C++ developers were deeply familiar with D, it would be a very different conversation.  Since this isn't the case, and given the number of people using C++,  it's an advantage not a disadvantage what you point out.  The job of an innovative challenger is long term an easier one.  And strategically its by far the best if you get no respect until the last minute when it's too late for the challenger to respond.  Strategically you want a growing number of people to be finding D useful, but most people to be dismissive.  That happens to get the case though it was never planned.

Maybe D isn't for you right now.  That's okay - come back in a bit and maybe you will feel differently.  It doesn't need to appeal to everyone.

> Other languages have slogans, they have selling points.

Yeah, and some people don't like slogans and aren't influenced by them or find them irritating.  The unpolished aspect of the D world isn't a bad thing in this respect.

> When i hear D, you hear ... ... ... ...
>
> Advantages:
>
> D has a lot of advantages like CTFE, Generics, betterC etc over Go. But the resources seem to be spread so much over so much code, that information about how to properly use those Technics is spread thin.

I skipped C++ because I didn't find it appealing when I learnt to program as a boy, and my career took me in a different direction.  I picked up programming again in Dec 2013 after a very long break, and I didn't know what generics were (sort of, but I had never written them), the only metaprogramming I had done was in a Forth clone I wrote in the 80s, and so on.  But if wasn't difficult to pick things up with D,and the documentation was worse then.  I agree it could still be better, and better organised, but it's not that bad.

> It makes D its learning curve also much higher.

Really? I found D easier to learn than Python (to be fair I already knew C well).  I started out writing it like C and progressively adopted language features.  I learnt from Stefan Koch and Adam Ruppe when they were helping me before, and I still learn from John Colvin, Atila, Jonathan Davis and Ilya about some more advanced language features, but I don't feel bad about not knowing them, and nor do I feel held back.

Your scorelist is a bit odd.  You mention the importance of Windows to you.  Does Crystal even work on Windows reliably yet?  And then you talk about the need for being production ready and stable.  You have a different perspective on what that means than me.

In any case Go looks like a nice language.  I've thought about using it for us for devops type stuff when the alternatives are powershell, bash and Perl.

I don't see why the drama.  D isn't right for you right now.  No big deal, it's a big world, diversity is a good thing.  One can't be all things to all people.

Out of interest, because it's sort of relevant, how many SLOC would you guess you have written in D?


> The amount of issues that plague D go beyond the few i mentioned here and frankly will take years with a lot of manpower ( that D lacks ) to even sort out. I think D really missed the boat years ago because if it had a influx of people maybe 10 years ago, it will have been a whole different ballgame now.

Maybe.  Things develop at their own pace, and can't be forced.  I personally disagree because an influx of people before a language is ready for it can be a disaster.  I wasn't around then but I read a fair number of old posts, and I don't think D was ready for it then.

Modern Western people are in so much of a hurry, but why? The stakes are so large it's better to get things right than do them quickly at any cost, which often means taking short cuts and mortgaging the future.

Things happen when the time is right and not before.  A natural sequencing too.  No point setting up a Foundation when there aren't enough corporate users ready to support the language.  The time is right and you set up the Foundation - that's a lot of work and now you have to figure out a strategy.   These things take time, but we have time.

> Is Go perfect? Hell no ... but one needs to way the positive and negative. And to me it feels like Go has made more positive decisions that actually help people develop, then D on doing too much everywhere. Go is here to stay for the foreseeable future, where as D... not sure and that is scary.

They are just very different languages that serve different purposes.  D isn't in general competing with Rust, any more than Go would have been a serious choice for Mozilla to write their browser engine in.  For some things, sure, but the set of use cases for a general purpose language is enormous.

I don't think D is going to go anywhere but continuing to grow organically. Life is risk.  Maybe we will have war with Russia.  Or maybe rising rates will detonate the private market and big tech, with consequences for the market for programmers and some kinds of software.  These things are possible too.  I don't think D is going to drop off the face of the planet because quietly the use cases it serves very well are, quietly, growing rather quickly, and that's really all that matters in the bigger picture.


> I am sure there will be lots of opinions regarding this post but its suffice to say that my decision to go with Go ( no pun intended ) is finally. I hope this final post is some indication of the issues that have plagued my decision process.

I hope it works out well for you. I'm sure it will.


Laeeth