www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thoughts from newcommer

reply Piotr Kowalski <p.kow gmail.com> writes:
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
Apr 11
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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)
Apr 11
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2017-04-11 at 20:07 +0000, Stefan Koch via Digitalmars-d wrote:
 [=E2=80=A6]
At the risk of starting a flame war:
=20
 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.=20
 (All gc-ed langauges recommend static preallocation :P)
Absolute ####### ######## --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Apr 12
parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Wednesday, 12 April 2017 at 09:38:49 UTC, Russel Winder wrote:
 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 ####### ########
Amen to that!
Apr 13
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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
Apr 11
next sibling parent reply Piotr Kowalski <p.kow gmail.com> writes:
 (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.
Apr 11
next sibling parent Eugene Wissner <belka caraus.de> writes:
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.
Apr 11
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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
Apr 11
parent Piotr Kowalski <p.kow gmail.com> writes:
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.
Apr 11
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 11/04/17 23:09, Jack Stouffer wrote:
 On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote:
 What about RAII?
It's already in the language.
There are two problems with that statement. The first is that the language does not offer any RAII containers out of the box. What it does provide is the *ability* to create RAII containers. D supports RAII, but does not actually have RAII. The second, more serious, problem is that RAII requires destructors to run 100% reliably, and D simply doesn't have that. In that sense, the claim that D supports RAII is, at this point in time, a lie. (And, yes, there is an open bug: https://issues.dlang.org/show_bug.cgi?id=14246) Shachar
Apr 16
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/16/17 3:50 AM, Shachar Shemesh wrote:
 https://issues.dlang.org/show_bug.cgi?id=14246
I'd raised the importance and urgency of this issue in the past. Walter is really overloaded for the time being. Any volunteer wants to look into this now? -- Andrei
Apr 16
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 16 April 2017 at 14:25:22 UTC, Andrei Alexandrescu 
wrote:
 On 4/16/17 3:50 AM, Shachar Shemesh wrote:
 https://issues.dlang.org/show_bug.cgi?id=14246
I'd raised the importance and urgency of this issue in the past. Walter is really overloaded for the time being. Any volunteer wants to look into this now? -- Andrei
I am going to take a look. This bug has been bugging me for a while ... it's time to take a shot at it ;)
Apr 16
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/16/17 12:05 PM, Stefan Koch wrote:
 On Sunday, 16 April 2017 at 14:25:22 UTC, Andrei Alexandrescu wrote:
 On 4/16/17 3:50 AM, Shachar Shemesh wrote:
 https://issues.dlang.org/show_bug.cgi?id=14246
I'd raised the importance and urgency of this issue in the past. Walter is really overloaded for the time being. Any volunteer wants to look into this now? -- Andrei
I am going to take a look. This bug has been bugging me for a while ... it's time to take a shot at it ;)
Terrific, thanks! -- Andrei
Apr 16
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Sunday, 16 April 2017 at 07:50:43 UTC, Shachar Shemesh wrote:
 The first is that the language does not offer any RAII 
 containers out of the box. What it does provide is the 
 *ability* to create RAII containers. D supports RAII, but does 
 not actually have RAII.
Semantic game. D actually has RAII. And D does have RAII containers: https://dlang.org/phobos/std_container.html
 (And, yes, there is an open bug: 
 https://issues.dlang.org/show_bug.cgi?id=14246)
So we can say that D has buggy RAII. Claiming that D doesn't have RAII is equally false.
Apr 16
next sibling parent reply Jerry <hurricane hereiam.com> writes:
On Sunday, 16 April 2017 at 17:00:25 UTC, Jack Stouffer wrote:
 Semantic game. D actually has RAII.

 And D does have RAII containers: 
 https://dlang.org/phobos/std_container.html
I wouldn't really call them RAII containers if they aren't nogc, and especially so if they aren't structs but classes. The container module needs a good rewriting, SList/DList are the most useless POS containers without some concept of iterators.
Apr 16
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Sunday, 16 April 2017 at 18:36:30 UTC, Jerry wrote:
 I wouldn't really call them RAII containers if they aren't  nogc
Moving the goal posts again. Even still, void main() nogc { Array!int ai; ai ~= 1; assert(ai.front == 1); ai.reserve(10); assert(ai.capacity == 10); static immutable arr = [1, 2, 3]; ai.insertBack(arr); }
Apr 16
parent reply Jerry <hurricane hereiam.com> writes:
On Sunday, 16 April 2017 at 22:18:51 UTC, Jack Stouffer wrote:
 On Sunday, 16 April 2017 at 18:36:30 UTC, Jerry wrote:
 I wouldn't really call them RAII containers if they aren't 
  nogc
Moving the goal posts again. Even still, void main() nogc { Array!int ai; ai ~= 1; assert(ai.front == 1); ai.reserve(10); assert(ai.capacity == 10); static immutable arr = [1, 2, 3]; ai.insertBack(arr); }
Okay, only one container, and happens to be most simple basic one. The others aren't nogc and some of them are even classes. Not only that, Array wasn't nogc until about a month ago. No idea what you mean about goal posts. Do you mean it's not an issue worth discussing? You made a false claim, and you still you are still persisting in it as if having a single container be nogc solves the entire issue.
Apr 16
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 17 April 2017 at 02:56:00 UTC, Jerry wrote:
 Okay, only one container, and happens to be most simple basic 
 one. The others aren't nogc and some of them are even classes. 
 Not only that, Array wasn't  nogc until about a month ago.

 No idea what you mean about goal posts. Do you mean it's not an 
 issue worth discussing? You made a false claim, and you still 
 you are still persisting in it as if having a single container 
 be  nogc solves the entire issue.
The first question was whether D had RAII or not. When it was shown that D does have RAII, then the goal posts were moved back to D needing RAII containers that cleaned up their elements on scope exit. When it was shown that D absolutely has RAII containers (that clean up all resources including GC ones on scope exit) then the goal posts were moved back yet again to the containers needed to be nogc containers. This is despite the fact that nogc has nothing to do with RAII and is just something people want for convenience. We are now nowhere near the original topic. I'll cut this off at the knees and say If you want nogc RAII containers that work with std.allocator then just use https://github.com/economicmodeling/containers
Apr 17
parent reply Jerry <hurricane hereiam.com> writes:
On Monday, 17 April 2017 at 15:10:59 UTC, Jack Stouffer wrote:
 On Monday, 17 April 2017 at 02:56:00 UTC, Jerry wrote:
 Okay, only one container, and happens to be most simple basic 
 one. The others aren't nogc and some of them are even classes. 
 Not only that, Array wasn't  nogc until about a month ago.

 No idea what you mean about goal posts. Do you mean it's not 
 an issue worth discussing? You made a false claim, and you 
 still you are still persisting in it as if having a single 
 container be  nogc solves the entire issue.
The first question was whether D had RAII or not. When it was shown that D does have RAII, then the goal posts were moved back to D needing RAII containers that cleaned up their elements on scope exit. When it was shown that D absolutely has RAII containers (that clean up all resources including GC ones on scope exit) then the goal posts were moved back yet again to the containers needed to be nogc containers. This is despite the fact that nogc has nothing to do with RAII and is just something people want for convenience.
It has everything to do with nogc, if it isn't nogc then it is using the garbage collector and even if it is using Destroy() it is still invoking the GC and something is still going to have to be freed by the GC, even if that class is empty. You can't say it is RAII if it is using the GC, that's just nonsense. So it is not just for convenience. Not to mention for some reason Array's internal implementation is ref counted. If you want ref counted arrays you should do RefCounted!(Array!T). Std.containers is just a giant mess. I wasn't part of the other discussion, what the hell is the point of having a discussion if you can't change the subject.
 We are now nowhere near the original topic. I'll cut this off 
 at the knees and say If you want  nogc RAII containers that 
 work with std.allocator then just use 
 https://github.com/economicmodeling/containers
I feel like if your solution is, don't use Phobo's containers here use this person's that isn't updating it anymore of questionable quality. Then I feel like you are agreeing with me that phobos containers suck. Oh and it looks like hackerpilot is responsible for merging pull request, lovely.
Apr 17
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 17 April 2017 at 15:24:26 UTC, Jerry wrote:

 It has everything to do with  nogc, if it isn't  nogc then it 
 is using the garbage collector and even if it is using 
 Destroy() it is still invoking the GC and something is still 
 going to have to be freed by the GC, even if that class is 
 empty. You can't say it is RAII if it is using the GC, that's 
 just nonsense. So it is not just for convenience.
On the contrary. All RAII does is establish a relation between resource lifetime and another resource's (e.g. object's) lifetime. It doesn't necessarily have to be limited to any particular scope.
 Not to mention for some reason Array's internal implementation 
 is ref counted. If you want ref counted arrays you should do 
 RefCounted!(Array!T). Std.containers is just a giant mess.
The "some reason" is mutable slices.
 I feel like if your solution is, don't use Phobo's containers 
 here use this person's that isn't updating it anymore of 
 questionable quality. Then I feel like you are agreeing with me 
 that phobos containers suck. Oh and it looks like hackerpilot 
 is responsible for merging pull request, lovely.
Yes, std.container does need quite a bit of love. That doesn't mean that D doesn't have RAII or that it's RAII support is somehow deficient.
Apr 17
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 17 April 2017 at 16:06:20 UTC, Stanislav Blinov wrote:
 Yes, std.container does need quite a bit of love. That doesn't 
 mean that D doesn't have RAII or that it's RAII support is 
 somehow deficient.
Of course the reason it doesn't get more love is well-known here. Walter and Andrei want to get safe RC working first.
Apr 17
prev sibling parent reply Jerry <hurricane hereiam.com> writes:
On Monday, 17 April 2017 at 16:06:20 UTC, Stanislav Blinov wrote:
 On Monday, 17 April 2017 at 15:24:26 UTC, Jerry wrote:

 It has everything to do with  nogc, if it isn't  nogc then it 
 is using the garbage collector and even if it is using 
 Destroy() it is still invoking the GC and something is still 
 going to have to be freed by the GC, even if that class is 
 empty. You can't say it is RAII if it is using the GC, that's 
 just nonsense. So it is not just for convenience.
On the contrary. All RAII does is establish a relation between resource lifetime and another resource's (e.g. object's) lifetime. It doesn't necessarily have to be limited to any particular scope.
So what happens when the resource outlives the object's lifetime. That's exactly what is happening when you are using the garbage collector. That's exactly the case with the containers in phobos. So calling them RAII container is just incorrect. You are using two techniques that do the same thing. Call it pure RAII containers if you want, for containers that only use RAII and the current implementation that is GC'd RAII/deterministic destructor containers.
 Not to mention for some reason Array's internal implementation 
 is ref counted. If you want ref counted arrays you should do 
 RefCounted!(Array!T). Std.containers is just a giant mess.
