www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - My choice to pick Go over D ( and Rust ), mostly non-technical

reply Benny <benny.luypaert rhysoft.com> writes:
First of all, please do not repost this on Reddit or any other 
forum. This is focused for the D community alone to help deal 
with internal issues and it does not need to be ridiculed as this 
is a personal opinion.

As some have seen my posting in the past week regarding D, i like 
to explain my reasoning. I have been looking for the language to 
use for my next project, one of them was D.

But the choice was more or less between Rust, D and Go. As all 3 
offered good multi-platform support ( essential ), fast, low 
memory usage.

It came down to a list of criteria. I will mostly focus on D and 
Go as mentioning Rust too much will simply sidetrack the post too 
much.

HTTP:

D has no default HTTP server. So you need to rely on vibe.d. 
Vibe.d being a external package that then relies on a few people 
to maintain it.

D has no future proof HTTP. There is currently no official http2 
build in to vibe.d. Test branches do not count ;)

Go is the only one in the short-list that has a default HTTP 
solution that is well tested by loads of people, is fast ( 
especially with pre-fork ) and future proof.


Performance:

When it comes down to anything HTTP related unfortunately D is 
lagging behind on this part. Especially vibe.d

www.techempower.com/benchmarks/previews/round15. The techempower 
is just as example.

My own tests show the same performance issues where D at minimum 
to a un-preforked Go loses over 30% in real life, network tested 
benchmarks ( not some silly local device benchmarks that most 
people do ).

It also shows D has a higher CPU usage for the relative lower 
performance. Pre-forking Go increases the CPU usage but also 
performance.

All of my own tests are done with LDC ( optimized flags ) not DMD.

Sure, benchmarks are the devils breath but it makes no sense 
building a application that even with database queries are slow 
compared to the rest.


Build:

DMD is fast, no doubt about it but Go is just instant in my case 
for the same type of content i need ( Go HTTP vs D vibe.d ).

Other issues in my past with D also did not help, namely the 
regressions and constant bug-fix releases.

Its time for D to figure out a stable API. Its really bad when 
one compiles editor plugin code and sees "deprecated function" 
all over the output.

How up to date is the https://dlang.org/deprecate.html even?


Community / Code examples:

D has a nice community here on the forum but out in the real 
world "the internet" D is more or less non existing.

Google searches end up so many times back to this forum with a 
LOT of outdated code going back 5+ years, what does not work 
anymore as API changes happened.

The fact that a lot of code out there is old or non functional is 
a issue. Worse when 80% of the search results end up in this 
forum, showing that D does not have a very broad community.

I do not deny that D is used by some big companies as a C++ 
replacement but the impression is that those are mostly closed 
source projects where very few code surfaces on the web.


Package support:

Again ... D has very few packages and a LOT of them are frankly 
so old that they do not work properly anymore with the current 
DMD versions. Deprecated functions galore.

If D had 1195 active, well supported high quality packages but it 
has not. Most packages at best have one decent package and that 
is it.

You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF 
generation tool last updated 3 years go.

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

GRPC? Imap? ...

As i post this code.dlang.org is down so no more comparing. *sigh*

https://github.com/avelino/awesome-go
https://github.com/zhaopuming/awesome-d < missing Excel-d

Just looking on Github for D vs Go packages. 323 vs 15,351 (dlang 
vs golang) ... This is again related to popularity and community. 
So there is much more chance for finding something exotic as a 
base project in Go then ever in D.


Windows support:

But unlike D, Go's Windows support is simply better.

Plugins work out of the box with VSC. It has its own Jetbrain IDE.

Is Go perfect, no...

Dealing with Gopath is stupid. Who's idiotic idea that was 
instead of managing simply by project location.

Its no fun dealing with the Go Sqlite plugin ( what is 3th party 
) on Windows but then your are in actual production doing 
something, not fighting D to get your IDE working. Or fighting 
dub versions when LDC and DMD are both installed and in the 
environment path.

The amount of strange issues, not bugs or cross platform support 
issue that crosses D Windows users, simply leaves a bad taste.


Windows / Community issues:

 From a persona point of view, its tiring with some people looking 
down on the fact that i use Windows and have true issues related 
to D. That have been reported and helped fix but its a never 
ending stream of fixing one thing, running into another. 
Currently need to fall back to D 77.1 because of "issues".

But let me say this:

D has a nice community IF you fit into the mold. As a Windows 
user i am frankly fed up with people giving responses as "report 
it, fix it yourself" when it has been clearly stated that i do as 
much.

Or when a opinion is voiced about potential improvements, it 
comes down to "do it yourself or pay for it".

It is my personal opinion that:

* Do it yourself
* Pay for it
* Report it ( when the author has stated that they did )

Those comments add nothing to any discussions, they sidetrack 
discussion and only alienate people. Just do a google search and 
its horrible how many posts show up with this type of comment or 
variation.

Some people feel overly aggressive in defending D from criticism 
that it only alienates people. It has alienated me. Whenever i 
think about D, it positive feeling to move forward is always 
matched with dread thinking about some people or comments when i 
want to talk about issues.

The nice people here do not way up, to the people with a chip on 
there shoulder, that just ruin your day/mood.

It also does not help when comments boil down how "windows users 
do not contribute" when they actually do. Its very condescending 
and just scares away people.

At times i think that D is better served as a language with just 
a blog / news sections, a every expanding ( and up-to date ) 
examples section and better documentation and no forum at all.


Target:

I am personally confused with D's message.

* Are you targeting C++ developers?

 From my perspective most seem to be plenty happy with C++ 17. And 
they have the whole massive tooling, debugging and IDE support 
already. Given D its tooling, IDE and other issues, you really 
expect to draw developers away?

* Are you targeting Script language developers?

Missing HTTP solution, no easy CGI solution, .. it feels like 
there is much missing in terms of convincing for what script 
language developers are used too.

* 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.

* Are you targeting people new to programming?

 From my perspective it does not even look like people with a 
lacking in programming skills are even welcome here. Everything 
is build around the idea of people with previous higher level 
programming skills. Discussions about ideas that tend to be so 
complex that anybody without a higher level programming 
background will simply say: "No, do not understand a darn thing" 
and they look for easier solutions.

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

...

What is D even targeting? The kitchen and sink? It feels like D 
does not even know who its targeting. In my opinion the focus 
seems to be with C++ developers with most not giving a darn about 
D.

Go knows its not a system programming language, the focus is 
clearly more normal and web development. Even Rust has a much 
more clear message.

Other languages have slogans, they have selling points.

When i hear Go, you hear uniformal, fast, simple syntax language.
When i hear Rust, you hear safe, manual memory management.
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.

As some wise people said in the past, use the tools you need for 
a project. And being a jack of all trades but master of non is 
not good.

It makes D its learning curve also much higher.


Conclusion:

In case people are interested, a personal list with 40 points 
that mattered to me. Each with a score ( Bad 1, Mediocre 2, Good 
3 ). As a way to create a impartial opinion just based upon my 
own needs.

75. Go
69. .Net
67. Rust
64. Pascal < This one surprised even me.
63. Crystal
60. D
55. Swift
51. Kotlin

60/D < Yes, it also came as a surprise. The issues like finding 
potential affordable employees ( or high training times ), the 
non existing default HTTP support, lack of packages, the lack of 
code and examples. And a lot of mediocre (2) scores really made D 
lower ranked then i expected. I gave every language as much 
leeway without overly focusing on one specific bad point. .Net 
ended up high but it was never a contender because of the memory 
usage, but it was still fairly judge on all other points. Same 
with Pascal ( talk about a surprise ).

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.

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.

I can go on about a whole lot of technical issue and be told how 
uninformed i am. There is nothing to gain going down that route 
as the non-technical issues really put a dampener on D already.

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.
Feb 02
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 D has no default HTTP server. So you need to rely on vibe.d. 
 Vibe.d being a external package that then relies on a few 
 people to maintain it.
You could also use my libs, which have been around far longer than vibe.d and work fairly well with a variety of things including http serving, cgi interfacing, databases, gui, scripting, all in easy-to-use independent modules and often using reliable first-party libraries to avoid bugs. Of course, you can be forgiven for not knowing that, since I don't aggressively advertise them. I'm tempted to package it all together someday though... a "just works" thing with the packaged libs and maybe even an IDE would be nice. But alas, I don't have an IDE packaged like that (yet, at least).
Feb 02
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:

You don't want any comments on your post, but this being the 
internet, it's necessary to respond when you disagree.

 D has a nice community IF you fit into the mold. As a Windows 
 user i am frankly fed up with people giving responses as 
 "report it, fix it yourself" when it has been clearly stated 
 that i do as much.

 Or when a opinion is voiced about potential improvements, it 
 comes down to "do it yourself or pay for it".

 It is my personal opinion that:

 * Do it yourself
 * Pay for it
 * Report it ( when the author has stated that they did )

 Those comments add nothing to any discussions, they sidetrack 
 discussion and only alienate people. Just do a google search 
 and its horrible how many posts show up with this type of 
 comment or variation.

 Some people feel overly aggressive in defending D from 
 criticism that it only alienates people. It has alienated me. 
 Whenever i think about D, it positive feeling to move forward 
 is always matched with dread thinking about some people or 
 comments when i want to talk about issues.

 The nice people here do not way up, to the people with a chip 
 on there shoulder, that just ruin your day/mood.

 It also does not help when comments boil down how "windows 
 users do not contribute" when they actually do. Its very 
 condescending and just scares away people.
