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

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Sat Feb 8 11:27:43 PST 2014


On Saturday, 8 February 2014 at 18:41:34 UTC, Paulo Pinto wrote:
> 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.


I am sure you are right, and they are probably the better 
alternative if you have the economic margins and if stability is 
critical.

The space I am thinking about is more that of scalable "artsy 
worlds", "freemium games" and "simple custom webservices/caches 
for mobile apps". It is important to keep costs down, both 
development and running cost because of the margins, so it should 
boot fast for scalability (and reboot after failure), easy to 
adapt and use memory well (for memcaching etc). The basic idea is 
to rent cheap cheap VMs close to the customers (in different 
countries) and be able to boot up more servers with little 
administration.

I think C++ only works out if the design is ready before you 
code, and redesigning is painful. I fear Java and C# is a bit 
heavy in terms of memory and booting to run on cheap servers that 
should boot up fast. So I feel D and Go are currently the most 
promising alternatives, though I feel Go might be a bit difficult 
to work with and D is not quite there either. Maybe Rust will be 
ready in a year or two…

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

Yeah, they have the economic margins to purchase dedicated 
servers.

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

It is, and I think you are quite right about the infrastructure 
part. On the client side I moved from Javascript to Dart and I 
think the productivity increased by a factor of 2 or something 
even though Dart compiles down to Javascript and has its own 
problems... But the IDE/library support really helps a lot.

But actually, I don't think D needs to find its place in the 
mainstream. I think it needs to be the best option in its niche. 
And I think light weight, snappy servers that boot/reset in an 
instant is a niche it can grab.


More information about the Digitalmars-d mailing list