View mode: basic / threaded / horizontal-split · Log in · Help
November 07, 2009
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote:
> grauzone wrote:
>> If you mean memory safety, then yes and will probably forever be for 
>> all practical uses (unless D gets implemented on a Java or .net like VM).
> 
> A VM is neither necessary nor sufficient to make a language memory safe. 
> It's all in the semantics of the language.

In practice, the big disadvantage which D has is that it can make calls 
to C libraries which are not necessarily memory safe -- and this is an 
important feature of the language. Dealing with the external, 
uncheckable libraries is always going to be a weak point. Both Java and 
.net have mitigated this by rewriting a fair chunk of an OS in their 
libraries. That's probably never going to happen for D.
November 07, 2009
Re: Safety, undefined behavior, @safe, @trusted
On 07/11/2009 11:53, Don wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> If you mean memory safety, then yes and will probably forever be for
>>> all practical uses (unless D gets implemented on a Java or .net like
>>> VM).
>>
>> A VM is neither necessary nor sufficient to make a language memory
>> safe. It's all in the semantics of the language.
>
> In practice, the big disadvantage which D has is that it can make calls
> to C libraries which are not necessarily memory safe -- and this is an
> important feature of the language. Dealing with the external,
> uncheckable libraries is always going to be a weak point. Both Java and
> .net have mitigated this by rewriting a fair chunk of an OS in their
> libraries. That's probably never going to happen for D.


Sun pretty much implemented a full OS inside the JVM. At least their RT 
offering contains a scheduler in order to provide guaranties regarding 
collection time.

In .Net land, MS uses .net to implement parts of their OS so no surprise 
there that those OS APIs are available to .net code. I wouldn't say that 
it's part of their libraries but rather parts of the OS itself.

What parts of the OS are still missing in D's standard library? Isn't 
tango/phobos already provide all the common parts like i/o and 
networking and a few other major libs provide bindings/implementation 
for UI, 3d & multimedia, db bindings, etc?

I think that the big disadvantage you claim D has isn't that big and it 
is well underway to go away compared to .net/java.
Both Java and .net also provide ways to use unsafe C code (e.g. JNI, 
COM), It just a matter of what's the default, what's easier to do and 
what can be done without choosing the unsafe option. I think that D 
isn't that far off behind and could and should catch up.
November 07, 2009
Re: Safety, undefined behavior, @safe, @trusted
Don wrote:
> In practice, the big disadvantage which D has is that it can make calls 
> to C libraries which are not necessarily memory safe -- and this is an 
> important feature of the language. Dealing with the external, 
> uncheckable libraries is always going to be a weak point. Both Java and 
> .net have mitigated this by rewriting a fair chunk of an OS in their 
> libraries. That's probably never going to happen for D.

Java has the jni interface where one can execute arbitrary C code. 
Obviously, that isn't memory safe, either.

Some of the standard C library functions are safe, some of them aren't. 
We'll mark them appropriately in the std.c.* headers.

I expect there will be a lot of pressure for 3rd party D libraries to be 
marked as safe, so I think this problem will sort itself out over time.
November 07, 2009
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote:
> grauzone wrote:
>> If you mean memory safety, then yes and will probably forever be for 
>> all practical uses (unless D gets implemented on a Java or .net like VM).
> 
> A VM is neither necessary nor sufficient to make a language memory safe. 
> It's all in the semantics of the language.

Yes, but VM bytecode is a much smaller language than D, which makes it 
far easier to verify for safety. In practice, SafeD will gradually 
become actually safe as people use it, see it break, and you fix the 
bugs. That's why I said for "all practical uses".
November 07, 2009
Re: Safety, undefined behavior, @safe, @trusted
grauzone wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> If you mean memory safety, then yes and will probably forever be for 
>>> all practical uses (unless D gets implemented on a Java or .net like 
>>> VM).
>>
>> A VM is neither necessary nor sufficient to make a language memory 
>> safe. It's all in the semantics of the language.
> 
> Yes, but VM bytecode is a much smaller language than D, which makes it 
> far easier to verify for safety. In practice, SafeD will gradually 
> become actually safe as people use it, see it break, and you fix the 
> bugs. That's why I said for "all practical uses".

The Java VM didn't start out as completely safe, either, as people found 
the holes they were fixed.
November 07, 2009
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote:
> grauzone wrote:
>> Walter Bright wrote:
>>> grauzone wrote:
>>>> If you mean memory safety, then yes and will probably forever be for 
>>>> all practical uses (unless D gets implemented on a Java or .net like 
>>>> VM).
>>>
>>> A VM is neither necessary nor sufficient to make a language memory 
>>> safe. It's all in the semantics of the language.
>>
>> Yes, but VM bytecode is a much smaller language than D, which makes it 
>> far easier to verify for safety. In practice, SafeD will gradually 
>> become actually safe as people use it, see it break, and you fix the 
>> bugs. That's why I said for "all practical uses".
> 
> The Java VM didn't start out as completely safe, either, as people found 
> the holes they were fixed.