The "some reason" is mutable slices.
Not really, slices aren't included in the ref counting. So if the array object is detroyed, the slices are no longer valid. You have to deal with the same issue, with or without ref counting. You manually have to ensure the array outlives the slice, and that the slices aren't invalidated by an operation like resize.
 I feel like if your solution is, don't use Phobo's containers 
 here use this person's that isn't updating it anymore of 
 questionable quality. Then I feel like you are agreeing with 
 me that phobos containers suck. Oh and it looks like 
 hackerpilot is responsible for merging pull request, lovely.
Yes, std.container does need quite a bit of love. That doesn't mean that D doesn't have RAII or that it's RAII support is somehow deficient.
I was never arguing that it didn't. Jack said it had RAII containers, which it doesn't. The standard library containers are shiat.
Apr 17
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 17 April 2017 at 21:20:42 UTC, Jerry wrote:

 So what happens when the resource outlives the object's 
 lifetime.
Then RAII rule is violated.
 That's exactly what is happening when you are using the garbage 
 collector.
Correction, that is what *may* happen in some cases when you are using GC.
 That's exactly the case with the containers in phobos. So 
 calling them RAII container is just incorrect.
I never said they were. You see, you were stating that in order for them to become such, they should be nogc, which is simply not true. nogc disallows GC calls, nothing more. You *can* have a RAII type that calls into GC. In fact, you can wrap a class reference into a struct that calls new in constructor and destroy in desctructor, and have a scoped lifetime for class instances that way. But such a struct's constructor and destructor cannot be nogc.
 Not to mention for some reason Array's internal 
 implementation is ref counted. If you want ref counted arrays 
 you should do RefCounted!(Array!T). Std.containers is just a 
 giant mess.
