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

2018-02-08 Thread Walter Bright via Digitalmars-d

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.


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

2018-02-08 Thread Nicholas Wilson via Digitalmars-d
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.


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

2018-02-08 Thread Ralph Doncaster via Digitalmars-d
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".





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

2018-02-08 Thread Nicholas Wilson via Digitalmars-d
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.


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

2018-02-07 Thread Ralph Doncaster via Digitalmars-d
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.


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

2018-02-07 Thread Ralph Doncaster via Digitalmars-d
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.




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

2018-02-07 Thread Nicholas Wilson via Digitalmars-d
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.


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

2018-02-06 Thread Iain Buclaw via Digitalmars-d
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.


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

2018-02-06 Thread Boris-Barboris via Digitalmars-d
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.




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

2018-02-06 Thread Boris-Barboris via Digitalmars-d
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.


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

2018-02-06 Thread Adam D. Ruppe via Digitalmars-d
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).


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

2018-02-06 Thread Luís Marques via Digitalmars-d
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)


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

2018-02-06 Thread David Nadlinger via Digitalmars-d

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


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

2018-02-06 Thread H. S. Teoh via Digitalmars-d
On Tue, Feb 06, 2018 at 09:44:16PM +, 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

-- 
Дерево держится корнями, а человек - друзьями.


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

2018-02-06 Thread bachmeier via Digitalmars-d
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


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

2018-02-06 Thread Jacob Carlborg via Digitalmars-d

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


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

2018-02-06 Thread Jonathan M Davis via Digitalmars-d
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



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

2018-02-06 Thread Ralph Doncaster via Digitalmars-d

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.


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

2018-02-06 Thread H. S. Teoh via Digitalmars-d
On Tue, Feb 06, 2018 at 08:55:31PM +, 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.


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

2018-02-06 Thread Adam D. Ruppe via Digitalmars-d
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.


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

2018-02-06 Thread Ralph Doncaster via Digitalmars-d

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.





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

2018-02-06 Thread John Gabriele via Digitalmars-d
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 
 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!



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

2018-02-06 Thread Atila Neves via Digitalmars-d

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


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

2018-02-05 Thread Boris-Barboris via Digitalmars-d
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.




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

2018-02-05 Thread Boris-Barboris via Digitalmars-d

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.


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

2018-02-05 Thread psychoticRabbit via Digitalmars-d
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/




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

2018-02-05 Thread psychoticRabbit via Digitalmars-d

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)



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

2018-02-05 Thread welkam via Digitalmars-d

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



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

2018-02-05 Thread welkam via Digitalmars-d

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.


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

2018-02-05 Thread Jonathan M Davis via Digitalmars-d
On Monday, February 05, 2018 18:54:32 John Gabriele via Digitalmars-d wrote:
> What is the specific purpose of -betterC? I see from
>  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



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

2018-02-05 Thread Boris-Barboris via Digitalmars-d

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.



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

2018-02-05 Thread Walter Bright via Digitalmars-d

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


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

2018-02-05 Thread John Gabriele via Digitalmars-d

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




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

2018-02-05 Thread Ola Fosheim Grøstad via Digitalmars-d

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?



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

2018-02-05 Thread bpr via Digitalmars-d

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.


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

2018-02-05 Thread Atila Neves via Digitalmars-d

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


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

2018-02-05 Thread Russel Winder via Digitalmars-d
On Sun, 2018-02-04 at 20:15 +, bpr via Digitalmars-d wrote:
> 
> […]

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

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.

[…]
-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part


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

2018-02-05 Thread Jacob Carlborg via Digitalmars-d

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


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

2018-02-05 Thread psychoticRabbit via Digitalmars-d
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.



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

2018-02-05 Thread Ola Fosheim Grøstad via Digitalmars-d

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.




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

2018-02-05 Thread psychoticRabbit via Digitalmars-d
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)




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

2018-02-05 Thread Michael via Digitalmars-d
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.


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

2018-02-05 Thread Ola Fosheim Grøstad via Digitalmars-d

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.




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

2018-02-05 Thread Boris-Barboris via Digitalmars-d

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.


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

2018-02-05 Thread psychoticRabbit via Digitalmars-d

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.

:)


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

2018-02-04 Thread Dgame via Digitalmars-d

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!


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

2018-02-04 Thread Laeeth Isharc via Digitalmars-d

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 

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

2018-02-04 Thread Walter Bright via Digitalmars-d

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.


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

2018-02-04 Thread psychoticRabbit via Digitalmars-d

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.



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

2018-02-04 Thread welkam via Digitalmars-d

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.


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

2018-02-04 Thread Walter Bright via Digitalmars-d

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.


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

2018-02-04 Thread Boris-Barboris via Digitalmars-d

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.


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

2018-02-04 Thread Dgame via Digitalmars-d

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.


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

2018-02-04 Thread bpr via Digitalmars-d

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.




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

2018-02-04 Thread psychoticRabbit via Digitalmars-d

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 :)




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

2018-02-04 Thread JN via Digitalmars-d

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.


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

2018-02-04 Thread Dgame via Digitalmars-d

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. :)


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