The reason you hear this is because you are getting an explanation of how things work around here. You write "Those comments add nothing to any discussions" and in a sense that is true. But that's because there really isn't a reason to have a discussion. You are getting an answer. There is nothing to be gained from saying "someone should do this and this and this". When you get those responses, it is simply people explaining how things are done. It wouldn't make sense to go into a clothing store and complain that they don't sell fried chicken. If you're in the market for fried chicken, don't go to a clothing store. The things you want - a perfect out-of-the-box Windows experience, where you can make requests for others to do the things you want - is not what D has to offer.
Feb 02
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 02, 2018 at 05:01:58PM +0000, bachmeier via Digitalmars-d wrote:
[...]
 The things you want - a perfect out-of-the-box Windows experience,
 where you can make requests for others to do the things you want - is
 not what D has to offer.
While I agree that in an open-source volunteer project like this one, it doesn't make sense to go around telling others what to do (it's their own free time, they get to decide what they like to work on), I think the bit about a perfect out-of-the-box Windows experience is something that we can and should work on, even if we may never get there, given our current manpower. Reducing unnecessary barriers like this will only benefit us in the long run. I don't think it's a good idea to just give up on it or ignore it. And AFAIK, there *are* some people working on improving Windows support, though progress is slow because of limited manpower. (And there's where more volunteers to step up to the plate would help expedite things.) So IMO it's unfair to say that D has absolutely nothing to offer on this front -- it's not perfect yet, but we're getting there! T -- What did the alien say to Schubert? "Take me to your lieder."
Feb 02
parent bachmeier <no spam.net> writes:
On Friday, 2 February 2018 at 17:24:47 UTC, H. S. Teoh wrote:
 On Fri, Feb 02, 2018 at 05:01:58PM +0000, bachmeier via 
 Digitalmars-d wrote: [...]
 The things you want - a perfect out-of-the-box Windows 
 experience, where you can make requests for others to do the 
 things you want - is not what D has to offer.
While I agree that in an open-source volunteer project like this one, it doesn't make sense to go around telling others what to do (it's their own free time, they get to decide what they like to work on), I think the bit about a perfect out-of-the-box Windows experience is something that we can and should work on, even if we may never get there, given our current manpower. Reducing unnecessary barriers like this will only benefit us in the long run. I don't think it's a good idea to just give up on it or ignore it. And AFAIK, there *are* some people working on improving Windows support, though progress is slow because of limited manpower. (And there's where more volunteers to step up to the plate would help expedite things.) So IMO it's unfair to say that D has absolutely nothing to offer on this front -- it's not perfect yet, but we're getting there! T
Not sure what happened to my response... Improving the Windows experience is definitely a good thing. The Windows experience is not yet what it should be, and that's where you either have to do the work or pay someone else to do the work.
Feb 02
prev sibling next sibling parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 [snip]
D is a fantastic language. If I can derive some gist from OP, we need high quality libraries for people to use. There are two things here: libraries (of) high quality (features, performance, stability) Most of the stated facts are known and there are many such threads in this forum. However actionable things will become reality only with *quality man power*. Probably the D website should highlight that before people come here to compare it with Rust, Go, C++ etc which are backed up by $$$ corporations. D might have lost it's mind share, but is trying hard to catch up to it. That's why you see things on D blog and so on.
Feb 02
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 75. Go
 69. .Net
 67. Rust
 64. Pascal < This one surprised even me.
 63. Crystal
 60. D
 55. Swift
 51. Kotlin
It is interesting that you took the time to score different languages, but of course, there probably are a lot languages or frameworks that you didn't score. Anyway, I think in most cases polyglot programmers looking for high productivity would pick a language from a very small set of parameters, which basically has very little to do with the language itself: What would be the most productive tooling for this very narrow problem I am facing? Then you look at tooling that has been used for similar problems, and the eco system around that. Rust, Crystal, Kotlin and Pascal would typically be very far down on that list. The eco system being an issue. In reality many programming tasks can be solved efficiently with "interpreted" languages like Python or the Javascript-ecosystem. I.e. you can get good performance and high productivity for many applications if you are selective in how you build your application. The reason for this? They have been used for many different applications, so other people have already done the groundwork.
Feb 02
prev sibling next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 ** Wall of text **
I dont post here often but... Most of what you complain is known already and/or not entirely correct. People who work on D are not some glue sniffing brain dead individuals that are incapable of understanding that documentation is not perfect, library support is lacking and user experience is not at the same level as C#. That and more are known here. Over the years that I lurked here I saw many people come on forums and complain about things that are obvious and say them in a way that indirectly imply incompetence of core contributors. Things don't work not because of incompetence but because there is not enough people working on things. Thats why you get answers you get. To fix problems we need people who work so either you become one (fix it yourself) or get some one else to work (pay money). The entire D project is fueled by coffee and dislike of C/C++ and its amazing that it achieved so much with so little
Feb 02
parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 2/2/18 1:38 PM, welkam wrote:
 On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 ** Wall of text **
I dont post here often but... Most of what you complain is known already and/or not entirely correct. People who work on D are not some glue sniffing brain dead individuals that are incapable of understanding that documentation is not perfect, library support is lacking and user experience is not at the same level as C#. That and more are known here. Over the years that I lurked here I saw many people come on forums and complain about things that are obvious and say them in a way that indirectly imply incompetence of core contributors. Things don't work not because of incompetence but because there is not enough people working on things. Thats why you get answers you get. To fix problems we need people who work so either you become one (fix it yourself) or get some one else to work (pay money). The entire D project is fueled by coffee and dislike of C/C++ and its amazing that it achieved so much with so little
It is pretty amazing, and it's a testament to how appealing the D language can be, even with all its surrounding pain points. As a long time lurker it seems like I see posts like Benny's more often recently than I recall seeing in years past. This makes me happy--to me it's a sign that more people are seriously considering D than used to. I also think it's good to be reminded of what newcomers' pain points are, and I'm glad Benny took the time to list his.
Feb 02
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 HTTP:

 D has no default HTTP server. So you need to rely on vibe.d. 
 Vibe.d being a external package that then relies on a few 
 people to maintain it.

 D has no future proof HTTP. There is currently no official 
 http2 build in to vibe.d. Test branches do not count ;)
D interfaces with C and C++ so you are not limited to vibe.d. You have entire C and probably all C++ HTTP libraries. And you didnt benchmark D. You benchmarked vibe.d
Feb 02
prev sibling next sibling parent reply Rubn <where is.this> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 HTTP:
If you are focusing on Http then yah Go is probably the better choice, it looks like it is entire geared towards http development. I wouldn't use D for http just like I wouldn't use C++ for http.
Feb 02
parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 2 February 2018 at 21:09:20 UTC, Rubn wrote:
 On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 HTTP:
