On Monday, 5 May 2014 at 06:35:07 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Sun, 04 May 2014 13:29:33 +0000
Meta via Digitalmars-d <[email protected]> wrote:
The only language I would
really trust is one in which it is impossible to write unsafe
code, because you can then know that the developers can't use
such unsafe hacks, even if they wanted to.
Realistically, I think that you ultimately have to rely on the
developers
doing a good job. Good tools help a great deal (including a
programming
language that's safe by default while still generally being
efficient), but if
you try and restrict the programmer such that they can only do
things that are
guaranteed to be safe, I think that you're bound to make it
impossible to do a
number of things, which tends to not only be very frustrating
to the
programmers, but it can also make it impossible to get the
performance that
you need in some circumstances.
So, while you might be able to better trust a library written
in a language
that's designed to make certain types of problems impossible, I
don't think
that it's realistic for that language to get used much in
anything performance
critical like an SSL implementation.
Ultimately, I think that the trick is to make things as safe as
they can be
without actually making it so that the programmer can't do what
they need to
be able to do. And while, I don't think that D hit the perfect
balance on that
one (e.g. we should have made @safe the default if we wanted
that), I think
that we've done a good job of it overall - certainly far better
than C or C++.
- Jonathan M Davis
Sometimes I wonder how much money have C design decisions cost
the industry in terms of anti-virus, static and dynamic analyzers
tools, operating systems security enforcements, security research
and so on.
All avoidable with bound checking by default and no implicit
conversions between arrays and pointers.
--
Paulo