2018-02-04 Thread Dgame via Digitalmars-d

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. :)


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

2018-02-04 Thread Joakim via Digitalmars-d

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%5B%5D=src%5B%5D=ddmd%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


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

2018-02-03 Thread Adam D. Ruppe via Digitalmars-d

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.


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

2018-02-03 Thread Rubn via Digitalmars-d

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


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

2018-02-03 Thread psychoticRabbit via Digitalmars-d

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.



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

2018-02-03 Thread welkam via Digitalmars-d

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


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

2018-02-03 Thread bachmeier via Digitalmars-d

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.


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

2018-02-03 Thread Dgame via Digitalmars-d

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.


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

2018-02-03 Thread Dgame via Digitalmars-d
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.


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

2018-02-03 Thread Christof Schardt via Digitalmars-d

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)





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

2018-02-03 Thread welkam via Digitalmars-d

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?


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

2018-02-03 Thread Norm via Digitalmars-d

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


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

2018-02-03 Thread Dgame via Digitalmars-d
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.


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

2018-02-03 Thread Rubn via Digitalmars-d

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.




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

2018-02-03 Thread bachmeier via Digitalmars-d

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


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

2018-02-03 Thread psychoticRabbit via Digitalmars-d

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



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

2018-02-03 Thread Joakim via Digitalmars-d
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.


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

2018-02-03 Thread Ola Fosheim Grøstad via Digitalmars-d

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.



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

2018-02-03 Thread H. S. Teoh via Digitalmars-d
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


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

2018-02-02 Thread Joakim via Digitalmars-d
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


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

2018-02-02 Thread Walter Bright via Digitalmars-d

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


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

2018-02-02 Thread psychoticRabbit via Digitalmars-d

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)



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

2018-02-02 Thread psychoticRabbit via Digitalmars-d

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





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

2018-02-02 Thread aberba via Digitalmars-d

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.


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

2018-02-02 Thread Adam D. Ruppe via Digitalmars-d

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.


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

2018-02-02 Thread aberba via Digitalmars-d

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.


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

2018-02-02 Thread aberba via Digitalmars-d

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.







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

2018-02-02 Thread user via Digitalmars-d
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.




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

2018-02-02 Thread Rubn via Digitalmars-d

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.


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

2018-02-02 Thread David Gileadi via Digitalmars-d

On 2/2/18 1:38 PM, welkam wrote:

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

** Wall of text **


I dont post here often but...

Most of what you complain is known already and/or not entirely correct. 
People who work on D are not some glue sniffing brain dead individuals 
that are incapable of understanding that documentation is not perfect, 
library support is lacking and user experience is not at the same level 
as C#. That and more are known here. Over the years that I lurked here I 
saw many people come on forums and complain about things that are 
obvious and say them in a way that indirectly imply incompetence of core 
contributors. Things don't work not because of incompetence but because 
there is not enough people working on things. Thats why you get answers 
you get. To fix problems we need people who work so either you become 
one (fix it yourself) or get some one else to work (pay money).


The entire D project is fueled by coffee and dislike of C/C++ and its 
amazing that it achieved so much with so little


It is pretty amazing, and it's a testament to how appealing the D 
language can be, even with all its surrounding pain points.


As a long time lurker it seems like I see posts like Benny's more often 
recently than I recall seeing in years past. This makes me happy--to me 
it's a sign that more people are seriously considering D than used to. I 
also think it's good to be reminded of what newcomers' pain points are, 
and I'm glad Benny took the time to list his.


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

2018-02-02 Thread welkam via Digitalmars-d

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


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

2018-02-02 Thread welkam via Digitalmars-d

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

** Wall of text **


I dont post here often but...

Most of what you complain is known already and/or not entirely 
correct. People who work on D are not some glue sniffing brain 
dead individuals that are incapable of understanding that 
documentation is not perfect, library support is lacking and user 
experience is not at the same level as C#. That and more are 
known here. Over the years that I lurked here I saw many people 
come on forums and complain about things that are obvious and say 
them in a way that indirectly imply incompetence of core 
contributors. Things don't work not because of incompetence but 
because there is not enough people working on things. Thats why 
you get answers you get. To fix problems we need people who work 
so either you become one (fix it yourself) or get some one else 
to work (pay money).


The entire D project is fueled by coffee and dislike of C/C++ and 
its amazing that it achieved so much with so little


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

2018-02-02 Thread bachmeier via Digitalmars-d

On Friday, 2 February 2018 at 17:24:47 UTC, H. S. Teoh wrote:
On Fri, Feb 02, 2018 at 05:01:58PM +, 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.


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

2018-02-02 Thread Arun Chandrasekaran via Digitalmars-d

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.


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

2018-02-02 Thread Ola Fosheim Grøstad via Digitalmars-d

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.




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

2018-02-02 Thread H. S. Teoh via Digitalmars-d
On Fri, Feb 02, 2018 at 05:01:58PM +, 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."


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

2018-02-02 Thread bachmeier via Digitalmars-d

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.


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

2018-02-02 Thread Adam D. Ruppe via Digitalmars-d

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