On Friday, 5 June 2015 at 18:25:26 UTC, Chris wrote:
On Friday, 5 June 2015 at 17:28:39 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 5 June 2015 at 14:51:05 UTC, Chris wrote:
I agree, but I dare doubt that a slight performance edge will
make the difference. There are load of factors (knowledge
base, infrastructure, complacency, C++-Guruism, marketing
etc.) why D is an underdog.
But everybody loves the underdog when it catches up to the
pack and beats the pack on the finish line. ;^)
I now follow Pony because of this self-provided benchmark:
http://ponylang.org/benchmarks_all.pdf
They are communicating a focus for a domain, a good
understanding of their area, and it makes me want to give it a
spin even at this early stage where I obviously can't actually
use it.
I am not saying Pony is good, but it makes a good case for
itself IMO.
no sugar, thanks." I know, as usual I simplify things and
exaggerate! He he he. But programming languages are like
everything else, only because something is good doesn't mean
that people will buy it.
Sure, but it is also important to make people take notice.
People take notice of benchmark leaders. And too often
benchmarks measure throughput while latency is just as
important.
End user don't notice peak throughput (which is measurable as
a bleep on the cloud server instance-count logs), they notice
reduced latency. So to me latency is the most important aspect
of a web-service (+ programmer productivity).
I don't find Go exciting, but they show concern for latency
(concurrent GC etc). Communicating that concern is good, even
before they reach whatever goals they have.
As regard compiler-based features, as soon as features are
compiler-based people will complain "Why is it built-in? That
should be handled by a library! I want more freedom!" I know
for sure.
Heh, not if it is getting you an edge, but if it is a second
citizen addition. Yes, then I agree.
Cheers!
Thanks for showing me Pony. Languages like Nim and Pony keep
popping up which shows a) how important native compilation is
and [...]
Which is why after all those years, the OpenJDK will eventually
support AOT compilation to native code for Java 10 with some work
being done in JEP 220[0], and .NET does AOT native code on
Windows Phone 8 (MDIL), with static compilation with Visual C++
backend coming with .NET Native.
And Android also went native with the Dalvik re-write.
The best approach is anyway to have a JIT/AOT capable toolchain
and use them accordingly to the deployment target.
[0]Which means Oracle finally accepted why almost all commercial
JVM vendors do offer such a feature. I read somewhere that JIT
only was a kind of Sun political issue.