If you are focusing on Http then yah Go is probably the better choice, it looks like it is entire geared towards http development. I wouldn't use D for http just like I wouldn't use C++ for http.
D can equally do HTTP in whatever way Go does it. It appears most core contributors are not into networking or web services so they may not see it as a blocker. Its more of an ecosystem issue and not a language issue. Even with D, we have libraries like request (http://code.dlang.org/packages/requests) for HTTP/FTP. Its does support http2 yet though but its enough for all my HTTP needs for now. We also have vibe.d which I don't get the point which saying it might be abandoned is not a reason to ignore it as useful or enough. I've seen several people here submitting pull requests in every release of it. Considering the size of this community (in my estimation), vibe.d is well supported. It does more than what express for NodeJS does on its own. There in also an effort to make D work on Alpine Linux which is very common for packaging applications into lightweight docker containers. Support for D in the cloud also require some amount of work since none of them support D SDKs. The Internet and the web is continuously growing and communication protocols are quite significant in the change.
Feb 02
next sibling parent aberba <karabutaworld gmail.com> writes:
On Friday, 2 February 2018 at 23:49:14 UTC, aberba wrote:
 On Friday, 2 February 2018 at 21:09:20 UTC, Rubn wrote:
 [...]
D can equally do HTTP in whatever way Go does it. It appears most core contributors are not into networking or web services so they may not see it as a blocker. Its more of an ecosystem issue and not a language issue. [...]
Now I can't fix my statement ... The statement doesn't make sense to me.
Feb 02
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 February 2018 at 23:49:14 UTC, aberba wrote:
 It appears most core contributors are not into networking or 
 web services so they may not see it as a blocker.
I do tons of HTTP stuff in D; to me it is a solved problem. Though I haven't implemented http2 since I don't need it; http 1.1 has much better compatibility (and will for many years to come) and performs plenty well enough for API client use, and server use is handled behind a production server anyway, so it works quite well. A http2 client might be worth doing someday, but right now there's just no pressing need, even using http resources every day.
Feb 02
parent aberba <karabutaworld gmail.com> writes:
On Saturday, 3 February 2018 at 00:11:06 UTC, Adam D. Ruppe wrote:
 On Friday, 2 February 2018 at 23:49:14 UTC, aberba wrote:
 It appears most core contributors are not into networking or 
 web services so they may not see it as a blocker.
I do tons of HTTP stuff in D; to me it is a solved problem. Though I haven't implemented http2 since I don't need it; http 1.1 has much better compatibility (and will for many years to come) and performs plenty well enough for API client use, and server use is handled behind a production server anyway, so it works quite well. A http2 client might be worth doing someday, but right now there's just no pressing need, even using http resources every day.
Yeah. I do know you're on of the few guys into web services.
Feb 02
prev sibling next sibling parent user <user tmp.com> writes:
 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
I usually hear awesome meta-programming and ranges. I think D community had put lot of effort in making these things work because (1) these are cool (2) increases expressive power. Unfortunately at the detriment of tooling and libraries. I think we should put a stop to adding new features in D2 at some point and focus on stability, libraries and tools. Can't wait to see how the road map looks like for 18H1.
Feb 02
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 I am personally confused with D's message.
I think that point hits the cause of your problem with D (along with your need to 'choose' something over 'something' else). Stop looking for the meaning of D .. and start experiencing it. (there is no meaning...to anything!) Stop comparing D to other things, and just enjoy what it has to offer. (tribalism not cool!) And btw. one persons technical justification for using x, is another persons technical justification for not using x. Plenty of experienced programmers (who never used D before) now enjoy using D, even if they still have to program in other languages...in order to earn a living. Too many corporations have big investments in other languages. Don't expect D to compete here anytime soon. That is the nature of business. If D is to take off anywhere, it will be in the open source community, and startups - not a google or facebook, and certainly never microsoft. D has a lot of good and interesting things to offer to the world of software development, including an amazing, reasonably efficient standard library (with support from the compiler). It also supports all major platforms that matter (although it's hard to argue that windows 32bit 'matters' ;-). And there is no corporate backer making this all happen. It's just people who want to build something great, and give up their time to do it. D has the benefit of having a compiler expert, and an algorithm expert in the core team. The advantage from this cannot be underestimated (which is why many are willing to look the other way when it comes to lack of significant management skills ;-) ..and I'd rather it that way, than the other way (i.e great managers, who don't understand a thing). Both would be nice.. but who has that? But D is on a road trip...it's not at its destination (I'm not sure it even knows - or cares - where its going ;-) Just enjoy the road trip! Or jump out. It's entirely your choice. But the road trip will continue, and those on it, will keep enjoying new sights...
Feb 02
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 3 February 2018 at 01:52:04 UTC, psychoticRabbit 
wrote:
 On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 I am personally confused with D's message.
I think that point hits the cause of your problem with D (along with your need to 'choose' something over 'something' else). Stop looking for the meaning of D .. and start experiencing it. (there is no meaning...to anything!) Stop comparing D to other things, and just enjoy what it has to offer. (tribalism not cool!) And btw. one persons technical justification for using x, is another persons technical justification for not using x. Plenty of experienced programmers (who never used D before) now enjoy using D, even if they still have to program in other languages...in order to earn a living. Too many corporations have big investments in other languages. Don't expect D to compete here anytime soon. That is the nature of business. If D is to take off anywhere, it will be in the open source community, and startups - not a google or facebook, and certainly never microsoft. D has a lot of good and interesting things to offer to the world of software development, including an amazing, reasonably efficient standard library (with support from the compiler). It also supports all major platforms that matter (although it's hard to argue that windows 32bit 'matters' ;-). And there is no corporate backer making this all happen. It's just people who want to build something great, and give up their time to do it. D has the benefit of having a compiler expert, and an algorithm expert in the core team. The advantage from this cannot be underestimated (which is why many are willing to look the other way when it comes to lack of significant management skills ;-) ..and I'd rather it that way, than the other way (i.e great managers, who don't understand a thing). Both would be nice.. but who has that?
Probably the best response to what he wrote and to similar sentiments expressed by others over the years, but I'll add one caveat: it has been mentioned here that D has been used a little by a few teams at both Facebook and Microsoft, dunno about Google. Though as you said, no sign that they'll embrace it much more, and probably better to have it adopted at many more smaller places.
 But D is on a road trip...it's not at its destination (I'm not 
 sure it even knows - or cares - where its going ;-)

 Just enjoy the road trip! Or jump out. It's entirely your 
 choice.

 But the road trip will continue, and those on it, will keep 
 enjoying new sights...
According to Linus, it is impossible to know your destination if your scope is wide enough, such as a general-purpose programming language or an OS kernel, as this is what he said in response to a question about whether linux could still be designed at the scale it reached 16 years ago: "I will go further and claim that _no_ major software project that has been successful in a general marketplace (as opposed to niches) has ever gone through those nice lifecycles they tell you about in CompSci classes. Have you _ever_ heard of a project that actually started off with trying to figure out what it should do, a rigorous design phase, and a implementation phase? Dream on. Software evolves. It isn't designed. The only question is how strictly you _control_ the evolution, and how open you are to external sources of mutations. And too much control of the evolution will kill you. Inevitably, and without fail. Always. In biology, and in software. Amen." http://yarchive.net/comp/evolution.html
Feb 02
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 3 February 2018 at 06:15:31 UTC, Joakim wrote:
 Software evolves. It isn't designed. The only question is how 
 strictly you
 _control_ the evolution, and how open you are to external 
 sources of
 mutations.
Unix was designed... and was based on a more ambitious design (Multics). Linux was a haphazard kitchensink DIY reimplementation of it... I wouldn't trust Linus much when it comes to general statements about software development. Evolution does not mean that you don't design. Cars evolve, but they sure are designed.
Feb 03
parent Joakim <dlang joakim.fea.st> writes:
On Saturday, 3 February 2018 at 10:55:41 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 3 February 2018 at 06:15:31 UTC, Joakim wrote:
 Software evolves. It isn't designed. The only question is how 
 strictly you
 _control_ the evolution, and how open you are to external 
 sources of
 mutations.
Unix was designed... and was based on a more ambitious design (Multics). Linux was a haphazard kitchensink DIY reimplementation of it... I wouldn't trust Linus much when it comes to general statements about software development. Evolution does not mean that you don't design. Cars evolve, but they sure are designed.
I suggest you read all his comments in that thread, as I told you to in a previous forum thread before, as basically every statement you make here was addressed by other Linus emails in that archive I linked above.
Feb 03
prev sibling parent Michael <michael toohuman.io> writes:
On Saturday, 3 February 2018 at 01:52:04 UTC, psychoticRabbit 
wrote:
 On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 [...]
I think that point hits the cause of your problem with D (along with your need to 'choose' something over 'something' else). [...]
I think it is worth mentioning that D does in fact have corporate interests driving some of the development behind D. They have "sponsors" just like many other languages, we just don't see the direct connection between a sponsor's donations and the focus of development of the language.
Feb 05
prev sibling next sibling parent psychoticRabbit <meagain meagin.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 Other languages have slogans, they have selling points.

 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
When i hear D, you hear: "The freedom to program, the way you want". (if you listen carefully..then you'll hear it)
Feb 02
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
Feb 02
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via Digitalmars-d wrote:
 On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
Frankly, that slogan makes me cringe. Makes D sound like a fast food chain -- cheap code, fast. Would you like fa^Wfries with that? If we're serious about being fast, we better get our act together and: - Make the GC faster, preferably on par with Java's best; - Make dmd's optimizer better, esp. with loop unrolling on par with ldc/gdc, or better, so that we don't keep having to defend poor dmd benchmarks with "use ldc/gdc instead"; - Replace commonly complained-about slow modules like std.json and std.xml with faster (and better-designed) replacements; - Make dub run faster -- I can't help feeling frustrated when every time I invoke dub it takes 10-20 secs to scan the network for updates, then another 5-10 seconds to resolve dependencies, and *then* build it, when dmd itself is well capable of running an order of magnitude faster than that on a comparable amount of code. - Shorten PR waiting times on Github. Some trivial PRs sit for weeks before even being noticed; kinda makes "fast code, fast" more of an ironic statement than a proud banner, y'know? (I've been diving into the deep end of the Phobos PR queue to declog old stuck PRs. Managed to bump the queue size from 100+ down to about 89 or so, but more help would be much appreciated. Sometimes I feel like a fast food janitor. Or fast code janitor. :-P) - Provide an option to turn on GC collection (or *any* memory management, really) in dmd. I know it never frees memory because of "performance" reasons. But performance ain't gonna mean squat on a low memory system when you run out of memory and start swapping... or worse, invoking the kernel OOM killer. Then "fast code, fast" becomes "no code, killed". So much for fast. "How fast can you invoke the OOM killer?" :-P I'd rather wait for a few more seconds and get an executable, than to shave off a few seconds and get zilch. T -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Feb 03
parent reply Rubn <where is.this> writes:
On Saturday, 3 February 2018 at 08:18:57 UTC, H. S. Teoh wrote:
 On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via 
 Digitalmars-d wrote:
 On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
Frankly, that slogan makes me cringe. Makes D sound like a fast food chain -- cheap code, fast. Would you like fa^Wfries with that?
Yup I agree, it's a horrible slogan. Speed isn't even a priority in D, if it was so many things would be different.
 - Make dmd's optimizer better, esp. with loop unrolling on par 
 with
   ldc/gdc, or better, so that we don't keep having to defend 
 poor dmd
   benchmarks with "use ldc/gdc instead";
I don't think time should be wasted on making DMD's optimizer better. It's not an easy job and it'll just pull resources for something that has no purpose. The compile times with DMD -O can vary dramatically, it's best just to not use it at all. The reason I hear as to why DMD even exists instead of just having 1 compiler like Rust or any other language that isn't 20+ years old. Is cause DMD's unoptimized compilation is fast and creates reasonably fast enough code for debugging.
Feb 03
parent reply Norm <norm.rowtree gmail.com> writes:
On Saturday, 3 February 2018 at 15:22:37 UTC, Rubn wrote:
 On Saturday, 3 February 2018 at 08:18:57 UTC, H. S. Teoh wrote:
 On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via 
 Digitalmars-d wrote:
 On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
Frankly, that slogan makes me cringe. Makes D sound like a fast food chain -- cheap code, fast. Would you like fa^Wfries with that?
Yup I agree, it's a horrible slogan. Speed isn't even a priority in D, if it was so many things would be different.
 - Make dmd's optimizer better, esp. with loop unrolling on par 
 with
   ldc/gdc, or better, so that we don't keep having to defend 
 poor dmd
   benchmarks with "use ldc/gdc instead";
I don't think time should be wasted on making DMD's optimizer better. It's not an easy job and it'll just pull resources for something that has no purpose. The compile times with DMD -O can vary dramatically, it's best just to not use it at all. The reason I hear as to why DMD even exists instead of just having 1 compiler like Rust or any other language that isn't 20+ years old. Is cause DMD's unoptimized compilation is fast and creates reasonably fast enough code for debugging.
I agree, DMD should switch to LLVM backend. But it is unlikely to happen because the core DMD developers are in their comfort zone with DMD backend and worried that switching to LLVM would put them at the mercy of the LLVM community. To be honest though I don't know how much time DMD backend optimizer really takes core devs away from D language development. It would be interesting to see some numbers on this. We use LDC exclusively where I work because DMD codegen just isn't production ready. And the argument that DMD debug builds are so much faster than LDC is bogus. Yes it is faster but nowhere near the point where we would consider swapping compilers between debug and release builds. So that leaves little scripts and the like where DMD could maybe replace Python. But again, LDC isn't *that* slow in debug builds either and could do this just as well. Cheers, Norm
Feb 03
parent reply Rubn <where is.this> writes:
On Saturday, 3 February 2018 at 23:07:30 UTC, Norm wrote:
 On Saturday, 3 February 2018 at 15:22:37 UTC, Rubn wrote:
 On Saturday, 3 February 2018 at 08:18:57 UTC, H. S. Teoh wrote:
 On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via 
 Digitalmars-d wrote:
 On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
Frankly, that slogan makes me cringe. Makes D sound like a fast food chain -- cheap code, fast. Would you like fa^Wfries with that?
Yup I agree, it's a horrible slogan. Speed isn't even a priority in D, if it was so many things would be different.
 - Make dmd's optimizer better, esp. with loop unrolling on 
 par with
   ldc/gdc, or better, so that we don't keep having to defend 
 poor dmd
   benchmarks with "use ldc/gdc instead";
I don't think time should be wasted on making DMD's optimizer better. It's not an easy job and it'll just pull resources for something that has no purpose. The compile times with DMD -O can vary dramatically, it's best just to not use it at all. The reason I hear as to why DMD even exists instead of just having 1 compiler like Rust or any other language that isn't 20+ years old. Is cause DMD's unoptimized compilation is fast and creates reasonably fast enough code for debugging.
I agree, DMD should switch to LLVM backend. But it is unlikely to happen because the core DMD developers are in their comfort zone with DMD backend and worried that switching to LLVM would put them at the mercy of the LLVM community. To be honest though I don't know how much time DMD backend optimizer really takes core devs away from D language development. It would be interesting to see some numbers on this. We use LDC exclusively where I work because DMD codegen just isn't production ready. And the argument that DMD debug builds are so much faster than LDC is bogus. Yes it is faster but nowhere near the point where we would consider swapping compilers between debug and release builds. So that leaves little scripts and the like where DMD could maybe replace Python. But again, LDC isn't *that* slow in debug builds either and could do this just as well. Cheers, Norm
I agree it isn't that much faster, though that's the argument I hear. I would prefer to have one compiler that is being worked on than having split effort for 3 different compilers when larger communities only have 1 compiler. Not that everyone working on those compilers will work on one compiler if it does happen. It's just a shame the solution was to create more compilers. With DMD it seems like they are entirely unwilling to let go from using DM tools/code. The backend is just one example. Optlink is another. DM Make is also another, etc...
Feb 03
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 4 February 2018 at 01:57:26 UTC, Rubn wrote:
 I would prefer to have one compiler that is being worked on 
 than having split effort for 3 different compilers when larger 
 communities only have 1 compiler.
There is very little split effort. The way this actually works is there's one D codebase that everyone works on, and three backends that basically nobody works on (they are done by independent teams). The only work that's separate between dmd, gdc, and ldc is a little bit of code with adapter classes that just fit that shared D codebase into each of the three backends. That is a tiny, tiny fraction of the work done since it doesn't actually reimplement any of the guts.
 With DMD it seems like they are entirely unwilling to let go 
 from using DM tools/code. The backend is just one example. 
 Optlink is another. DM Make is also another, etc...
D uses the Visual Studio linker and the GNU or LLVM linker as well as GNU make on all platforms except 32 bit Windows.
Feb 03
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 4 February 2018 at 01:57:26 UTC, Rubn wrote:
 On Saturday, 3 February 2018 at 23:07:30 UTC, Norm wrote:
 On Saturday, 3 February 2018 at 15:22:37 UTC, Rubn wrote:
 On Saturday, 3 February 2018 at 08:18:57 UTC, H. S. Teoh 
 wrote:
 On Fri, Feb 02, 2018 at 08:16:25PM -0800, Walter Bright via 
 Digitalmars-d wrote:
 On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
Frankly, that slogan makes me cringe. Makes D sound like a fast food chain -- cheap code, fast. Would you like fa^Wfries with that?
Yup I agree, it's a horrible slogan. Speed isn't even a priority in D, if it was so many things would be different.
 - Make dmd's optimizer better, esp. with loop unrolling on 
 par with
   ldc/gdc, or better, so that we don't keep having to defend 
 poor dmd
   benchmarks with "use ldc/gdc instead";
I don't think time should be wasted on making DMD's optimizer better. It's not an easy job and it'll just pull resources for something that has no purpose. The compile times with DMD -O can vary dramatically, it's best just to not use it at all. The reason I hear as to why DMD even exists instead of just having 1 compiler like Rust or any other language that isn't 20+ years old. Is cause DMD's unoptimized compilation is fast and creates reasonably fast enough code for debugging.
I agree, DMD should switch to LLVM backend. But it is unlikely to happen because the core DMD developers are in their comfort zone with DMD backend and worried that switching to LLVM would put them at the mercy of the LLVM community. To be honest though I don't know how much time DMD backend optimizer really takes core devs away from D language development. It would be interesting to see some numbers on this. We use LDC exclusively where I work because DMD codegen just isn't production ready. And the argument that DMD debug builds are so much faster than LDC is bogus. Yes it is faster but nowhere near the point where we would consider swapping compilers between debug and release builds. So that leaves little scripts and the like where DMD could maybe replace Python. But again, LDC isn't *that* slow in debug builds either and could do this just as well. Cheers, Norm
I agree it isn't that much faster, though that's the argument I hear. I would prefer to have one compiler that is being worked on than having split effort for 3 different compilers when larger communities only have 1 compiler. Not that everyone working on those compilers will work on one compiler if it does happen. It's just a shame the solution was to create more compilers.
All the major compilers, dmd, ldc, and gdc, share the same frontend. Two of the backends, llvm and gcc, are not worked on by the D compiler devs. The DM backend used by dmd is not worked on much, mostly bug fixes and some refactoring recently, as Walter prepares to move it to D: https://github.com/dlang/dmd/commits/0b8d1fc0d5f6d09478d282202ad50a0c964b75b0?after=0b8d1fc0d5f6d09478d282202ad50a0c964b75b0+104&path%5B%5D=src&path%5B%5D=ddmd&path%5B%5D=backend There is no evidence that having more compiler backends available to D devs has "split effort" in any way. As for the compilers' speed, I thought I'd test that out. I just built the dmd frontend a handful of times in a single-core linux/x64 VPS, both with the official dmd 2.078.0 and the latest ldc 1.7.0. Leaving out all the C++ files, dmd consistently took 3-4 seconds to build the D frontend alone and link the final dmd binary, whereas ldc took 9-10 seconds for the same work. This is with no debug or optimization options added, just the default build by the dmd makefile. That's a 200% increase in compilation speed when iterating on the almost 80k lines of code (reported by DScanner) in the dmd frontend, certainly not insignificant. When the backend is in D too- the C++ files currently take about 10 seconds to compile- building dmd itself will be incredibly fast, even more than it is now.
 With DMD it seems like they are entirely unwilling to let go 
 from using DM tools/code. The backend is just one example. 
 Optlink is another. DM Make is also another, etc...
Why let it go, when you don't have to use it? Optlink has around 5 commits in the last 3 years, it's not like it's taking up much time: https://github.com/DigitalMars/optlink/commits/master Rather than worrying about DM tools that receive almost no attention, D would be better off if more people chipped in on the code they _do_ care about, whether through submitting pull requests or posting bounties: https://github.com/dlang/dmd/pulls https://github.com/dlang/phobos/pulls https://www.bountysource.com/teams/d
Feb 03
prev sibling next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Saturday, 3 February 2018 at 04:16:25 UTC, Walter Bright wrote:
 On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
I think this (below) might be closer to your intention...(idea taken from a google tech talk) "Life's Too Short - Write Fast Code, fast."
Feb 03
prev sibling parent bachmeier <no spam.net> writes:
On Saturday, 3 February 2018 at 04:16:25 UTC, Walter Bright wrote:
 On 2/2/2018 7:06 AM, Benny wrote:
 Other languages have slogans, they have selling points.
 
 When i hear Go, you hear uniformal, fast, simple syntax 
 language.
 When i hear Rust, you hear safe, manual memory management.
 When i hear D, you hear ... ... ... ...
Fast code, fast
You forgot the most important word: Fast, correct code, fast
Feb 03
prev sibling next sibling parent reply Dgame <r.schuett.1987 gmail.com> writes:
This is a nice, refreshing post. You state problems and why you 
switched to Go. You give a ton of informations (here and in your 
prior posts) why you did what you did and what problems you've 
seen. This could be used to improve D. But the regular reply you 
will get if you criticize D even a little is "You are wrong! D is 
great!" or "You have a point, but ...". You can watch these 
discussions regularly, it's really hilarious. It always ends in 
the same way: Criticism is being hunted down and after Page 3 you 
can only read how great D is and why.
I congratulate you on your decision. I also changed to another 
language and I've never regretted it. Sadly the D community will 
never learn from those excelent posts which only wants to help D 
to become better than it is. It's really sad...
I bet this post will also torn apart to bash any sign of 
criticism.
Feb 03
next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 This could be used to improve D
So when will you start working on issues he described?
Feb 03
parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Saturday, 3 February 2018 at 23:25:09 UTC, welkam wrote:
 On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 This could be used to improve D
So when will you start working on issues he described?
And when will you? I already tried in the past as you can see.
Feb 03
parent welkam <wwwelkam gmail.com> writes:
On Saturday, 3 February 2018 at 23:37:43 UTC, Dgame wrote:
 On Saturday, 3 February 2018 at 23:25:09 UTC, welkam wrote:
 On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 This could be used to improve D
So when will you start working on issues he described?
And when will you? I already tried in the past as you can see.
Searched forums and didnt find any discussion on contributing. https://dlang.org/contributors.html Doesnt show you either. I already try but depression makes a very slow process
Feb 03
prev sibling next sibling parent reply Christof Schardt <christof schardt.info> writes:
On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 I congratulate you on your decision. I also changed to another 
 language and I've never regretted it.
Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book)
Feb 03
parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt 
wrote:
 On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 I congratulate you on your decision. I also changed to another 
 language and I've never regretted it.
Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book)
First back to C++11/14/17. Since 2017 I'm mostly using Rust.
Feb 03
parent reply bachmeier <no spam.net> writes:
On Saturday, 3 February 2018 at 23:39:00 UTC, Dgame wrote:
 On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt 
 wrote:
 On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 I congratulate you on your decision. I also changed to 
 another language and I've never regretted it.
Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book)
First back to C++11/14/17. Since 2017 I'm mostly using Rust.
Then why are you posting here? Your post was 100% troll.
Feb 03
parent Dgame <r.schuett.1987 gmail.com> writes:
On Saturday, 3 February 2018 at 23:45:21 UTC, bachmeier wrote:
 On Saturday, 3 February 2018 at 23:39:00 UTC, Dgame wrote:
 On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt 
 wrote:
 On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 I congratulate you on your decision. I also changed to 
 another language and I've never regretted it.
Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book)
First back to C++11/14/17. Since 2017 I'm mostly using Rust.
Then why are you posting here? Your post was 100% troll.
It was not, your posts shows exactly what I meant. :)
Feb 04
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote:
 This is a nice, refreshing post. You state problems and why you 
 switched to Go. You give a ton of informations (here and in 
 your prior posts) why you did what you did and what problems 
 you've seen. This could be used to improve D. But the regular 
 reply you will get if you criticize D even a little is "You are 
 wrong! D is great!" or "You have a point, but ...". You can 
 watch these discussions regularly, it's really hilarious. It 
 always ends in the same way: Criticism is being hunted down and 
 after Page 3 you can only read how great D is and why.
 I congratulate you on your decision. I also changed to another 
 language and I've never regretted it. Sadly the D community 
 will never learn from those excelent posts which only wants to 
 help D to become better than it is. It's really sad...
 I bet this post will also torn apart to bash any sign of 
 criticism.
