www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What are the prominent upsides of the D programming language?

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
Top reasons to use D instead of for example Rust, Julia, Go etc :)
Sep 21 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/21/20 7:04 AM, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc :)


My list, in no particular order:

1. Metaprogramming
2. Using Metaprogramming to generate code
3. Using CTFE to generate Metaprogramming to generate code.

-Steve
Sep 21 2020
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 21 September 2020 at 17:20:41 UTC, Steven 
Schveighoffer wrote:

 On 9/21/20 7:04 AM, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go 
 etc :)


 My list, in no particular order:

 1. Metaprogramming
 2. Using Metaprogramming to generate code
 3. Using CTFE to generate Metaprogramming to generate code.

 -Steve


True, this is so nice to have. I would also say unittesting built 
in is a really powerful concept.
Sep 21 2020
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 21 September 2020 at 17:20:41 UTC, Steven 
Schveighoffer wrote:

 On 9/21/20 7:04 AM, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go 
 etc :)


 My list, in no particular order:

 1. Metaprogramming
 2. Using Metaprogramming to generate code
 3. Using CTFE to generate Metaprogramming to generate code.

 -Steve


No 3 is really meta ❤️🐣
Sep 26 2020
prev sibling next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


 From my experience:





Great introductory material and generally well documented, and 
shallow learning curve but you need to be prepared to adapt to a 
different way of doing things. If you do as the documentation 
says, you will have remarkably few problems.



Far more difficult and poorly documented integration with C than 
in D. You can write C code and call it from Rust but just try 
calling BLAS from Rust - that's a headache, but it's 
comparatively child's play in D.

Rust doesn't ship with a threading library or parallel for loop 
in its standard library. In this day and age that's a non-starter 
for me.

