What is something inside of Laravel that is used extensively that you would want to see used more often in other projects? I.e. helper functions, Collections, Eloquent, etc.

"Stating that one is the worst programmer alive if not knowing or seeing the difference is downright harsh." But true. It isn't as if this is some weird PHP specific thing, it's true of every major language: Python, JavaScript, Ruby, C++, Java, etc. Whether they call them hashmaps, dicts, key-value pairs, etc. It's even weirder when a guy has "Hardcore JavaScript Dev" as his tagline and he complains about non-static types. JavaScript has the buggiest types in programming, the entire "WTFJavaScript" is all about how bad the type-conversion system is. PHP 7 adds full type-hinting for scalar types, but just like JavaScript, you have options like TypeScript to get around that limitation if you need it for older projects, (it's still not native to JavaScript, unlike PHP). In fact, every last complain he has can be applied back to JavaScript, so how "hardcore" a dev he is in JavaScript when he doesn't recognize the problems of his own language choice. It looks to me like the typical "I went to google and typed in 'Why PHP sucks' and pasted the result" problem. "And besides, it being a difficult language" Well I think that's the issue, it's not a difficult language. It's an easy language, just like JavaScript, this really irks some people. Languages (or really frameworks) like Ruby on Rails require knowing about MVC architecture, ORMs, Active Record, Database Migrations, Seeding, Factories, Unit Tests, and a whole host of other factors before you can even get started. PHP just lets you go, with no real structure. It's up to you to supply it. It's why Laravel has become so popular because it's taken the best parts of PHP, abstracted the worst parts, and wrapped it in a framework that can be easily extended. Also, Jeffrey Way is an exceptional teacher and Laracasts has helped tremendously at popularizing the framework. PHP is a "Leatherman" language, a language that's not specialized for any particular thing, but generally good at most things. For most businesses that are scaling, they have specialized needs. It's why Twitter left Ruby on Rails for Scala, Scala is designed for the problems that Twitter faces. Erlang might be a good choice for other companies, but when you get to the point where your business needs to scale like that, you'll know.

I think we'd all love it, but I remember several talks with engineers and they all said that this would be a nightmare for performance.

One computer science guru put it this way, paraphrasing. "Anyone can build a dog house. And a cathedral is really just a gigantic dog house. So you build your cathedral and it collapses, because the more you scale something, the more architecture becomes more important than process. You can either then go learn sound architecture or pretend the collapsing building was the desired result." This is not entirely true, as I've worked on projects with unsound architecture before and what usually happens is that instead of collapsing, a gigantic wooden beam gets propped up to support the cathedral from collapsing. Except it gets in the way, so now you have to build around that gigantic protrusion, making any new additions to the cathedral take much longer than it should. Over time, more and more of these protrusions and add-ons and workarounds get tacked on, until even the most minor change involves navigating over a land-mine of bad choices and bad architecture, slowing any new development to a crawl. When something is properly scaled and architectured out, adding new features is easy because the system is designed to scale. Since the goal of software development is to solve problems using software, proper architecture is about learning how to solve larger problems in a shorter amount of time.

There is no one size fits all answer to this question, but this seems to be going about things the wrong way. "Premature optimization is the root of all evil." How exactly do you know that query caching is the bottleneck of your application, as opposed to not using a queue for processing requests? Redis is best used as an application caching system and not a database caching system. When you think about it, you'll understand why. If you want to cache queries, you need to know when they were last updated. Otherwise, you're not implementing anything other than a guessing system. "I guess I should delete this particular query cache every 24 hours." Well, what if your customer logs in immediately the first time, then changes their information in Userdetails? They have to wait 24 hours to see it updated. They'd assume your system or application is broken. How else could you go about it? Well, you could do something like have a timestamp on Userdetails for something like "Last Modified". You'll see this in most Laravel and Rails apps that each data table has a last modified property. Perform the query, check the last modified against the value you have for it in Redis, and then either execute the query or use Redis to serve up a cached version. Did you catch the problem there? You're still performing the query. Without running a new query or checking the query cache, you don't know whether or not you're serving stale data. The performance boost is going to be minimal. You can even introduce new bugs into the system like this: http://en.wikipedia.org/wiki/Cache_stampede You can implement a less naive caching system by caching things that are always going to be the same, e.g. cache a query like "SELECT * FROM comments where id = 1", since the id is unique. Still, same problem occurs if the comment is updated, you're serving stale data. Instead, for parts of your system that require less latency replace MySQL with Redis, MongoDB, or another NoSQL system. This is a lot less headache to implement effectively. You should also look at questions like whether or not you should set up a replication server to perform most of your reads, using a queue effectively like Resque (which is Redis backed), and so forth.

Java didn't have support for many of JavaScripts native features like lambdas, reduce, map, filter, etc. until Java 8. As far as one language copying another, if an idea is good, then who cares which language "invented" it.

"Extremely difficult to manage as it not very modular. " Use Composer. "PHP is interpreted, hence PHP websites are slow unless proper caching management is implemented." Opcache is native, it's only byte-compiled the first time. "PHP is not strongly typed" Use Hack: https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/ You can use SPL_Types, compile from Zephir, or which gives you native code speed. Even natively, you can type-hint arrays and objects when using classes, only scalar values can't be type-hinted (natively). I'd prefer it if PHP were duck-typed, but that's a limitation. "No multi-threading" http://php.net/manual/en/book.pcntl.php That would surprise people who've actually used the language, which it's obvious, you haven't. "No background threads or asynchronous execution of jobs" This could be a point if you're using Node as it's the only language that really supports async, but the way most people deal with this is to use RabbitMQ or another enquement system. "Some of the PHP functions are horror like eval" I've never seen it in source code anywhere except when writing simple command line scripts that require evaluating a string and the docs tell you not to use it in production code. So pointing it out seems useless. "Confusion between objects and associative arrays" You are the worst programmer alive if you don't understand the difference. It's also obvious you've never programmed in PHP, so stop.

Node, Python, Rails, Go, etc. are languages optimized for doing one thing. Rails is optimized for rapid prototyping, but it runs like garbage on production servers. Node is also optimized for rapid prototyping, but it has the one great trick of being exceptionally fast for multi-user real-time data situations. It's terrible at heavy processing tasks, but you can enqueue it using RabbitMQ, Resque, or some other system and pass it off to another programming language to do that portion of heavy-lifting. Just like we're seeing more apps with hybrid SQL/NoSQL sections, we'll be seeing more hybrid apps where different languages are utilized based upon what they're good at rather than having one language overall that does everything. These are all web-app languages, not what you'd typically build a desktop application on. Java is not optimized for anything, it's a general purpose language designed mostly to be cross-platform across Windows, Macs, and Linux AND provide a visual GUI components. This is better than languages like C++ which doesn't have a GUI component and has to rely upon various plug-ins and extra libraries to do that, (same is true of Python as well). The question is, "Will we need a cross-platform programming language capable of giving users consistent graphic elements?" and if the answer to that is yes, we'll still have Java.