There is always friction, and often conflict, in the open source community. Why? Because there is no dictator, dictating the terms of what people should do, how they should do it, when they should do it. There are no consequences for not submitting to some authority. People are free to think and do as they choose. So if you want to be part of an 'real' open source community, you need to understand that fact - before you understand anything else. This is why democracies are what they are - frought with fiction, and often partisan conflict - cause people are free to think for themselves - and this often leads to friction and conflict. You need to be able to maturely deal with that friction and conflict. Go try living in north korea. not much conflict there - you get inprisoned or shot if you do not think and do as the leader dictates. 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. If you are free to think and do, so are others.
Feb 03
parent reply Dgame <r.schuett.1987 gmail.com> writes:
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. :)
Feb 04
parent reply psychoticRabbit <meagain meagain.com> writes:
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 :)
Feb 04
parent reply Dgame <r.schuett.1987 gmail.com> writes:
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.
Feb 04
parent reply welkam <wwwelkam gmail.com> writes:
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.
Feb 04
parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Monday, 5 February 2018 at 00:56:20 UTC, welkam wrote:
 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.
Nice try in twisting someones words. As I already said, you are one of those guys I spoke about. :) Keep going!
Feb 04
parent psychoticRabbit <meagain meagain.com> writes:
On Monday, 5 February 2018 at 07:46:46 UTC, Dgame wrote:
 On Monday, 5 February 2018 at 00:56:20 UTC, welkam wrote:
 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.