I wonder whether completely shifting your programming style to 
Rust is worth it when I tend to segfault in D only once or twice 
every 6 months (if I'm intensively coding D), they are easy fixes 
(within 5-10 minutes) and usually happen when I've called a C 
library in an incorrect way.






Great introductory material and generally well documented. Since 
it is a dynamic language beginners can lean on the dynamic 
notation until they understand the typed side. Also great 
performance and out-of-the-box scientific data structures and 
algorithms. Its multiple dispatch OOP is very convenient and 
easy, great collection of programming paradigms and a well 
designed language. Can call C libraries easily. Easy to write 
code abuse when you need to because it has embedded compiler and 
is dynamic but also typed. Very good interpreter.



Can't distribute proprietary libraries/modules, no dlls so people 
will see the implementations.

Pointers and references are in their infancy, constants are not 
really constant, even though it is typed, it has poor support for 
other things static languages take for granted, e.g. good enums, 
static, and so forth.

Long compile times for various libraries which can take between 
10 seconds to over a minute to compile even simple libraries, and 
they need to be compiled each time they are loaded. If you are 
working with libraries, you can suddenly come to a standstill 
when you have to wait for the function/module to compile.

Even though it's technically a "dynamic" language, I think it's 
somewhere in between. I'm not sure you can call a language 
"dynamic" if it has a compiler backend embedded built into it 
that causes very long all-stops. I feel as if there is a bit of 
"slight of hand" in that definition, but whatever.

IMO, defaulting to private in a module is the wrong call, but you 
also you have write export lists a bit like a header file [Gag!].

You have to be careful about how you write code since the 
compiler can mark things dynamic rather than creating efficient 
code for it. It requires experience and constant vigilance using 
the provided tools. Writing an object one way rather than another 
can have a massivley deliterious effect on performance, and with 
a drive to "simplify" coding by leaving out type information and 
so forth, it's something that can easily happen.

Julia is a useful langage but it not a panacea, you have to take 
extra care to understand why you are using it, because it doesn't 
easily fall into the usual categories of programming languages.



Don't know much about Golang, but I don't tend to take modern 
static languages with no templates/parametric polymorphism 
seriously.






You didn't ask for this but Nim is worth mentioning. Fantastic 
base language, very easy integration with C, great performance. 
C/C++/JavaScript backends are an inspired move.



Very poor documentation, the official book doesn't even begin to 
touch the usefulness of Ali's "Programming in D".

Poor standard library, for example the threading library doesn't 
even begin to compare with D's or indeed parallel for loops in D. 
Currenly in Nim's standard library, the parallel for loop will 
seriously malfunction in a variety of ways for example, if you 
are trying to read/write to then same array (in different 
locations) - apparently there's no current fix for that apart 
from using another library (which kind of defeats the purpose of 
a standard library). I found the syntax a little tricky at first, 
which wasn't helped by the lack of documentation. Module items 
default to private but not as bad as Julia because you can export 
with a simple asterix next to the implementation.
Sep 21 2020
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer 
wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 [...]


 From my experience:



 [...]


Great summary! I also actually tried Nim for some time and kind 
of liked it. But at the end of the day you need more than just 
nice syntax.
Sep 21 2020
prev sibling next sibling parent Vinod K Chandran <kcvinu82 gmail.com> writes:
On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer 
wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:


Well explained. Thanks for your comments. Well, i would like to 
add a little more in the con section of Nim. Module management in 
Nim is really annoying. In D, i can import anything from any 
module at anywhere. But in Nim, circular module dependency is a 
hell. And yes, you are right in the case of Ali's book vs Nim 
docs. Ali's book is the only thing which brought me to D.

-Vinod Chandran
Sep 21 2020
prev sibling next sibling parent reply Araq <rumpf_a web.de> writes:
On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer 
wrote:

 Poor standard library, for example the threading library 
 doesn't even begin to compare with D's or indeed parallel for 
 loops in D. Currenly in Nim's standard library, the parallel 
 for loop will seriously malfunction in a variety of ways for 
 example, if you are trying to read/write to then same array (in 
 different locations) -


Well we map '||' to the OpenPM standard which works well enough 
for most of the industry. Could have picked a more credible 
example about how bad our stdlib is.
Sep 21 2020
next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Monday, 21 September 2020 at 20:59:30 UTC, Araq wrote:

 On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer 
 wrote:

 Poor standard library, for example the threading library 
 doesn't even begin to compare with D's or indeed parallel for 
 loops in D. Currenly in Nim's standard library, the parallel 
 for loop will seriously malfunction in a variety of ways for 
 example, if you are trying to read/write to then same array 
 (in different locations) -


 Well we map '||' to the OpenPM standard which works well enough 
 for most of the industry. Could have picked a more credible 
 example about how bad our stdlib is.


This comment is linked to this query in the Nim forums: 
https://forum.nim-lang.org/t/6317. D, Chapel, and Julia are able 
to carry out this calculation between their base and standard 
libraries.

I would have liked to include Nim in a benchmark I was doing for 
an article with the other three languages actually discussed the 
Nim forums: https://forum.nim-lang.org/t/6443#39740 but one of 
the requirements I set for the article is that only the standard 
libraries and base language could be used.

**As I said, I think Nim is a fantastic language**, but as a data 
scientist, there are certain things I expect from standard 
libraries in modern languages. One of them is being able to 
easily write and run code like the example threaded kernel matrix 
calculation using either elements from the base or standard 
library. That is pretty basic to me.
Sep 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Monday, 21 September 2020 at 21:26:26 UTC, data pulverizer 
wrote:

 **As I said, I think Nim is a fantastic language**, but as a 
 data scientist, there are certain things I expect from standard 
 libraries in modern languages. One of them is being able to 
 easily write and run code like the example threaded kernel 
 matrix calculation using either elements from the base or 
 standard library. That is pretty basic to me.


Well so get rid of that requirement. If it can be built as a 
library, that's a *strength* of a language. ;-)
Sep 21 2020
parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Monday, 21 September 2020 at 21:50:40 UTC, Araq wrote:

 Well so get rid of that requirement. If it can be built as a 
 library, that's a *strength* of a language. ;-)


Nice try.
Sep 21 2020
parent reply Araq <rumpf_a web.de> writes:
On Tuesday, 22 September 2020 at 06:41:23 UTC, data pulverizer 
wrote:

 On Monday, 21 September 2020 at 21:50:40 UTC, Araq wrote:

 Well so get rid of that requirement. If it can be built as a 
 library, that's a *strength* of a language. ;-)


 Nice try.


Or you use the builtin '||', it works.
Sep 21 2020
parent data pulverizer <data.pulverizer gmail.com> writes:
On Tuesday, 22 September 2020 at 06:53:56 UTC, Araq wrote:

 On Tuesday, 22 September 2020 at 06:41:23 UTC, data pulverizer 
 wrote:

 On Monday, 21 September 2020 at 21:50:40 UTC, Araq wrote:

 Well so get rid of that requirement. If it can be built as a 
 library, that's a *strength* of a language. ;-)


 Nice try.


 Or you use the builtin '||', it works.


Thanks will check it out and update the article to include Nim 
(hopefully in the next few weeks - a little busy at the moment). 
Thanks for the tip.
Sep 22 2020
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 21 September 2020 at 20:59:30 UTC, Araq wrote:

 On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer 
 wrote:

 Poor standard library, for example the threading library 
 doesn't even begin to compare with D's or indeed parallel for 
 loops in D. Currenly in Nim's standard library, the parallel 
 for loop will seriously malfunction in a variety of ways for 
 example, if you are trying to read/write to then same array 
 (in different locations) -


 Well we map '||' to the OpenPM standard which works well enough 
 for most of the industry. Could have picked a more credible 
 example about how bad our stdlib is.


Nim is great, it just needs time to grow
Sep 21 2020
prev sibling parent reply tastyminerals <tastyminerals gmail.com> writes:
On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer 
wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 [...]


 From my experience:



 [...]


I would also add that Julia is very memory hungry and in some 
cases outdoes Java in this regard. I have hard time understanding 
why Julia gets so much praise on HN despite such glaring 
performance flaws... The only thing I can imagine why ppl wave 
performance arguments off is great and growing Julia's ecosystem.
Sep 26 2020
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 26 September 2020 at 07:32:20 UTC, tastyminerals 
wrote:

 I would also add that Julia is very memory hungry and in some 
 cases outdoes Java in this regard. I have hard time 
 understanding why Julia gets so much praise on HN despite such 
 glaring performance flaws... The only thing I can imagine why 
 ppl wave performance arguments off is great and growing Julia's 
 ecosystem.


Yes, Julia is unreasonable memory hungry. I had to disable it for 
inputs above 5000 functions in

https://github.com/nordlow/compiler-benchmark

For details on the superiority of D's compilation speed see

https://github.com/nordlow/compiler-benchmark#conclusions-from-sample-run-shown-below
Sep 26 2020
parent reply mw <mingwu gmail.com> writes:
On Saturday, 26 September 2020 at 17:34:44 UTC, Per Nordlöw wrote:

 On Saturday, 26 September 2020 at 07:32:20 UTC, tastyminerals 
 wrote:

 I would also add that Julia is very memory hungry and in some 
 cases outdoes Java in this regard. I have hard time 
 understanding why Julia gets so much praise on HN despite such 
 glaring performance flaws... The only thing I can imagine why 
 ppl wave performance arguments off is great and growing 
 Julia's ecosystem.


 Yes, Julia is unreasonable memory hungry. I had to disable it 
 for inputs above 5000 functions in

 https://github.com/nordlow/compiler-benchmark

 For details on the superiority of D's compilation speed see

 https://github.com/nordlow/compiler-benchmark#conclusions-from-sample-run-shown-below


Just want to confirm: it's the Julia *compiler* itself that is 
memory hungry, not the generated app that is memory hungry?
Sep 26 2020
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 26 September 2020 at 18:19:28 UTC, mw wrote:

 Just want to confirm: it's the Julia *compiler* itself that is 
 memory hungry, not the generated app that is memory hungry?


Yes
Sep 28 2020
prev sibling next sibling parent Arun <aruncxy gmail.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


My personal favourites to use D

1. Sane language (modules, dot operator, UFCS, etc niceties)
2. Uniform dot operator for member access - makes writing 
algorithms seamless. No need to worry about pointer vs 
reference/value. This is so underrated!!
3. Compile-time introspection for humans
4. Readable std lib
5. Truly multi-paradigm
6. Default thread local
Sep 21 2020
prev sibling next sibling parent reply Ruby The Roobster <michaeleverestc79 gmail.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


1. In C and C++, you have to define the size of the array. In D, 
you can just leave the brackets empty.
2. You can return an array directly. In C and C++, you would have 
to return a pointer to an array:

int* return_int_array() {
int* ret = new int[3];
return ret;
}
3.The foreach loop. Just iterates over things. You could also use 
a for loop in place of this, but writing out a foreach loop is 
shorter and is easier to read.

4.  Mixins. These allow mixing in strings into the code. These 
are not in C or C++.

Completely unrelated, but is this code valid?

import std.string;
import std.stdio;
T someTemplate(T) () {
//function template
}

void main(){
string template_type;
strip(readln(data));
mixin("someTemplate!" ~ data ~ "()");
}
Sep 21 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 September 2020 at 22:18:44 UTC, Ruby The Roobster 
wrote:

 Completely unrelated, but is this code valid?
 strip(readln(data));
 mixin("someTemplate!" ~ data ~ "()");



Nope, all the data for mixin must be known by the compiler and 
thus cannot depend on any run time value.
Sep 21 2020
prev sibling next sibling parent starcanopy <starcanopy protonmail.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


Easy meta-programming, ranges, and all the features that support 
them, changed my life to the extent that I've concluded that we 
must spread Mars' glory to the impoverished and emaciated 
programmers who wallow in programming's drudgery. Yes, they will 
resist. And yes, they will despise we who bring peace to their 
weathered souls. It will be difficult--possibly 
insurmountable--yet through great works and many a blog post, 
even the most inveterate among them will capitulate to Mars' gift 
of productivity, extensibility, and pacification. All hail Mars!
Sep 21 2020
prev sibling next sibling parent JN <666total wp.pl> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


most of my upsides are compared to C++, but not all.

- good compatibility with C libraries and similarity to C/C++ 
code. You can copy paste C++ snippets to D and they work with 
minor changes

- GC with value types

- compile time reflection

- well working package manager

- friendly, helpful community

- batteries included standard library (xml, json)
Sep 22 2020
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)



