ponce:

> Rust is supposed to replace C++, and it happens working in C++ since years, I can't help but notice we actually have very few memory safety problems,

Are you always able to detect them? I think languages (and programmers) that don't have a strict attitude toward memory safety will be slowly left behind in the few next years. D is lacking in this (and the scoping management should be able to plug some holes, and in the meantime there is this: https://github.com/D-Programming-Language/dmd/pull/4277 ).

Bye,
bearophile

On Sunday, 11 January 2015 at 19:38:12 UTC, bearophile wrote:
> Are you always able to detect them? I think languages (and programmers) that don't have a strict attitude toward memory safety will be slowly left behind in the few next years. D is lacking in this (and the scoping management should be able to plug some holes, and in the meantime there is this: https://github.com/D-Programming-Language/dmd/pull/4277 ).

There are tools to do that: https://software.intel.com/en-us/intel-inspector-xe
When we do have a memory safety bug, these tools help, and then I think "this wouldn't have happened in D" even without @safe. So I don't think D lacking in this.

On 1/11/15 10:25 AM, francesco.cattoglio wrote:
> I'm obviously being the devil's advocate here, but we can't just say "D
> is much more far ahead, we have nothing to fear from Go and Rust",
> because it's just not true.

Totally agreed. It's a competitive climate out there, and we need to mind our competition.

> And I say it as a daily D user, daily facing
> issues like the horrible invalidMemoryOperationError exception.

What is that?


Andrei

On Sunday, 11 January 2015 at 19:49:32 UTC, Andrei Alexandrescu wrote:
> On 1/11/15 10:25 AM, francesco.cattoglio wrote:
>> And I say it as a daily D user, daily facing
>> issues like the horrible invalidMemoryOperationError exception.
>
> What is that?


It happens if you try to do a GC operation while the GC is running.

The typical cause is allocating in a destructor. (Accessing reference type member variables from  class destructor is another way to get a crash, since the GC might collect them first.)


There's a handful of memory issues in D, some with the GC and some when you try to avoid the GC, but they typically don't bother me.... perhaps because I've learned to avoid problematic areas, like non-trivial class destructors.

On Sunday, 11 January 2015 at 19:38:12 UTC, bearophile wrote:
> ponce:
>
>> Rust is supposed to replace C++, and it happens working in C++ since years, I can't help but notice we actually have very few memory safety problems,
>
> Are you always able to detect them?

When Intel MPX comes you should be able to in debug builds, since you then supposedly cache the bounds for all mallocs. It basically attaches bounds to every pointer with a hardware mechanism for lookups. And you can turn it off at runtime, which turns the MPX instructions into NOP. So you can basically deploy an application with MPX builtin and tell a customer to turn on MPX if there is a problem that is suspected to be memory related.

But keep in mind that linear typing also affords safer multi-threading and removes doubts about aliasing which can prevent optimization... How important is it? Time will show && YMMV.

On Sunday, 11 January 2015 at 17:44:59 UTC, Andrei Alexandrescu wrote:
>
> http://erdani.com/d/downloads.daily.png that is. -- Andrei

You could go a long way with a little tracking code on dlang.org. Just saying.

On Sunday, 11 January 2015 at 19:42:38 UTC, ponce wrote:
> On Sunday, 11 January 2015 at 19:38:12 UTC, bearophile wrote:
>> Are you always able to detect them? I think languages (and programmers) that don't have a strict attitude toward memory safety will be slowly left behind in the few next years. D is lacking in this (and the scoping management should be able to plug some holes, and in the meantime there is this: https://github.com/D-Programming-Language/dmd/pull/4277 ).
>
> There are tools to do that: https://software.intel.com/en-us/intel-inspector-xe
> When we do have a memory safety bug, these tools help, and then I think "this wouldn't have happened in D" even without @safe. So I don't think D lacking in this.

Recently both Clang and GCC(? I think GCC has all of them now, maybe not) have integrated address,memory,thread, and undefined behavior sanitizer tools directly into their compiler aswell.

