View mode: basic / threaded / horizontal-split · Log in · Help
January 04, 2014
D - Unsafe and doomed
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).
January 04, 2014
Re: D - Unsafe and doomed
On Saturday, 4 January 2014 at 02:09:51 UTC, 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).

Disclaimer: I only have a cursory understanding of the subject.

With Rust, there are no dangling or null pointers. This means 
that if a pointer exists, it points to a valid object of the 
appropriate type. When a pointer does not point to a valid object 
of the appropriate type, accessing the content at the pointer 
results in undefined behavior or an error in languages that allow 
it. Rust implements all of these pointer safety checks at compile 
time, so they do not incur a performance penalty. While `@safe` 
helps reduce this class of logic errors, it does not go so far as 
Rust -- you can still have null and dangling pointers, hence it 
is usually considered inferior with regards to safety. There was 
a SafeD[1] subset of D being worked on, but I'm not sure if it is 
active anymore.

As for D slowly dying, I would say it is not true. It has been 
growing by all measures lately. With projects like DUB and 
Derelict making progress, the ecosystem is more inviting to 
users. I think a lot of people have a bad taste in their mouth 
from D1 with Phobos/Tango. D exceeds Rust in some aspects, but my 
understanding is that Rust is a more safe language.

Anyhow, my analysis may be wrong, so I expect that someone may 
correct it.

Regards,
Kelet
January 04, 2014
Re: D - Unsafe and doomed
Thanks!
January 04, 2014
Re: D - Unsafe and doomed
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
January 04, 2014
Re: D - Unsafe and doomed
On Saturday, 4 January 2014 at 02:09:51 UTC, 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).

I'd say Kelet has it right, and I don't think the author has it 
wrong either. He goes into the specific issue he has in the 
section about Rust:

"Go and D provide memory safety but with all objects being 
automatically managed with a garbage collector (over which 
languages users have little control). Rust provides a way for 
programmers to declare objects that are automatically managed or 
explicitly managed, and statically checks that explicitly managed 
objects are used safely."

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.
January 04, 2014
Re: D - Unsafe and doomed
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.

Haha, he covers that in the next section, just before I stopped 
reading to reply.

"Rust still provides an escape hatch to allow students to 
experiment with unsafe code."

So realy Rust requires safety by default while D allows unsafe 
code by default. This leads me to believe that the reason Rust is 
safer is three fold, the SafeD system (@safe, @trusted, @system) 
isn't fully implemented, not enough libraries are marking @safe, 
and we don't have a good library to encapsulate the unsafe manual 
memory management (a library could probably get pretty close to 
what Rust's compiler does).
January 04, 2014
Re: D - Unsafe and doomed
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).
https://github.com/logicchains/ParticleBench/blob/master/D.d
https://github.com/logicchains/ParticleBench/blob/master/R.rs
January 04, 2014
Re: D - Unsafe and doomed
On Saturday, 4 January 2014 at 02:09:51 UTC, 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).

Quoting: "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. "

On surface this looks like explaining why D is unsafe, but the 
article fails to study real issues which were discussed in 
newsgroups or were filed in bugzilla. From my experience, there 
are much better opportunities to elaborate on why D is unsafe. 
Quoted citation looks extremely naive.

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

I doubt.

Why have you posted this ungrounded Rust advertisement anyway?
January 04, 2014
Re: D - Unsafe and doomed
On Saturday, 4 January 2014 at 02:27:24 UTC, Kelet wrote:
> While `@safe` helps reduce this class of logic errors […]
> you can still have […] dangling pointers, hence it is
> usually considered inferior with regards to safety.

This is not true. While it _is_ possible to get null pointers in 
@safe code, they are not a safety problem, as the first page is 
never mapped in any D processes (yes, I'm aware of the subtle 
issues w.r.t. object size here, c.f. Bugzilla). And if you find a 
way to obtain a dangling pointer in @safe code, please report it 
to the bug tracker, this is not supposed to happen.

> There was a SafeD[1] subset of D being worked on, but I'm not 
> sure if it is active anymore.

SafeD is D in @safe mode.

Cheers,
David
January 04, 2014
Re: D - Unsafe and doomed
On Saturday, 4 January 2014 at 04:20:30 UTC, David Nadlinger 
wrote:
> On Saturday, 4 January 2014 at 02:27:24 UTC, Kelet wrote:
>> While `@safe` helps reduce this class of logic errors […]
>> you can still have […] dangling pointers, hence it is
>> usually considered inferior with regards to safety.
>
> This is not true. While it _is_ possible to get null pointers 
> in @safe code, they are not a safety problem, as the first page 
> is never mapped in any D processes (yes, I'm aware of the 
> subtle issues w.r.t. object size here, c.f. Bugzilla). And if 
> you find a way to obtain a dangling pointer in @safe code, 
> please report it to the bug tracker, this is not supposed to 
> happen.
>
>> There was a SafeD[1] subset of D being worked on, but I'm not 
>> sure if it is active anymore.
>
> SafeD is D in @safe mode.
>
> Cheers,
> David

Thanks for the corrections.

Ultimately, it sounds like Rust primarily takes the 'default on' 
approach for things like safety and immutability, whereas D takes 
the 'default off' approach.

Regards,
Kelet
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home