I tend to pick languages due to eco-systems, so there isn't much 
I would pick D for, given the work I do, however I would still 
like to place a general list of D's pros.


- As mentioned on the other thread, great community;


are still trying to catch up with (20 - 25 years later). There 
are AOT solutions like .NET Native, but with caveats;

- A tracing GC with support for value types in the tradition of 
system languages like Mesa/Cedar, Modula-3, Oberon and descendants

- Powerful metaprogramming capabilities

- Generics

- Modules

- Even if not fully supported (I know there is work in progress), 
D experience to generate WebAssembly via ldc is much better than 
having to deal with emscripten
Sep 22 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 22 September 2020 at 19:24:30 UTC, Paulo Pinto wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 [...]



 I tend to pick languages due to eco-systems, so there isn't 
 much I would pick D for, given the work I do, however I would 
 still like to place a general list of D's pros.

 [...]


True, I've tried CoreRT for .NET and it's not seamless.
Sep 22 2020
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


My biggest use is compatibility with C. Not necessarily only C, 
but if another language has an FFI, you need compatibility with 
C. When I started using D, it was the best option.

I tried Rust and Go before D. Rust was weird and had a learning 
curve that was irrelevant for my purposes and guaranteed nobody 
I'd ever work with would ever use it. I would have been ashamed 
to even ask. I tried Go, but I don't need someone else to tell me 
how to program. I also spent a little time evaluating Julia, but 
by the time it was ready for production I had no reason to use 
it. There's nothing in particular wrong with Julia. It's just 
that there's nothing special about it either relative to D.

