Re: Thoughts from newcommer

[Stefan Koch via Digitalmars-d]

On Tuesday, 18 April 2017 at 16:42:38 UTC, Andrei Alexandrescu 
wrote:

On 04/18/2017 03:00 AM, Shachar Shemesh wrote:
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.


Yah, clearly there's a problem with the language implementation 
(and the definition that is incomplete, leaving too much leeway 
to the implementation). Clearly the way to go is fix the bug, 
which has been preapproved and of raised gravity. That would 
obviate the entire "implementation has a bug therefore language 
does not support RAII" line of reasoning. Thanks Stefan for 
looking into this! -- Andrei


This is going to be tricky without breaking code which worked 
around the bug.

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 04/18/2017 03:00 AM, Shachar Shemesh wrote:

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.


Yah, clearly there's a problem with the language implementation (and the 
definition that is incomplete, leaving too much leeway to the 
implementation). Clearly the way to go is fix the bug, which has been 
preapproved and of raised gravity. That would obviate the entire 
"implementation has a bug therefore language does not support RAII" line 
of reasoning. Thanks Stefan for looking into this! -- Andrei

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 04/18/2017 10:55 AM, Russel Winder via Digitalmars-d wrote:

On Tue, 2017-04-18 at 09:23 -0400, Andrei Alexandrescu via Digitalmars-
d wrote:

On 4/18/17 8:48 AM, prdan wrote:

Thanks, maybe I will write a blog post about my experiences also.


That would be great! Michael Parker may be of help if you consider
publishing in the official D Blog. -- Andrei


And I am sure CVu or Overload can publish an article on this if you
were to write one.


That would be fantastic, thanks for this great idea. prdan please push 
this forward! -- Andrei

Re: Thoughts from newcommer

[Russel Winder via Digitalmars-d]

On Tue, 2017-04-18 at 09:23 -0400, Andrei Alexandrescu via Digitalmars-
d wrote:
> On 4/18/17 8:48 AM, prdan wrote:
> > Thanks, maybe I will write a blog post about my experiences also.
> 
> That would be great! Michael Parker may be of help if you consider 
> publishing in the official D Blog. -- Andrei

And I am sure CVu or Overload can publish an article on this if you
were to write one.

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

signature.asc
Description: This is a digitally signed message part

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 4/18/17 8:48 AM, prdan wrote:

Thanks, maybe I will write a blog post about my experiences also.


That would be great! Michael Parker may be of help if you consider 
publishing in the official D Blog. -- Andrei

Re: Thoughts from newcommer

[prdan via Digitalmars-d]

On Tuesday, 18 April 2017 at 12:22:10 UTC, Andrei Alexandrescu 
wrote:


Cool, thanks for this work! However, a word of caution - 
experiments ran on different CPUs can't count as comparable.




I didn't compare D times to numbers from benchmarks game site.
I've ran other languages on the same CPU also, all the numbers 
I've posted are from the same CPU for those 3 languages so they 
are comparable in this case :)




That's an awesome initiative, please keep us posted!


Andrei


Thanks, maybe I will write a blog post about my experiences also.

Re: Thoughts from newcommer

[rikki cattermole via Digitalmars-d]

On 18/04/2017 1:22 PM, Andrei Alexandrescu wrote:

On 04/17/2017 10:57 PM, prdan wrote:

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.


Cool, thanks for this work! However, a word of caution - experiments ran
on different CPUs can't count as comparable.


Even if the hardware is identical, all it takes is a setting changed in 
the thread scheduler of an OS and you will be getting wildly different 
results, beware of separate computers for benchmarking period.

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 04/17/2017 10:57 PM, prdan wrote:

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.


Cool, thanks for this work! However, a word of caution - experiments ran 
on different CPUs can't count as comparable.



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.


That's an awesome initiative, please keep us posted!


Andrei

Re: Thoughts from newcommer

[prdan via Digitalmars-d]

On Tuesday, 18 April 2017 at 07:22:29 UTC, thedeemon wrote:

Which compiler did you use for D?



I've used newest LDC.

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.


Not in this case, there is a batch of the job that need to be 
done parallel but second part is done sequential (that takes 
majority of the time) so in this case this is good. Just look at 
source code of the algorithm in the link I've provided.
I've also looked at callgrind and majority of the time is spent 
in regex so it's good.

Re: Thoughts from newcommer

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 18 April 2017 at 07:22:29 UTC, thedeemon wrote:
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.


