Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 17, 2017 at 08:58:31PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
> What will cause a shift is a continuous business loss.
> 
> If business A and B are competing in the same space, and business A
> has a larger market share, but experiences a customer data breach.
> Business B consumes many of A's customers, takes over the market, and
> it turns out that the reason B wasn't affected was that they used a
> memory-safe language.
> 
> The business cases like this will continue to pile up until it will be
> considered ignorant to use a non-memory safe language. It will be even
> more obvious when companies like B are much smaller and less funded
> than companies like A, but can still overtake them because of the
> advantage.

This is a possible scenario, but I don't see it being particularly
likely, because in terms of data breaches, memory safety is only part of
the equation. Other factors will also come into play in determining the
overall susceptibility of a system. Things like secure coding practices,
and by that I include more than just memory safety, such as resource
management, proper use of cryptographic technology, privilege
separation, access control, data sanitation, etc..  In spite of C's
flaws, it *is* still possible to create a relatively secure system in C.
It's harder, no argument about that, but possible.  It depends on how
the company implements secure coding practices (or not).  In a memory
safe language you can still make blunders that allow breaches like SQL
injection in spite of memory safety.



> At least, this is the only way I can see C ever "dying". And of course
> by dying, I mean that it just won't be selected for large startup
> projects. It will always live on in low level libraries, and large
> existing projects (e.g. Linux).
[...]

If that's your definition of "dying", then C has been steadily dying
over the past decade or two already. :-)  Since the advent of Java, C#,
and the rest of that ilk, large droves of programmers have been leaving
C and adopting these other languages instead. I don't have concrete data
to back this up, but my suspicion is that the majority of new projects
started today are not in C, but in Java, C#, Javascript, and similar
languages, and a smaller percentage in C++, depending on the type of
project. Perhaps in gaming circles C++ might still be dominant, but in
the business applications world and in the web apps world the trend is
definitely on Java, C#, et al. C's role has pretty much been shrinking
to embedded software and low-level stuff like OSes (mainly Posix) and
low-level network code. (Unfortunately it still accounts for a
significant number of low-level network code, especially those running
on network hardware like routers and firewalls, which is why security
issues in C code are still a concern today.)

Nevertheless, there is still an ongoing stream of exploits and security
incidents in the web programming world largely driven by supposedly
memory-safe languages like Java or Javascript. (Well, there is that
disaster called PHP that's still prevalent on the web, maybe that
accounts for some percentage of these exploits. But that's mostly in the
implementation of PHP rather than the language itself, since AFAIK it
doesn't let you manipulate memory directly in an unsafe way like C does.
But it does let you do a lot of other stupid things, security-wise, that
will still pose problems even though it's technically memory-safe.
That's why I said, memory safety only goes so far -- you need a lot more
than that to stand in the face of today's security threats.)


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth