www.digitalmars.com         C & C++   DMDScript  

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

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

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

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

 [...]


This is a pretty well thought out post. Are we getting forward?
Nov 07 2021
next sibling parent jfondren <julian.fondren gmail.com> writes:
On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:

 https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

 Are we getting forward?


You mean, has any of that changed? No, it hasn't. Maybe small 
details like http/2 support have. If your only interest is making 
little HTTP servers then go has few disadvantages vs. D (although 
I'm surprised performance is so bad, when I compared a go UDP 
server with a D one the difference was enormous--go worked 
hundreds of times harder to have a fraction of the throughput). 
I've also found rocket.rs to have competitive compiletimes vs. 
vibe for a little server with a few dozen routes (not from 
scratch obviously, but Rust's edit-compile-test cycle took half 
the time of D's).

If your code amounts to

```python
import solution
solution.work()
```

then the language doesn't matter at all and your complaints start 
to look like that post's: "language A has more investment in its 
solution library than language B has, so I want to use language 
A". Where language might start to matter for you is when you try 
to go against the grain of the the 'solution' library, or when 
something goes wrong, or when you want a feature that wasn't 
intended. This is where my happy little Rust solutions turned 
into nightmares. It didn't matter that Rust has an SMTP server 
library for me to use and d didn't when writing an d SMTP server 
was easier than adding what should be trivial features to the 
Rust server.
Nov 07 2021
prev sibling next sibling parent mw <mingwu gmail.com> writes:
On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:

 https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

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

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

 [...]


 This is a pretty well thought out post. Are we getting forward?



Quote from that post:

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

Sadly it's very true, and I actually have tried to fix the two 
RPC issues that I reported 
(https://forum.dlang.org/thread/ompyepvaeeorbldfyjkd forum.dlang.org)

But I am not a complier guy or network guy, I was not able to 
fixed them myself, so my project using D stalled.

I think that is the same experience for many people who just want 
to use D develop applications: many needed component libraries 
are simply not working. (In 2021, who can live without a network 
/ RPC library?)
Nov 07 2021
prev sibling next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:

 https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

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

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

 [...]


 This is a pretty well thought out post. Are we getting forward?


I had an experience where (because I'm not a network programmer, 
and the situation was time sensitive) I opted to use a Rust 
solution rather than Vibe.d which I tried but found unsuitable. 
It frustrated me because I know D can do a great job in this 
sphere - but I wasn't in a position to do anything about it.

One thing about languages such as Rust and Go is that lots of 
people in their ecosystem have an internet/network programming 
background. So you're likely to find decent server/client 
libraries, and there isn't just one option for a HTTP library, 
but there might be three, four, or more relatively high quality 
libraries. In addition because of the nature of their 
communities, if the "flagship" solution was for any reason to 
become unsuitable, someone would immediately write a great 
replacement.

A lot of issues like this in the D space will be greatly 
ameliorated and some will be eliminated altogether once ImportC 
is made to work robustly. It won't be a "panacea" but it will 
help immeasurably. In that situation, you'd just dial up a C 
library and call it from D. You'd be able to lean on C libraries 
for the tools you need and write D code for the stuff I want to 
build. Bootstrapping from C in this way is the key to resolve 
this issue.
Nov 07 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 7 November 2021 at 21:39:55 UTC, data pulverizer wrote:

 A lot of issues like this in the D space will be greatly 
 ameliorated and some will be eliminated altogether once ImportC 
 is made to work robustly. It won't be a "panacea" but it will 
 help immeasurably. In that situation, you'd just dial up a C 
 library and call it from D. You'd be able to lean on C 
 libraries for the tools you need and write D code for the stuff 
 I want to build. Bootstrapping from C in this way is the key to 
 resolve this issue.


I don't know if using C (or C++) frameworks will provide an 
acceptable programming experience. C frameworks tend to be quite 
distant from what you would expect from a higher level language 
like D. You would have to modify the C framework's «runtime», 
like making it create treads using the D runtime, etc.
Nov 07 2021
parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Sunday, 7 November 2021 at 22:19:13 UTC, Ola Fosheim Grøstad 
wrote:

 I don't know if using C (or C++) frameworks will provide an 
 acceptable programming experience. C frameworks tend to be 
 quite distant from what you would expect from a higher level 
 language like D. You would have to modify the C framework's 
 «runtime», like making it create treads using the D runtime, 
 etc.


You're right that C frameworks programming experience is far from 
D. But I think if you are looking to get work done, it is the 
difference between having the tool there and being able to use D 
and perhaps having to use a different language altogether.

Further more I think that `ImportC` is actually an opportunity to 
show off D's meta-programming features, by presenting how lots of 
imported functions with ordered parameter naming can be "lifted" 
into one of D's nicer programming methodologies including showing 
off std.traits, template/string mixins and so on. Julia does 
similar things with their C library backends.

I haven't had to deal with making C frameworks «runtime» 
multithreaded in D, perhaps because the C libraries I tend to 
call are already multi-threaded, or it wasn't an issue for my use 
case. I think C libraries are a valuable resource to "lean on" 
and perhaps "write away" at a later date if they are not 
suitable, and `ImportC` is central to easing that pathway.

Having said that runtimes *might* become an issue in the near 
future since I am working with interop between R and D. Basic 
things like calling R functions from D and D functions from R can 
be straightforward, but I quickly discovered that since R has 
it's own runtime and memory allocation schemes as does D, there 
were some issues. Certain features in D rely on D runtime, which 
you have to negotiate carefully with R's and you have to use R's 
memory allocation if you want the data accessible in R, but I 
think these are secondary issues - they are more about extending 
functionality and will be negotiated in various ways. The basic 
functionality I require is **immediately** available with a fully 
developed `ImportC`.

As someone whose work is centred on data science C libraries are 
basically at the centre or backend of > 95% of what we do (even 
people working with JVM languages still have to call BLAS, 
Lapack, and so on). `ImportC` would make a huge difference there 
and in many other application spheres.
Nov 08 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 8 November 2021 at 09:02:53 UTC, data pulverizer wrote:

 You're right that C frameworks programming experience is far 
 from D. But I think if you are looking to get work done, it is 
 the difference between having the tool there and being able to 
 use D and perhaps having to use a different language altogether.


Yes, if you want use one language for all projects that is 
absolutely true. Of course, most C libraries do not require a 
"runtime". So you can make elegant wrappers easily for those.



 on. Julia does similar things with their C library backends.


I haven't used Julia, but it sounds interesting. I assume Julia 
is more dynamic/runtime focused than D though?



 there were some issues. Certain features in D rely on D 
 runtime, which you have to negotiate carefully with R's and you 
 have to use R's memory allocation if you want the data 
 accessible in R, but I think these are secondary issues - they 
 are more about extending functionality and will be negotiated 
 in various ways. The basic functionality I require is 
 **immediately** available with a fully developed `ImportC`.


It would be interesting to read about you experiences when the 
time comes, hope you find time to share what worked/didn't work 
here in the forums. Maybe create a separate thread and "blog" 
about strengths and weaknesses? I think there sometimes is a 
distance between language designers and programmers because they 
use the language differently.
Nov 08 2021
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 7 November 2021 at 21:39:55 UTC, data pulverizer wrote:

 On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:

 https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

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

 [...]


 This is a pretty well thought out post. Are we getting forward?


 I had an experience where (because I'm not a network 
 programmer, and the situation was time sensitive) I opted to 
 use a Rust solution rather than Vibe.d which I tried but found 
 unsuitable. It frustrated me because I know D can do a great 
 job in this sphere - but I wasn't in a position to do anything 
 about it.

 One thing about languages such as Rust and Go is that lots of 
 people in their ecosystem have an internet/network programming 
 background. So you're likely to find decent server/client 
 libraries, and there isn't just one option for a HTTP library, 
 but there might be three, four, or more relatively high quality 
 libraries. In addition because of the nature of their 
 communities, if the "flagship" solution was for any reason to 
 become unsuitable, someone would immediately write a great 
 replacement.

 A lot of issues like this in the D space will be greatly 
 ameliorated and some will be eliminated altogether once ImportC 
 is made to work robustly. It won't be a "panacea" but it will 
 help immeasurably. In that situation, you'd just dial up a C 
 library and call it from D. You'd be able to lean on C 
 libraries for the tools you need and write D code for the stuff 
 I want to build. Bootstrapping from C in this way is the key to 
 resolve this issue.


Yeah, I still have hope. I also see much happening in D now. 
There are forces wanting it to succeed. But we need to focus.

Most important thing I need rn (I know ppl find it silly, but 
coming from other languages you get so used to it) is a reliable 
and good IDE with static analysis, autocomplete, goto definition 
that just works and built in package management and a good set of 
core libraries that are rock solid.


is my goal. (We have some devices where we barely have space left 
for dotnet runtime)
Nov 07 2021
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 08/11/2021 11:30 AM, Imperatorn wrote:

 Most important thing I need rn (I know ppl find it silly, but coming 
 from other languages you get so used to it) is a reliable and good IDE 
 with static analysis, autocomplete, goto definition that just works and 
 built in package management and a good set of core libraries that are 
 rock solid.


As of late, when I try goto definition with DCD it works fine.

But the future of DCD is to be rewritten to use dmd-fe.

I did say this on Discord earlier today, that I'm hoping someone steps 
up to do the rewrite (really its a refactor + addition of the extra engine).

But in saying that, this stuff should be owned by the compiler 
developers. They are the ones that are going to make the IDE integration 
actually good.
Nov 07 2021
parent reply Dr Machine Code <jckj33 gmail.com> writes:
On Monday, 8 November 2021 at 01:11:38 UTC, rikki cattermole 
wrote:

 On 08/11/2021 11:30 AM, Imperatorn wrote:

 Most important thing I need rn (I know ppl find it silly, but 
 coming from other languages you get so used to it) is a 
 reliable and good IDE with static analysis, autocomplete, goto 
 definition that just works and built in package management and 
 a good set of core libraries that are rock solid.


 As of late, when I try goto definition with DCD it works fine.

 But the future of DCD is to be rewritten to use dmd-fe.


what's dmd-fe?
Nov 12 2021
parent max haughton <maxhaton gmail.com> writes:
On Saturday, 13 November 2021 at 03:57:22 UTC, Dr Machine Code 
wrote:

 On Monday, 8 November 2021 at 01:11:38 UTC, rikki cattermole 
 wrote:

 On 08/11/2021 11:30 AM, Imperatorn wrote:

 Most important thing I need rn (I know ppl find it silly, but 
 coming from other languages you get so used to it) is a 
 reliable and good IDE with static analysis, autocomplete, 
 goto definition that just works and built in package 
 management and a good set of core libraries that are rock 
 solid.


 As of late, when I try goto definition with DCD it works fine.

 But the future of DCD is to be rewritten to use dmd-fe.


 what's dmd-fe?


dmd frontend
Nov 12 2021
prev sibling parent data pulverizer <data.pulverizer gmail.com> writes:
On Sunday, 7 November 2021 at 22:30:30 UTC, Imperatorn wrote:

 Most important thing I need rn (I know ppl find it silly, but 
 coming from other languages you get so used to it) is a 
 reliable and good IDE with static analysis, autocomplete


++1 I think IDE experience I've had in VS Code in a language like 
Rust is frankly awesome and D's was quite poor and frankly enough 
to put new people off the language. Sorry but that was my 
experience. I now just use C++ syntax highlighting and the 
terminal, but it's some time since I used the D plugin so I might 
try it again.


 .. and built in package management and a good set of core 
 libraries that are rock solid.


Honestly, I think the standard library is getting better. From a 
looking to get work done perspective it's certainly much better 
than before. Improvements are of course necessary, but I wouldn't 
say that things are bad at all, but then I'm not from the DotNet 
world. I compare it to things like Julia, Nim, Rust, Chapel and 
so on, and I'd say D compares very well indeed.
Nov 08 2021
prev sibling parent Dr Machine Code <jckj33 gmail.com> writes:
On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:

 https://forum.dlang.org/post/vnkgayrbnokeufduuuba forum.dlang.org

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

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

 [...]


 This is a pretty well thought out post. Are we getting forward?


there's also 
https://forum.dlang.org/thread/nj2mm1$1hun$1 digitalmars.com?page=1
Nov 13 2021