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.

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.

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.

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

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.

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.

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.

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

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.

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