lod723

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.

That didn't answer the question.

Concurring with sibling comments, last week I had a Lyft driver who was using that feature because she was ending her shift.

You mean Norway is the Canada of the EU?

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.

Safari's JS engine is different than Chrome's though, no?

SPARC does speculative execution, so it would be vulnerable to Spectre too.

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.

Just speculating, but maybe it's because Google, Facebook, and Amazon have a tech presence in Austin and not in the other 3 metros you mentioned?

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 can think of a couple trivial ways to express this in Erlang/Elixir. You should take a look at them.

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.

Will take a look! There really should be more ecosystems that try to solve modern problems effectively.

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.

Yeah, this is important. Therapist-client privilege has a specific legal definition, and it'd be very bad to loophole that away due to some inadvertent implementation detail.

It's possible however that some juniors may take longer to reach their full potential, or perhaps never reach it at all in a remote environment. Also juniors may not have the self-introspection to perceive that the environment is not working out for them, and rather feel discouraged about their ability.

Pulling off that balance is extremely hard to implement in practice though. Usually it swings heavily one direction or the other, so one group is marginalized.

I experience regular UI glitches and occasional full app hangs that require a force kill to reset, the latter most notably in poor connectivity situations like the subway. It's not terrible, it's just not that good either. It's tier-2 app quality with a tier-1 size userbase.

People are more tolerant of buggy and/or slow tech if said tech might increase their chances of getting laid. A more direct example is Tinder and other dating apps like it: the quality of those apps are somewhat lower than others with similar popularity, but people just deal with it anyway.