D is crap

[Paulo Pinto via Digitalmars-d]

On Monday, 11 July 2016 at 16:44:27 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 11 July 2016 at 16:26:11 UTC, Paulo Pinto wrote:
>> Happy not to disappoint.  :)
>
> You never disappoint in the GC department ;-)
>
>> OS vendors are the ones that eventually decided what is a 
>> systems programming language on their OSes.
>
> To a large extent on Apple and Microsoft OSes. Not so much on 
> open source OSes as you are not tied down to binary blobs.
>
>> And if they say so, like Apple is nowadays doing with Swift, 
>> developers will have no option other than accept it or move to 
>> other platform, regardless of their opinion what features a 
>> systems programming languages should offer.
>
> It is true that there have been policy changes which makes it 
> difficult to access features like GPU and Audio on OS-X/iOS 
> without touching Objective-C or Swift. You don't have to use it 
> much, but you need some binding stubs in Objective-C or 
> Objective-C++ if you want to be forward compatible (i.e. link 
> on future versions of the OS without recompiling).
>
> But I _have_ noticed that Apple increasingly is making low 
> level setup only available through Objective-C/Swift. It is 
> probably a lock-in strategy to raise porting costs to Android.

Actually NeXTStep drivers were written in Objective-C.

http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/

They are not alone, as of Android N, Google is making it pretty 
clear that if one tries to circuvent the constrained set of NDK 
APIs and workaround the JNI to
access existing shared objects, the application will be simply be 
killed.

http://android-developers.blogspot.de/2016/06/android-changes-for-ndk-developers.html

Which basically boils down to OEMs, 3D rendering and low

>
>> Just like C developers that used to bash C++, now have to 
>> accept the two biggest C compilers are written in the language 
>> they love to hate.
>
> There was a thread on reddit recently where some Microsoft 
> employees admitted that parts of Windows now is implemented in 
> C++ and C#, IIRC. I believe it is parts that run in user mode 
> as separate processes, but still...

Yes, the trend started with Windows 8 and the new application 
model based on the initial design of COM+ Runtime, which was the 
genesis of .NET before they decided to ditch it for the CLR.

If you check the latest BUILD, the current approach being 
evangelised is .NET Native for 90% of the code, C++/CX or plain 
C++ with WRL for glueing to low level code until C# gets the 
missing features from System C#, and C++ for everything else.

On the UWP model, DirectX is probably the only user space API 
that doesn't have a WinRT projection fully available, but they 
have been slowly surfacing it in each release.

The WinRT, User Driver Framework, the new container model and 
Linux subsystem, the Checked C, input to the C++ Core Guidelines 
and new C# features all trace back to the MSR work in 
Singularity, Midori and Drawbridge.