Nice try in twisting someones words. As I already said, you are one of those guys I spoke about. :) Keep going!
You keep demonstrating the 'actual' problem...everytime you post. :)
Feb 04
prev sibling next sibling parent reply JN <666total wp.pl> writes:
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.
Feb 04
next sibling parent reply bpr <brogoff gmail.com> writes:
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.
Feb 04
next sibling parent reply Boris-Barboris <ismailsiege gmail.com> writes:
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.
Feb 04
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 04
next sibling parent reply Boris-Barboris <ismailsiege gmail.com> writes:
On Monday, 5 February 2018 at 05:28:54 UTC, Walter Bright wrote:
 True, D cannot directly read .h files. There are tools, though, 
 to convert C .h files to D.
'Tools' sounds very capritious, but I have no experience with such things. I somehow doubt things like SWIG will work ok on kernel headers (let's assume driver\LKM development).
 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.
I think that would be most logical thing to have, but that would also imply preprocessor, or at least it's restricted subset, wich you most probably though about as well.
 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.
I have no doubt it can be done in the end. I solely imply that the disadvantage here is that in C's "main" (imo) use case it has to be done, and that is a thing to be concerned about when picking a language. Building baroque district in brutalist city is intriguing, but good luck pushing it through municipality and ministry of culture. It's content must be realy fancy. That is not a problem though, if you're building a little town of your own somewhere nearby.
Feb 05
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 5 February 2018 at 08:06:16 UTC, Boris-Barboris wrote:
 I have no doubt it can be done in the end. I solely imply that 
 the disadvantage here is that in C's "main" (imo) use case it 
 has to be done, and that is a thing to be concerned about when 
 picking a language.
Yes, the wheels are turning. C is for portability and C++ is for system level programming.
Feb 05
parent reply psychoticRabbit <meagain meagain.com> writes:
On Monday, 5 February 2018 at 10:23:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 5 February 2018 at 08:06:16 UTC, Boris-Barboris 
 wrote:
 I have no doubt it can be done in the end. I solely imply that 
 the disadvantage here is that in C's "main" (imo) use case it 
 has to be done, and that is a thing to be concerned about when 
 picking a language.
Yes, the wheels are turning. C is for portability and C++ is for system level programming.
C is for trusting the programmer, so that they can do anything. It's also for keeping things fast - *even if not portable*. Last but not least, C is for keeping things small, and simple. (btw. these are somewhat paraphrased versions I took from a MISRA C paper) C does all this really well, and has done so... for a very long time. I believe this is why its not so easy to create a 'better' C (let alone convince people that there is a need for a better c)
Feb 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 5 February 2018 at 11:25:15 UTC, psychoticRabbit wrote:
 C is for trusting the programmer, so that they can do anything.

 It's also for keeping things fast - *even if not portable*.
C++ is the same...
 Last but not least, C is for keeping things small, and simple.
Yes, it takes less discipline to keep executables small in C, thanks to the lack of powerful abstraction mechanisms... Although in theory there is no difference.
 C does all this really well, and has done so... for a very long 
 time.
I don't know how well it does it. When designing for assembly you tend to be annoyed by how inefficient C is in translating to machine language... But people generally don't do that anymore so I guess that perception is lost.
 I believe this is why its not so easy to create a 'better' C 
 (let alone convince people that there is a need for a better c)
I don't think many want a replacement for C, in the sense that the language is very limited. It is possible to create a much better language for embedde programming than C, but the market is not growing, thanks to CPUs being much more powerful now, even for embedded.
Feb 05
parent reply psychoticRabbit <meagain meagain.com> writes:
On Monday, 5 February 2018 at 11:38:58 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 5 February 2018 at 11:25:15 UTC, psychoticRabbit 
 wrote:
 C is for trusting the programmer, so that they can do anything.

 It's also for keeping things fast - *even if not portable*.
C++ is the same...
No. C++ is primarliy about higher order abstractions. That's why it came about. Without the need for those higher order abstractions, C is just fine - no need for C++ The benefits of C, come from C - and only C (and some good compiler writers)
 I believe this is why its not so easy to create a 'better' C 
 (let alone convince people that there is a need for a better c)
I don't think many want a replacement for C, in the sense that the language is very limited.
(depends on what 'many' means) - There certinaly are 'numerous' (what ever that means) projects trying to create a better c - which contradicts your assertion. A limited language can be a good thing too.
Feb 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 5 February 2018 at 12:23:58 UTC, psychoticRabbit wrote:
 No. C++ is primarliy about higher order abstractions. That's 
 why it came about.
 Without the need for those higher order abstractions, C is just 
 fine - no need for C++
Actually, many programmers switched to C++ in the 90s just to get function overloads and inlining without macros. If you think C is just fine then I'm not sure why you are interested in D.
 The benefits of C, come from C - and only C (and some good 
 compiler writers)
Not sure what you mean by that. There is little overhead by using C++ over C if you set your project up for that. The only benefits with C these days is portability.
 (depends on what 'many' means)  - There certinaly are 
 'numerous' (what ever that means) projects trying to create a 
 better c - which contradicts your assertion.
Which ones are you thinking of?
Feb 05
parent psychoticRabbit <meagain meagain.com> writes:
On Monday, 5 February 2018 at 16:03:44 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 5 February 2018 at 12:23:58 UTC, psychoticRabbit 
 wrote:
 No. C++ is primarliy about higher order abstractions. That's 
 why it came about.
 Without the need for those higher order abstractions, C is 
 just fine - no need for C++
Actually, many programmers switched to C++ in the 90s just to get function overloads and inlining without macros.
Not me. I refused (during the 90's) to use C++ for anything ;-) (my housemate loved C++ though - to this day, I still don't know why..)
 If you think C is just fine then I'm not sure why you are 
 interested in D.
Cause D is interesting (too)... do I have to choose only one language?? I have my own IDE - which I wrote, and i can switch between (currently) 7 different languages - with just a single click of my mouse button. I'll keep adding more languages that interest me.
 The benefits of C, come from C - and only C (and some good 
 compiler writers)
Not sure what you mean by that.
I mean C++ was implemented upon the foundation of C - as such, C++ was able to take advantage of what that foundation offered.
 There is little overhead by using C++ over C if you set your 
 project up for that. The only benefits with C these days is 
 portability.

 (depends on what 'many' means)  - There certinaly are 
 'numerous' (what ever that means) projects trying to create a 
 better c - which contradicts your assertion.
Which ones are you thinking of?
I looked at several recently - I can't recall them all .. but for starters.. (C2 -- interestingly this seems a lot like D) http://c2lang.org/site/ (CheckedC - a Microsoft Research Project to 'extend' C) https://www.microsoft.com/en-us/research/project/checked-c/
Feb 05
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/5/2018 12:06 AM, Boris-Barboris wrote:
 I think that would be most logical thing to have, but that would also imply 
 preprocessor, or at least it's restricted subset, wich you most probably
though 
 about as well.
Sure. I could use the Boost licensed preprocessor in DMC, or the Boost licensed preprocessor in Warp.
 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.
I have no doubt it can be done in the end. I solely imply that the disadvantage here is that in C's "main" (imo) use case it has to be done, and that is a thing to be concerned about when picking a language.
Most of those gcc builtin's I've never heard of, and I've been programming C for 35 years now. I've also never had a use for them. I find it hard to believe that list would be a deal breaker, especially since much of it seems to be a replacement for the inline assembler, and D has a nice inline assembler. This is called "checklisting". One lists the features of X culled from the documentation, and then compares it with Y. Inevitably, Y is found wanting. The checklist is never taken from the features of Y, because then X would be wanting :-) This can be done with virtually any X and Y. (Also, the builtins are extensions, and are hardly reliably available in any random Standard-conforming C compiler.)
Feb 05
next sibling parent reply Boris-Barboris <ismailsiege gmail.com> writes:
On Monday, 5 February 2018 at 20:12:09 UTC, Walter Bright wrote:
 Most of those gcc builtin's I've never heard of, and I've been 
 programming C for 35 years now. I've also never had a use for 
 them. I find it hard to believe that list would be a deal 
 breaker, especially since much of it seems to be a replacement 
 for the inline assembler, and D has a nice inline assembler.