The main points that stood out to me about D were the garbage 
collector (critical), compatibility with C, ability to easily 
create a reference counted type when I needed it, and the fact 
that it "makes sense", being a good alternative to scripting 
languages. Unlike some languages, it's easy to work with a small 
subset of the language. For instance, I rarely use templates, and 
that doesn't cause any trouble. It also doesn't hurt that I 
subjectively like it better than other languages.
Sep 22 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 22 September 2020 at 20:45:32 UTC, bachmeier wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go 
 etc :)


 My biggest use is compatibility with C. Not necessarily only C, 
 but if another language has an FFI, you need compatibility with 
 C. When I started using D, it was the best option.

 I tried Rust and Go before D. Rust was weird and had a learning 
 curve that was irrelevant for my purposes and guaranteed nobody 
 I'd ever work with would ever use it. I would have been ashamed 
 to even ask. I tried Go, but I don't need someone else to tell 
 me how to program. I also spent a little time evaluating Julia, 
 but by the time it was ready for production I had no reason to 
 use it. There's nothing in particular wrong with Julia. It's 
 just that there's nothing special about it either relative to D.

 The main points that stood out to me about D were the garbage 
 collector (critical), compatibility with C, ability to easily 
 create a reference counted type when I needed it, and the fact 
 that it "makes sense", being a good alternative to scripting 
 languages. Unlike some languages, it's easy to work with a 
 small subset of the language. For instance, I rarely use 
 templates, and that doesn't cause any trouble. It also doesn't 
 hurt that I subjectively like it better than other languages.


