On 3/17/13 4:44 PM, Walter Bright wrote:
> On 3/17/2013 8:58 AM, Suliman wrote:
>> Yesterday I had tried to put it reddit, but I have never used reddit
>> before and
>> do not sure that it was added at proper section.
>>
>
> reddit.com/r/programming is where it should go.

It was at:

http://www.reddit.com/r/programming/comments/1aet4m/rust_vs_d/

Unfortunately reddit's fairness system has more popular submitters rank higher than new submitters.


Andrei

On Saturday, 16 March 2013 at 14:42:58 UTC, Suliman wrote:
> Hi folks! I had wrote small article about Rust vs D. I hope that you will like it!
>
> http://versusit.org/rust-vs-d

This can see the D language is very good, I like the D language

The reason I use golang and not dlang for development at work is because debugging is straightforward no weird segfaults after you program has been running for a couple of days.

Their debugging and benchmark tools are really good and the documentation
is fantastic. I haven't used dlang for a while now so I don't know how much
that sort of thing is improved.
I'm guessing from the fact that more companies are starting to use it, that
it becoming more stable to use.

I am a HUGE fan of D and hope to use it exclusively one day, but last I checked if you have 5 days to do a project in golang is more likely to get you results.

One question, is there a place where I can see who is currently involved with D and what their primary roles are?

-Rory

On Sun, 2013-03-17 at 22:13 +0100, Paulo Pinto wrote:
> Am 17.03.2013 20:28, schrieb 1100110:
[…]
> > The day I can compile pypy without needing 8Gb of memory is the day I'll consider it.
> 
> Uau, that much?!
> 
> I tend to use Python only for shell scripting type of tasks, so I wasn't aware that PyPy is so memory hungry.

Using PyPy to execute Python scripts is not the problem, that is fast and efficient. 1100110 stated that it took 8GB to compile the PyPy system in his experience. Most people will never need to do that.

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

On Sun, 2013-03-17 at 13:56 -0700, Walter Bright wrote:
> On 3/17/2013 3:01 AM, Russel Winder wrote:
> > I guess this is because of the segmented stacks architecture behind the realization of Go.
> 
> Segmented stacks have a significant performance cost to them, as well as making it hard to interface to other languages. I also think that the shift to 64 bits makes them obsolete anyway.

I think this is possibly not the case or Go and Rust would not have gone this route – which is the imperative native code equivalent of what the functional languages and the dynamic languages do using the heap. The problem is to not have a single stack so that it becomes easy to manage 1,000+ threads within a single process.

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

On 3/18/2013 2:22 AM, Russel Winder wrote:
> On Sun, 2013-03-17 at 13:56 -0700, Walter Bright wrote:
>> On 3/17/2013 3:01 AM, Russel Winder wrote:
>>> I guess this is because of the segmented stacks architecture behind the
>>> realization of Go.
>>
>> Segmented stacks have a significant performance cost to them, as well as making
>> it hard to interface to other languages. I also think that the shift to 64 bits
>> makes them obsolete anyway.
>
> I think this is possibly not the case or Go and Rust would not have gone
> this route – which is the imperative native code equivalent of what the
> functional languages and the dynamic languages do using the heap. The
> problem is to not have a single stack so that it becomes easy to manage
> 1,000+ threads within a single process.
>

That's just not an issue when you have 64 bits of address space. You can still have 4 billion stacks of 4 billion bytes each.

On Monday, 18 March 2013 at 09:18:38 UTC, Russel Winder wrote:
> On Sun, 2013-03-17 at 22:13 +0100, Paulo Pinto wrote:
>> Am 17.03.2013 20:28, schrieb 1100110:
> […]
>> > The day I can compile pypy without needing 8Gb of memory is the day I'll
>> > consider it.
>> 
>> Uau, that much?!
>> 
>> I tend to use Python only for shell scripting type of tasks, so I wasn't aware that PyPy is so memory hungry.
>
> Using PyPy to execute Python scripts is not the problem, that is fast
> and efficient. 1100110 stated that it took 8GB to compile the PyPy
> system in his experience. Most people will never need to do that.

Yeah, you are right. Compiling Firefox will even require more than that.

Walter Bright:

> That's just not an issue when you have 64 bits of address space. You can still have 4 billion stacks of 4 billion bytes each.

At this point I suggest you to study exactly why Rust developers have decided to use a segmented stack. It seems to work well for them.

Bye,
bearophile

On Saturday, 16 March 2013 at 14:42:58 UTC, Suliman wrote:
> Hi folks! I had wrote small article about Rust vs D. I hope that you will like it!
>
> http://versusit.org/rust-vs-d

Your first Rust example has "100.times" instead of "10.times".

Is factorial really a built-in Rust function?? If so, the text should say so.

Might perhaps be worth noting that thread-local variables are built-in in D, so that D's support for threads is not entirely library-based.
The core language is aware of threads, but thread creation etc is library based.

On 3/18/13 1:46 AM, Rory McGuire wrote:
> The reason I use golang and not dlang for development at work is because
> debugging is straightforward no weird segfaults after you program has
> been running for a couple of days.
>
> Their debugging and benchmark tools are really good and the
> documentation is fantastic.

Could you please go into details on the debugging and benchmarking tools? Thanks.

> I haven't used dlang for a while now so I
> don't know how much that sort of thing is improved.
> I'm guessing from the fact that more companies are starting to use it,
> that it becoming more stable to use.
>
> I am a HUGE fan of D and hope to use it exclusively one day, but last I
> checked if you have 5 days to do a project in golang is more likely to
> get you results.
>
> One question, is there a place where I can see who is currently involved
> with D and what their primary roles are?

At this point roles are determined by what people work on, and how intensely.


Andrei