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