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.
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.
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?
{
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.Maybe "deterministic"?
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.
Rust: "statically memory managed" Java, Go: "dynamically memory managed"
Similar to: "statically typed" or "dynamically typed"
Rails, for that matter, is known for being easy to produce multi-second pages too.
Slow languages are slow in practice, too.
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.