Inline assembler requires, ghm, assembly. Builtins are a bit more gracious. I have been dabbling in C for 6 months during OS course about 3 years ago, when I for some reason wanted to have a good understanding of Linux scheduler, and I wrote a toy real-time periodic scheduling class. The code there is swarming with stuff like 'likely\unlikely' and other tricks, wich is understandable, if the importance of it's speed is taken into consideration. The point is, I could use stuff written by people way more experienced than me without writing a single line of assembly, just because it was already there, tested and integrated into the compiler, and there were plenty of examples in other parts of battle-tested code. "Here is a one-liner wich may make your condition statements faster, if you use it right. Here's how you use it, here's the doc wich teaches how it works under the hood, so you don't cargo cult". Pretty neat in my opinion. Of course you can write it in asm, but you don't need to under gcc. Oh, and look what I just found: https://github.com/rust-lang/rust/issues/26179
 This is called "checklisting". One lists the features of X 
 culled from the documentation, and then compares it with Y. 
 Inevitably, Y is found wanting. The checklist is never taken 
 from the features of Y, because then X would be wanting :-)

 This can be done with virtually any X and Y.
If Y is not a superset of X, you always lose something when ditching X for Y. No place for miracles under the sun.
 (Also, the builtins are extensions, and are hardly reliably 
 available in any random Standard-conforming C compiler.)
I am of the opinion that currently C has no use outside of OS\embedded stuff (everywhere else it has a superior competitor, imo), and therefore I don't share this concern about C's portability. Well, that, and the fact that I am probably of about half of your age, wich distinguishes the C we know. You probably remember it big\general purpose, but it never was in my days. Extentions wouldn't emerge, if pure C was enough.
Feb 05
next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
 "Here is a one-liner wich may make your condition statements 
 faster, if you use it right.
There is PGO (Profile Guided Optimization) that can do that without additional language extensions. You need to find better example to support your claims.
Feb 05
parent Boris-Barboris <ismailsiege gmail.com> writes:
On Monday, 5 February 2018 at 23:42:18 UTC, welkam wrote:
 There is PGO (Profile Guided Optimization) that can do that 
 without additional language extensions. You need to find better 
 example to support your claims.
It is sometimes impossible. Some parts of the Linux kernel cannot be profiled at all, for example. My claim is simple: you switch from gcc -> you lose this thing. I don't even care if it has actually mattered. I had a choice then, and now I don't. I have different choices now.
Feb 05
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
 I am of the opinion that currently C has no use outside of 
 OS\embedded stuff....
Plenty of others seems to have a different opinion ;-) https://github.com/kozross/awesome-c (and that link is just for starters)
Feb 05
parent Boris-Barboris <ismailsiege gmail.com> writes:
On Tuesday, 6 February 2018 at 02:31:42 UTC, psychoticRabbit 
wrote:
 Plenty of others seems to have a different opinion ;-)
That's just my opinion. My generation has plenty of C++ programmers, but I have no acquaintance who does userspace C. I would never do that too, unless forced to work with existing code base. I don't know why would freshman\young dude do that today.
Feb 05
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
 Oh, and look what I just found:
 https://github.com/rust-lang/rust/issues/26179
Oh, look: https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587 — David
Feb 06
next sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger 
wrote:
 On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris 
 wrote:
 Oh, and look what I just found:
 https://github.com/rust-lang/rust/issues/26179
Oh, look: https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587
Ahahah, noyce! :o)
Feb 06
prev sibling next sibling parent Boris-Barboris <ismailsiege gmail.com> writes:
On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger 
wrote:
 Oh, look:

 https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587

  — David
Not gcc, no platforms, BEBEBEBEBEBE. On the serious note: nice, good to see.
Feb 06
prev sibling parent reply Boris-Barboris <ismailsiege gmail.com> writes:
On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger 
wrote:

Apparently, GDC folks do not populate builtin module, so there's 
no easy way to look check it, besides actually trying to compile:
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/builtins.d#L24
A bit of a shame it's so implicit, but it will probably actually 
work.
Feb 06
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 7 February 2018 at 06:29:01 UTC, Boris-Barboris 
wrote:
 On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger 
 wrote:

 Apparently, GDC folks do not populate builtin module, so 
 there's no easy way to look check it, besides actually trying 
 to compile:
 https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/builtins.d#L24
 A bit of a shame it's so implicit, but it will probably 
 actually work.
Read the docs, not the source code. ;-) If all types have a D equivalent, and it isn't a generic macro style built-in. Then it will be generated and pushed to the module. https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins https://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target-Builtins But indeed you do have the generate interface file trick to emit a .di of the module which will be populated with all available functions.
Feb 06
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Monday, 5 February 2018 at 20:12:09 UTC, Walter Bright wrote:
 much of it seems to be a replacement for the inline assembler, 
 and D has a nice inline assembler.
Inline assembler is not portable and limits optimizing compilers ability to optimize your code. Also assembler is bad at communicating intent but judging from the code both you and Andrei write you do not value the idea of self documenting code with one or two letter variables everywhere in your code. To write really low level code you need more than what standard C provides because just changing alignment can have huge difference in performance https://stackoverflow.com/questions/19470873/why-does-gcc-generate-15-20-faster-code-if-i-optimize-for-size-instead-of-speed
Feb 05
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 5 February 2018 at 20:12:09 UTC, Walter Bright wrote:
 On 2/5/2018 12:06 AM, Boris-Barboris wrote:
 I think that would be most logical thing to have, but that 
 would also imply preprocessor, or at least it's restricted 
 subset, wich you most probably though about as well.
Sure. I could use the Boost licensed preprocessor in DMC, or the Boost licensed preprocessor in Warp.
I tried Warp on a non-trivial C codebase. It didn't work (by which I mean the code wouldn't compile with it). I don't know how clang managed to build a (for all practical purposes I can see) bug-compatible preprocessor from scratch to gcc, but it did and in large projects it makes a difference. Atila
Feb 06
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-02-06 10:51, Atila Neves wrote:

 I tried Warp on a non-trivial C codebase. It didn't work (by which I 
 mean the code wouldn't compile with it). I don't know how clang managed 
 to build a (for all practical purposes I can see) bug-compatible 
 preprocessor from scratch to gcc, but it did and in large projects it 
 makes a difference.
"gcc" on macOS is an alias to "clang". The idea was to replace GCC with Clang without having to do any changes what so every, code changes, configuration, linking, even the name of the compiler. -- /Jacob Carlborg
Feb 06
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2018 1:51 AM, Atila Neves wrote:
 I tried Warp on a non-trivial C codebase. It didn't work (by which I mean the 
 code wouldn't compile with it). I don't know how clang managed to build a (for 
 all practical purposes I can see) bug-compatible preprocessor from scratch to 
 gcc, but it did and in large projects it makes a difference.
Warp successfully compiles all of Boost, including their advanced preprocessor metaprogramming library. So it's very, very compatible. If you have something that didn't work, I suspect it is because the user-defined list of predefined macros supplied to Warp wasn't correct. If that wasn't it, I'd appreciate it if you could boil down what went wrong.
Feb 08
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2018-02-05 06:28, Walter Bright wrote:

 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.
I did that as an experiment. Embedding DStep in the compiler [1]. It got a mixed response. Some prefer to have it as a separate tool, some prefer to have it built-in. DStep depends on libclang, meaning the compiler would depend on libclang as well. [1] https://forum.dlang.org/post/ks3kir$1ubq$1 digitalmars.com -- /Jacob Carlborg
Feb 05
parent Atila Neves <atila.neves gmail.com> writes:
On Monday, 5 February 2018 at 12:41:29 UTC, Jacob Carlborg wrote:
 On 2018-02-05 06:28, Walter Bright wrote:

 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.
