[FoRK] The collapse of the .net ecosystem
Stephen D. Williams
sdw at lig.net
Sun Jun 21 11:32:38 PDT 2015
On 6/21/15 11:00 AM, J. Andrew Rogers wrote:
>> On Jun 21, 2015, at 1:07 AM, Stephen D. Williams <sdw at lig.net> wrote:
>> I meant "server-side web app C++". For actual heavy lifting, of course C++ is always key. I am surprised by how much of Hadoop, Spark, and similar systems and apps, even for ML, are all Java.
> A decade ago the requirements were different and the Java bandwagon was in full effect despite the limitations. The justification for Java on the server was easy portability. This was further enabled by the relative lack of sophistication (or need for sophistication) of server-side architectures back then. Generic portability was pretty adequate when Hadoop was created, particularly since those platforms were not designed to do what they are used for today. The use of Java is a legacy of the times.
> Fast forward to 2015 and few people need portability because Linux is pervasive, server architectures are much more sophisticated in their use of the hardware, and garbage collection is a bad idea for these use cases.
>> I credit C++11 with a lot of it. Finally threads and many other things are in the language/library. Move semantics resolved a lot of the lingering inefficiency, etc. It falls a little short (Qt's memory management / thread-safe collections, and thread-aware signals/slots really should have been incorporated somehow), but it was a huge improvement for portability, interoperability, baseline features that avoid proprietary solutions for key basic capabilities.
> C++11 was important because it majorly cleaned up the language and added some critical features and capabilities that make robust code much easier to implement. But for most of the use cases where C++ excels, the standard library is barely used; it was probably one of the least useful parts of C++11. If you need libraries for memory management, thread-safe collections, etc for your application then C++ is probably the wrong language in any case.
Sometimes you need efficiency. Sometimes you need programmer efficiency. Sometimes you need both in different areas in greatly
different proportions. Sometimes the library routines are more efficient than you think they would be. Premature optimization is
the root of all evil.
But, outside of new primitives like thread handling, mutexes, move semantics, etc., I agree that can be the case.
One thing that C++ needs, which I think the LLVM guys are working on, is global and peephole run-time performance analysis and JIT
replacement code. Perhaps an option to insert runtime probes to create compilation hints or simply solidify to either a non-probe
version vs. JIT for each block of code.
And we always need far more intelligence for SIMD and other parallelism. Competent hand coded SIMD assembly beats all compilers
hands down there, especially on ARM.
More information about the FoRK