Nice summary. I also "tried" Rust. It was just such a pain. I 
wish it wasn't, but it was. Go was nice, I got productive quite 
fast. But yeah, it feels like a toy language and I can't express 
more advanced concepts without abusing the multiverse. Julia is 
really nice, but deployment is almost impossible. A single 
executable could very well be like 100MB... Sure, things might 
have improved since then, but we have D so why bother? :)

I honestly feel we should try and improve D as much as possible. 
If we get some things right and can prove it's stable and 
scalable for production I really think D could be one of those 
languages people would turn to (instead of trying to convince 
them to use it)

So, let's fix as many issues as possible and make the future of D 
bright (no pun intended).
Sep 22 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2020 4:04 AM, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc :)


The top reason for me is plasticity. The combination of D's features make it 
much easier to refactor and redesign code to improve it. With C, the initial 
design tends to stick because it's so difficult to redesign it.
Sep 22 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 23 September 2020 at 00:35:56 UTC, Walter Bright 
wrote:

 On 9/21/2020 4:04 AM, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go 
 etc :)


 The top reason for me is plasticity. The combination of D's 
 features make it much easier to refactor and redesign code to 
 improve it. With C, the initial design tends to stick because 
 it's so difficult to redesign it.


Yes! I truly think D is in a sweet spot of low/high 
multi-paradigm programming while aslo having great performance. 
To be honest I've looked at other languages, a lot. But what I 
find is that I actually come back to D after a while. Because, 
well, it's actually great :)
Sep 26 2020
prev sibling next sibling parent reply mw <mingwu gmail.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


One of the upside of D I like is that one can mix GC with manual 
memory management:

https://dlang.org/library/core/memory/gc.free.html

which gives you the best of both world.

Currently I have a personal project, initially I was solely 
relying on GC just like in Java: allocate all the objects via 
`new`, and let the GC take care of all the bookkeeping. But there 
is a particular set of objects which takes the majority of memory 
consumption of the program, and even after I carefully removed 
all the reference after the object is no longer used, the program 
still use lots of memory because GC collection is un-predictable, 
both in terms of timing and efficiency.

Then I decided to do manual core.memory.GC.free just for that 
particular objects, (it was not very easy in a multi-threaded 
program to make all the logic right, but eventually I got it 
done). And the resulting program now only use ~10% of the memory 
it used to use.

I think this flexibility to mix GC & manual memory management is 
very unique in D. Actually I'm not sure if it can be done in 
other languages at all.
Sep 22 2020
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 23 September 2020 at 04:04:04 UTC, mw wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go 
 etc :)


 [...]

 I think this flexibility to mix GC & manual memory management 
 is very unique in D. Actually I'm not sure if it can be done in 
 other languages at all.


