D not considered memory safe

Paulo Pinto pjmlp at progtools.org
Thu Jul 11 07:37:38 UTC 2024


On Wednesday, 10 July 2024 at 16:06:50 UTC, ryuukk_ wrote:
> On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:
>> On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:
>>> On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:
>>>> We have very few details on what this will look like for 
>>>> someone that doesn't want it. Not breaking existing code is 
>>>> far from sufficient for those writing unsafe code.
>>>
>>> Sorry, but having unsafe code is burden enough.
>>
>> This is not helpful. If the biggest selling point is working 
>> with legacy C code, unsafe code needs to be a core part of the 
>> language, and it needs to be as easy as possible. (As in, as 
>> easy as it is right now.)
>>
>>> I don't see any need to help people continue to write unsafe 
>>> code.
>>
>> D will quickly die without unsafe code. I would certainly have 
>> no reason to continue using it. Rust has the small market for 
>> "safe by default" code. D can not and will not compete with 
>> Rust on this - the battle is over and all parties have moved 
>> on.
>>
>>> If at all, it is enough that it will be still possible to 
>>> write unsafe code. Its not required to make that easy.
>>
>> We can already do it. There's no "make that easy" to do.
>>
>>> Why can't those people be bothered with giving -unsafe as 
>>> compile parameter?
>>
>> Proposed and rejected. Whereas safe by default is already 
>> available with a switch.
>
> +1
>
> AI devs picked C, not rust

They picked C++, CUDA and Python JIT compilers, alongside Java, 
Scala, C++, and Rust for the tools used in big data ecosystem 
like Spark and Arrow.

Pytorch and Tensorflow, use C++ with Python and Java bindings.

Depending on how sucessful, Modular's agreement with NVidia turns 
out, they might pick Mojo as well.

C not really part of the story beyond being Python's FFI ABI.



More information about the Digitalmars-d mailing list