Fantastic exchange from DConf

[Patrick Schluter via Digitalmars-d]

On Thursday, 18 May 2017 at 06:36:55 UTC, Paulo Pinto wrote:
> On Thursday, 18 May 2017 at 05:07:38 UTC, Patrick Schluter 
> wrote:
>> On Thursday, 18 May 2017 at 00:58:31 UTC, Steven Schveighoffer 
>> 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.
>>>
>>> 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).
>>>
>>> I wonder how much something like D in betterC mode can take 
>>> over some of these tasks?
>>>
>> If you get it to compile for and run the code on an AVR, 
>> Cortex R0 or other 16 bit µC, then it would have a chance to 
>> replace C. As it stands, C is the only general "high-level" 
>> language that can be used for some classes of cpu's.
>> D requires afaict at least a 32 bit system with virtual 
>> memory, which is already a steep requirement for embedded 
>> stuff.
>> C will remain relevant in everything below that.
>
> https://www.mikroe.com/products/#compilers-software
>
> One of the few companies that thinks there is more to AVR, 
> Cortex R0 or other 16 bit µC than just C.
>
> On this specific case they also sell Basic and Pascal (TP 
> compatible) compilers.
>
> There are other companies selling alternatives to C and still 
> in business, one just has to look beyond FOSS.

The thing with C is that it is available from the tiniest to the 
biggest. I remember in my former work place where the asset of 
the company were communication protocols (mainframe, telecom, 
lan, industrial). The same sources were used on Z80, x86 (from 
80186 to Pentium), 68030, ARM, AVR and 8051 (granted the 2 last 
didn't use much of the C code). Except for C I'm not aware of any 
language capable of that spread.
This doesn't mean that it won't change or that something similar 
wasn't possible with other languages. Pascal was a good contender 
in the 90s but paradoxically it is the success of turbo-pascal 
that killed it (i.e. there was no chance for the ISO standard to 
be appealing). As for Basic, the big issue with it is that it is 
not even portable within a platform or between versions.
Don't get me wrong, the products you listed are nice and a good 
step in the right direction, but they are far from there.
I love D but it is not being unfair to notice that it has a lack 
of platform diversity (I wanted to use D for years for our 
project at work but the lack of Solaris-SPARCv9 version was an 
insurmountable issue).