Disadvantages of building a compiler and library on top of a specific memory management scheme

[Paulo Pinto]

Am 08.02.2014 19:09, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>":
> On Saturday, 8 February 2014 at 17:08:44 UTC, Daniel Murphy wrote:
>  ...
>
> I think D could steal the VM/OS/embedded space with a very focused
> effort. C/C++ is ahead, but I believe D can surpass that if you go
> beyond C/C++ and forget about pleasing the Java/C# crowd.

Speaking from my Java/C# experience, D has a big up-hill battle against
those ecosystems:

- Tooling is great, we love our IDEs and just imagine having something 
like VisualVM to track down unwanted memory allocations and other 
contention points

- Compilation to native code is also available, if one wishes to do so.

- There are lots of embedded VM for both ecosystems capable to run in 
boards as small as a SIM card

- High performance trading systems with low latency are moving away from
C++ systems to JVM/.NET ones. Quite common in city, in London, for example.

- The going native wave, has made both JVM guys think about including 
AOT as part of the standard JDK, add value types, make unsafe package 
official as part of the post Java 8 features. Whereas the .NET camp has 
a new JIT (RyuJIT) in the works, and a switch to full native deployment 
is being worked on (ProjectN). Triggered mostly by what seems to be the 
C++/CX failure.

I wish D also finds its place in the mainstream, it is a hard fight 
nonetheless.

--
Paulo