3 ms·

It may be improving but it's not there yet, let alone battle-tested with years of production use in serious applications on Linux. And we are talking about a di

by boris 3y ago

It may be improving but it's not there yet, let alone battle-tested with years of production use in serious applications on Linux. And we are talking about a distributed database here, where a bug can very well lead to it eating your data. Imagine PostgreSQL developers decided that, say, Zig will be their successor language. We would rightfully call them insane, no? > 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-server-swift https://flak.tedunangst.com/post/an-aborted-experiment-with-...

mintybit 3y ago
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.
georgelyon 3y ago
The great thing about FDB is that they have a testing infrastructure that is unlike any other database: https://m.youtube.com/watch?v=4fFDFbi3toc https://m.youtube.com/watch?v=4fFDFbi3toc If there is a Swift compiler bug that causes data loss I will bet money they will catch it (I will also bet they will find at least one Swift compiler bug)

by boris 3y ago

mintybit 3y ago

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.

georgelyon 3y ago

The great thing about FDB is that they have a testing infrastructure that is unlike any other database: https://m.youtube.com/watch?v=4fFDFbi3toc https://m.youtube.com/watch?v=4fFDFbi3toc If there is a Swift compiler bug that causes data loss I will bet money they will catch it (I will also bet they will find at least one Swift compiler bug)