Minor note: sometimes high CPU usage isn't good either, if the 
CPU is used for multithreading overhead/bookkeeping (eg: 
scheduler).

Re: Thoughts from newcommer

[thedeemon via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Shachar Shemesh via Digitalmars-d]

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

Re: Thoughts from newcommer

[Jerry via Digitalmars-d]

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.

Re: Thoughts from newcommer

[prdan via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Stanislav Blinov via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Jerry via Digitalmars-d]

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.

Re: Thoughts from newcommer

[jmh530 via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Stanislav Blinov via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Jerry via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Jack Stouffer via Digitalmars-d]

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

Re: Thoughts from newcommer

[Jonathan M Davis via Digitalmars-d]

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

Re: Thoughts from newcommer

[Stanislav Blinov via Digitalmars-d]

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

Re: Thoughts from newcommer

[Basile B. via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Shachar Shemesh via Digitalmars-d]

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

Re: Thoughts from newcommer

[Jerry via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Thoughts from newcommer

[Jack Stouffer via Digitalmars-d]

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);
}

Re: Thoughts from newcommer

[Jerry via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Jack Stouffer via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Russel Winder via Digitalmars-d]

On Sun, 2017-04-16 at 16:09 +, Isaac Gouy via Digitalmars-d wrote:
> 
[…]
> I wish the D community would stop using the benchmarks game as an 
> excuse.
> 

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.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Thoughts from newcommer

[Joakim via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Isaac Gouy via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Stefan Koch via Digitalmars-d]

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

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Thoughts from newcommer

[Walter Bright via Digitalmars-d]

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.


On 4/16/2017 12:11 AM, 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 ;-)




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!

Re: Thoughts from newcommer

[Shachar Shemesh via Digitalmars-d]

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

Re: Thoughts from newcommer

[Isaac Gouy via Digitalmars-d]

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!

Re: Thoughts from newcommer

[Joakim via Digitalmars-d]

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/bjqcszlnohjjjersv...@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/ihfqubwtadgvlxkve...@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.

Re: Thoughts from newcommer

[Isaac Gouy via Digitalmars-d]

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/ihfqubwtadgvlxkve...@forum.dlang.org

Re: Thoughts from newcommer

[thedeemon via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Dejan Lekic via Digitalmars-d]

On Wednesday, 12 April 2017 at 09:38:49 UTC, Russel Winder wrote:
On Tue, 2017-04-11 at 20:07 +, 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!

Re: Thoughts from newcommer

[Russel Winder via Digitalmars-d]

On Wed, 2017-04-12 at 19:31 +, thedeemon via Digitalmars-d 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.
> 

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?

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

signature.asc
Description: This is a digitally signed message part

Re: Thoughts from newcommer

[Joakim via Digitalmars-d]

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/wcownwoteiownrtni...@forum.dlang.org
https://forum.dlang.org/post/rrfbuokpyhjsusuxq...@forum.dlang.org
https://forum.dlang.org/post/iskkpwaaaqlcgjymh...@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

Re: Thoughts from newcommer

[qznc via Digitalmars-d]

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/wcownwoteiownrtni...@forum.dlang.org
https://forum.dlang.org/post/rrfbuokpyhjsusuxq...@forum.dlang.org
https://forum.dlang.org/post/iskkpwaaaqlcgjymh...@forum.dlang.org

Re: Thoughts from newcommer

[thedeemon via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Russel Winder via Digitalmars-d]

On Tue, 2017-04-11 at 20:07 +, 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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Thoughts from newcommer

[Russel Winder via Digitalmars-d]

On Tue, 2017-04-11 at 19:57 +, 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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Thoughts from newcommer

[Piotr Kowalski via Digitalmars-d]

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.

Re: Thoughts from newcommer

[qznc via Digitalmars-d]

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

Re: Thoughts from newcommer

[Jack Stouffer via Digitalmars-d]

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

Re: Thoughts from newcommer

[Eugene Wissner via Digitalmars-d]

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.

Re: Thoughts from newcommer

[Piotr Kowalski via Digitalmars-d]

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

Re: Thoughts from newcommer

[Jack Stouffer via Digitalmars-d]

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

Re: Thoughts from newcommer

[Stefan Koch via Digitalmars-d]

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=ph=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)

Thoughts from newcommer

[Piotr Kowalski via Digitalmars-d]

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=ph=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