It seems D comes up often in Rust threads :-)

http://www.reddit.com/r/programming/comments/11j38z/mozilla_and_the_rust_team_announce_version_04_of/

I still think D and Rust should join forces to design a single GC usable for both languages :-) Their GC needs are not _that_ different.


A question in that thread:
> My question is, what are the advantages of Rust over D? How do you think they compare?

An answer by ssylvan:

>For me, the memory management of Rust (the three pointer types, per-task GC), as well as the additional safety (in particular, D still has nulls all over the place - IME the by far most common remaining "real world" crash seen in so called "memory safe" languages - it's unfortunate because we know that they can be statically eliminated). Also, not a fan of the class/struct distinction in D, I think it encourages heap allocations, whereas Rust drastically prefers big chunky objects that mostly stay on the stack or inside another object with only the extremely rare allocation, and even then most of those can be unique (no GC/RC).<

Bye,
bearophile

Am Tue, 16 Oct 2012 04:48:07 +0200
schrieb "bearophile" <bearophileHUGS@lycos.com>:

> It seems D comes up often in Rust threads :-)

And you are here to remedy that situation?
No offense, I started to keep an eye on Rust myself. I'm
pretty sure it will eventually have to cater to the people who
use it and tack some features on, like D2 that make it look
less carefully designed. New features lead to language WATs.

Also thanks for the strawman citation about not-null types. ;) Since I don't write compilers I don't worry about their complexity, and I think they are supposed to be a language feature. Library solutions are clumsy to use and lack the static flow analysis that is possible inside a compiler.

This three pointer types stuff also sounds effective to keep the GC heap slim. I can't tell without personal experience though, if all they implemented is an advantage in practice. I agree with them, that it would be nice if D classes could naturally be placed on the stack. Again I think it's a language feature, just as 'ref' parameters are. Otherwise, as long as I don't need polymorphism, I never missed anything from structs, so I get along fine most of the time.

-- 
Marco

Well, it's true non-null types can be statically checked. But if you try to code without nulls, what is the chance to run into null pointer?

Kagamin:

> Well, it's true non-null types can be statically checked. But if you try to code without nulls, what is the chance to run into null pointer?

I presume then the probability becomes lower (but I don't have statistics to support this opinion.)

Bye,
bearophile

On Tue, Oct 16, 2012 at 3:35 AM, Kagamin <spam@here.lot> wrote:

> Well, it's true non-null types can be statically checked. But if you try to code without nulls, what is the chance to run into null pointer?
>

You mean by calling external (potentially unsafe) code that contains null
pointers?

--
Ziad

Ziad Hatahet:

> You mean by calling external (potentially unsafe) code that contains null pointers?

This is *not* a significant problem for a language with a well designed non-null system. See how ATS language removes similar problems.

Bye,
bearophile

Marco Leise:

> I agree with them, that it would be nice if D classes could
> naturally be placed on the stack.

Allocating D class instances in-place (on the stack or inside other structs/class instances) is not hard, but in practice I never do it (Like I never use Rebindable or Typedef. I sometimes use Nullable or AssumeUnique). But to make it safe enough you probably need a smarter type system, that they have mostly finished designing in Rust.

Avoiding most heap allocations is positive because it reduces the amount of garbage, reduces pressure on the GC, gives good performance even if you use a not too much refined GC, avoids GC precision troubles, helps use less levels of indirection, and generally helps keep the code faster.

Another thing Rust team is doing is (I think) having the reference compiler based on LLVM. This means saving time to develop only the front-end and designing the language. Scala development was quick because the "back-end" and the GC was already done (but of course it introduced some limitations. Now they are porting Scala to the LLVM, removing most or all of the limitations, but they keep all layers of the compiler but the last one, so they have to translate stack-based code to the infinite-number-of-registers-based IR of LLVM, and I think this is sub-optimal, but they will have time to fix this problem later removing one more stage in the middle).

Bye,
bearophile

On Tue, Oct 16, 2012 at 1:16 PM, bearophile <bearophileHUGS@lycos.com>wrote:

> Now they are porting Scala to the LLVM, ...
>
>
>
This Scala to LLVM port ( http://greedy.github.com/scala-llvm/ )? It seems to not have been updated in a while though.


--
Ziad

I can't compile even hello world on both Win 7 and Win XP.

rust 0.4, latest mingw.

 I guess D doesn't support unique_ptr like behavior, humm.. I like this in C++, is it possible in D?