Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
Dicebot via Digitalmars-d
digitalmars-d at puremagic.com
Sun Nov 22 02:58:31 PST 2015
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
> 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
No objections here but it is indeed irrelevant to scaling in any
> 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
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
> 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
> 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
But going straight to "PHP scales, suck it" and backing it by
"hey, Facebook uses it"? That is missing important context at
More information about the Digitalmars-d