I did that as an experiment. Embedding DStep in the compiler [1]. It got a mixed response. Some prefer to have it as a separate tool, some prefer to have it built-in. DStep depends on libclang, meaning the compiler would depend on libclang as well. [1] https://forum.dlang.org/post/ks3kir$1ubq$1 digitalmars.com
I started working on something like this, but not integrated with the compiler. But also not like DStep. Atila
Feb 05
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 04
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
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.
Feb 04
parent bpr <brogoff gmail.com> writes:
On Monday, 5 February 2018 at 01:38:13 UTC, psychoticRabbit wrote:
 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 ;-)
Thanks, that's a good answer! I did put a bit of effort in trying out betterC (I don't write C these days and it was fun) but I admit I don't program in the 16 bit realm. I'm more interested in HPC than tiny embedded systems, so my concerns are probably different.
Feb 05
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2018-02-04 at 20:15 +0000, bpr via Digitalmars-d wrote:
=20
 [=E2=80=A6]
 Maybe, Rust is a decent language, and it appears to be getting=20
 better faster than D is. I recall the announcement of an=20
 experimental precise GC for D in 2013 or so, and Andrei at the=20
 time made it clear that a precise GC would be worth it even at=20
 some cost in performance. I don't think D will ever get a precise=20
 GC. Maybe the Rust and "Modern C++" guys are right and it's not=20
 worth it in a systems programming language?
Go is a systems programming language with a GC. Well at any one time there is one GC, but it does keep evolving, changing, and improving. The Go team obsess, and quite right too, about having a GC that has as little effect on the user application as possible. As does the JVM. I think it is now on the seventh GC, and it always gets better. G1GC is very good but still people are trying to improve it. The problem seems to be when you have a GC and don't then try to improve it. [=E2=80=A6] --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Feb 05
prev sibling parent reply John Gabriele <jgabriele fastmail.fm> writes:
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? 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.
What is the specific purpose of -betterC? I see from <https://dlang.org/spec/betterc.html> that it's (A) useful when targeting constrained environments, and (B) for easier embedding of D libraries into larger projects. But I think I've read elsewhere in this forum that it was specifically useful for the DMD implementation itself. Is betterC intended to be used for standalone "D -betterC" programs where C might've otherwise been used? My impression of D so far is that it can indeed already be used as a better C by avoiding the GC yourself, or invoking it yourself when appropriate. It may be useful if that betterc.html page gave a rationale for it; to avoid any confusion on what its intended purpose is.
Feb 05
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, February 05, 2018 18:54:32 John Gabriele via Digitalmars-d wrote:
 What is the specific purpose of -betterC? I see from
 <https://dlang.org/spec/betterc.html> that it's (A) useful when
 targeting constrained environments, and (B) for easier embedding
 of D libraries into larger projects. But I think I've read
 elsewhere in this forum that it was specifically useful for the
 DMD implementation itself.

 Is betterC intended to be used for standalone "D -betterC"
 programs where C might've otherwise been used? My impression of D
 so far is that it can indeed already be used as a better C by
 avoiding the GC yourself, or invoking it yourself when
 appropriate.

 It may be useful if that betterc.html page gave a rationale for
 it; to avoid any confusion on what its intended purpose is.
Based on Walter's comments, I get the impression that he thinks that the primary benefit of -betterC is to make it easier to port a C program to D, because then you can port it piece by piece rather than having to do it all at once. After that, it's D, and you can ditch -betterC and start taking advantage of the full feature set of D. Certainly, that's all that I would ever consider using -betterC for. I have zero interest in giving up on the features that require druntime. If I were going to consider that, I'd just ditch D for C++. At least then, I'd get a fully featured language even if it isn't as nice as D. However, there are some folks who like the idea of using -betterC as their primary or only way to use D, because they don't want the runtime for whatever reason. Some of that comes from the fact that it's easier to link against a D library from a C/C++ program when the D library doesn't require the runtime, but I don't think that that's the only reason. - Jonathan M Davis
Feb 05
parent John Gabriele <jgabriele fastmail.fm> writes:
On Monday, 5 February 2018 at 22:56:47 UTC, Jonathan M Davis 
wrote:
 On Monday, February 05, 2018 18:54:32 John Gabriele via 
 Digitalmars-d wrote:
 What is the specific purpose of -betterC? I see from 
 <https://dlang.org/spec/betterc.html> that it's (A) useful 
 when targeting constrained environments, and (B) for easier 
 embedding of D libraries into larger projects. But I think 
 I've read elsewhere in this forum that it was specifically 
 useful for the DMD implementation itself.

 Is betterC intended to be used for standalone "D -betterC" 
 programs where C might've otherwise been used? My impression 
 of D so far is that it can indeed already be used as a better 
 C by avoiding the GC yourself, or invoking it yourself when 
 appropriate.

 It may be useful if that betterc.html page gave a rationale 
 for it; to avoid any confusion on what its intended purpose is.
Based on Walter's comments, I get the impression that he thinks that the primary benefit of -betterC is to make it easier to port a C program to D, because then you can port it piece by piece rather than having to do it all at once. After that, it's D, and you can ditch -betterC and start taking advantage of the full feature set of D. Certainly, that's all that I would ever consider using -betterC for. I have zero interest in giving up on the features that require druntime. If I were going to consider that, I'd just ditch D for C++. At least then, I'd get a fully featured language even if it isn't as nice as D.
Thanks, Jonathan! Sounds like a great tool to have available to assist migrating to D.
 However, there are some folks who like the idea of using 
 -betterC as their primary or only way to use D, because they 
 don't want the runtime for whatever reason. Some of that comes 
 from the fact that it's easier to link against a D library from 
 a C/C++ program when the D library doesn't require the runtime, 
 but I don't think that that's the only reason.
Ah, I see. Around this notion then is where I'm seeing some folks here concerned about D "choosing a direction". If your impression (your first paragraph) is correct, then D has actually not changed direction (wrt betterC) in the first place. Incidentally, this is one of those situations that reminds me how important names are, for example: * "D" = "the new and improved next incarnation of C/C++" * "-betterC" = "use this as a better (and in place of) C" Naming is hard!
Feb 06
prev sibling next sibling parent Laeeth Isharc <laeeth laeeth.com> writes:
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
Feb 04
prev sibling parent reply Ralph Doncaster <nerdralph github.com> writes:
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
 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.
Thanks for the detailed post. I'm an old C/C++ guy (got started with C++ back in the cfront days), and have been kicking the tires on D recently. The poor state of libraries is something that may push me away from D as well. In my case, need opencl and crypto libs. The opencl package in dub is a crude wrapper around the original C API. I couldn't find any sha lib, so I've started porting a reference sha3 implementation from C. I, like you, may end up jumping off the ship though. I've done a bit of work with golang before, so maybe I'll take another look at it. The opencl bindings aren't much better, but there are ready-made sha3 libs I can use instead of porting from C.
Feb 06
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster 
wrote:
 The opencl package in dub is a crude wrapper around the 
 original C API.  I couldn't find any sha lib, so I've started 
 porting a reference sha3 implementation from C.
Don't port libraries like that, just call them directly. Porting crypto stuff is just asking for bugs and there's fairly little benefit over just calling them.
Feb 06
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 06, 2018 at 08:55:31PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
 On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote:
 The opencl package in dub is a crude wrapper around the original C
 API.  I couldn't find any sha lib, so I've started porting a
 reference sha3 implementation from C.
Don't port libraries like that, just call them directly. Porting crypto stuff is just asking for bugs and there's fairly little benefit over just calling them.
Yeah, porting crypto code is usually a bad idea unless you're a crypto expert. Careless porting of crypto code is often vulnerable especially to side-channel attacks due to unexpected interactions with the target language and/or subtle semantic differences. D was designed especially to interface with C as painlessly as possible, so if your chosen crypto library has a C API, the best approach is just to call it directly. Wrapping an idiomatic D interface around it is nice, but I'd still leave the actual implementation to the C library. T -- Those who don't understand Unix are condemned to reinvent it, poorly.
Feb 06
prev sibling parent reply Ralph Doncaster <nerdralph github.com> writes:
On Tuesday, 6 February 2018 at 20:55:31 UTC, Adam D. Ruppe wrote:
 On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster 
 wrote:
 The opencl package in dub is a crude wrapper around the 
 original C API.  I couldn't find any sha lib, so I've started 
 porting a reference sha3 implementation from C.
Don't port libraries like that, just call them directly. Porting crypto stuff is just asking for bugs and there's fairly little benefit over just calling them.
Is there an automatic way to make D wrappers for all the C function calls? There's also the problem that the test code for the C/C++ libraries would have to be wrapped up into the library or ported to D. Although I'm new to D, I do know crypto quite well, and especially sha3/keccak. One reason I considered porting was to see if dmd outputs better code than gcc. On x86_64 with the xmm registers there is enough room for 1600 bits of the keccak state to be stored in registers, but gcc 5.4 will still use RAM for the state. It stays in L1, but storing all the state in registers should be much faster as it would avoid a lot of mov instructions loading parts of the state into registers.
Feb 06
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, February 06, 2018 21:44:16 Ralph Doncaster via Digitalmars-d 
wrote:
 One reason I considered porting was to
 see if dmd outputs better code than gcc.
It almost certainly won't. dmd compiles code lightning fast and has a decent optimizer, but it's really not on par with gcc or llvm's optimizers at this point. For quite some time now, Walter's focus has been on D's frontend, not on the dmd backend (which is dmc), and he's the main person who would improve the backend, whereas gcc and llvm have a number of folks working on improving their optimizers. If you want comparable optimization, then you'd need to use gdc or ldc - though until gdc has another release, it's using a rather old version of the frontend, so ldc would be better; the gdc folks were seriously delayed in updating after the frontend switched to D. When using gdc or ldc, you can get binaries that compare quite favorably with C/C++ - even beat them in some case - but in general, if you compare C/C++ code compiled with gcc or clang, it will probably beat dmd compiled code - not necessarily by leaps and bounds but consistently enough that if you want your code to be as fast as possible, then you use gdc or ldc for your production builds. - Jonathan M Davis
Feb 06
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Tuesday, 6 February 2018 at 21:44:16 UTC, Ralph Doncaster 
wrote:

 Is there an automatic way to make D wrappers for all the C 
 function calls?
