On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
> Am 28.04.2013 12:03, schrieb Dicebot:
>> On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:
>>> I also think when modules are integrated into the C++
> True, but only now the major OS vendors are switching from C to C++ as their main systems programming language.

I think that exactly because it is a switch *in the happening*, it is the moment for D to be involve in that switch. Because project managers are considering switching and they look for alternatives. Maybe some of them will tell themselves: "well, if we switch, why do not take that D in consideration? at least, for experimenting and see what it gives".

It is useless to be a good alternative if nobody wants to switch.

If they go down on the C++ path, then two things will happen:
-they will be even more reluctant to do another switch, while their code base matures (and, do not forget, interoperability or portability from C to D is one thing; form C++ to D is a different, huge, beast).
-C++ will get more traction and more pressure to improve itself, from vendors and community at large. it will advance faster.

In the end, we should not be sorry, as programmers we will win better language, better tools. But I am afraid that D will not win as much.

On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
> ...

D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view.

On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:
> On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
> D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view.

Well, then a list of what's still missing should be compiled (in terms of features and language changes, not in terms of bugs). An rush to complete it.

Some of the issues were discussed since many months, and no definitive decision has been taken (see the @property).

I am rather in favor of taking a decision, good or bad, than to prolonge ambiguity. Also for several minor issues (ie: double[$] static arrays and __MODULE__ identifier and so on).

For those, I would like to see a more accelerated pace.

I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation.

On Monday, 29 April 2013 at 08:07:05 UTC, eles wrote:
> I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation.

That brings us back to the "Stable D" subject, and the separation between stable and unstable.
Those preliminary features should be included in the unstable releases, where changes can be made without the fear of breaking things.
Then, after some actual usage, they would be merged to the stable branch.

On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
> On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
>> True, but only now the major OS vendors are switching from C to C++ as their main systems programming language.
>
> Curious, which ones are you referring to?
>
> Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack.
>
> Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers).
>
> Which vendors have switched to C++ for systems programming?

BeOS/Haiku - C++

Symbian - C++

MacOS X - Device Drivers are written in a C++ subset (IOKit)

z/OS - Original code was Modula-2/Assembly, with new code being C++

Windows - WinRT is C++, C is considered legacy, Herb Sutter stated at BUILD 2012 that Windows team is making kernel code C++ compatible. I can search for the exact minute in the videos if you wish.

On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
> On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

> Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers).

err, Linus

On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:
> On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
>> ...
>
> D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view.

This guys don't have any issues selling Oberon compilers for embedded use.

http://www.oberonday2011.ethz.ch/talks/armembedded.pdf

http://www.astrobe.com/default.htm

A GC enabled systems programming language.

Oracle with their Spots  and the new Keil board support (Java)

http://www.sunspotworld.com/

http://docs.oracle.com/javame/config/cldc/rel/3.3/keil/gs/html/getstart_rtx/running.htm

Or the Netduino guys (C#)

http://netduino.com/

Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards.

On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:
> This guys don't have any issues selling Oberon compilers for embedded use.
> ...

That is simple, "embedded" is a buzzword often understood as "something like PC but small". Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not.

Much more practical definition of "embedded" is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there.

On Monday, 29 April 2013 at 10:38:32 UTC, Dicebot wrote:
> On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:
>> This guys don't have any issues selling Oberon compilers for embedded use.
>> ...
>
> That is simple, "embedded" is a buzzword often understood as "something like PC but small". Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not.
>
> Much more practical definition of "embedded" is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there.

Quoting myself

"Or course this is a very limited subset of what embedded is all
about, but I think D could also be usable in such types of boards."

On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote:
> Quoting myself
>
> "Or course this is a very limited subset of what embedded is all
> about, but I think D could also be usable in such types of boards."

Okay, pardon me, may be I have not highlighted my point clear enough: there is no real market for D in that limited subset because it has to compete with Java, C# or any modern language based on their virtual machines. And, similar to desktop usage, lot of selling points for D are lost then, because, well, why bother?

Contrary to this, any language who can make it into real embedded domain will be almost uncontested, because this industry is still stuck with 40-year obsolete tools. But that is not something that may happen on its own.