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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 

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 2018
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 

 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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018



  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 2018



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 2018



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 2018



 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 2018



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 2018



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 2018



  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 2018



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 2018



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 2018



  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 2018



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 2018



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 2018



  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 2018



  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 2018



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 2018



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 2018



 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 2018



 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 2018



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 2018



 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 2018



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 2018



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 2018



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 2018



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 2018



  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 2018



  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 2018



  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 2018



  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 2018



  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 2018