Kem did a feature request for True Multi-Core Threads at Xojo: Account Login. I mean, yeah, it’s something we could all use at some point or the other but since Workers were their ‘answer’ to the issue, and that they don’t have a dedicated compiler engineer, I just don’t see it happening.
Maybe they’ll get to it when Android and iOS are merged into Mobile and they’re no longer using Win32 controls. Not holding my breath.
Kem cited Go, Rust, Kotlin, or Erlang/Elixir but those are all newer languages that started with concurrency in mind. I just don’t see Xojo doing the heavy lifting for it.
For years now performance scaling has had to rely more and more on leveraging more cores rather than higher clock speeds. Plus it has become more important because of the need to make multiple RPCs of varying response times / latencies … it can be absolutely critical to optimizing throughput in some workflows.
I have been avoiding threads like the plague in my work, because it does make things more complicated. But I can get away with it similar to how Xojo is trying to, by having independent worker machines processing requests. At MegaCorp, we had scaled up to 3 of those and that has been adequate to keep up with heavy processing days. But our loads were quite predictable and the work queue was less “keep up with 10,000 requests per second” and more “never have more than about an hour’s backlog of unprocessed files on a busy day”.
So it’s not like workers are useless or unwelcome … they just aren’t the answer to every bottleneck. Any product without a way to leverage multiple cores or time-sliced threads is going to be a show-stopper for standing up certain kinds of large-scale / high-volume services and it will limit relying on pure Xojo solutions for large and important classes of problems.
Given the abstractions and syntax sugar in C# and some other languages to support such true threading, I think it is something Xojo has to deflect from and dance around as it represents a lot of labor invested just to keep the product viable as a general purpose tool for professional developers.
The in-house Xojo app I built is just intended for a handful of people to use on the desktop and it works fine for that. But not dramatically faster to develop with than, say, WinForms, either. And if I needed to make a few async calls from a WinForms app I could do that, but not in Xojo. So if I want an ops dashboard in my new gig it won’t be built in Xojo.
For the HDR application, I wrote a dylib in Objective-C (using GCD) and I was pretty shocked at how easy it was, the dylib then executed the task in 1/7th of the time the Xojo code took (on an 8 core system).
Even if I replicated this work with “Workers” it would be much slower as I’d need to punt 128-BPP data into shared memory and then back again once completed. We’re talking GB of pixel data, and I’d have to use Declares (don’t say you can do it with my plugin) to handle the shared memory as Xojo refuse to implement native support for shared memory. I even gave them the source code for Sandbox safe shared memory, so they could implement it quicker.
Its not just about the only 2 people can use it now, it’s about retaining your advocates and letting them help you with marketing. If a developer is happy with the tool of choice, they write about it, they write tutorials, they let others know what things they can do with the tool. People researching the tool, find those articles/tutorials on line and it gives them confidence in the tool, it also helps newbie strengthen their decision in said tool, helping them to become advocates for the product also.
The opposite can be said, if a Xojo dev writes about having to use another tool to get their app to adopt concurrency because Xojo’s solution is too under-designed, this influences people researching the tool. If a Xojo customer is getting fed up fighting their system, it can help cement their decision to move to a different tool. It makes Xojo look like they don’t give a shit about developers who want to do something more complicated than a FileMaker style app…
In one of my in-depth reviews of Xojo many years ago I cited lack of “workers” as an easy add to assist. I think its a good option but pales in comparison to true parallelism.
Go does make it easier but there can still be challenges with it outside the simplest examples. When you are targeting hobbyist “citizen developers” talking to them about goroutines and channel messaging is probably out of scope.
it’s too late now away… Even if they started now (and they would very likely need to hire expertise they don’t have these days), it would likely be at least 5 to 10 years before they had it in truly usable shape… and the world will have evolved further.