10 ms·

That statement is just not true. Swift on Linux is more than ready and battle tested. I personally have ran a bunch of work with Swift on Linux already and comp

That statement is just not true. Swift on Linux is more than ready and battle tested. I personally have ran a bunch of work with Swift on Linux already and companies like Apple or Amazon are using it as well in production systems. 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.

fauigerzigerk 3y ago
In my experience, it depends a lot on the sort of libraries you need. The library ecosystem is still relatively small and client centric. Swift can be a fast language (if you avoid reference counting) but many libraries are incredibly slow and clearly unsuitable for server-side use. 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.
boris 3y ago
> Swift on Linux already and companies like Apple or Amazon are using it as well in production systems. 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!
- mintybit 3y ago
  Amazon wrote a blog post about it and they are also part of the Swift on Server workgroup. https://aws.amazon.com/blogs/opensource/continuous-delivery-server-side-swift-aws/ https://aws.amazon.com/blogs/opensource/continuous-delivery-... 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.

fauigerzigerk 3y ago

In my experience, it depends a lot on the sort of libraries you need. The library ecosystem is still relatively small and client centric. Swift can be a fast language (if you avoid reference counting) but many libraries are incredibly slow and clearly unsuitable for server-side use. 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.

boris 3y ago

> Swift on Linux already and companies like Apple or Amazon are using it as well in production systems. 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!

mintybit 3y ago
Amazon wrote a blog post about it and they are also part of the Swift on Server workgroup. https://aws.amazon.com/blogs/opensource/continuous-delivery-server-side-swift-aws/ https://aws.amazon.com/blogs/opensource/continuous-delivery-... 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.