The "some reason" is mutable slices.
Not really, slices aren't included in the ref counting.
Yes, they are.
 So if the array object is detroyed, the slices are no longer 
 valid.
The underlying storage is destroyed once the last reference dies, not when Array's destructor is called.
 You have to deal with the same issue, with or without ref 
 counting. You manually have to ensure the array outlives the 
 slice...
No.
 and that the slices aren't invalidated by an operation like 
 resize.
That is true. My argument was, from the start, that assessing the *language* RAII capability has nothing to do with *library* containers or the (lack of) use of nogc attribute.
Apr 17
parent Jerry <hurricane hereiam.com> writes:
On Monday, 17 April 2017 at 22:44:52 UTC, Stanislav Blinov wrote:
 On Monday, 17 April 2017 at 21:20:42 UTC, Jerry wrote:

 So what happens when the resource outlives the object's 
 lifetime.
Then RAII rule is violated.
 That's exactly what is happening when you are using the 
 garbage collector.
Correction, that is what *may* happen in some cases when you are using GC.
Not may, will definitely happen. Even if the destructor is called the memory is freed, alas the resource isn't freed and is freed at a later time when the object is destroyed. And as your above statement says, this violates the RAII rule.
 That's exactly the case with the containers in phobos. So 
 calling them RAII container is just incorrect.
