Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust.
I really want to like Rust more, but the library support, and the jobs in my area just aren't there (yet?).
Picking up Kotlin feels like coming home.
Just to be clear, my reasons stated above is why I'm moving to Kotlin. I make no claim that other people should or would want the same things. I've realised that I like languages with explicit strict typing, and that allow for a greater level of expressiveness at the cost of a higher intrinsic complexity and the comprehension that requires.
Kotlin also feels like a pretty safe bet since both Google & Jetbrains are backing it.
By operating as a non-threaded application, entire categories of bugs and security holes are avoided.
Are there situations where threads could genuinely help? Sure, there is always an exception to any rule, but for the vast majority of projects where PHP is used, I don't believe threading would achieve much in terms of performance gains.
The first example in that article even highlights that `in_array` has a `$strict` parameter.
I'd bet a months salary it's easier to teach developers to use strict comparisons (either through arguments to be passed, or strict operators to be used) than it is to teach developers how to avoid thread-safety bugs.
Though, it might take longer to train them to spot every place where they could/should be using some stricter version of the defaults. That's the problem with opt-in safety.
On the other hand, there are languages that make thread-safety bugs much less likely. Some day those ecosystems will catch up to the languages that have been around "forever" and we'll get our cake and eat it, too.
I don't recall ever seeing any kind of dev tooling that can just automatically fix thread safety issues.
The shenanigans that WP plugin devs go through to get around the lack of a queue is ridiculous (chunk the file and keep reloading the page until we’ve processed all the chunks or have an Ajax endpoint that processes a chunk at a time...) and the when I asked a marketing friend of mine who works with Wordpress he said that redis is an “advanced requirement” and I should keep things simple.
In Django land I’ve always set up queues even just to send emails because it keeps things snappy.
What solution would you prefer for this kind of jobs? launching a new thread directly? or have a worker project always running and send to it the job directly?
Using Wordpress (or it's plugins) as any kind of reference for what PHP is capable of, is like using McDonalds as the basis for a cook book.
The example was where each SQS call (there could be as many as five) was taking between 50ms-200ms, and logging took another 75ms. The rest of the request processing time was approx 50ms.
There's a bunch of other architecture options we could have looked at, but due to the share-nothing nature of PHP, they weren't an option.
Arguably the same problem would exist in other languages, but at least there we would have had the option of using threads, and we could have executed multiple calls to SQS in parallel. Probably not something I'd want to do all the time, but it would be nice to have had that option in this case.
Callbacks are not how you do non-blocking IO. You typically have multiple threads and use constructs like futures or promises to make them easy to manage.
PHP bakes you into a very simple request flow. There's so much more you can build if you get out of that manner of thinking.
Edit: FYI I have experience with other languages too, so if at my work I use PHP does not imply that I am some inexperienced person that has no idea how other languages work. I do not have experience with your domain of high concurrency, low latency stuff but I worked with threads, and thread pools and multi-processes programs(it happened that some thread would segfault and bring the app down so we had to use background processes instead of threads) .
You can defined what types/interfaces methods needs to return, what types/interfaces variables must have, what types/interfaces the method arguments needs to have.
It also supports class inheritance, abstract classes, interface classes, class traits, etc.
If PHP hadn't made advances in it's type system with the 7.x series, I probably would not have stuck with it this long.
However, while PHP the language supports strict typing, it does it at run time (inherently a limitation of scripted languages, I know), rather than compile time.
That is probably never going to happen. GraalVM native images are a more realistic approach in this space, and even that is not trivial in most cases.
Not saying Elixir is the answer to everything but that's where it differs in the concurrency sector. It doesn't have static typing though, which is a requirement for some.