Scenario: OpenSSL in D language, pros/cons

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Sun May 4 23:34:45 PDT 2014


On Sun, 04 May 2014 13:29:33 +0000
Meta via Digitalmars-d <digitalmars-d at puremagic.com> 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


More information about the Digitalmars-d mailing list