11–20 of 318 posts
I love to focus my energy on building a great frontend with React or Vue.
Modern websites in big companies require pretty complex backends that require data processing queues and other background activities. Can PHP compete with languages such as Go, Python or Ruby in the future?
Enums with functions. WTF
Can you give a reason why we should not have them?
I was a php developer for some time two years ago, before switching to go. I was mainly solving high performance parallel processing and distributed problems. There are things like ReactPHP which are an awesome achievement, but still every lib you use needs to be developed for ReactPHP. After learning about go and goroutines I only find it painful to solve these problems in PHP, even using ReactPHP.
So you switched from a language X not designed to do Q to a language Y designed to do Q, presumably because language Y didn't exist when you started doing Q. I imagine that happens all the time, but seldom is it a fault of X. But what I find puzzling is why PHP, of all things, was your choice for these kinds of problems before Go appeared.
PHP is my go to language for building simple backends that store data as json in a file and synchronize access using flock(...). There are a ton of cheap hosting providers that support PHP and all you have do to is copy your files over and everything works. I love to focus my energy on building a great frontend with React or Vue.
Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…
Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…
1. Low barrier to entry;
2. Hard to leak resources since the model is to tear down everything after a request finishes;
3. Stateless API core which means the efforts of creating an environment for a request for (2) is extremely low. Compare this to, say, the bootstrap time for Python or Java (which is why those generally don't follow the request teardown model);
4. Almost no multithreading.
This makes it great for servicing HTTP requests IMHO.
I need to compare it to Hack/HHVM though since I used that for years and it's still playing catch up with features Hack has had for years eg:
1. Hack has had the async-await model for years;
2. The type system is actually really good. It made me appreciate how nullability being part of the type system is incredibly useful. Plus it's had generics for years; and
3. Better inbuilt collection types with less odd coercion behaviour (ie dict, keyset, vec).
I find PHP hate in 2022 to be tired. Look at something like Laravel and PHP is completely fine. The sins of the past and even the odd inconsistencies still left in the language (eg needle and haystack param ordering) don't really matter.