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