I never said they were.
Then why are you arguing for Jack..
 My argument was, from the start, that assessing the *language* 
 RAII capability has nothing to do with *library* containers or 
 the (lack of) use of  nogc attribute.
I never replied to you, you replied to me an my argument. I never said RAII capability has anything to do with, go back and read the comments and user names. You are confusing me for someone else it seems.
Apr 17
prev sibling parent reply prdan <noreply a.a> writes:
I've written multi-threaded regex-redux benchmark for D language 
and made some tests. This is my first program written in D, I 
didn't know much about D a week ago.

Here are the results for other languages:

http://benchmarksgame.alioth.debian.org/u64q/regexredux.html

I have newer CPU than one used on this page. Tests were made on 
Debian 8 with i7-3770 3.4 Ghz (4C/8T) CPU.

I've tested C and Rust besides D becasue those are the top two 
languages on this benchmark.

Rust version 1.16 (newest stable)
GCC ver 4.9.2 (newest debian 8 stable)

I've changed target-cpu in Rust compile command to match my cpu.

C was the fastest (1.32) but used the most CPU, D was second 
(1.45) with lowest CPU usage!, Rust was third (1.55). In this 
benchmark D is faster than any other language besides C.

Code in D is very clean and readable, GC is operating normally.


Exacts results are below:

D
   User time (seconds): 1.91
         System time (seconds): 0.14
         Percent of CPU this job got: 140%
         Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.45
         Average shared text size (kbytes): 0
         Average unshared data size (kbytes): 0
         Average stack size (kbytes): 0
         Average total size (kbytes): 0
         Maximum resident set size (kbytes): 263848

Rust

   User time (seconds): 2.72
         System time (seconds): 0.09
         Percent of CPU this job got: 181%
         Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.55
         Average shared text size (kbytes): 0
         Average unshared data size (kbytes): 0
         Average stack size (kbytes): 0
         Average total size (kbytes): 0
         Maximum resident set size (kbytes): 199008

C
     User time (seconds): 4.51
         System time (seconds): 0.08
         Percent of CPU this job got: 346%
         Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.32
         Average shared text size (kbytes): 0
         Average unshared data size (kbytes): 0
         Average stack size (kbytes): 0
         Average total size (kbytes): 0
         Maximum resident set size (kbytes): 151716


I got inspired by those results that's why I thought I will write 
all the other benchmarks from benchmarks game also for D and 
share the code and results on github + comparison to couple other 
languages.
Apr 17
parent thedeemon <dlang thedeemon.com> writes:
On Tuesday, 18 April 2017 at 02:57:59 UTC, prdan wrote:
 I've written multi-threaded regex-redux benchmark for D 
 language and made some tests.
Nice!
 Rust version 1.16 (newest stable)
 GCC ver 4.9.2 (newest debian 8 stable)
Which compiler did you use for D?
 C was the fastest (1.32) but used the most CPU, D was second 
 (1.45) with lowest CPU usage!
In benchmarks where some fixed amount of work should be done as fast as possible low CPU usage is not a good sign, it just means some cores were idle when they could really be working.
Apr 18
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On Sunday, 16 April 2017 at 17:00:25 UTC, Jack Stouffer wrote:

 So we can say that D has buggy RAII. Claiming that D doesn't 
 have RAII is equally false.
To me, that's a basic misunderstanding of what RAII mean. RAII, to me, means you wrap your resource in a container, and then can just go ahead and forget about releasing it. As such, saying that D has RAII, but they only work most of the time means that the core functionality that RAII provides is simply not working. There are other languages out there that have unreliable destructors. Java has them. Python has them. No one will use them. D's destructors are in much better shape than either Java's or Python's, but let's take a simple survey: Does anyone here use RAII in D? Please step forward. Please go over your scope(exit)s and tell me that 70% of them (and I'm being generous here, I'm guessing actual number is closer to 95%) are *not* release of resources acquired in the same scope. If they are, then you are in a position where RAII would have made your code cleaner and simpler, but you chose not to use it. scope(exit) is a much cleaner solution than a finally clause, but not as clean as RAII. If the language supports RAII, how come people are not using it? Shachar
Apr 17
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 17 April 2017 at 11:14:47 UTC, Shachar Shemesh wrote:
 On Sunday, 16 April 2017 at 17:00:25 UTC, Jack Stouffer wrote:

 So we can say that D has buggy RAII. Claiming that D doesn't 
 have RAII is equally false.
