> PHP pages that take two or three full seconds to render
I don't use php personally, but most of my rails apps render full pages in under 100ms. I'd imagine php performance to be at least on-par with a full rails app.
Once you start seeing hundreds or thousands of requests coming in per second and you see your cpu utilization sky rocket, then the "slowness" of the interpreted languages really comes into full play. Most apps/websites will never achieve this kind of load or scale though.
> interpreted languages really comes into full play.
There are plenty of non-interpreted languages that don't require GC though. When you pick Rust you are picking manual memory management. Does even Google opt for non-GCed languages for their web servers?
We've been having a debate lately, within Rust, if "manual" is really the right term here.
{
let x = Box::new(5); // malloc
} // free
Is this really _manual_? In a sense it is, but it's very different than what most people think about. "Automatic" is kind of a good word, but Objective-C/Swift's "ARC" already covers that, and we don't do refcounting, so that could be misleading too.
"RAII" seems to cover it nicely, and extends beyond memory management to other resources. Admittedly it's not a very friendly term for non-C++ programmers.
What's this non-lexical borrowing idea you mentioned in your other comment? (I can't reply there for some reason.) Is there an RFC for that?
There hasn't been an RFC yet, because we're in the middle of a large amount of compiler internals work (HIR/MIR), which will make overall analysis easier, including these two features.
> (I can't reply there for some reason.)
HN limits responses based on the depth of the comment tree and the length of time since the comment was posted, to discourage flamewars, you can always click on a comment link directly to kind of bypass that though.
Borrows may be non-lexical in the future, but deallocation via ownership will always be at the end of a lexical scope. Not only would eager deallocation be bad for performance, it's also a backcompat hazard at this point.
Statically memory managed already has a meaning. It means that there is no malloc during runtime, all memory addresses are decided (usually manually) beforehand and written into the executable.
I'm thinking Wordpress, or bespoke status pages for internal apps. Of course you can get a PHP page out in under a millisecond if you try hard enough, but it's often not used in that sort of place. (And it often is, but that still doesn't mean it often isn't.)
Rails, for that matter, is known for being easy to produce multi-second pages too.
It actually amazes me that people find the statement that slow languages are actually slow offensive and worthy of downvoting. As I said, it is my experience that simply switching from slow to fast languages even on "IO dominated" workloads has real, visible effects.
If you haven't tried it, consider trying it before becoming offended at the idea that your tool may not be appropriate for all use cases. Yes, it can matter when your language is 50 times slower than another.