On Sunday, 22 November 2015 at 08:00:51 UTC, deadalnix wrote:
Erlang makes state terrible to work with (but doesn't bound
state to a request). PHP has request local state. The model is
very different. One of these models is way easier to work with.
I see the point but it is quite subjective/arguable. If one wants
to go for scalability model with discardable requests context
there is a lot of merit in not having any locally stored state at
all.
I also didn't went into this as it was irrelevant to the
scaling argument, but having rapid iteration is key, especially
for UI work where automation is hard. Erlang doesn't fit the
bill.
No objections here but it is indeed irrelevant to scaling in any
sense.
Last but not least, Erlang has a foreign syntax, so ramping up
devs is harder.
It is also quite true and irrelevant to scaling statement. Though
I'd expect Facebook to have less trouble with it considering the
famous hiring standards.
Back on PHP, there are many other aspects of the siloed
requests model that provide benefits that erlang simply cannot
provide.
Probably, though wording "simply cannot" is very rare to be true.
But it is also true the other way around - in PHP it rather hard
to get transparent messaging between services (decoupled from
underlying physical server layout) and I will call that more
important for scaling than all of your points combined.
Reimplementing main points from abovementioned list (primarily
isolation and request-local allocators) can be done with
pretty much any decent language and potentially save huge
amount of money on server costs.
Well one can recode the runtime to get these behaviors. Or one
can focus on delivering value to customers.
Recode runtime? Most of stuff you mention is provided for free by
simply using CGI model :) Using vibe.d processes in single thread
mode with external load balancer provides system with similar
benefits and better performance/maintainability - right here and
now. Apart from COW bit of course, but that is one I completely
disagree with as beneficial at all.
And D isn't any special here. You describe one specific (not even
necessarily as scalable as you claim) approach to service
architecture and call it inherent property of a language (and
pretty much a killing feature). That is absurd.
Scaling implies not only being able to increase the load
without system redesign but also doing it efficiently - both
in server and maintenance costs. PHP is rather bad at both.
No, performance, efficiency and scalability are disjoint
things. Scalability is about how much more resource are needed
to serve how much more requests.
Yes, and if absolute amount of resources is too costly, it
doesn't matter if relative increase is linear. It like having
algorithm with good complexity but huge constant - theoretically
it scales but in practice you want better.
Maintenance costs are directly related though - developer
resource also counts when measuring the increase. Because of that
one can't ignore problematic parts of PHP as a language itself
when talking scalabiliy. If it can't survive business logic
increase, being able to survive request count increase only helps
so much.
There are good plateforms that come with shit language out
there. We have a good language with a shit plateform (let's be
honest one second). Facts show that 1/ win over 2/ 100% of the
time.
Writing how bad 1/ is in the 2/ forum is simply an exercise in
finding excuses to not look where it is ugly.
I'm living in the real world, where at least half or the
request you make to a webserver are handled by PHP. Arguments
are cheap when facts refuse to match.
And this is what struck me as unpleasantly surprising in your
comments on topic. You take social factors (getting the momentum,
gathering large stable community) and derived beneficial factors
(good tooling, good platforms, lot of out of the box solutions)
and proceed to use it as a backing argument to mostly technical
statement ("PHP (as a language) scales"), casually accusing
everyone of being stupid in process. Like, WTF?
One can also say that PHP is easy language to start with which
got in right place in right time with good vision. That
contribution snowball effect resulted in having very good
platform and collective wisdom, as well as solid developer pool.
That it outshines all commonly called technical flaws and,
together with convenient common request processing model, can
make it feasible decision for scalable systems if one can afford
it.
But going straight to "PHP scales, suck it" and backing it by
"hey, Facebook uses it"? That is missing important context at
best.