To me, that's a basic misunderstanding of what RAII mean. RAII, to me, means you wrap your resource in a container, and then can just go ahead and forget about releasing it. As such, saying that D has RAII, but they only work most of the time means that the core functionality that RAII provides is simply not working. There are other languages out there that have unreliable destructors. Java has them. Python has them. No one will use them. D's destructors are in much better shape than either Java's or Python's, but let's take a simple survey: Does anyone here use RAII in D? Please step forward.
D would have the ability to have a nice container that would do RAII (for classes since for structs, __dtors are called automatically) but such a thing doesn't exist in the standard library. For example in Delphi or FPC standard libs there's the TObjectList class that can be set to delete the instances stored in the list (but there's still the obligation to explicitly free the list itself). D could do even better: An interesting fact: for the members that are plain structs (not new-ed struct), __fieldDtor automatically calls the __xdtor of the structs. __fieldDtor is itself called automatically, so - make a `struct ObjectContainer {}` (basically it would be an array) - in this ObjectContainer, add a member function that adds new "owned" resources (e.g `T addNew(T,A...)(A a){items ~= make!T(Mallocator.instance, a); return items.last;}`) - in the ObjectContainer `~this()`, add code that loop the resources and dispose() them. Resources will be automatically freed: class/struct Stuff { ObjectContainer resources; } when a Stuff goes out of scope or is released, this happens: Stuff.__fieldDtor() -> ObjectContainer.__xdtor() -> foreach(r; resources) r.__xdtor. So there's definitively the features to do RAII in D but they are not usable "out-of-the-box", one has to code his specialized containers.
 scope(exit) is a much cleaner solution than a finally clause, 
 but not as clean as RAII.
Actually for local variables and other temporaries I personally don't care much about RAII. I even think that in this case I can let the GC managing the junks.
 If the language supports RAII, how come people are not using it?
Because the default management is done by the GC and the GC works. Mixing RAII and GC can lead to unexpected results. Put a GC-managed member (e.g a string) in a RAII-managed aggregate and then, at a time, the GC will think that the member is not used anymore and it frees it. ___ note about the ObjectContainer: it can be very easy to do actually, using std.array.Array and "alias this". No need to code a full container.
Apr 17
parent Shachar Shemesh <shachar weka.io> writes:
 D would have the ability to have a nice container that would do RAII
 (for classes since for structs, __dtors are called automatically)
That's just it, though. They are not. Not reliably. Shachar
Apr 18
prev sibling next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 17 April 2017 at 11:14:47 UTC, Shachar Shemesh wrote:
 On Sunday, 16 April 2017 at 17:00:25 UTC, Jack Stouffer wrote:

 So we can say that D has buggy RAII. Claiming that D doesn't 
 have RAII is equally false.
To me, that's a basic misunderstanding of what RAII mean. RAII, to me, means you wrap your resource in a container, and then can just go ahead and forget about releasing it. As such, saying that D has RAII, but they only work most of the time means that the core functionality that RAII provides is simply not working.
RAII !== containers. Containers will not release resources for types that are themselves don't do so via their destructor. You can have a vector<FILE*>, and it will dutifully release it's own memory, but won't close the files. Containers are library types. RAII is a language feature. How on Earth in this discussion the two became interchanged?
 There are other languages out there that have unreliable 
 destructors. Java has them. Python has them. No one will use 
 them.

 D's destructors are in much better shape than either Java's or 
 Python's, but let's take a simple survey: Does anyone here use 
 RAII in D? Please step forward.
I do. Phobos does. vibe.d does. Many other projects do.
 Please go over your scope(exit)s and tell me that 70% of them 
 (and I'm being generous here, I'm guessing actual number is 
 closer to 95%) are *not* release of resources acquired in the 
 same scope. If they are, then you are in a position where RAII 
 would have made your code cleaner and simpler, but you chose 
 not to use it.
Writing a whole new struct just to release one specific resource once is neither cleaner nor simpler.
 scope(exit) is a much cleaner solution than a finally clause, 
 but not as clean as RAII. If the language supports RAII, how 
 come people are not using it?
If it is more convenient to use scope(exit) than to introduce a new type, I don't see why the latter should be considered. At least until the need for the same scope(exit) is encountered more than once. Not to mention there are also scope(success|failure) that simply cannot be achieved with destructors. D supports ("has") RAII idiom, period. Whether or how it is used by various libraries does not in any way augment that fact.
Apr 17
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 17, 2017 11:14:47 Shachar Shemesh via Digitalmars-d wrote:
 scope(exit) is a much cleaner solution than a finally clause, but
 not as clean as RAII. If the language supports RAII, how come
 people are not using it?
Well, if you're talking managing memory, most folks just use the GC. And for the rest, I think that RAII does get used fairly frequently (e.g. std.stdio.File uses it), but largely, RAII is only going to get used when some resource is going to need to be passed around or managed in the same way in several places, because otherwise, it's simpler to just put a scope(exit) statement in there than to declare a type. And the programs that do use RAII are simply buggy in the cases where constructors don't clean up properly when an exception is thrown. For a lot of code, it really doesn't matter (e.g. they simply aren't at any real risk of an exception being thrown during construction), and even in code where it does matter, it could easily be missed, especially if exceptions aren't thrown often. Certainly, this topic comes up infrequently enough that I really don't think that all that many folks are using scope(exit) instead of RAII simply because of the bug with constructors. I'd guess that most folks aren't even aware that it's an issue. Now, I totally agree that https://issues.dlang.org/show_bug.cgi?id=14246 is a serious issue that needs to be fixed and that some software is going to have some major issues as long as it uses RAII and that bug exists. But because D does not rely as heavily on RAII as C++ does, and RAII works correctly in many cases (particularly if an exception is not thrown during construction), a lot of code can be written which happens to use RAII without being buggy or without the bug being caught. It's when you start relying heavily on RAII that you're more likely to notice it. If RAII were completely broken, I suspect that this would have been a higher priority and would have been fixed ages ago. But because RAII mostly works, this problem has managed to go sufficiently under the radar that it's never become as high a priority as it arguably should be, and it hasn't yet been fixed like it should have been. - Jonathan M Davis
Apr 17
prev sibling next sibling parent qznc <qznc web.de> writes:
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
Apr 11
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2017-04-11 at 19:57 +0000, Piotr Kowalski via Digitalmars-d
wrote:
 Hello D community,
=20
 I am language polyglot that lately got interested in D. I love=C2=A0
 it, it's very elegant language, so simple and so powerful same=C2=A0
 time. I will write some thoughts as outsider.
=20
=20
[=E2=80=A6] 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++ =E2=86=92 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Apr 12
prev sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote:

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

 Why D is not there?
Because maintainer of that site doesn't want D there, as I remember from previous discussions. At some point (years ago) D was present there, then removed. C and C++ programs are trivially translatable to D and compiled with the same LLVM backend with LDC, so whatever speed is shown by C and C++ there can usually be repeated in D.
Apr 12
next sibling parent reply qznc <qznc web.de> writes:
On Wednesday, 12 April 2017 at 19:31:06 UTC, thedeemon wrote:
 On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote:

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

 Why D is not there?
Because maintainer of that site doesn't want D there, as I remember from previous discussions. At some point (years ago) D was present there, then removed. C and C++ programs are trivially translatable to D and compiled with the same LLVM backend with LDC, so whatever speed is shown by C and C++ there can usually be repeated in D.
No. Isaac is very cooperative. He usually pops up quickly, if someone mentions benchmarksgame. https://forum.dlang.org/post/wcownwoteiownrtnilow forum.dlang.org https://forum.dlang.org/post/rrfbuokpyhjsusuxqxka forum.dlang.org https://forum.dlang.org/post/iskkpwaaaqlcgjymhjzi forum.dlang.org
Apr 12
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 12 April 2017 at 19:37:06 UTC, qznc wrote:
 On Wednesday, 12 April 2017 at 19:31:06 UTC, thedeemon wrote:
 On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski 
 wrote:

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

 Why D is not there?
Because maintainer of that site doesn't want D there, as I remember from previous discussions. At some point (years ago) D was present there, then removed. C and C++ programs are trivially translatable to D and compiled with the same LLVM backend with LDC, so whatever speed is shown by C and C++ there can usually be repeated in D.
No. Isaac is very cooperative. He usually pops up quickly, if someone mentions benchmarksgame. https://forum.dlang.org/post/wcownwoteiownrtnilow forum.dlang.org https://forum.dlang.org/post/rrfbuokpyhjsusuxqxka forum.dlang.org https://forum.dlang.org/post/iskkpwaaaqlcgjymhjzi forum.dlang.org
Cooperative with what? He chose not to include D anymore, which at one point dominated the shootout, and says we should just start our own site: https://forum.dlang.org/post/no8klt$1d1i$1 digitalmars.com
Apr 12
parent reply Isaac Gouy <igouy2 yahoo.com> writes:
On Thursday, 13 April 2017 at 03:29:26 UTC, Joakim wrote:

 Cooperative with what?  He chose not to include D anymore, 
 which at one point dominated the shootout, and says we should 
 just start our own site:

 https://forum.dlang.org/post/no8klt$1d1i$1 digitalmars.com
When did D dominate? http://web.archive.org/web/20090303214521/http://shootout.alioth.debian.org:80/gp4/benchmark.php?test=all%26lang=all On that archived page you can see a lot of language implementations that I chose not to include on the "new" quad core measurements, that began back in 2008 iirc. For newer languages like Crystal and Nim and Julia the tiny benchmarks game programs have been used to provide performance examples (without needing my involvement): https://github.com/kostya/crystal-benchmarks-game https://github.com/def-/nim-benchmarksgame https://github.com/JuliaLang/julia/tree/master/test/perf/shootout :but when it comes to D as-far-as-I-can-tell those efforts seem to somehow disappoint the D community and the comparisons are not publicized in the same way: https://forum.dlang.org/post/ihfqubwtadgvlxkvedbl forum.dlang.org
Apr 15
parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 15 April 2017 at 18:00:50 UTC, Isaac Gouy wrote:
 On Thursday, 13 April 2017 at 03:29:26 UTC, Joakim wrote:

 Cooperative with what?  He chose not to include D anymore, 
 which at one point dominated the shootout, and says we should 
 just start our own site:

 https://forum.dlang.org/post/no8klt$1d1i$1 digitalmars.com
When did D dominate? http://web.archive.org/web/20090303214521/http://shootout.alioth.debian.org:80/gp4/benchmark.php?test=all%26lang=all
Probably a year or so before that page was archived, when I played around with your results to see what languages popped up. It was likely the second time I came across D- the first may be Yegge's blog post mentioning D as a possible Next Big Language (http://forum.dlang.org/thread/bjqcszlnohjjjersvojp forum.dlang.org)- when I found that D came out tops if I weighted time, memory, and source code size equally. Not always highest, as Free Pascal would sometimes beat it, but D usually won. You are only weighting time in that archived page, which will favor languages that take hundreds of lines of code to do the same thing, because there's no penalty for verbosity.
 On that archived page you can see a lot of language 
 implementations that I chose not to include on the "new" quad 
 core measurements, that began back in 2008 iirc.
D was in the top 10 for time alone on the page you linked, without even the benefit of an llvm backend like it has today, I wonder why you'd remove a language that performed so well.
 For newer languages like Crystal and Nim and Julia the tiny 
 benchmarks game programs have been used to provide performance 
 examples (without needing my involvement):

 https://github.com/kostya/crystal-benchmarks-game
kostya does another one that includes D, it does very well: https://github.com/kostya/benchmarks
 https://github.com/JuliaLang/julia/tree/master/test/perf/shootout
This one doesn't show any benchmarks because it says it's in your game, so you are involved.
 :but when it comes to D as-far-as-I-can-tell those efforts seem 
 to somehow disappoint the D community and the comparisons are 
 not publicized in the same way:

 https://forum.dlang.org/post/ihfqubwtadgvlxkvedbl forum.dlang.org
I'm guessing that's because he tried to update the old D benchmarking code and likely the C/C++ code has been optimized a lot more since. I took the source for the top C regex-dna benchmark late last year and compared it to the latest D implementation by Dmitry, the author of std.regex. I found that the D benchmark easily beat the top C regex benchmark on a single core- not surprising as Dmitry's regex always beats everyone else- but would lose on multi-core, only because Dmitry's benchmark had not been parallelized. The D source was an order of magnitude smaller, partially because both call external regex libraries that do most of the work but mostly because the C one back then needed a lot more source to be parallelized. I see that benchmark has since been renamed to regex-redux and new C implementations have been added, though the benchmark description appears to be the same. I suspect D would do just as well on the other benchmarks now.
Apr 15
parent reply Isaac Gouy <igouy2 yahoo.com> writes:
On Sunday, 16 April 2017 at 04:19:56 UTC, Joakim wrote:
 came out tops if I weighted time, memory, and source code size 
 equally.  Not always highest, as Free Pascal would sometimes 
 beat it, but D usually won.
You juggled the numbers to get a result ;-)
 This one doesn't show any benchmarks because it says it's in 
 your game, so you are involved.
No it does not say that. It says "This directory contains the Julia version of the "The Computer Language Benchmarks Game". It provides "perf.jl" to time those Julia programs. Those Julia programs are not included in the benchmarks game.
 I'm guessing that's because he tried to update the old D 
 benchmarking code and likely the C/C++ code has been optimized 
 a lot more since. ...
 I suspect D would do just as well on the other benchmarks now.
What a great opportunity for someone in the D community to help publicize the language!
Apr 16
next sibling parent reply Isaac Gouy <igouy2 yahoo.com> writes:
On Sunday, 16 April 2017 at 08:44:07 UTC, Walter Bright wrote:
 When anyone mentions the Compiler Shootout for the last 10 
 years, Isaac always pops up and says he won't put it on his 
 site. I wish he'd just go away.
I wish the D community would stop using the benchmarks game as an excuse.
Apr 16
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2017-04-16 at 16:09 +0000, Isaac Gouy via Digitalmars-d wrote:
=20
[=E2=80=A6]
 I wish the D community would stop using the benchmarks game as an=C2=A0
 excuse.
=20
But you have a position of great power. People look at your game and if a language isn't in it, it is assumed to be crap. You may not be making choices with this in mind, but a lot of programmers and managers make this inference. This is particularly the case because not all the languages are computationally inclined. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Apr 16
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 16 April 2017 at 07:11:23 UTC, Isaac Gouy wrote:
 On Sunday, 16 April 2017 at 04:19:56 UTC, Joakim wrote:
 came out tops if I weighted time, memory, and source code size 
 equally.  Not always highest, as Free Pascal would sometimes 
 beat it, but D usually won.
You juggled the numbers to get a result ;-)
Nope, simply weighted everything equally and saw what came out on top, strange that you call equal weights "juggling the numbers." As I said, I'd only heard of D once before and certainly wasn't using it, so I wasn't out to get a particular result.
 This one doesn't show any benchmarks because it says it's in 
 your game, so you are involved.