Before Java and .NET took over the computing world, we had 
Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Oberon-07, 
Active Oberon, Component, Pascal, Zonnon, Common Lisp/Interlisp, 
Eiffel.


rich enough to support C++ as well. Initially via Managed C++, 
later replaced by C++/CLI.


intrisics at language level.



As of lately we get Swift, Go and Nim.

When Valhala/Panama finally get done, Java as well (Java 15 just 
got the first drop of this work).

While it is a very good feature and I appreciate D took down this 
path, the competition is getting hard, as mainstream language 
designers finally got that GC without escape hatches doesn't 
really cut it, and those 80 and 90's languages had a point 
offering all those features alongside each other.

And now with Rust making the rounds, everyone is trying to find a 
way to integrate some form of affine types with a GC, as a 
compromise between productivity and performance while not going 
crazy with lifetime annotations.

So it is nice to see D among those languages.
Sep 22 2020
parent reply mw <mingwu gmail.com> writes:
On Wednesday, 23 September 2020 at 06:34:43 UTC, Paulo Pinto 
wrote:

 On Wednesday, 23 September 2020 at 04:04:04 UTC, mw wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go 
 etc :)


 [...]

 I think this flexibility to mix GC & manual memory management 
 is very unique in D. Actually I'm not sure if it can be done 
 in other languages at all.


 When Valhala/Panama finally get done, Java as well (Java 15 
 just got the first drop of this work).


Manual memory management option is on the road-map of Java 15? 
any reference? I googled a bit, but can't find any clue.
Sep 22 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 23 September 2020 at 06:57:54 UTC, mw wrote:

 On Wednesday, 23 September 2020 at 06:34:43 UTC, Paulo Pinto 
 wrote:

 On Wednesday, 23 September 2020 at 04:04:04 UTC, mw wrote:

 On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn 
 wrote:

 Top reasons to use D instead of for example Rust, Julia, Go 
 etc :)


 [...]

 I think this flexibility to mix GC & manual memory management 
 is very unique in D. Actually I'm not sure if it can be done 
 in other languages at all.


 When Valhala/Panama finally get done, Java as well (Java 15 
 just got the first drop of this work).


 Manual memory management option is on the road-map of Java 15? 
 any reference? I googled a bit, but can't find any clue.


https://openjdk.java.net/jeps/383

"Panama Update with Maurizio Cimadamore"
https://www.youtube.com/watch?v=r4dNRVWYaZI

"ByteBuffers are dead, long live ByteBuffers!"
https://www.youtube.com/watch?v=RYrk4wvar6g

This is just the ground work for what Valhalla and Panama are 
going to deliver, so eventually the JVM boilerplate will be 
hidden behind language features, just like it happens today when 
lambdas get actually converted into instances of invokedynamic 
calls.

Eventually those 25 year old jars will be able to run unmodified 
in a JVM that also understands value semantics, specialized 
generics and can do manual memory management within safe 
constraints.
Sep 23 2020
prev sibling parent Elronnd <elronnd elronnd.net> writes:
On Wednesday, 23 September 2020 at 04:04:04 UTC, mw wrote:

 there is a particular set of objects which takes the majority 
 of memory consumption of the program, and even after I 
 carefully removed all the reference after the object is no 
 longer used, the program still use lots of memory because GC 
 collection is un-predictable, both in terms of timing and 
 efficiency.

 Then I decided to do manual core.memory.GC.free just for that 
 particular objects, (it was not very easy in a multi-threaded 
 program to make all the logic right, but eventually I got it 
 done). And the resulting program now only use ~10% of the 
 memory it used to use.


I recommend experimenting with 'scope' and seeing if it will work 
in place of manually freeing.  If that doesn't work, then I 
recommend using libc's malloc and free instead of GC.malloc and 
GC.free.  Reason: you avoid increasing the GC's heap size.  
https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation has
a good example of using std.emplace to do this.  (Note that you only need to
use GC.addRange if the objects you allocate themselves point to other objects.)



 I think this flexibility to mix GC & manual memory management 
 is very unique in D. Actually I'm not sure if it can be done in 
 other languages at all.


