Hello D community,

I am language polyglot that lately got interested in D. I love it, it's very elegant language, so simple and so powerful same time. I will write some thoughts as outsider.

The reason I am looking at D in 2017 is that D it's almost nonexistent on popular sites for programmers (reddit/HN etc). The only discussion I remember about D was that it had two standard libraries and there were no consensus on which to use and that it uses GC so it's slow.

In my opinion D can get traction but it needs a lot more marketing and people need to be more vocal about blog posts written about D usage. If you don't have account on Reddit or HackerNews, create one, upvote articles about D, answer questions about D in comments, promote D (without zealotry).

Two other important things to change people minds about D performance:

http://benchmarksgame.alioth.debian.org/

Why D is not there?

https://www.techempower.com/benchmarks/previews/round14/#section=data-r14&hw=ph&test=plaintext

This is another very popular benchmark that people discuss and can attract new people to look at D. vibe.d here is not working, it would be good to fix that.

What is the plan for D for next 5 years? What about RAII?

Did you consider implementing solutions from which we could get memory safety without GC in D? Static analysis combined with some additional annotations/rules (but not intrusive).
For example using some of the solutions from Cyclone[1] or Rust or proposed solutions for lifetimes in C++[2]

[1] http://www.cs.umd.edu/projects/cyclone/papers/cyclone-safety.pdf

[2] https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf

On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote:
> Hello D community,
>
> I am language polyglot that lately got interested in D. I love it, it's very elegant language, so simple and so powerful same time. I will write some thoughts as outsider.
>
> The reason I am looking at D in 2017 is that D it's almost nonexistent on popular sites for programmers (reddit/HN etc). The only discussion I remember about D was that it had two standard libraries and there were no consensus on which to use and that it uses GC so it's slow.
>
> In my opinion D can get traction but it needs a lot more marketing and people need to be more vocal about blog posts written about D usage. If you don't have account on Reddit or HackerNews, create one, upvote articles about D, answer questions about D in comments, promote D (without zealotry).
>
> Two other important things to change people minds about D performance:
>
> http://benchmarksgame.alioth.debian.org/
>
> Why D is not there?
>
> https://www.techempower.com/benchmarks/previews/round14/#section=data-r14&hw=ph&test=plaintext
>
> This is another very popular benchmark that people discuss and can attract new people to look at D. vibe.d here is not working, it would be good to fix that.
>
> What is the plan for D for next 5 years? What about RAII?
>
> Did you consider implementing solutions from which we could get memory safety without GC in D? Static analysis combined with some additional annotations/rules (but not intrusive).
> For example using some of the solutions from Cyclone[1] or Rust or proposed solutions for lifetimes in C++[2]
>
> [1] http://www.cs.umd.edu/projects/cyclone/papers/cyclone-safety.pdf
>
> [2] https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf

The memory safety is currently in the works.
We just have one std-lib now.
GC is slow, yes.
The short-term solution is to avoid it.
(All gc-ed langauges recommend static preallocation :P)

On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote:
> The only discussion I remember about D was that it had two standard libraries and there were no consensus on which to use and that it uses GC so it's slow.

It seems it's impossible to completely shrug off past impressions. The two std libs thing hasn't been a problem since 2012. Solutions to the GC being slow have existed for a while and the GC has been sped up a lot in the past couple of years.

> What is the plan for D for next 5 years?

https://wiki.dlang.org/Vision/2017H1

> What about RAII?

It's already in the language.

> Did you consider implementing solutions from which we could get memory safety without GC in D?

The current proposal is this https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

This is currently a point of contention.

See also https://dlang.org/spec/function.html#function-safety

> (All gc-ed langauges recommend static preallocation :P)

;) Thanks for replying.

> https://wiki.dlang.org/Vision/2017H1
>

Thanks, I have read that already, that's why I've asked about longer term.

>> What about RAII?
>
> It's already in the language.

Is it in std already? How do I allocate equivalent of std::vector on heap with RAII in D that will be disposed at the end of the scope automatically?

> The current proposal is this https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Thanks, after first glance I think this is addressing exactly what I was asking.