Because the bytecode language is much smaller than a high level language 
like D, it's easier for Java. Also, Java was planned to be safe right 
from the beginning, while SafeD is a rather unnatural feature added on 
the top of a complex existing language. To make it safe, you need to 
forbid a set of features, which inconveniences the programmer and will 
possibly reduce code efficiency. I'm not even opposed to the idea of 
SafeD, I'm just worrying that forcing all D code to adhere to SafeD by 
default will cause more trouble than gain.
November 08, 2009
Re: Safety, undefined behavior, @safe, @trusted
grauzone wrote:
> Because the bytecode language is much smaller than a high level language 
> like D, it's easier for Java.

I don't agree that has anything to do with it. The VM is compiled down 
to the same old CPU instructions that D is compiled to. What matters is 
the semantics.

> Also, Java was planned to be safe right 
> from the beginning, while SafeD is a rather unnatural feature added on 
> the top of a complex existing language. To make it safe, you need to 
> forbid a set of features, which inconveniences the programmer and will 
> possibly reduce code efficiency. I'm not even opposed to the idea of 
> SafeD, I'm just worrying that forcing all D code to adhere to SafeD by 
> default will cause more trouble than gain.

Only time will tell, of course, but D has a lot of inherently safe 
constructs (such as length-delimited arrays) that obviate most of the 
need for manipulating pointers.

C++ users have also discovered that if they stick to writing in certain 
ways and using the STL, their programs are memory safe. The problem with 
C++ is, once again, this is by convention and is not checkable by the 
compiler.
November 08, 2009
Re: Safety, undefined behavior, @safe, @trusted
grauzone wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> Walter Bright wrote:
>>>> grauzone wrote:
>>>>> If you mean memory safety, then yes and will probably forever be 
>>>>> for all practical uses (unless D gets implemented on a Java or .net 
>>>>> like VM).
>>>>
>>>> A VM is neither necessary nor sufficient to make a language memory 
>>>> safe. It's all in the semantics of the language.
>>>
>>> Yes, but VM bytecode is a much smaller language than D, which makes 
>>> it far easier to verify for safety. In practice, SafeD will gradually 
>>> become actually safe as people use it, see it break, and you fix the 
>>> bugs. That's why I said for "all practical uses".
>>
>> The Java VM didn't start out as completely safe, either, as people 
>> found the holes they were fixed.
> 
> Because the bytecode language is much smaller than a high level language 
> like D, it's easier for Java. Also, Java was planned to be safe right 
> from the beginning, while SafeD is a rather unnatural feature added on 
> the top of a complex existing language. To make it safe, you need to 
> forbid a set of features, which inconveniences the programmer and will 
> possibly reduce code efficiency. I'm not even opposed to the idea of 
> SafeD, I'm just worrying that forcing all D code to adhere to SafeD by 
> default will cause more trouble than gain.

On the other hand, Java has had a much larger ambition, i.e. executing 
untrusted code in a sandbox, so that balances things a bit.

I may as well be wrong, but my intuition is that there are no 
insurmountable holes that would make D unusable for safe programs. I can 
clearly see the exact reasons why C++ cannot have a reasonably 
well-defined safe subset: you can't do anything of significance in C++ 
without using pointers and pointer arithmetic. (That could be mitigated 
by a library.) Anyhow, here are a few elements that I think contribute 
to D's ability to approach memory safety:

* garbage collection
* built-in arrays
* reference semantics for classes
* pass-by-reference (ref)
* safe approach to variadic functions

Without some or all of these, a safe subset of D would be more difficult 
to define and less expressive.


Andrei
November 08, 2009
Re: Safety, undefined behavior, @safe, @trusted
Yigal Chripun wrote:
> In .Net land, MS uses .net to implement parts of their OS so no surprise 
> there that those OS APIs are available to .net code.

Really? What parts?

There are a bajillion APIs that you can use from .NET that aren't 
written in .NET. Microsoft just made it easier to use native code from 
.NET than Java does.
November 08, 2009
Re: Safety, undefined behavior, @safe, @trusted
Christopher Wright wrote:
> Yigal Chripun wrote:
>> In .Net land, MS uses .net to implement parts of their OS so no 
>> surprise there that those OS APIs are available to .net code.
> 
> Really? What parts?
> 
> There are a bajillion APIs that you can use from .NET that aren't 
> written in .NET. Microsoft just made it easier to use native code from 
> .NET than Java does.

WPF for one. yes, it uses an unmanaged low-level engine called MIL to 
improve performance and interoperability but the windowing APIs 
themselves are .NET only and it's not just wrappers, it contains over 
3000 classes according to MSDN.

Of course there are bajillion Non .net APIs that are accessible from 
.NET. That's because MS has backward compatibility support starting from 
the DOS era. New technology is however done in .NET
Next ›   Last »
6 7 8 9 10
Top | Discussion index | About this forum | D home