D and Nim

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Mon Jan 5 05:47:21 PST 2015


On Monday, 5 January 2015 at 13:13:43 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 5 January 2015 at 10:21:12 UTC, Paulo  Pinto wrote:
>> On Monday, 5 January 2015 at 09:51:22 UTC, Suliman wrote:
>>> What is kill future of Nim?
>>>
>>> D is successor of C++, but Nim? Successor of Python?
>>
>> A C++ successor is any language that earns its place in a OS 
>> vendors SDK as the OS official supported language for all OS 
>> layers.
>>
>> Which one it will be is still open game.
>
> But C++ gained traction before any OS officially supported it 
> (sans BeOS)?

Yes. It was almost immediately adopted by C compiler vendors 
given it came from AT&T and as compatible with C.

UNIX vendors jumped on it for CORBA and telecommunications (C++ 
original field) so by the early 90's pretty much all UNIXes had 
some form of C++ support.

Walter's work was also an influence, given it was the first C++ 
compiler to directly produce native code.

Epoch/Symbian and later OS/400 revisions were also done in C++.

On MS-DOS I was already using C++ back in 1993.

>
> Without an ABI, I think C++ will be it's own successor. And I 
> think key C++ people know this and will avoid creating an ABI...

C ABI only works in OS that happen to be written in C. There are 
a few where this is not the case. OS/400 is such an example.

For C++ there is the Itanium ABI, COM/WinRT on Windows and the 
upcoming C++17 ABI.

>
> Besides that I don't think there will be a single replacement. 
> It will more likely be several languages aiming at different 
> domains where you have different hardware requirements (hpc, 
> embedded, servers, interactive apps...)
>
> D needs to pick one area, and do it well there.
>
> * If D is aiming for conserving memory and realtime apps, then 
> it needs better memory model/reference type system,
>
> * if D is aiming for convenient server programmer (that can 
> afford wasting memory), then it need to tune the language for 
> better garbage collection.
>
> With no tuning... other languages will surpass it. Be it Rust, 
> Chapel, Go, Nim or one of the many budding language projects 
> that LLVM has inspired...

Yes there are lots of options, still the ones that live longer as 
system programming languages, are the ones that get OS vendor 
adoption.

So far, it has always been the case.

--
Paulo



More information about the Digitalmars-d mailing list