On Monday, 11 July 2016 at 14:19:07 UTC, ketmar wrote:
> On Monday, 11 July 2016 at 14:02:09 UTC, Ola Fosheim Grøstad wrote:
>> Actually, I am certain that GC is a feature that _nobody_ would expect from a system level language, outside the Go-crowd.
>
> hello. i am the man born to ruin your world.

Of course, you are the extra 1% that comes on top of the other 100%.

On Monday, 11 July 2016 at 14:02:09 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 11 July 2016 at 13:24:14 UTC, Chris wrote:
>> I bet you that if D hadn't had GC when it first came out, people would've mentioned manual memory management as a reason not to use GC. I never claimed that D was _propelled_ by GC, but that it was a feature that most users would expect. Not having it would probably have done more harm than having it.
>
> Actually, I am certain that GC is a feature that _nobody_ would expect from a system level language, outside the Go-crowd.
>

I am no longer dabbling in D, but could not resist:

- UK Royal Navy with Algol 68 RS

- Xerox PARC with Mesa/Cedar

- DEC/Olivetti/Compaq with Modula-3

- ETHZ with Oberon, Oberon-2, Active Oberon, Component Pascal

- Microsoft with Spec#, System C# and the upcoming .NET Native C# 7.0+ features
 (http://joeduffyblog.com/2015/12/19/safe-native-code/, https://www.infoq.com/news/2016/06/systems-programming-qcon)

- Astrobe with Oberon for micro-controlers (ARM Cortex-M4, Cortex-M3 and
Xilinx FPGA Systems)

- PTC Perc Ultra with Java

- IS2T with their MicroEJ OS Java/C platform


The biggest problem with D isn't the GC, is lack of focus to make it stand out versus .NET Native, Swift, Rust, Ada, SPARK, Java, C++17.

On Monday, 11 July 2016 at 14:45:56 UTC, Paulo Pinto wrote:
> The biggest problem with D isn't the GC, is lack of focus to make it stand out versus .NET Native, Swift, Rust, Ada, SPARK, Java, C++17.

I knew you would chime in... Neither .NET, Swift or Java should be considered system level tools. Ada/Spark has a very narrow use case. Rust is still in it's infancy. C++17 is not yet finished. But yes, C++ currently owns system level programming, C is loosing terrain and Rust has an uncertain future.

The biggest problem with D is not GC, because we now how @nogc. But D is still lacking in memory management.

On Monday, 11 July 2016 at 14:03:36 UTC, Infiltrator wrote:
> On Monday, 11 July 2016 at 13:24:14 UTC, Chris wrote:
>> ...
>> To have GC was definitely a good decision. What was not so
>> good was that it was not optional with a simple on/off switch.
>> ...
>
> I know that I'm missing something here, but what's wrong with the functions provided in core.memory?  Specifically, GC.disable()?

I was thinking of a compiler switch (as they did in Objective-C), and had D been designed with `-nogc` in mind from the start, Phobos would be GC free too. No GC is still a bit rough around the edges.

On Monday, 11 July 2016 at 14:12:35 UTC, Chris wrote:
> Most certainly from a multi-purpose language. GC would have been demanded sooner or later. The mistake was not to make it optional from the beginning.

If D was designed as a high level language then it would be a mistake not to provide a GC in most scenarios. Yes.

> care about GC overheads, however, and without GC a lot of people wouldn't even have considered it.

Lots of people have been happy with Perl and Python before they added GC to catch cycles... Most applications don't leak a lot of memory to cyclic references and they usually have to run for a while. (But constructing a worst case is easy, of course.)

(Btw, didn't mean to say that autorelease pools are the same as a region allocator, but they are similar in spirit.)

> Go ahead, I'm sure it's fun. ;)

Oh, I didn't mean to say I have designed a language. I have many ideas and sketches, but far too many to implement and polish ;-).

I have started extending my knowledge on type systems, though, quite interesting. I think the change in computing power we now have is opening up for many new interesting opportunities.

On Monday, 11 July 2016 at 14:45:56 UTC, Paulo Pinto wrote:
>
> The biggest problem with D isn't the GC, is lack of focus to make it stand out versus .NET Native, Swift, Rust, Ada, SPARK, Java, C++17.

How true!
That's the only real problem with this beautiful language!

/P

On Monday, 11 July 2016 at 14:58:16 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 11 July 2016 at 14:45:56 UTC, Paulo Pinto wrote:
>> The biggest problem with D isn't the GC, is lack of focus to make it stand out versus .NET Native, Swift, Rust, Ada, SPARK, Java, C++17.
>
> I knew you would chime in... Neither .NET, Swift or Java should be considered system level tools. Ada/Spark has a very narrow use case. Rust is still in it's infancy. C++17 is not yet finished. But yes, C++ currently owns system level programming, C is loosing terrain and Rust has an uncertain future.
>
> The biggest problem with D is not GC, because we now how @nogc. But D is still lacking in memory management.

Happy not to disappoint.  :)

OS vendors are the ones that eventually decided what is a systems programming language on their OSes.

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.

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.

On Monday, 11 July 2016 at 14:12:35 UTC, Chris wrote:
>
> You focus on a small niche where people use all kinds of performance tricks even in C and C++. A lot of software doesn't care about GC overheads, however, and without GC a lot of people wouldn't even have considered it.
>

+1
A large majority of performance-heavy software can live with the GC.
GC is a blocker for people using micro-controllers with little memory, that usually don't get to choose a compiler.

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.

> 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...

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.