Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent

[Dicebot via Digitalmars-d]

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.