I must say I am not a fan of this decision. FDB looked like a promising solution but not if it is tied to a niche language.
I must say I am not a fan of this decision. FDB looked like a promising solution but not if it is tied to a niche language.
Also, it might be niche on the backend, but it's definitely not niche overall.
> Also, it might be niche on the backend, but it's definitely not niche overall.
I think it's safe to say it will always be a niche language on Linux, which is what matters here.
Here is recent report of trying Swift on a non-Mac OS platform, it's pretty damning:
https://flak.tedunangst.com/post/an-aborted-experiment-with-...
Personally the great thing about Swift is that it brings the performance of a C like language but compared to Rust has way better ergonomics.
Of course there are some problems that need solving like the foundation stuff but it got a whole lot better in the recent years.
For instance, I recently needed reasonably fast JSON and CSV parsers with predictable memory usage for incrementally parsing potentially large files. The libraries I found were either too slow or clearly written for client side use cases like mapping a few kilobytes of config files to objects in memory. I ended up writing my own, which was absolutely not what I wanted to spend my time on.
The upside is that Swift's C interop is excellent and now it's even getting C++ interop. So one way around library issues is using Swift like Python, as a thin layer on top of C. But as this FoundationDB talk shows, no one is really happy with this state of affairs.
I think server-side and cross-platform Swift is moving ahead at pace. Things will be looking lot brighter in two or three years.
Hm, any citations on the latter? That is, companies like Apple and Amazon using Swift in production systems on Linux, especially for something similar to FDB? Thanks!
Apple is always careful with their statements but at the last Swift Server conference they had a talk where they outlined some of their usages.