www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Rust vs Dlang

reply "Suliman" <evermind live.ru> writes:
Hi folks! I had wrote small article about Rust vs D. I hope that 
you will like it!

http://versusit.org/rust-vs-d
Mar 16 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/16/13, Suliman <evermind live.ru> 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 code:

```
In D a similar code would look as follows:
void main() {
  for (int i = 0; i < 10; i++) {
      writeln("Hello");
 }
}
```

Should really be:

```
foreach (i; 0 .. 10)
     writeln("Hello");
```

It avoids the common mistake of using a signed 32-bit type for indexing.

This:
```
void main() {
foreach (i, val; taskPool.parallel(new int[10]))
{
writeln("Hello:", i);
}
}
```

Also very very wrong, you don't have to allocate, use iota:

void main()
{
    foreach (i, val; taskPool.parallel((iota(0, 10)))
    {
        writeln("Hello:", i);
    }
}

Also your example code seems to embed some strange hidden Unicode
characters (Error: unsupported char 0xfeff) which make copy-pasting
and running the examples not work.

Anyway I don't agree with the conclusions, this is barely scratching
the surface of either language.
Mar 16 2013
next sibling parent "Suliman" <evermind live.ru> writes:
Andrej Mitrovic, thanks! I will fix it!
yes look like bbcode put some crap in page body. We will try to 
fix it.
Mar 16 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 16 Mar 2013 11:14:15 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 On 3/16/13, Suliman <evermind live.ru> 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 code:

 ```
 In D a similar code would look as follows:
 void main() {
   for (int i = 0; i < 10; i++) {
       writeln("Hello");
  }
 }
 ```

 Should really be:

 ```
 foreach (i; 0 .. 10)
      writeln("Hello");
 ```

 It avoids the common mistake of using a signed 32-bit type for indexing.


That is not a mistake in this code.  In fact, your replacement still uses  
signed types.


 Also your example code seems to embed some strange hidden Unicode
 characters (Error: unsupported char 0xfeff) which make copy-pasting
 and running the examples not work.


feff is a BOM (byte order mark) which is typically at the beginning of a  
file to establish the number of bits per code point and the byte order of  
the code points.  It is not strange, and it should be handled correctly by  
dmd.  If not, that is a bug.

-Steve
Mar 17 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/17/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 In fact, your replacement still uses
 signed types.


Hmm, I was expecting it to always be size_t. Apparently it's based on the range:

foreach (i; 0 .. int.max) { }  // i is int
foreach (i; 0 .. size_t.max) { }  // i is size_t

Well, we can put a 'size_t' in there so it's not too bad.
Mar 17 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/17/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:

  it should be handled correctly by dmd.  If not, that is a bug.


It likely wasn't located at the beginning. Anyway the samples now seem
to be images.
Mar 17 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/13 10:42 AM, 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


Nice writeup. Could you please fix the code formatting? Indentation is 
lost at least on Chrome and Firefox on OSX. Then I'll be glad to post on 
reddit.

Andrei
Mar 16 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sat, 2013-03-16 at 21:06 -0400, Andrei Alexandrescu wrote:

 On 3/16/13 10:42 AM, 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


=20
 Nice writeup. Could you please fix the code formatting? Indentation is=


=20

 lost at least on Chrome and Firefox on OSX. Then I'll be glad to post on=


=20

 reddit.


Comments such as "There are no threads in D out of the box, but they can
be implemented with the use of language libraries" seems unfair all
round. The D platform is compiler + Phobos so there are threads out of
the box. D also has spawn just as Rust does; out of the box.=20

Also all the imports for D are missing from the code.=20

The error handling example is unfair to D, it is not like Go where
return codes are the sole mechanism of error handling, D has exceptions
analogous to Rust.

The switch example maximizes the number of write operations which is
minimizing the "functional approach" that the article appears to be
driving at. So does the switch statement return a value in either
language? If not can maps/dictionaries be used so as to have a single
output statement of a selected string?

--=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
Mar 16 2013
parent "JN" <666total wp.pl> writes:
On Sunday, 17 March 2013 at 06:57:32 UTC, Russel Winder wrote:

 Comments such as "There are no threads in D out of the box, but 
 they can
 be implemented with the use of language libraries" seems unfair 
 all
 round. The D platform is compiler + Phobos so there are threads 
 out of
 the box. D also has spawn just as Rust does; out of the box.


Well, there is an advantage of having stuff built-in. Look at 
C++, it's annoying to type #include <string> whenever you want to 
use such a basic type as string. In D a basic program will also 
require multiple imports for usually the same basic behaviour. In 

list, in D we don't have it (yet ;)). Imagine if you had to 
import std.string; everytime you wanted to use a string type. It 
wouldn't be the most fun thing to use. IMHO there's nothing wrong 
in putting the basic functionality built-in. It doesn't matter if 
it's somehow baked into the language or as an auto-import 
library, it's a matter of convenience but in these cases it's 
worth it (IMHO).
Mar 18 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2013-03-16 at 21:06 -0400, Andrei Alexandrescu wrote:

 On 3/16/13 10:42 AM, 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


=20
 Nice writeup. Could you please fix the code formatting? Indentation is=


=20

 lost at least on Chrome and Firefox on OSX. Then I'll be glad to post on=


=20

 reddit.


Sorry I forgot to add:

Can either of the codes calculate:

	factorial(40)

?

i.e. are the codes at all relevant given that 32-bit and 64-bit integers
are useless for this calculation?

Python happily and correctly calculates factorial(2000).

Also if a functional approach is being advertised why use an imperative
algorithm for factorial, with it's explicit iteration, why not use
reduce so as to hide the itertation. In D:

	reduce!"a * b"(1L, iota(1, n+1)(

It appears the 1L is needed here when using ulongs or type inference
fails :-(
--=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
Mar 17 2013
prev sibling parent reply "Suliman" <evermind live.ru> writes:
Nice writeup. Could you please fix the code formatting? 
Indentation is lost at least on Chrome and Firefox on OSX. Then 
I'll be glad to post on reddit.


Andrei Alexandrescu, I redid it and put source code as files for 
downloading till we will not fix or bbcode parser. You may check. 
I would thanks full if you will reddit it.
Mar 17 2013
parent reply "Suliman" <evermind live.ru> writes:
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.
Mar 17 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 17 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 17 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
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


I agree, only Rust seems to compete with D for the goal as being 
a real alternative to C/C++. Interesting read comparing the two.

If I may critique, the section concerning error handling, the 
comparison is not accurate. The D equivalent of what was shown in 
Rust needs to show how try-catch-finally, or scope(...), is used 
to perform the equivalent error handling.

--rt
Mar 16 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On 17.03.2013 07:25, Rob T wrote:

 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


 I agree, only Rust seems to compete with D for the goal as being a real
 alternative to C/C++. Interesting read comparing the two.



Microsoft decides to offer a direct native code compiler instead of the 
AOT + JIT combo.

They have done it for Singularity and part of that work is now being 
used in Windows Phone 8, where .NET applications are actually compiled 
to native code when uploaded to the Windows Store.

Go could be an alternative, given the proofs given by Oberon and Active 
Oberon as system programming languages, which Go kind of follows.

However the Go guys just don't agree with the progresses made in 
language abstractions in the last decades, which in my view is a plus 
point for D and Rust, and made me stop caring about Go.

In Europe Ada seems to be picking up some users now that there is a good 
quality free compiler available (GNAT) and the public is more aware of 
the security issues created by C and C++ when used by junior developers.

Anyway the more languages the better.

--
Paulo
Mar 17 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2013-03-17 at 08:59 +0100, Paulo Pinto wrote:
[=E2=80=A6]

 However the Go guys just don't agree with the progresses made in=20
 language abstractions in the last decades, which in my view is a plus=20
 point for D and Rust, and made me stop caring about Go.


[=E2=80=A6]

So what are the features that Go is ignoring that D has?

An article on this would be good marketing for D just now.

--=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
Mar 17 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On 17.03.2013 09:05, Russel Winder wrote:

 On Sun, 2013-03-17 at 08:59 +0100, Paulo Pinto wrote:
 […]

 However the Go guys just don't agree with the progresses made in
 language abstractions in the last decades, which in my view is a plus
 point for D and Rust, and made me stop caring about Go.


 […]

 So what are the features that Go is ignoring that D has?

 An article on this would be good marketing for D just now.


The first known one is that Go is the only strong typed language to 
eschew generics in the 21st century.

For the rest, copying from my discussion on Lambda the Ultimate about 
C++ developers not jumping into Go 
(http://lambda-the-ultimate.org/node/4554#comment-71504):

- exceptions;
- enumerations;
- generic types;
- direct use of OS APIs, without the need of writing wrappers;
- currently only static compilation is available;
- due to static compilation only model, there are issues with 3rd party 
code;
- no support for meta-programming;
- rich set of available libraries;
- the PR about go routines and channels, usually forgets to mention that 
similar features do exist as libraries for other languages


I know you can fake enumerations with typed consts, but it is not the 
same thing as real enumerations.

My point about direct OS APIs is that while D and Rust follow the 
approach used by other languages where you just declare bindings, Go 
forces the use of the CGO tool and a C compiler that speaks Go ABI.

Their talk about fast compilation is also quite effective with young 
developers that did not grew up with Modula-2 and Mac/Turbo Pascal or 
using other compiled languages with modules, so they think Go is the 
first compiled language to offer that.

Feel free to destroy. :)

--
Paulo
Mar 17 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2013 1:17 AM, Paulo Pinto wrote:

 On 17.03.2013 09:05, Russel Winder wrote:

 So what are the features that Go is ignoring that D has?


 - exceptions;
 - enumerations;
 - generic types;
 - direct use of OS APIs, without the need of writing wrappers;
 - currently only static compilation is available;
 - due to static compilation only model, there are issues with 3rd party code;
 - no support for meta-programming;
 - rich set of available libraries;
 - the PR about go routines and channels, usually forgets to mention that
similar
 features do exist as libraries for other languages


I'd like to add that D has:

- operator overloading
- user defined attributes
- dll's (coming soon)
- vector operations
- SIMD operations
- scope guard
- compile time function execution
- true immutability and purity
- inline assembler



 Their talk about fast compilation is also quite effective with young developers
 that did not grew up with Modula-2 and Mac/Turbo Pascal or using other compiled
 languages with modules, so they think Go is the first compiled language to
offer
 that.


Andrei did some tests a while back showing that D compiles considerably faster 
than Go. High compilation speed has been a major factor among companies who
have 
adopted D.
Mar 17 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote:
[=E2=80=A6]

 I'd like to add that D has:
=20
 - operator overloading
 - user defined attributes
 - dll's (coming soon)
 - vector operations
 - SIMD operations
 - scope guard
 - compile time function execution
 - true immutability and purity
 - inline assembler


[=E2=80=A6]

On the other hand "creeping featurism" can be a bad thing. Isn't the
mantra "small language, large (properly indexed) library"?=20

Immutability though I like. Single assignment rules.

Inline assembler is anathema.


 Andrei did some tests a while back showing that D compiles considerably f=


aster=20

 than Go. High compilation speed has been a major factor among companies w=


ho have=20

 adopted D.


Excellent.

Java / Scala is an interesting battle: Java is massively verbose, Scala
is not; Java takes a while to compile, Scala takes eons. Hence static
Groovy (as well as dynamic), and Kotlin. The jury is still out on
whether Ceylon has any relevance to the universe.

PS Can I have shared objects last week please ;-)

--=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
Mar 17 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
17-Mar-2013 14:06, Russel Winder пишет:

 On Sun, 2013-03-17 at 01:57 -0700, Walter Bright wrote:
 […]

 I'd like to add that D has:

 - operator overloading
 - user defined attributes
 - dll's (coming soon)
 - vector operations
 - SIMD operations
 - scope guard
 - compile time function execution
 - true immutability and purity
 - inline assembler


 […]

 On the other hand "creeping featurism" can be a bad thing. Isn't the
 mantra "small language, large (properly indexed) library"?


Built-in channels and goroutines don't count as feature creep ? ;)


 Immutability though I like. Single assignment rules.

 Inline assembler is anathema.


 Andrei did some tests a while back showing that D compiles considerably faster
 than Go. High compilation speed has been a major factor among companies who
have
 adopted D.


 Excellent.

 Java / Scala is an interesting battle: Java is massively verbose, Scala
 is not; Java takes a while to compile, Scala takes eons. Hence static
 Groovy (as well as dynamic), and Kotlin. The jury is still out on
 whether Ceylon has any relevance to the universe.

 PS Can I have shared objects last week please ;-)



-- 
Dmitry Olshansky
Mar 17 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2013 3:06 AM, Russel Winder wrote:

 On the other hand "creeping featurism" can be a bad thing. Isn't the
 mantra "small language, large (properly indexed) library"?


It can be a bad thing, no doubt about it. On the other hand:

When I was in London for the 2010 ACCU (when the volcano stranded me there), I 
took a chance to tour the Belfast cruiser sitting in the Thames. One
interesting 
aspect of it was the ship's machine shop.

It was full of carefully selected machine tools. It was pretty clear to me that 
an expert machinist could quickly and accurately make or repair about anything 
that broke on that ship.

Sure, you can make do with fewer, more general purpose machines. But it'll take 
you considerably longer, and the result won't be as good. For example, I've
used 
electric drills for years. I was never able to get it to drill a hole perfectly 
perpendicular. I finally got a drill press, and problem solved. Not only is it 
far more accurate, it's much faster when you've got a lot of holes to drill.

I prefer to view D as a fully equipped machine shop with the right tools for
the 
right job. Yes, it will take longer to master it than a simpler language. But 
we're professionals, we program all day. The investment of time to master it is 
trivial next to the career productivity improvement.

And as for the library, yes that is crucial. A large part of D's feature set is 
there to enable more powerful libraries, such as the language support for 
ranges, and the language support for library-defined garbage collection.
Mar 17 2013
next sibling parent "Peter Sommerfeld" <noreply rubrica.at> writes:
Walter Bright wrote:
[snip]

 I prefer to view D as a fully equipped machine shop with the right tools  
 for the right job. Yes, it will take longer to master it than a simpler  
 language. But we're professionals, we program all day.


Not everyone is. With its "scripting abilities" (fast compilation,
a rich std lib, nice syntax) D is attractive for people which has
used a scripting language + C/C++ before to get their job done and
are frustrated by the limitations of such a combo.


 The investment of  time to master it is trivial next to the career
 productivity improvement.


IMHO the problem here is documentation and integration of the various
aspects of the language. The learning curve is rather steep and takes
(much) more time than is really needed.

Of course, I agree with you on the bottom line to prefer a rich set
of tools over overly simplification.

Peter
Mar 17 2013
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 03/17/2013 03:44 PM, Walter Bright wrote:

 On 3/17/2013 3:06 AM, Russel Winder wrote:

 On the other hand "creeping featurism" can be a bad thing. Isn't the
 mantra "small language, large (properly indexed) library"?


 It can be a bad thing, no doubt about it. On the other hand:

 When I was in London for the 2010 ACCU (when the volcano stranded me
 there), I took a chance to tour the Belfast cruiser sitting in the
 Thames. One interesting aspect of it was the ship's machine shop.

 It was full of carefully selected machine tools. It was pretty clear to
 me that an expert machinist could quickly and accurately make or repair
 about anything that broke on that ship.

 Sure, you can make do with fewer, more general purpose machines. But
 it'll take you considerably longer, and the result won't be as good. For
 example, I've used electric drills for years. I was never able to get it
 to drill a hole perfectly perpendicular. I finally got a drill press,
 and problem solved. Not only is it far more accurate, it's much faster
 when you've got a lot of holes to drill.

 I prefer to view D as a fully equipped machine shop with the right tools
 for the right job. Yes, it will take longer to master it than a simpler
 language. But we're professionals, we program all day. The investment of
 time to master it is trivial next to the career productivity improvement.

 And as for the library, yes that is crucial. A large part of D's feature
 set is there to enable more powerful libraries, such as the language
 support for ranges, and the language support for library-defined garbage
 collection.


Soo...  You're saying D is like Vim?  =P
Mar 17 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, March 17, 2013 17:14:42 1100110 wrote:

 Soo...  You're saying D is like Vim?  =P


LOL. D's learning curve is nowhere near as steep as that. Almost nothing has a 
learning curve as steep as vim...

But on some level, the concept is the same. In order for something to be 
powerful enough to properly equip an experienced user, it usually ends up 
being more complicated for the newbie to learn. Making it super easy for the 
newbie to learn will just make it less useful for them in the long run, 
because the power just won't be there even when they're no longer a newbie. 
The trick is to make something which is powerful and flexible for the 
experienced user and yet not too daunting for the newbie. I don't know how 
well we've succeeded on that front, but I'm sure that more tutorials and 
better documentation and whatnot would help.

- Jonathan M Davis
Mar 17 2013
parent "Paul" <phshaffer gmail.com> writes:
 The trick is to make something which is powerful and flexible 
 for the
 experienced user and yet not too daunting for the newbie. I 
 don't know how
 well we've succeeded on that front, but I'm sure that more 
 tutorials and
 better documentation and whatnot would help.

 - Jonathan M Davis


Jonathan you've answered some many of me questions and I wanted 
to comment on this thought.  I am a very poor programmer who has 
only used languages as needed to get a job done and never 
becoming good at any of them.  I picked up D to start developing 
some text processing tools.  I started with other guys in our 
office building these tools in Python but then learned I could 
actually generate tiny .exe's and not have to have Python 
installed on systems that I needed my tools on.  The slices and 
associative arrays are awesome.  I've acquired the habit of using 
the time functions and printing out how long it takes the program 
to do its work.  245ms! 657ms! LOL.  D rocks!  It is extremely 
complex and 90% of it is over my head but making my own little 
.exe's that blast through things orders of magnitude faster than 
the scripting languages is fun.  Keep up the good work all!
Oct 04 2013
prev sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
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
Mar 17 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 18 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 18.03.2013 13:21, schrieb Andrei Alexandrescu:

 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.


 From the time I used Go.

You can use gdb or if you prefer something like a debugger IDE, LiteIDE

http://code.google.com/p/liteide/

For benchmarking there is an old blog entry about the tools.

http://blog.golang.org/2011/06/profiling-go-programs.html

Nothing that you cannot find in other languages, unless there is now 
something much better available.

--
Paulo
Mar 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2013 12:08 PM, Paulo Pinto wrote:

 Am 18.03.2013 13:21, schrieb Andrei Alexandrescu:

 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.


  From the time I used Go.

 You can use gdb or if you prefer something like a debugger IDE, LiteIDE

 http://code.google.com/p/liteide/

 For benchmarking there is an old blog entry about the tools.

 http://blog.golang.org/2011/06/profiling-go-programs.html

 Nothing that you cannot find in other languages, unless there is now something
 much better available.


dmd has the -profile, to automatically generate a profile report, and -cov, to 
tell you which lines were executed and how many times.
Mar 18 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 18 March 2013 at 19:39:38 UTC, Walter Bright wrote:

 On 3/18/2013 12:08 PM, Paulo Pinto wrote:

 Am 18.03.2013 13:21, schrieb Andrei Alexandrescu:

 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.


 From the time I used Go.

 You can use gdb or if you prefer something like a debugger 
 IDE, LiteIDE

 http://code.google.com/p/liteide/

 For benchmarking there is an old blog entry about the tools.

 http://blog.golang.org/2011/06/profiling-go-programs.html

 Nothing that you cannot find in other languages, unless there 
 is now something
 much better available.


 dmd has the -profile, to automatically generate a profile 
 report, and -cov, to tell you which lines were executed and how 
 many times.


That was my point.

I was initially attracted to Go given its similarity with Oberon 
concepts and was even enthusiastic to try to contribute something.

However the way some Go concepts are sold as being new, while 
other languages outside the C world have had them for years, and 
the resistance of Go community to anything new look elsewhere.

This answer from one of their developers is a good example,
http://9fans.net/archive/2008/08/134

--
Paulo
Mar 19 2013
prev sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
On Mon, Mar 18, 2013 at 2:21 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


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


Hi Andrei,

Apologies for not replying sooner.

Perhaps it is actually just the "feel" of the debugging and benchmarking,
and the general completeness of the *documentation*.
This set of slides: http://talks.golang.org/2012/simple.slide introduces
pretty much everything you need to know about Go. Graphs that show memory
allocation
by which function allocated, and the time taken of each function (d has a
way to get the data as Walter points out). Ah the profiling was only
mentioned in that slide set.
The profiling doc is here:
http://blog.golang.org/2011/06/profiling-go-programs.html
It is all super easy, and documented so that you can do it now. All in one
place. And I think possibly the most important thing about it is that it
does what it says.
The standard library all works together as a whole. Another thing which is
different and makes Go easier or faster to pick up is that there is often
only one way to
do something. D excels in allowing a multitude of ways to do things.

Do you know of any all encompassing slide set of document that one can pick
up the information contained in http://talks.golang.org/2012/simple.slide?
Is there an equivalent to
http://blog.golang.org/2011/06/profiling-go-programs.html?
Mar 25 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/13 8:02 AM, Rory McGuire wrote:

 Perhaps it is actually just the "feel" of the debugging and
 benchmarking, and the general completeness of the *documentation*.
 This set of slides: http://talks.golang.org/2012/simple.slide introduces
 pretty much everything you need to know about Go. Graphs that show
 memory allocation
 by which function allocated, and the time taken of each function (d has
 a way to get the data as Walter points out). Ah the profiling was only
 mentioned in that slide set.
 The profiling doc is here:
 http://blog.golang.org/2011/06/profiling-go-programs.html
 It is all super easy, and documented so that you can do it now. All in
 one place. And I think possibly the most important thing about it is
 that it does what it says.
 The standard library all works together as a whole. Another thing which
 is different and makes Go easier or faster to pick up is that there is
 often only one way to
 do something. D excels in allowing a multitude of ways to do things.

 Do you know of any all encompassing slide set of document that one can
 pick up the information contained in
 http://talks.golang.org/2012/simple.slide? Is there an equivalent to
 http://blog.golang.org/2011/06/profiling-go-programs.html?


Thanks, Rory, these are good reads. We should get some articles too, we 
definitely have most of the technical pieces in place!

Andrei
Mar 25 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/25/2013 5:02 AM, Rory McGuire wrote:

 The profiling doc is here:
http://blog.golang.org/2011/06/profiling-go-programs.html
 It is all super easy, and documented so that you can do it now.


What it says about profiling:

"To start tuning the Go program, we have to enable profiling. If the code used 
the Go testing package's benchmarking support, we could use gotest's standard 
-cpuprofile and -memprofile flags. In a standalone program like this one, we 
have to import runtime/pprof and add a few lines of code:"
[... bunch of code you have to copy/pasta in ...]
"After adding that code, we can run the program with the new -cpuprofile flag 
and then run gopprof to interpret the profile."


How to do profiling with the dmd D compiler:

1. Add the -profile switch to the command line.

2. Read the report generated.

To do coverage analysis:

1. Add the -cov switch to the command line.

2. Read the report generated.

That's it.
Mar 25 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/13 10:43 PM, Walter Bright wrote:

 On 3/25/2013 5:02 AM, Rory McGuire wrote:

 The profiling doc is here:
 http://blog.golang.org/2011/06/profiling-go-programs.html
 It is all super easy, and documented so that you can do it now.


 What it says about profiling:

 "To start tuning the Go program, we have to enable profiling. If the
 code used the Go testing package's benchmarking support, we could use
 gotest's standard -cpuprofile and -memprofile flags. In a standalone
 program like this one, we have to import runtime/pprof and add a few
 lines of code:"
 [... bunch of code you have to copy/pasta in ...]
 "After adding that code, we can run the program with the new -cpuprofile
 flag and then run gopprof to interpret the profile."


 How to do profiling with the dmd D compiler:

 1. Add the -profile switch to the command line.

 2. Read the report generated.

 To do coverage analysis:

 1. Add the -cov switch to the command line.

 2. Read the report generated.

 That's it.


We need an article on that.

Andrei
Mar 25 2013
parent reply "Alan" <geouke gmail.com> writes:
Whether it is Go or D, I wish one of you guys would fill the gap 
between the numeric work I need to do in fortran and the 
ui/string parsing/web work/plotting/animating I do in python.

While working in two languages is realistically not a huge deal, 
it would be nice if there was something that bridged the gap for 
all of us people out there writing stuff for science so that we 
could just learn one and be done with it.

the day a D program can begin with "import SciD; import Dplot;", 
and progress to "matrix.invert();" and "surf(matrix);", I will 
ditch both python and Go.

I am being incredibly self-serving and am half-kidding on this 
post since other people use D for all sorts of other things and 
they probably outnumber me. Still, I would love to see a compiled 
language implement numeric libraries that worked as fluidly as 
numpy and matplotlib work with python.

One reason I prefer D over Go is that the D community is so 
incredibly nice :)
Mar 25 2013
next sibling parent "Alan" <geouke gmail.com> writes:
edit: ditch both python and fortran.
Mar 25 2013
prev sibling parent reply "Geancarlo Rocha" <geancarlo.rocha gmail.com> writes:
That's julia's(http://julialang.org/) goal, but of course it's 
not nearly polished.

I'm interested in this as well, since I'm not totally comfortable 
about using a pirated MATLAB version and I hear that numpy can't 
match its performance on "macro" code.
Mar 25 2013
parent "Alan" <geouke gmail.com> writes:
On Tuesday, 26 March 2013 at 04:11:05 UTC, Geancarlo Rocha wrote:

 That's julia's(http://julialang.org/) goal, but of course it's 
 not nearly polished.

 I'm interested in this as well, since I'm not totally 
 comfortable about using a pirated MATLAB version and I hear 
 that numpy can't match its performance on "macro" code.


I have heard of Julia and have not really messed with it yet for 
the reason you mentioned (it being in its early stages).

I used MATLAB for a about a year before switching to numpy full 
time. I would totally recommend it. The performance loss (which I 
am not sure is actually there in all problems being solved) is 
really not that big of a deal unless you are doing some pretty 
heavy math, in which case MATLAB is slow compared to using C or 
fortran anyway. Another great thing is that numpy shares a lot of 
the same syntax as MATLAB, so the switch is fairly painless.

If it were just numeric stuff, fortran would work okay (albeit it 
is a chore). I have a small collection of libraries I have 
written so I can execute MATLAB-esque commands for creating 
vectors and doing basic plotting. For example, this works:

call linspace(0, pi, 100, x)
y = sin(x)
call plot2d(x,y)

It's not the cleanest looking thing, but its better than doing it 
from scratch every time :P

What if I wanted to plot a surface? Well, I need to write another 
fortran subroutine for that (which I have). The point is, it gets 
old having to write subroutines to do every little thing. 
Calculating an exponential integral requires me to link to the 
SLATEC library while MATLAB will do it with expint(x).

There are so many things that are commonly used in numeric 
programming and not standard in fortran (or any compiled 
language). Is there some rule that only scripting languages are 
allowed to do these sorts of things easily?

I would LOVE to see a compiled language that ran on par with C or 
fortran and had libraries that executed as cleanly as numpy and 
matplotlib do.
Mar 25 2013
prev sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright
<newshound2 digitalmars.com>wrote:


 How to do profiling with the dmd D compiler:

 1. Add the -profile switch to the command line.

 2. Read the report generated.

 To do coverage analysis:

 1. Add the -cov switch to the command line.

 2. Read the report generated.

 That's it.


Hi Walter,

Thanks I remember about the -profile switch but I don't see memory usage
there. If you see your program using more and more memory even though it
should not be
how do you check where the problem is?
In Go you generate a graph that shows the relationship between the various
function calls their memory use and cpu time. Its not a flashy graph I
think they use graphviz or something.

What would I use in D to profile heap usage? Would I be able to find the
problem area as quickly?
Mar 26 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Mar-2013 13:38, Rory McGuire пишет:

 On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:

     How to do profiling with the dmd D compiler:

     1. Add the -profile switch to the command line.

     2. Read the report generated.

     To do coverage analysis:

     1. Add the -cov switch to the command line.

     2. Read the report generated.

     That's it.


 Hi Walter,

 Thanks I remember about the -profile switch but I don't see memory usage
 there. If you see your program using more and more memory even though it
 should not be
 how do you check where the problem is?
 In Go you generate a graph that shows the relationship between the
 various function calls their memory use and cpu time. Its not a flashy
 graph I think they use graphviz or something.

 What would I use in D to profile heap usage? Would I be able to find the
 problem area as quickly?


What everybody in all other native languages use, for instance:
valgrind --tool=massif, valgrind --tool=callgrind

Any general purpose profiler works.  I can confirm that e.g. AMD 
CodeAnalyst works just fine if application is compiled with symbols. 
Intel's Vtune also should work as well as many opensource tools.

-- 
Dmitry Olshansky
Mar 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-26 10:49, Dmitry Olshansky wrote:


 What everybody in all other native languages use, for instance:
 valgrind --tool=massif, valgrind --tool=callgrind

 Any general purpose profiler works.  I can confirm that e.g. AMD
 CodeAnalyst works just fine if application is compiled with symbols.
 Intel's Vtune also should work as well as many opensource tools.


On Mac OS X there's Instruments. There's also dtrace.

-- 
/Jacob Carlborg
Mar 26 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2013 2:38 AM, Rory McGuire wrote:

 Thanks I remember about the -profile switch but I don't see memory usage there.


-profile and -cov do not track memory usage.


 If you see your program using more and more memory even though it should not be
 how do you check where the problem is?


I've written memory usage profilers before, but haven't done one for D. You're 
the first to ask for one.


 What would I use in D to profile heap usage? Would I be able to find the 


problem area as quickly?

What you can do is use -cov and see how often particular calls to new are done. 
This will give a pretty good clue as to where memory consumption is coming from.
Mar 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2013 3:04 AM, Walter Bright wrote:

 On 3/26/2013 2:38 AM, Rory McGuire wrote:

 Thanks I remember about the -profile switch but I don't see memory usage there.


 -profile and -cov do not track memory usage.


 If you see your program using more and more memory even though it should not be
 how do you check where the problem is?


 I've written memory usage profilers before, but haven't done one for D. You're
 the first to ask for one.


Now that I think about it, it wouldn't be that hard to add memory allocated per 
function when using -profile.

But my larger point is how simple it is to use -cov and -profile; it's hard to 
imagine it being any easier.
Mar 26 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 26 March 2013 at 10:08:30 UTC, Walter Bright wrote:

 On 3/26/2013 3:04 AM, Walter Bright wrote:

 On 3/26/2013 2:38 AM, Rory McGuire wrote:

 Thanks I remember about the -profile switch but I don't see 
 memory usage there.


 -profile and -cov do not track memory usage.


 If you see your program using more and more memory even 
 though it should not be
 how do you check where the problem is?


 I've written memory usage profilers before, but haven't done 
 one for D. You're
 the first to ask for one.


 Now that I think about it, it wouldn't be that hard to add 
 memory allocated per function when using -profile.

 But my larger point is how simple it is to use -cov and 
 -profile; it's hard to imagine it being any easier.


Something like this?

http://visualvm.java.net/features.html
Mar 26 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 17 March 2013 at 08:57:48 UTC, Walter Bright wrote:

 I'd like to add that D has:

 - operator overloading
 - user defined attributes
 - dll's (coming soon)


So it doesn't.


 - vector operations
 - SIMD operations
 - scope guard
 - compile time function execution
 - true immutability and purity


It isn't guaranteed by the current type system.


 - inline assembler



 Their talk about fast compilation is also quite effective with 
 young developers
 that did not grew up with Modula-2 and Mac/Turbo Pascal or 
 using other compiled
 languages with modules, so they think Go is the first compiled 
 language to offer
 that.


 Andrei did some tests a while back showing that D compiles 
 considerably faster than Go. High compilation speed has been a 
 major factor among companies who have adopted D.


If you use some of the mentioned above features, resources 
required to compile can explode dramatically.
Mar 17 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
[=E2=80=A6]

 The first known one is that Go is the only strong typed language to=20
 eschew generics in the 21st century.


On the other hand, perhaps generics is not a good thing, yet has created
an unchallenged mindset? NB I am tainted by C++ templates and generics

has
much less of a problem here, and Scala hacks it's way around it. Also I
use Python a lot which has only one variable type, reference to object.
Heterogeneity is not your enemy.

I like the experiment of objects as values with methods added as needed,
very Pythonic. Go even makes this static compile time type checked;
though I think they miss the underlying irony of this.

Far too many "object oriented" languages have forgotten that the
computational model is one of sending messages to objects asking them to
undertake a behaviour.  Statically typed languages constrain objects not
to be able to evolve their behaviours.


 For the rest, copying from my discussion on Lambda the Ultimate about=20
 C++ developers not jumping into Go=20
 (http://lambda-the-ultimate.org/node/4554#comment-71504):
=20
 - exceptions;
 - enumerations;
 - generic types;
 - direct use of OS APIs, without the need of writing wrappers;
 - currently only static compilation is available;
 - due to static compilation only model, there are issues with 3rd party=


=20

 code;
 - no support for meta-programming;
 - rich set of available libraries;
 - the PR about go routines and channels, usually forgets to mention that=


=20

 similar features do exist as libraries for other languages


Go is a stripped down C with stronger type checking. memory management
and CSP. This actually makes it an important language in the scheme of
things, even if I agree with you that in so many way it is a regression
into the 1960s.

The major problem for all statically compiled languages is the reliance
on hardware integers.


 I know you can fake enumerations with typed consts, but it is not the=20
 same thing as real enumerations.


On the other hand C and C++ enumerations are just syntactic sugar for
the same thing so not real difference. In fact exactly the opposite,
they are a delusion. Conversely Java enumerations are a bit heavyweight.


 My point about direct OS APIs is that while D and Rust follow the=20
 approach used by other languages where you just declare bindings, Go=20
 forces the use of the CGO tool and a C compiler that speaks Go ABI.


I guess this is because of the segmented stacks architecture behind the
realization of Go.


 Their talk about fast compilation is also quite effective with young=20
 developers that did not grew up with Modula-2 and Mac/Turbo Pascal or=20
 using other compiled languages with modules, so they think Go is the=20
 first compiled language to offer that.
=20
 Feel free to destroy. :)


Far from it. I think Go is a significant improvement over C, but that in
2013 applications programmers should be using something better. I
continue to be surprised by Python people moving to Go. The only
"positive" for Go is goroutines. Python's GIL's days are numbered at
which point even that issue goes away.

The issue is then how to make D appealing to Python programmers. People
need to convince me why I should stop training people to use Python.
This will be hard given that C/C++/Python is now the standard model for
computational systems.

--=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
Mar 17 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On 17.03.2013 11:01, Russel Winder wrote:

 On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
 […]

 The first known one is that Go is the only strong typed language to
 eschew generics in the 21st century.


 On the other hand, perhaps generics is not a good thing, yet has created
 an unchallenged mindset? NB I am tainted by C++ templates and generics

 much less of a problem here, and Scala hacks it's way around it. Also I
 use Python a lot which has only one variable type, reference to object.
 Heterogeneity is not your enemy.

 I like the experiment of objects as values with methods added as needed,
 very Pythonic. Go even makes this static compile time type checked;
 though I think they miss the underlying irony of this.


I think for static strong type languages you need some kind of 
genericity support like generics, parametric types or similar.

There are many other ways to implement them. Eiffel, Modula-3, Ada
and many other strong type languages also offer generics.

Interfaces are halfway there, because if you are not allowed to use 
operators as functions, then there is always the need to write 
boilerplate code, even for basic types.

Dynamic type languages don't require this of course, given the way their
type systems work.


 Far too many "object oriented" languages have forgotten that the
 computational model is one of sending messages to objects asking them to
 undertake a behaviour.  Statically typed languages constrain objects not
 to be able to evolve their behaviours.


I might be brain damaged here, because I used OO in Object Pascal, C++, 


So I don't see the mainstream enterprise OO way of doing things as the 
only way of how OO is supposed to be.

Sadly most developers in the enterprise world lack this kind of 
understanding and write the type of code that gives bad name to OO.


 For the rest, copying from my discussion on Lambda the Ultimate about
 C++ developers not jumping into Go
 (http://lambda-the-ultimate.org/node/4554#comment-71504):

 - exceptions;
 - enumerations;
 - generic types;
 - direct use of OS APIs, without the need of writing wrappers;
 - currently only static compilation is available;
 - due to static compilation only model, there are issues with 3rd party
 code;
 - no support for meta-programming;
 - rich set of available libraries;
 - the PR about go routines and channels, usually forgets to mention that
 similar features do exist as libraries for other languages


 Go is a stripped down C with stronger type checking. memory management
 and CSP. This actually makes it an important language in the scheme of
 things, even if I agree with you that in so many way it is a regression
 into the 1960s.


Here they follow Niklaus Wirth, which I admire, school of though.

When he went out to create Oberon, he decided to remove all language 
features he did not consider essential in a programming language.

Actually all the successors, Oberon-2, Component Pascal and Active 
Oberon were created by his students or collaborators. In 2011 the last 
Oberon language report, Oberon-07, removes even a few more features.

On his talk at HOPL-3 he recognizes that the industry did not follow his 
appreciation for smaller languages.

http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf

Go seems to be heading this way, as Rob Pike already wrote a blog entry 
about the same issue, where he mentions that Go only attracts Ruby and 
Python guys, but not the C++ one he expected to attract.

Although I am a big fan of the Oberon operating systems and languages, I 
think we are no longer in the late 90's, and given the mainstream 
acceptance of many features that used to be only academic, why throw 
them away?

Go's workarounds for lack of generics remind me of the time C++ still 
lacked generics and there were a few pre-processor tools to generate
generic code. Borland used to ship one in their compilers.

I don't miss those days.


 The major problem for all statically compiled languages is the reliance
 on hardware integers.


 I know you can fake enumerations with typed consts, but it is not the
 same thing as real enumerations.


 On the other hand C and C++ enumerations are just syntactic sugar for
 the same thing so not real difference. In fact exactly the opposite,
 they are a delusion. Conversely Java enumerations are a bit heavyweight.


I prefer the enumerations the Pascal away, similar to what Java and .NET 
offer with primitives for generic manipulation of values.


 My point about direct OS APIs is that while D and Rust follow the
 approach used by other languages where you just declare bindings, Go
 forces the use of the CGO tool and a C compiler that speaks Go ABI.


 I guess this is because of the segmented stacks architecture behind the
 realization of Go.


 Their talk about fast compilation is also quite effective with young
 developers that did not grew up with Modula-2 and Mac/Turbo Pascal or
 using other compiled languages with modules, so they think Go is the
 first compiled language to offer that.

 Feel free to destroy. :)


 Far from it. I think Go is a significant improvement over C, but that in
 2013 applications programmers should be using something better. I
 continue to be surprised by Python people moving to Go. The only
 "positive" for Go is goroutines. Python's GIL's days are numbered at
 which point even that issue goes away.


Me too.


 The issue is then how to make D appealing to Python programmers. People
 need to convince me why I should stop training people to use Python.
 This will be hard given that C/C++/Python is now the standard model for
 computational systems.


Actually I think the day PyPy becomes the main Python implementation 
there is hardly the need for Python developers to write C or C++ code.

--
Paulo
Mar 17 2013
parent reply 1100110 <0b1100110 gmail.com> writes:
On 03/17/2013 07:09 AM, Paulo Pinto wrote:

 On 17.03.2013 11:01, Russel Winder wrote:

 On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
 […]

 The first known one is that Go is the only strong typed language to
 eschew generics in the 21st century.


 On the other hand, perhaps generics is not a good thing, yet has created
 an unchallenged mindset? NB I am tainted by C++ templates and generics

 much less of a problem here, and Scala hacks it's way around it. Also I
 use Python a lot which has only one variable type, reference to object.
 Heterogeneity is not your enemy.

 I like the experiment of objects as values with methods added as needed,
 very Pythonic. Go even makes this static compile time type checked;
 though I think they miss the underlying irony of this.


 I think for static strong type languages you need some kind of
 genericity support like generics, parametric types or similar.

 There are many other ways to implement them. Eiffel, Modula-3, Ada
 and many other strong type languages also offer generics.

 Interfaces are halfway there, because if you are not allowed to use
 operators as functions, then there is always the need to write
 boilerplate code, even for basic types.

 Dynamic type languages don't require this of course, given the way their
 type systems work.


 Far too many "object oriented" languages have forgotten that the
 computational model is one of sending messages to objects asking them to
 undertake a behaviour. Statically typed languages constrain objects not
 to be able to evolve their behaviours.


 I might be brain damaged here, because I used OO in Object Pascal, C++,


 So I don't see the mainstream enterprise OO way of doing things as the
 only way of how OO is supposed to be.

 Sadly most developers in the enterprise world lack this kind of
 understanding and write the type of code that gives bad name to OO.


 For the rest, copying from my discussion on Lambda the Ultimate about
 C++ developers not jumping into Go
 (http://lambda-the-ultimate.org/node/4554#comment-71504):

 - exceptions;
 - enumerations;
 - generic types;
 - direct use of OS APIs, without the need of writing wrappers;
 - currently only static compilation is available;
 - due to static compilation only model, there are issues with 3rd party
 code;
 - no support for meta-programming;
 - rich set of available libraries;
 - the PR about go routines and channels, usually forgets to mention that
 similar features do exist as libraries for other languages


 Go is a stripped down C with stronger type checking. memory management
 and CSP. This actually makes it an important language in the scheme of
 things, even if I agree with you that in so many way it is a regression
 into the 1960s.


 Here they follow Niklaus Wirth, which I admire, school of though.

 When he went out to create Oberon, he decided to remove all language
 features he did not consider essential in a programming language.

 Actually all the successors, Oberon-2, Component Pascal and Active
 Oberon were created by his students or collaborators. In 2011 the last
 Oberon language report, Oberon-07, removes even a few more features.

 On his talk at HOPL-3 he recognizes that the industry did not follow his
 appreciation for smaller languages.

 http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf

 Go seems to be heading this way, as Rob Pike already wrote a blog entry
 about the same issue, where he mentions that Go only attracts Ruby and
 Python guys, but not the C++ one he expected to attract.

 Although I am a big fan of the Oberon operating systems and languages, I
 think we are no longer in the late 90's, and given the mainstream
 acceptance of many features that used to be only academic, why throw
 them away?

 Go's workarounds for lack of generics remind me of the time C++ still
 lacked generics and there were a few pre-processor tools to generate
 generic code. Borland used to ship one in their compilers.

 I don't miss those days.


 The major problem for all statically compiled languages is the reliance
 on hardware integers.


 I know you can fake enumerations with typed consts, but it is not the
 same thing as real enumerations.


 On the other hand C and C++ enumerations are just syntactic sugar for
 the same thing so not real difference. In fact exactly the opposite,
 they are a delusion. Conversely Java enumerations are a bit heavyweight.


 I prefer the enumerations the Pascal away, similar to what Java and .NET
 offer with primitives for generic manipulation of values.


 My point about direct OS APIs is that while D and Rust follow the
 approach used by other languages where you just declare bindings, Go
 forces the use of the CGO tool and a C compiler that speaks Go ABI.


 I guess this is because of the segmented stacks architecture behind the
 realization of Go.


 Their talk about fast compilation is also quite effective with young
 developers that did not grew up with Modula-2 and Mac/Turbo Pascal or
 using other compiled languages with modules, so they think Go is the
 first compiled language to offer that.

 Feel free to destroy. :)


 Far from it. I think Go is a significant improvement over C, but that in
 2013 applications programmers should be using something better. I
 continue to be surprised by Python people moving to Go. The only
 "positive" for Go is goroutines. Python's GIL's days are numbered at
 which point even that issue goes away.


 Me too.


 The issue is then how to make D appealing to Python programmers. People
 need to convince me why I should stop training people to use Python.
 This will be hard given that C/C++/Python is now the standard model for
 computational systems.


 Actually I think the day PyPy becomes the main Python implementation
 there is hardly the need for Python developers to write C or C++ code.

 --
 Paulo


The day I can compile pypy without needing 8Gb of memory is the day I'll 
consider it.
Mar 17 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 17.03.2013 20:28, schrieb 1100110:

 On 03/17/2013 07:09 AM, Paulo Pinto wrote:

 On 17.03.2013 11:01, Russel Winder wrote:

 On Sun, 2013-03-17 at 09:17 +0100, Paulo Pinto wrote:
 […]

 The first known one is that Go is the only strong typed language to
 eschew generics in the 21st century.


 On the other hand, perhaps generics is not a good thing, yet has created
 an unchallenged mindset? NB I am tainted by C++ templates and generics

 much less of a problem here, and Scala hacks it's way around it. Also I
 use Python a lot which has only one variable type, reference to object.
 Heterogeneity is not your enemy.

 I like the experiment of objects as values with methods added as needed,
 very Pythonic. Go even makes this static compile time type checked;
 though I think they miss the underlying irony of this.


 I think for static strong type languages you need some kind of
 genericity support like generics, parametric types or similar.

 There are many other ways to implement them. Eiffel, Modula-3, Ada
 and many other strong type languages also offer generics.

 Interfaces are halfway there, because if you are not allowed to use
 operators as functions, then there is always the need to write
 boilerplate code, even for basic types.

 Dynamic type languages don't require this of course, given the way their
 type systems work.


 Far too many "object oriented" languages have forgotten that the
 computational model is one of sending messages to objects asking them to
 undertake a behaviour. Statically typed languages constrain objects not
 to be able to evolve their behaviours.


 I might be brain damaged here, because I used OO in Object Pascal, C++,

 languages.

 So I don't see the mainstream enterprise OO way of doing things as the
 only way of how OO is supposed to be.

 Sadly most developers in the enterprise world lack this kind of
 understanding and write the type of code that gives bad name to OO.


 For the rest, copying from my discussion on Lambda the Ultimate about
 C++ developers not jumping into Go
 (http://lambda-the-ultimate.org/node/4554#comment-71504):

 - exceptions;
 - enumerations;
 - generic types;
 - direct use of OS APIs, without the need of writing wrappers;
 - currently only static compilation is available;
 - due to static compilation only model, there are issues with 3rd party
 code;
 - no support for meta-programming;
 - rich set of available libraries;
 - the PR about go routines and channels, usually forgets to mention
 that
 similar features do exist as libraries for other languages


 Go is a stripped down C with stronger type checking. memory management
 and CSP. This actually makes it an important language in the scheme of
 things, even if I agree with you that in so many way it is a regression
 into the 1960s.


 Here they follow Niklaus Wirth, which I admire, school of though.

 When he went out to create Oberon, he decided to remove all language
 features he did not consider essential in a programming language.

 Actually all the successors, Oberon-2, Component Pascal and Active
 Oberon were created by his students or collaborators. In 2011 the last
 Oberon language report, Oberon-07, removes even a few more features.

 On his talk at HOPL-3 he recognizes that the industry did not follow his
 appreciation for smaller languages.

 http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf

 Go seems to be heading this way, as Rob Pike already wrote a blog entry
 about the same issue, where he mentions that Go only attracts Ruby and
 Python guys, but not the C++ one he expected to attract.

 Although I am a big fan of the Oberon operating systems and languages, I
 think we are no longer in the late 90's, and given the mainstream
 acceptance of many features that used to be only academic, why throw
 them away?

 Go's workarounds for lack of generics remind me of the time C++ still
 lacked generics and there were a few pre-processor tools to generate
 generic code. Borland used to ship one in their compilers.

 I don't miss those days.


 The major problem for all statically compiled languages is the reliance
 on hardware integers.


 I know you can fake enumerations with typed consts, but it is not the
 same thing as real enumerations.


 On the other hand C and C++ enumerations are just syntactic sugar for
 the same thing so not real difference. In fact exactly the opposite,
 they are a delusion. Conversely Java enumerations are a bit heavyweight.


 I prefer the enumerations the Pascal away, similar to what Java and .NET
 offer with primitives for generic manipulation of values.


 My point about direct OS APIs is that while D and Rust follow the
 approach used by other languages where you just declare bindings, Go
 forces the use of the CGO tool and a C compiler that speaks Go ABI.


 I guess this is because of the segmented stacks architecture behind the
 realization of Go.


 Their talk about fast compilation is also quite effective with young
 developers that did not grew up with Modula-2 and Mac/Turbo Pascal or
 using other compiled languages with modules, so they think Go is the
 first compiled language to offer that.

 Feel free to destroy. :)


 Far from it. I think Go is a significant improvement over C, but that in
 2013 applications programmers should be using something better. I
 continue to be surprised by Python people moving to Go. The only
 "positive" for Go is goroutines. Python's GIL's days are numbered at
 which point even that issue goes away.


 Me too.


 The issue is then how to make D appealing to Python programmers. People
 need to convince me why I should stop training people to use Python.
 This will be hard given that C/C++/Python is now the standard model for
 computational systems.


 Actually I think the day PyPy becomes the main Python implementation
 there is hardly the need for Python developers to write C or C++ code.

 --
 Paulo


 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.

--
Paulo
Mar 17 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2013-03-17 at 22:13 +0100, Paulo Pinto wrote:

 Am 17.03.2013 20:28, schrieb 1100110:


[=E2=80=A6]

 The day I can compile pypy without needing 8Gb of memory is the day I'l=




l

 consider it.


=20
 Uau, that much?!
=20
 I tend to use Python only for shell scripting type of tasks, so I wasn't=


=20

 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.

--=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
Mar 18 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Mar 18 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 17 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 17.03.2013 21:56, schrieb Walter Bright:

 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.


If I am not mistaken, Rust makes use of them as well.
Mar 17 2013
parent "ponce" <contact gam3sfrommars.fr> writes:
On Sunday, 17 March 2013 at 21:13:48 UTC, Paulo Pinto wrote:

 If I am not mistaken, Rust makes use of them as well.


Rust doesn't anymore:
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html

The announcement also mentions performance problems related to Go 
segmented stacks: 
https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub
Nov 05 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
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.


=20
 Segmented stacks have a significant performance cost to them, as well as =


making=20

 it hard to interface to other languages. I also think that the shift to 6=


4 bits=20

 makes them obsolete anyway.


I think this is possibly not the case or Go and Rust would not have gone
this route =E2=80=93 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.

--=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
Mar 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 18 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Mar 18 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2013 3:25 AM, bearophile wrote:

 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.


If you know a reason, please post one.
Mar 18 2013
parent "jokster" <josterk do.not.reply> writes:
On Monday, 18 March 2013 at 19:05:09 UTC, Walter Bright wrote:

 On 3/18/2013 3:25 AM, bearophile wrote:

 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.


 If you know a reason, please post one.


I believe the Rust developers are also targeting embedded systems 
that may not have 64-bit virtual address spaces.  Hence the 
spaghetti stacks.
Aug 31 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
18-Mar-2013 14:25, bearophile пишет:

 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.


Walter's position is crystal clear.

IMHO virtual memory was designed among other things to avoid piecing 
together segmented memory blocks by hand. Memory manager (OS) will od 
the whole dirty work for you and even hardware assists the process 
resulting in decent speed and complete transparency of operation. Why 
destroy this marvelous creation of hardware and OS developers?

The whole segmented stack thing smells a lot like good ol' 16-bit days 
and is a step backwards unless you assume that:

a) There is no virtual memory i.e. no MMU. Well, some MCU units are 
still like this but the trend goes towards having MMU even on tiny chips.

b) Virtual ram / physical ram relation is close to 1 or even worse, like 
in 32-bit OS running on 8G desktops. As for virtual memory to be truly 
exploitable address space better be many times the total ram, the more 
the better.

Both cases do not seem likely to be related to the future technology 
like at all.


 Bye,
 bearophile



-- 
Dmitry Olshansky
Mar 18 2013
prev sibling next sibling parent "master" <djj shumtn.com> writes:
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
Mar 17 2013
prev sibling next sibling parent "Don" <turnyourkidsintocash nospam.com> writes:
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.
Mar 18 2013
prev sibling next sibling parent "Tommy McGuire" <mcguire crsr.net> writes:
On Saturday, 16 March 2013 at 14:42:58 UTC, Suliman wrote:

 http://versusit.org/rust-vs-d


I just saw this post on the Rust subreddit: 
http://www.reddit.com/r/rust/comments/1agj5i/rust_vs_dlang_d_programming_
anguage_discussion/ 
(that is, oddly, linking to this discussion and not the original 
post), and was very confused by the "Rust" code. Quoting kibwen 
on Reddit, "Not only are the Rust snippets using ancient 0.0 
syntax, they are written such that they would never compile in 
the first place."

The io module isn't in std, integers don't have a .times method 
(that I know about, anyway), "alt" is now "match" (I think), and 
there is no "try".
Mar 18 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
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


I don't know if you still follow this, but there's a typo here:

Now, let’s see, how the code, outputting the word "Hello" 10 
times, will look. In Rust it will look like this:

     fn main() {
         for 100.times {
         ...

Should be:

         ...
         for 10.times {
         ...

Also, the formatting still sucks and imports are missing for the 
D code, whereas imports are verbosely stated in Rust. FWIW, 
"std::io::println" can be stated as just "println", since it's 
available by default. Don't know if this was the case when you 
wrote the post though...

Also, you don't mention the difference between D and Rust in 
switch statements (FWIW, Rust doesn't have switch statements, 
they're now "match" statements, which are closer to haskell's 
case statements than D's switch, because D's switch has optional 
fallthrough (goto case;) and Rust has no fallthrough.

Also, I second the objection to your exception example. D does 
have exceptions and there are some very important differences 
between them and Rust's exception handling (which is more like 
Go's recover() than D's catch).
Aug 17 2013
prev sibling parent "Paul Jurczak" <pauljurczak yahoo.com> writes:
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


There is more online activity in Rust vs. D corner. See 
http://relistan.com/a-week-with-mozilla-rust/, which is about 
Rust, but commentators inevitably end up making comparisons with 
D. More discussion on reddit: 
http://www.reddit.com/r/programming/comments/1kub90/a_week_with_mozillas_rust/.
Aug 23 2013