Take a look at cone and its gradual memory management - 
https://pling.jondgoodwin.com/post/gradual-memory-management/
Sep 23 2020
prev sibling next sibling parent reply glis-glis <andreas.fueglistaler gmail.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


I am working in computational sciences and a common use-case is 
working with a numeric code using MPI, OpenMP and/or CUDA 
(written in C++ in my case, can also be C or Fortran), and doing 
the pre- and post-treatment with python tools.

Pre-treatment is usually not very time-consuming as there are few 
input-files, but for post-treatment, you can easily end up 
running the same tools on 10⁴ - 10⁶ files. Even if a tool only 
takes 0.1s, multiplying this by 10⁶ is more than a day. When a 
python tool gets too slow, I usually rewrite the most 
time-consuming part in C++ and expose it through ctypes. This is 
working but not very convenient.

I was looking for a "more convenient" replacement of Python+C++ 
for some time, and replacing C++ with Rust was one of my first 
candidates. But at least to me, Rust felt even less convenient 
than C++ and solves problems I do not really have (basically all 
my data lives in arrays which get allocated at the start of the 
program and will remain alive until the end of the program).

Using a JIT-programming language, such as Julia or PyPy, does not 
help that much, as the same program is usually executed 10⁴ - 10⁶ 
times, doing just-in-time compilation every single time. Julia 
can do some caching but the startup-time is still rather slow.

In D, I found a language which combines the convenience of Python 
and the speed of C++, and basically removes the need of using two 
languages. I translated my most-used Python-tools to D and got a 
nice 1-2 orders of magnitude speedup.

For me, the key features I like about D are:
* Ranges
* UFCS
* Familiar syntax
* Pseudo-gradual typing: Usually, I start defining my functions 
as returning auto and template every parameter. Once the function 
is finished and passes the unit-tests, I start thinking about 
types
Sep 24 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 24, 2020 at 07:58:23AM +0000, glis-glis via Digitalmars-d wrote:
[...]

 For me, the key features I like about D are:


[...]

 * Pseudo-gradual typing: Usually, I start defining my functions as
 returning auto and template every parameter. Once the function is
 finished and passes the unit-tests, I start thinking about types


That's a very interesting way to approach it!  I might adopt this
approach for my future prototyping experiments!


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor
first.
Sep 24 2020
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


For me it is.

* Best in class FFI. Interfacing to C or C++ is very easy thanks 
to the built in compatability.

* Template programming makes sense. C++ functional style template 
programming makes your brain hurt. With D you can still do meta 
programming in a imperative fashion which fits the language you 
work with.

* User friendly name resolution. C++ solves this by endless rows 
of namespaces like 
Namespace1::Namespace2::OneMore::EvenMore::theFunction. Since D 
has rules how to figure out the name itself, you don't need to 
hazzle with that. Only if there are collisions you need to be 
more specific.

* Data structure compatability with C/C++. Since D is so similar 
to C/C++, all data structures can be more or less be ported to D 
without any changes.

* Convenient "built in" arrays. While the are pitfalls in 
performance with the arrays, they are very convenient to work 
with. Arrays together with the slices is really something that 
makes D close to scripting languages. Very nice to prototype with.
Sep 24 2020
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:

 Top reasons to use D instead of for example Rust, Julia, Go etc 
 :)


As quick as possible speed (no room below) which matters for a 
few domains, and very high productivity - so the end result often 
end up providing value.

There are of course a few newer native languages now, but there 
is a disturbing trend.

They seems to increasingly rehash old ideas that did NOT work: 
forcing TABs on people (or a particular style), doing away with 
exceptions, having AST macros, lifetimes annotations, segmented 
stack, lack of GC... all these things do not kill a language but 
in the large they do not work and it's strange to try the 
experiment again.
To me it's worrying that the new native language don't learn from 
the past.
Sep 28 2020