pencilhappen

Dropbox's core product is trying to tack on P to CA systems. The CAP theorem explains how well this will actually work out. It's good they raised a bunch of cash, because they need to diversify their product base beyond that confused core. Time will tell if they do or not. Currently, I do not view them as a good long term investment.

Not my tweet, but so so relevant:

https://twitter.com/littleidea/status/532927711472549888

Node is adequate at async, but not excellent. As I said in a sibling comment, things that are synchronous still, like GC, make it fall down at scale. Isomorphic JS isn't that useful in most real situations.

My point about Scala is that there doesn't seem to be a clear cut niche that it excels at. There are numerous other non-Java languages that run on the JVM that could be in the running, and they all get to take advantages of the whole Java ecosystem too.

Node isn't great at async, despite the hype. Important things are still synchronous, most notably the GC, so you can very easily wind up with service stalls at scale. The module churn in Node land means that few things are actually battle tested.

BEAM languages are the sweet spot for concurrency right now.

> Each language has special strengths and weaknesses, there is no silver bullet that excels at everything. Go, C/C++, Lua, Ruby, Perl, Scala, Node.js, Python... each of these are THE best choice for certain classes of problems (and terrible for others).

Not quite true... not all languages have a sweet spot in a production environment. Node.js isn't particularly excellent at anything, the attraction is mainly "I know JS, and I don't want to learn anything else right now", which is a terrible attitude for someone who wants to have a career in tech. Knowing more than one tool in the toolbox is a key skill, since there is no one-size-fits-all.

Jury is still out on Scala. It's a big language, but unclear if there's a production sweet spot or not compared to other JVM hosted languages.

The rest of the ones you listed have their definite sweet spots. There are tons of languages though, and most don't have one.

This sort of anecdata always crops up on airline threads. Flight experience can vary pretty wildly by airline, even on the same type of plane, since the interior layout and amenities are up to the airline, and not the plane manufacturer.

The best long haul experience I've had in recent years was on a Singapore Airlines A380. The worst one in the same timeframe was on a British Airways A380. Both times economy class.

I've been on a 787 on a few different carriers and they've all been pretty nice.

What's funny is the article says this about the Navier-Stokes equations: "The equations work. They describe fluid flows as reliably as Newton’s equations predict the future positions of the planets"

Newton's equations do not in fact reliably predict Mercury's orbit, and it took GR to do it. Lazy journalist!

> but the recent years brought quite some progress. Go makes it easy ...

It actually feels like the recent years have been pretty disappointing. Go is one of the few places where the language developers are making a real effort around multicore. Erlang came with a bunch of opinions about how to do this in the 90s.

But every other mainstream language is taking a head-in-the-sand attitude about this. Python squandered their backwards compatibility break without addressing this at all. The JVM developers are making no effort to get away from the global heap. Ruby and Node are completely ignoring it entirely. PHP from it's request/response web history actually does well, except its non-web story is as dismal as ever. Lua has coroutines, which are a reasonable abstraction, but no multicore VM story...

> Parallel Universe's Quasar is basically OTP for Java, so I know logically that Java is basically a superset of Erlang at this point

It's not really a superset. The JVM has a single global heap, whereas BEAM has per-process heaps. Global state is the enemy of concurrency, and the best GC algorithm is one you don't need to run at all. The "several hundred millisecond HTTP response latency and horde (sic) memory" problems you note are in part a result of having a global heap.

A thread pool is far from "ergonomic", it's accidental complexity with numerous gotchas.

async/await still has the fundamental problem of composability that all the other attempts at sugaring around an event loop have (aka the "functions have colors" problem [1]). It sucks for collaboration, which is one of the most important things for modern software development.

1. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Thank you for articulating what was behind the Mossberg phenomenon in a positive way. An anecdote:

About a decade ago, I was working at a startup. The VP of Marketing got it into his head that we just had to get Mossberg to write about us and it'd be great for user acquisition. We had a bunch of meetings and shuffled and reprioritized the product roadmap around this. I'd actually not heard of Mossberg before, as my prior experience was at a BigCo selling to enterprise, a market where Mossberg was essentially irrelevant. So I went and read a few of his past columns, and felt that the quality of insights was all over the place, ranging the whole gamut from good to middling to bad. At this point I was wondering in my head "Why is this guy so special? Who crowned him this way? Why are we doing contortions to attempt to please him?"

Our strategy did work, insasmuch as Mossberg wound up writing a glowing column about us. However, this did nothing to do move the needle at all with regards to user acquisition, and likely was a distraction and misallocation of resources that negatively impacted finding market fit. This left me with a bad taste about Mossberg, as clearly whatever his tastes were didn't fit the market very well. The review might have helped us if we were raising a series A or B, but we were in C territory by then, which is when investors actually look to see if you have a viable business rather than responding to hype and FOMO.

In retrospect now, after reading your comment, the bad taste I felt was really about our VP of Marketing, who was chasing a prize that in the end didn't help the business. Said VP was ineffective in other ways, and this was just one symptom of his ineffectiveness. Mossberg was just playing the cards he was dealt in life effectively, and as you said, who wouldn't?