http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation

I don't think the memory safety issue is as big of an issue for 99% of people as it is for a group like Mozilla. I'm not even sure if Rust is going to replace C++ so much as possibly displace Ada.

Rust's lifetimes and borrow checker also really aren't fun, I feel like it really breaks my flow when I use Rust. It's like the opposite of python(or D), where I can get the least amount of scaffolding I need to get my concepts working, then fix it later. Maybe the language just isn't targeted for someone like me though.

Rust still has things I'd like to see in D.
Just my two cents.

On Sunday, 11 January 2015 at 20:47:37 UTC, weaselcat wrote:
> On Sunday, 11 January 2015 at 19:42:38 UTC, ponce wrote:
>> On Sunday, 11 January 2015 at 19:38:12 UTC, bearophile wrote:
>>> Are you always able to detect them? I think languages (and programmers) that don't have a strict attitude toward memory safety will be slowly left behind in the few next years. D is lacking in this (and the scoping management should be able to plug some holes, and in the meantime there is this: https://github.com/D-Programming-Language/dmd/pull/4277 ).
>>
>> There are tools to do that: https://software.intel.com/en-us/intel-inspector-xe
>> When we do have a memory safety bug, these tools help, and then I think "this wouldn't have happened in D" even without @safe. So I don't think D lacking in this.
>
> Recently both Clang and GCC(? I think GCC has all of them now, maybe not) have integrated address,memory,thread, and undefined behavior sanitizer tools directly into their compiler aswell.
>
> http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
>
> I don't think the memory safety issue is as big of an issue for 99% of people as it is for a group like Mozilla. I'm not even sure if Rust is going to replace C++ so much as possibly displace Ada.
>
> Rust's lifetimes and borrow checker also really aren't fun, I feel like it really breaks my flow when I use Rust. It's like the opposite of python(or D), where I can get the least amount of scaffolding I need to get my concepts working, then fix it later. Maybe the language just isn't targeted for someone like me though.
>
> Rust still has things I'd like to see in D.
> Just my two cents.

P.S., the sanitizer tools are built directly ontop of LLVM AFAIK(I haven't looked into how GCC incorporated them,) is there any chance we could ever see them being used for D?

On 1/11/15 12:28 PM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler@gmail.com>" wrote:
> On Sunday, 11 January 2015 at 17:44:59 UTC, Andrei Alexandrescu wrote:
>>
>> http://erdani.com/d/downloads.daily.png that is. -- Andrei
>
> You could go a long way with a little tracking code on dlang.org. Just
> saying.

What do you mean? -- Andrei

On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote:
> On Sunday, 11 January 2015 at 18:25:39 UTC, francesco.cattoglio wrote:
>> On Sunday, 11 January 2015 at 14:10:56 UTC, ponce wrote:
>>> None of them has Visual Studio integration with debugging support and that is pretty important for native and enterprise programmers.
>> If I remember correctly, just 2 month ago someone was explaining
>> how they lost a commercial user because D debugging experience
>> was still not good enough by a long shot. And in my daily use,
>> debug experience is still subpar on windows.
>>
>>> only to discover it is not fun enough and fun is more important than "memory safety without GC".
>> WHAT? Syntax is boring, but I don't get the sense of the sentence
>
> Right, might be personal judgement, at this point I was in rant-mode. :)
>
> Rust is supposed to replace C++, and it happens working in C++ since years, I can't help but notice we actually have very few memory safety problems, to the point that I question that it's something worth worrying about....[cutted]

Somehow I feel you are in the very lucky position of having top notch colleagues, with small attrition in team members and budget to buy C++ sanitation tools.

Many of the projects I worked for hadn't that luck.

Although I have spent part of Sunday doing C++ coding with the Android NDK, I don't miss those long weeks at work, looking for that pointer causing a server core dump, only to find out it was a double free/delete or an out of bounds error in a complete different module several minutes before the crash.

--
Paulo