On 4 January 2014 03:31, logicchains <jonathan.t.barnard@gmail.com> wrote:
> On Saturday, 4 January 2014 at 03:16:37 UTC, Jesse Phillips wrote:
>>
>> Basically D provides safety, but it also provides means to do unsafe things. I'm not familiar with Rust, but I wouldn't be surprised if unsafe actions could also be taken.
>
>
> You can still take unsafe actions, they just need to be wrapped in an 'unsafe' block. Any code that calls this block also needs to be marked as 'unsafe'. I recently wrote the exact same program in both D and Rust, and if you compare the two you'll find that almost the entire Rust program is enclosed in 'unsafe' blocks (note the Rust code is for a release from a couple of months ago, so the syntax is outdated).


Rust syntax changes every couple of months?!?!?

On Saturday, 4 January 2014 at 08:10:18 UTC, Walter Bright wrote:
> On 1/3/2014 11:42 PM, ilya-stromberg wrote:
>> So, in a few cases null pointers are a safety issue.
>
> I believe this is a misunderstanding of what safety is. It means memory safety - i.e. no memory corruption. It does not mean "no bugs".

OK, but this feature can be also useful. For example:

class Foo
{
	int i;
}

void main(string[] args)
{
	Foo f;

	//Oops!
	writeln(f.i);
}

It's definetly bug, but compiler hasn't got any mistakes. I know that I'll have seg fault at runtime, but see an error at compile time will be much better. Have you got any plans to impove this situation?

On Saturday, 4 January 2014 at 12:31:06 UTC, Iain Buclaw wrote:
> Rust syntax changes every couple of months?!?!?

It looks like yes: "The following code examples are valid as of
Rust 0.8. Syntax and semantics may change in subsequent versions."

http://en.wikipedia.org/wiki/Rust_%28programming_language%29

> The biggest disadvantage of D compared to Rust is that it does not have the kind of safety perspective that Rust does, and in particular does not provide safe constructs for concurrency.

Pretty sure immutable, purity, and thread-local statics are all safe constructs for concurrency; not to mention all the library features.

Rust probably is safer by some metric, but all those pointer types add considerable complexity.


> The other argument against using D is that it has been around more than 10 years now, without much adoption and appears to be more likely on its way out rather than increasing popularity.

This is just false. Any metric you look at suggests D use is on the increase, and certainly starting to get more commercial interest.

It's worth noting that many languages take a long time before they blossom. It took Ruby 10 years before Rails appeared.

On 04.01.2014 03:39, Adam D. Ruppe wrote:
> On Saturday, 4 January 2014 at 02:09:51 UTC, NoUseForAName wrote:
>> .. includes a pretty damning assessment of D as "unsafe" (compared to
>> Rust) and generally doomed.
>
> I'd say the author is simply wrong about the doomed thing, the link he
> cites doesn't make a convincing case, and is many years old anyway.
>
> As for the safety thing, I partially agree. The concepts Rust has are
> potentially very useful when working without the garbage collector. If
> you can use the gc, it obviates much of it (the owner of all items is
> the gc and they have an infinite lifetime, so tracking those things is
> trivial), but writing a kernel is one place where you probably don't
> want to use it, so that makes sense.
>
> It is possible to use the Rust concepts in D, but you don't get as much
> help from the compiler. Still better than C, but the rust system is nice
> in this respect.
>
> but i hate the rust syntax lol

I love it except for the pointer sigils, but then again I use ML languages (Caml Light, OCaml, Haskell, F#), on and off, since 1996.

--
Paulo

On 04.01.2014 13:09, QAston wrote:
> On Saturday, 4 January 2014 at 11:36:20 UTC, bearophile wrote:
>> NoUseForAName:
>>
>>> http://rust-class.org/pages/using-rust-for-an-undergraduate-os-course.html
>>>
>>
>> Why aren't they using Ada? It has a really refined and safe
>> parallelism, it's quite safe, it teaches a student the correct ways of
>> dealing with pointers, memory etc in a low-level setting. It's usable
>> for hard-realtime. And it's way more commonly used than Rust. There
>> are books on Ada. Its compilers are solid, and while Ada is being
>> updated significantly (the latest is Ada2012) there's no risk in
>> having important parts of the language become backward incompatible in
>> the short term. Ada code is not sexy, but this is not a significant
>> problem for an advanced course lasting few months. Ada is a complex
>> language, but it's the right kind of complexity, it's not special
>> cases piled on special cases, it's features piled on features to deal
>> correctly with different needs (just like in D, despite D is less
>> designed for correctness compared to Ada).
>>
>> Bye,
>> bearophile
>
> Ada is not hype enough, so it doesn't qualify. J/K (no death-threats
> please), I gave rust a try, i couldn't get it to run on my OS.


I agree with you here.

Ada seems to be growing in Europe, at least from what I can tell every time I attend FOSDEM.

I would say we have to thank C's lack of safety and the availability of GNAT for it.

But the language uses Algol based syntax and is verbose for C developers, which makes it not hype enough as you say.

--
Paulo

On 04.01.2014 03:09, NoUseForAName wrote:
> This piece (recently seen on the Hacker News front page):
>
> http://rust-class.org/pages/using-rust-for-an-undergraduate-os-course.html
>
> .. includes a pretty damning assessment of D as "unsafe" (compared to
> Rust) and generally doomed. I remember hearing Walter Bright talking a
> lot about "safe code" during a D presentation. Was that about a
> different kind of safety? Is the author just wrong? Basically I want to
> hear the counterargument (if there is one).

He gets his assumptions about D wrong, but I find it nice that he decided to show his students there are other safer languages to write operating systems on.

If UNIX did not widespread outside academia, most likely C would not have reached the status it achieved.

--
Paulo

On 01/04/2014 06:16 AM, Walter Bright wrote:
> On 1/3/2014 8:36 PM, Timon Gehr wrote:
>> On 01/04/2014 05:31 AM, Walter Bright wrote:
>>> ...
>>>
>>> Null pointers are not a safety issue.
>>
>> In the general sense of the word, yes they are.
>
> Please explain.
>

Safety is some kind of guarantee that something bad never happens.

Eg. memory safety guarantees that memory never gets corrupted and null safety guarantees that null pointers never get dereferenced. Any property that can be stated in this way is a safety property.

Hence it is fine to claim that the lack of dereferenceable null pointers makes a language safer, even though it has no bearing on memory safety.

On Saturday, 4 January 2014 at 12:37:34 UTC, ilya-stromberg wrote:
> Have you got any plans to impove this situation?

I wrote a NotNull struct for phobos that could catch that situation. I don't think it got pulled though.

http://arsdnet.net/dcode/notnull.d

With @disable is becomes reasonably possible to restrict built in types with wrapper structs. It isn't perfect but it isn't awful either.

The big thing people have asked for before is

Object foo;
if(auto obj = checkNull(foo)) {
   obj == NotNull!Object
} else {
  // foo is null
}

and i haven't figured that out yet...

On Saturday, 4 January 2014 at 04:31:16 UTC, Walter Bright wrote:
> Null pointers are not a safety issue. Safety means no memory corruption.

That's all well and good until you corrupt the interrupt vector table through a null pointer. We are talking about kernels after all.

(though i think this is different in 32 and 64 bit, but as you'll probably remember, the interrupt table in 16 bit DOS was located at address 0.)