On Tuesday, 11 April 2017 at 20:48:13 UTC, Piotr Kowalski wrote:
>> (All gc-ed langauges recommend static preallocation :P)
>
> ;) Thanks for replying.
>
>> https://wiki.dlang.org/Vision/2017H1
>>
>
> Thanks, I have read that already, that's why I've asked about longer term.
>
>>> What about RAII?
>>
>> It's already in the language.
>
> Is it in std already? How do I allocate equivalent of std::vector on heap with RAII in D that will be disposed at the end of the scope automatically?
>
std.container.array is something similar.

On Tuesday, 11 April 2017 at 20:48:13 UTC, Piotr Kowalski wrote:
> Is it in std already? How do I allocate equivalent of std::vector on heap with RAII in D that will be disposed at the end of the scope automatically?

You're asking about two different things here.

RAII is already in the language. As soon as a struct exits its scope, its destructor is called.

Specifically for a vector type with elements allocated on the heap that is destroyed on scope exit, I would look at https://dlang.org/phobos/std_container_array.html

If you want a more performant version that is integrated with std.experimental.allocator, then I would look at https://github.com/economicmodeling/containers

On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote:
> Two other important things to change people minds about D performance:
>
> http://benchmarksgame.alioth.debian.org/
>
> Why D is not there?

I worked on that [0] and decided its not worth it. It is literally a "game". You can have some fun tuning benchmark programs. You should not let it influence your decision making.

If you want to talk about performance, articles like the one on Mir GLAS [1] provides better information.

[0] https://github.com/qznc/d-shootout
[1] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html

On Tuesday, 11 April 2017 at 21:06:28 UTC, Jack Stouffer wrote:
> On Tuesday, 11 April 2017 at 20:48:13 UTC, Piotr Kowalski wrote:
>> Is it in std already? How do I allocate equivalent of std::vector on heap with RAII in D that will be disposed at the end of the scope automatically?
>
> You're asking about two different things here.
>
> RAII is already in the language. As soon as a struct exits its scope, its destructor is called.
>
> Specifically for a vector type with elements allocated on the heap that is destroyed on scope exit, I would look at https://dlang.org/phobos/std_container_array.html
>
> If you want a more performant version that is integrated with std.experimental.allocator, then I would look at https://github.com/economicmodeling/containers



Ok, maybe I was too specific, I wanted to ask what is the current support of RAII in whole std while using @nogc, not in the language itself.

> I worked on that [0] and decided its not worth it. It is literally a "game". You can have > some fun tuning benchmark programs. You should not let it influence your decision making.

It's all about perception, if you don't know that something exists or is capable of doing something then you will never choose it. Sure it's a benchmarking game, but game people refer to a lot on reddit or hn. And people still think D is slow so they don't even consider using it. It's really about marketing.

On Tue, 2017-04-11 at 19:57 +0000, Piotr Kowalski via Digitalmars-d wrote:
> Hello D community,
> 
> I am language polyglot that lately got interested in D. I love it, it's very elegant language, so simple and so powerful same time. I will write some thoughts as outsider.
> 
> 
[…]

If do write something, why not write it as an article for Overload? Andrei did a workshop and keynote at ACCU 2016, it would be good to get some articles in ACCU journals about D, especially ones from people doing the C++ → D switch.

https://accu.org/index.php/journal

https://conference.accu.org/site/stories/2016/speakers.html#Andrei_Alex andrescu

Getting more discussion of D at ACCU conference is always welcome.

https://conference.accu.org/site/index.html

Language specific conferences are increasingly the trend, but their main purpose is to reinforce membership of the language tribe rather than actually do much marketing. ACCU has never been a C and C++ only conference: Java, then C#, as well as other languages, and agile development methods, have always had a core place in the programme. So about 55% of the conference is C++ this year, but that is exactly the sort of audience to take some good D sessions to.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 2017-04-11 at 20:07 +0000, Stefan Koch via Digitalmars-d wrote:
> […]

At the risk of starting a flame war:

> 
> The memory safety is currently in the works.
> We just have one std-lib now.
> GC is slow, yes.

I don't care, it doesn't impact the programs I write, and the GC means I can be a little profligate with memory.

> The short-term solution is to avoid it.

But only if you have to, if you don't have to don't worry.

Oh and measure do not guess.

> (All gc-ed langauges recommend static preallocation :P)

Absolute ####### ########

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder