Having a bad rap inside the tech bubble affects them in relation to recruiting and retention though. If the tech zeitgeist turns against Facebook as a "cool place to work" that's pretty bad news for them.
It's worth posting the long version. I've been following the various Pony blog posts with interest (I'm a both language geek and a distributed systems geek), but I always come away with the notion "Huh, kinda cool, but why didn't they just use Erlang, it'd be a great fit for this".
So either:
a) Erlang is not a good fit, and I'm wrong. Then I'd really like to know why I'm wrong!
b) Your friends at Basho led you astray. Would also be interesting to know what happened in this case!
Either way, without knowing more details, the short version you just posted is inconsistent with the claim that you guys did serious research into existing language ecosystems before going your own way.
I've read that blog post and some of your other posts on HN. I get why the JVM, C/C++, and Go were not fits. However, I have not seen a lucid explanation of why you didn't go with Erlang or Elixir.
Java and C# incur more much more developer complexity for web development than Phoenix.
And as the the sibling comment points out, raw CPU performance isn't the only measure of efficiency. The JVM loves to eat memory, and if you get 100x CPU efficiency but use 10x the RAM, you're still bounded on machine resource usage by that memory usage.
For an improvement of 2 orders of magnitude while maintaining the same level of developer complexity, I'm hard pressed to think of any other web framework besides Phoenix that can deliver this.
No, because the JVM currently lacks features to truly isolate threads of execution, which is important for both performance and reliability. AFAIK, the JVM folk aren't even talking about addressing this, which is disappointing.
You realize that this sounds like more of the same hype to anyone who was burned by the overpromising in the 1.x and 2.x days? Whether your statement about 3.x is true or not, the MongoDB people dug their own hole that they need to try extra hard to get out of, and so far it's not enough.
I think he got it right. Mossberg was one amongst a number of everyman tech columnists for a while, but Jobs really elevated him once Apple got popular.
You left out Millbrae. I don't think the grandposter tried very hard. There's definitely a number of proper Chinese places in that corridor, but the average ones do suck. That or the in-laws are looking for a specific region in China that isn't well represented in the bay.
There's a reasonable argument to be made that Chinese food in the San Gabriel Valley in LA is better than in China, since you can find a large number of regional cuisines all in one place, and the raw ingredient quality is higher when compared to mainland China.
The JVM has the same global heap problem as Node... it's frustrating that with all the development that goes into the JVM this problem remains unaddressed.
The multiprocess Node concurrency model is brittle and fault intolerant. The event loop scan actually has real bottlenecks at a certain level of fds in flight. A real scheduler really wins here; libuv sits below the knowledge of the runtime to really be optimal. You become CPU bound far sooner than you expect.
With a global heap, you also become memory bound far sooner than you expect as well.
> Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language.
FYI, anyone who has worked with Elixir or Erlang views these sort of statements about Node as completely ridiculous. The only languages right now that are making a serious effort to bring real concurrency to modern programming are Go and Elixir. Node with its single threadedness and global heap doesn't come close, since those are fundamental problems with JS. The papering over the defienct language concepts with attempts like promises don't address these issues at all.