On Friday, 9 October 2015 at 10:13:07 UTC, Chris wrote:
such as Go and Rust. I remember the VM fashion a couple of years back (mainly Java and C#), but still languages that compile to native code kept coming up and now everyone goes native, including the VM supporters. Why? Cos it didn't work and everybody working with Java realized that, it's too fookin slow.
VMs and JIT compilation works well for things that aren't engine level, like most of the application level code. I think sluggish performance for has more to do with static typing and memory layout than codegen (sans SIMD).
So maybe just compiling to JIT friendly Javascript with typed arrays is good enough. The problem is that you need to know all the JITs and runtimes in order to figure out what kind of Javascript constructs you need to use. Basically figuring out what "templates" the JITs translate into efficient machine code.
How can we tell that Go is the way to go (pardon the pun)?
Go is not the way to go in general, but it is currently the best option for ahead of time compiled web services that are I/O bound. But for me it is _primarily_ an infrastructure issue. Infrastructure issues makes it difficult to compete with languages like Go, Java and Python for web servers.
Maybe in a few years' time the thing to do will be library based memory management.
I think that is unlikely given all the research on pointer analysis etc.
One of D's strengths is to be impervious to fashion and to try to do what's right and what works. Ironically enough, C++ is playing catch up with D.
C++ is under pressure from Rust, Go and perhaps also D. Mostly because it takes years (or decades) to get new features into C++, so they have to start working on new features early. I am not even sure we would have seen the C++ guidelines/GSL initiative without Rust. They basically bypassed the standard process in order to "add features" faster by pushing it at CppCon...
