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.

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

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.

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.

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.

Actually F#/C#/VB could do it since ever, because CLR/MSIL is rich enough to support C++ as well. Initially via Managed C++, later replaced by C++/CLI.

Recent F#/C#/VB versions expose more of those capabilities as intrisics at language level.

On MSR labs there was Sing# and System C#.

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.

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.

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.

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/

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

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.