[FoRK] The collapse of the .net ecosystem

Stephen D. Williams sdw at lig.net
Sun Jun 21 01:07:44 PDT 2015

On 6/20/15 10:04 PM, J. Andrew Rogers wrote:
>> On Jun 20, 2015, at 2:10 PM, Stephen D. Williams <sdw at lig.net> wrote:
>> What Unicorn, hot startup, or really any startup that you respect, is using C# (outside of Unity)?
> There are more startups using C# in their core infrastructure than you would think, including large ones, just not in Silicon Valley due to Silicon Valley’s UNIX-centric history and relative lack of B2B and ecommerce focus. There is no real downside for most startups to using C# if the team knows it well since it minimizes cost and execution risk. The choice of language isn’t that important unless you are doing something that requires atypical scale, efficiency, or resource intensity.

True, as long as you either don't need to frequently and rapidly integrate with key libraries on an ongoing basis, or you can afford 
to duplicate the leading ecosystems' output, a la Facebook & PHP.

These are good examples of libraries that might be a pain to duplicate and maintain in a new language.  Sort of a bad example here 
because it is relatively easy to port and is widely needed.


For PHP:
>> Android has strengthened Java, which still also has wide use/support in cloud and enterprise computing.  It's being challenged by Go, Javascript, Python, etc., although apparently server-side C++ just can't get respect.  I'd be interested in Qt+C++11 myself for server side dev, but for a few reasons, splitting web apps between Node & Go, with specific subsystems in Java / Python / C++, seems promising right now.
> What do you mean by “server-side C++”?

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.
C++ as a direct web app competitor doesn't seem popular at all (say as dynamically loaded modules in nGinx, and/or using Qt), 
although it sort of is as the infrastructure and addons for NodeJS and similar.

> C++11 has completely replaced Java for a lot of new development on the server over the last five years. In a similar reversal of fortune Java may end up being the client-side language it always wanted to be, thanks to Android.
> LLVM is an overlooked part of the C++ resurgence story. LLVM is increasingly being used to do all sorts of dynamic runtime compilation within C++ code bases to the point where it is on its way to becoming a standard architecture pattern. You get much of the expressiveness of dynamic languages but with runtime performance similar to C++. Along with C++11/14, it greatly increases the elegance of many C++ code bases. Without LLVM, many of the use cases that are currently making C++ irreplaceable would be difficult to implement.

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.

LLVM and the runtime availability of LLVM translation is an added bonus.  Android and a lot of other systems are definitely becoming 
reliant on runtime compiling in big ways.

>> Python, it has pockets where it seems strong (math/HPC/ML), and other areas where it seems failed (client apps or web apps client or server).  There are various other niches.  But for the best architectural and technological ideas and tools, where is the momentum and acceleration going?
> Python is still incredibly strong as a scripting and analytics language, which is a pretty broad set of use cases. I run into it everywhere with no sign of slowing down. Nothing else is sufficiently better that I would expect it to take over. Not a terrible outcome, far worse languages have become de facto standards (e.g. Javascript).

Python's cool in some ways.  The indent thing still is annoying, and when I set out to do some serious development with it on OSX, I 
spent way too much time trying to get libraries installed with compatible versions in a way that any of my installed Pythons to use 
properly.  Otherwise, I don't have much against it but I only do little things with it.  I know pypy exists, but until the main 
engine has Javascript/Java competitive JIT, and it is predictably usable everywhere, I'm wary.

>> In 1998 or so, I had a Linux vs. BSD discussion with a friend who was a BSD contributor.  He was certain that BSD was better for various reasons, better security, TCP stack, etc.  Sure, probably is, I allowed, but it didn't matter: Linux had momentum and acceleration of that momentum that nothing was going to match. Various network effects of the people that count, openness of gathering and refining the best ideas, Linus driving, and companies left out of other avenues were converging around the right ideals, principles, and culture of common cause.
> The reasons were much more pragmatic and path dependent. Linux ultimately succeeded *because* BSD became the free server operating system of choice for the web because it was performant and bulletproof. Consequently, development of BSD was conservative because it was important that no one broke it. Like with most critical infrastructure software, you are limited in practice to incremental upgrades even when forklift upgrades would radically improve capabilities. You can’t risk breaking the code base. PostgreSQL is an example of a great code base that is chronically hamstrung by the necessity of incrementalism in the open source version.

Yes, *BSD made the same mistakes as Sun / Solaris, and VMS.
Redhat went down that path, addicted to corporate client money.  But Linux moved on anyway.  Ways to survive and eventually avoid 
constant breakage were key also, and the sheer will to fix things so breakage never lasted long.
> During those early years, Linux benefitted greatly from the HPC community using Linux as a test bed for a lot of experimentation with high-scale systems because it was possible to hack in some unusual or exotic capabilities without someone invoking the Precautionary Principle. Fast forward a decade and all systems start to look “high-scale”, at which point those capabilities were mature in Linux because they’d been there and hacked on for years.

That happened in every area.  Momentum and acceleration.  Safety third.


More information about the FoRK mailing list