https://github.com/jacob-carlborg/dstep
Feb 06
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 06, 2018 at 09:44:16PM +0000, Ralph Doncaster via Digitalmars-d
wrote:
[...]
 Although I'm new to D, I do know crypto quite well, and especially
 sha3/keccak.  One reason I considered porting was to see if dmd outputs
 better code than gcc.  On x86_64 with the xmm registers there is enough room
 for 1600 bits of the keccak state to be stored in registers, but gcc 5.4
 will still use RAM for the state.  It stays in L1, but storing all the state
 in registers should be much faster as it would avoid a lot of mov
 instructions loading parts of the state into registers.
Don't have high expectations of dmd's codegen. If you're looking for highly-optimized codegen, you want to be using ldc or gdc instead. In my own projects, I routinely find that executables produced by dmd are about 30-50% slower than executables produced by gdc or ldc. What dmd is very good at is lightning fast compilation, and also having the latest and greatest D features, being the reference compiler and all that. However, it's optimizer leaves much to be desired. For performance-sensitive code, my recommendation is, don't even bother with dmd. That's not to say that dmd codegen is bad; it's pretty decent for your average non-performance-sensitive GUI app. But it doesn't hold a candle to gdc/ldc, especially when it comes to loop optimizations. T -- Дерево держится корнями, а человек - друзьями.
Feb 06
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 6 February 2018 at 21:44:16 UTC, Ralph Doncaster 
wrote:
 Is there an automatic way to make D wrappers for all the C 
 function calls?
Yeah, I hear the dstep https://github.com/jacob-carlborg/dstep works well, though I haven't personally used it - I just bring in C functions by hand and that's fairly easy (certainly a lot easier than actually porting the whole thing!) and a one time thing, then it can keep up with impl updates with upstream easily - the interface rarely changes, so you just update it like anything else.
  One reason I considered porting was to see if dmd outputs 
 better code than gcc.
If you want D to outperform C, it usually means doing architecture changes, and mature C libraries are usually already pretty heavily optimized and hard to beat. D and C have about the same performance potential; when fully optimized by hand and by machine, both will top out about the same. D's big advantage over C is that is is easier to realize that potential; it takes less programmer effort to write the faster code in the first place. But again, if the C library already has the work done to it, D is unlikely to actually beat it, especially with a direct port where it is likely to generate basically the same machine code (or worse - dmd's optimizer is generally worse than gcc's, and gdc's optimizer is exactly the same as gcc's).
Feb 06
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster 
wrote:
 Thanks for the detailed post.  I'm an old C/C++ guy (got 
 started with C++ back in the cfront days), and have been 
 kicking the tires on D recently.  The poor state of libraries 
 is something that may push me away from D as well.  In my case, 
 need opencl and crypto libs.  The opencl package in dub is a 
 crude wrapper around the original C API.  I couldn't find any 
 sha lib, so I've started porting a reference sha3 
 implementation from C.

 I, like you, may end up jumping off the ship though.  I've done 
 a bit of work with golang before, so maybe I'll take another 
 look at it.  The opencl bindings aren't much better, but there 
 are ready-made sha3 libs I can use instead of porting from C.
For crypto there is also Botan: http://code.dlang.org/packages/botan https://github.com/etcimon/botan For OpenCL I develop and maintain DCompute: http://code.dlang.org/packages/dcompute https://github.com/libmir/dcompute It has a much beautified interface to OpenCL (and is mostly consistent with its CUDA interface). You can also write kernels directly in D, however this requires that LDC is built against my fork of LLVM: https://github.com/thewilsonator/llvm It's still in dev but should be usable. Please let me know if you have issues using it.
Feb 07
parent reply Ralph Doncaster <nerdralph github.com> writes:
On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson 
wrote:
 On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster 
 wrote:
 I, like you, may end up jumping off the ship though.  I've 
 done a bit of work with golang before, so maybe I'll take 
 another look at it.  The opencl bindings aren't much better, 
 but there are ready-made sha3 libs I can use instead of 
 porting from C.
For crypto there is also Botan: http://code.dlang.org/packages/botan https://github.com/etcimon/botan
That looks more promising. Strange that it doesn't show up when searching for sha or sha3. https://code.dlang.org/search?q=sha3
 For OpenCL I develop and maintain DCompute:
 http://code.dlang.org/packages/dcompute
 https://github.com/libmir/dcompute

 It has a much beautified interface to OpenCL (and is mostly 
 consistent with its CUDA interface). You can also write kernels 
 directly in D, however this requires that LDC is built against 
 my fork of LLVM: https://github.com/thewilsonator/llvm

 It's still in dev but should be usable. Please let me know if 
 you have issues using it.
I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.
Feb 07
parent reply Ralph Doncaster <nerdralph github.com> writes:
On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster 
wrote:
 On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson 
 wrote:
 For OpenCL I develop and maintain DCompute:
 http://code.dlang.org/packages/dcompute
 https://github.com/libmir/dcompute

 It has a much beautified interface to OpenCL (and is mostly 
 consistent with its CUDA interface). You can also write 
 kernels directly in D, however this requires that LDC is built 
 against my fork of LLVM: https://github.com/thewilsonator/llvm

 It's still in dev but should be usable. Please let me know if 
 you have issues using it.
I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.
p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD. I use -legacy when building my kernels to get the good old compiler.
Feb 07
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster 
wrote:
 On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster 
 wrote:
 On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson 
 wrote:
 For OpenCL I develop and maintain DCompute:
 http://code.dlang.org/packages/dcompute
 https://github.com/libmir/dcompute

 It has a much beautified interface to OpenCL (and is mostly 
 consistent with its CUDA interface). You can also write 
 kernels directly in D, however this requires that LDC is 
 built against my fork of LLVM: 
 https://github.com/thewilsonator/llvm

 It's still in dev but should be usable. Please let me know if 
 you have issues using it.
I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.
Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work.
 p.s. since you seem to be a green team guy, you might not know 
 that llvm optimization sucks on AMD.  I use -legacy when 
 building my kernels to get the good old compiler.
"green team guy"? It that with the OpenCL C compiler? DCompute goes through SPIR-V for OpenCL (although it would be nice to support SPIR. Unfortunately the official version SPIR 2.0 is based of is not supported by LDC), I dont know if this makes a difference. It would be nice to eventually support AMDGCN et. al. at some point but I don't have the time at the moment.
Feb 08
parent reply Ralph Doncaster <nerdralph github.com> writes:
On Thursday, 8 February 2018 at 15:59:28 UTC, Nicholas Wilson 
wrote:
 On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster 
 wrote:
 On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster 
 wrote:
 On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas 
 Wilson wrote:
 For OpenCL I develop and maintain DCompute:
 http://code.dlang.org/packages/dcompute
 https://github.com/libmir/dcompute

 It has a much beautified interface to OpenCL (and is mostly 
 consistent with its CUDA interface). You can also write 
 kernels directly in D, however this requires that LDC is 
 built against my fork of LLVM: 
 https://github.com/thewilsonator/llvm

 It's still in dev but should be usable. Please let me know 
 if you have issues using it.
I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.
Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work.
OK, maybe I'll take a closer look.
 p.s. since you seem to be a green team guy, you might not know 
 that llvm optimization sucks on AMD.  I use -legacy when 
 building my kernels to get the good old compiler.
"green team guy"? It that with the OpenCL C compiler?
nVidia's logo is green, while AMD's logo is often red. On Linux with AMDGPU-Pro 17 and up, the driver uses llvm/amdgpu. The driver still has the old gcc-based? compiler. The old compiler can be selected with clBuildProgram using the option "-legacy".
Feb 08
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 8 February 2018 at 17:24:31 UTC, Ralph Doncaster 
wrote:
 On Thursday, 8 February 2018 at 15:59:28 UTC, Nicholas Wilson 
 wrote:
 On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster 
 wrote:
 On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph 
 Doncaster wrote:
 On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas 
 Wilson wrote:
 For OpenCL I develop and maintain DCompute:
 http://code.dlang.org/packages/dcompute
 https://github.com/libmir/dcompute

 It has a much beautified interface to OpenCL (and is mostly 
 consistent with its CUDA interface). You can also write 
 kernels directly in D, however this requires that LDC is 
 built against my fork of LLVM: 
 https://github.com/thewilsonator/llvm

 It's still in dev but should be usable. Please let me know 
 if you have issues using it.
I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.
Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work.
OK, maybe I'll take a closer look.
 p.s. since you seem to be a green team guy, you might not 
 know that llvm optimization sucks on AMD.  I use -legacy when 
 building my kernels to get the good old compiler.
"green team guy"? It that with the OpenCL C compiler?
nVidia's logo is green, while AMD's logo is often red.
Ah, I have no affiliation with any of the hardware vendors. The only reason DCompute supports CUDA is LLVM has a backend for it and I thought "it can't be too hard". I test (not nearly as frequently as I should) on a rather old Intel CPU and very old (CC2.1) Nvidia card, simply due to availability (i.e. I had them before I started). CI Testing is on my list of things to do but I just haven't got around to it yet.
 On Linux with AMDGPU-Pro 17 and up, the driver uses 
 llvm/amdgpu.  The driver still has the old gcc-based? compiler.
  The old compiler can be selected with clBuildProgram using the 
 option "-legacy".
Unfortunately I can't help much there but I should definitely test (and optimise) with AMD. Hopefully it catches up with the legacy one because DCompute is currently tied to LDC and hence LLVM. The mainlining of polly, region vectoriser and VPlan should boost perf all round.
Feb 08