No it does not say that. It says "This directory contains the Julia version of the "The Computer Language Benchmarks Game". It provides "perf.jl" to time those Julia programs. Those Julia programs are not included in the benchmarks game.
You're right, I saw the links to the game and thought they were saying it did, guess not.
 I'm guessing that's because he tried to update the old D 
 benchmarking code and likely the C/C++ code has been optimized 
 a lot more since. ...
 I suspect D would do just as well on the other benchmarks now.
What a great opportunity for someone in the D community to help publicize the language!
As I pointed out to you, there are other benchmarks already doing that. You're free to include whatever languages you like in your game, of course, but it's strange that you're throwing out languages that were already implemented for all the benchmarks and doing well, especially since their communities would be happy to keep them up to date.
Apr 16
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2017-04-12 at 19:31 +0000, thedeemon via Digitalmars-d wrote:
 On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote:
=20
 http://benchmarksgame.alioth.debian.org/
=20
 Why D is not there?
=20 Because maintainer of that site doesn't want D there, as I=C2=A0 remember from previous discussions. At some point (years ago) D=C2=A0 was present there, then removed. C and C++ programs are trivially=C2=A0 translatable to D and compiled with the same LLVM backend with=C2=A0 LDC, so whatever speed is shown by C and C++ there can usually be=C2=A0 repeated in D. =20
It is Isaac's game, he runs it, he chooses which languages are up there. It is not an official Debian thing as far as I know. So what the problem? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Apr 13
parent thedeemon <dlang thedeemon.com> writes:
On Thursday, 13 April 2017 at 08:08:04 UTC, Russel Winder wrote:

 It is Isaac's game, he runs it, he chooses which languages are 
 up there. It is not an official Debian thing as far as I know. 
 So what the problem?
I think Piotr stated the problem in the original post. If a language is missing in that shootout many people think the language is too obscure, unknown, out of mainstream, maybe even dead. This shootout and a couple of other ratings have significant influence on public opinion on different languages and also on public awareness of different languages.
Apr 13