4 ms·

Is there any recent rundown on the state of server-side Swift in general? I know there was a lot of discussion when IBM stopped working on it back in January.

Is there any recent rundown on the state of server-side Swift in general? I know there was a lot of discussion when IBM stopped working on it back in January. At the broadest level, I wonder what the footprint of Swift at runtime is, both in terms of CPU and RAM. I've been really enjoying Kotlin as a server-side language - it's a massive step up in productivity from TypeScript - but the overhead of the JVM certainly is notable, even in small personal projects (my small Javalin app uses four times the RAM at rest as my Express app did). Swift is really interesting to me because it is very similar in practice to Kotlin, but with some very cool and powerful additional language features. So, if server-side Swift has a smaller footprint at runtime and equal or better performance than Kotlin on the JVM[1], that'd be a really compelling language for me. [1] yes, I know GraalVM/native options exist for Kotlin, but every time I've tried to investigate ecosystem compatibility, it leads to me glancing at pages long-articles about "how to configure X framework for GraalVM" that make it not seem worth the effort yet

technics256 6y ago
What about Kotlin make it a step above typescript in terms of productivity?
- avolcano 6y ago
  This is a blog post I've been putting off writing for a while; I'll try to tl;dr it best I can given it's somewhat off-topic: * TypeScript's lack of runtime types and stable reflection APIs make it hard to have any guarantees of type soundness without either code generation (e.g. schemats) or complex type programming to convert a runtime representation of a type to a static type (e.g. io-ts). I find this very frustrating when doing web backend programming, where you are constantly doing i/o with external services (whether HTTP APIs, or input from client requests, or database interaction). This is particularly maddening because there's no de facto standards (seriously, there are a lot of these libraries: https://github.com/moltar/typescript-runtime-type-benchmarks https://github.com/moltar/typescript-runtime-type-benchmarks), so it's not easy to e.g. find a DB library that will let you define an io-ts schema that a query should match without re-wrapping things yourself. Basically: if TypeScript had runtime types, and an `as` cast threw an exception when a value doesn't match the specified type, I'd be much more inclined to keep using it. I genuinely think that's table stakes for a type safe language. (and lest you think this has to be how TS works given the nature of how it's compiled to vanilla JS, I suggest you take a peek at Sorbet, which knew this was necessary: https://sorbet.org/docs/runtime https://sorbet.org/docs/runtime) * The TS ecosystem is generally underwhelming. I don't think any HTTP framework for it is particularly good, nor any ORM/query builder. I think there are a lot of really neat experiments still happening in this space, and it seems like every day GitHub's little "explore repositories" sidebar shows me another cool library someone's built for TS trying to solve some of these problems, but it's all early stage stuff with a bus factor of 1 and a long todo list. To be fair, _Kotlin's_ ecosystem actually has a lot of these problems; the semi-official Jetbrains-maintained Kotlin web framework and DB access library both have a ton of untriaged issues and seemingly little production use. The good news is, at least on the server, you can completely ignore the "Kotlin" ecosystem in favor of the Java ecosystem, and this is _shockingly_ effective. Just about every JVM framework I've seen has some kind of officially-maintained Kotlin adapter, presumedly because it's not hard to sell Java developers on "what if you could keep using the exact same tools with a nicer language." These adapters aren't even needed, mind you, they just provide nicer APIs that can use Kotlin language features. Javalin + JDBI is infinitely nicer out of the box than trying to turn Express and Knex into a production-ready API with anything approaching type safety. * This isn't a make-or-break thing, but Kotlin is just generally _nicer_ than JS or TS in a lot of ways, while still having a very similar programming style. For example, the collection types are far more robust than something like Lodash (let alone the absolute joke that is the ES6 Map/Set API).
  - colinmorelli 6y ago
    I actually went back and forth with these exact same options recently. To the extent any of this is helpful: * Agreed with the problem, although I've found io-ts to be great. For incoming client requests: GraphQL is helpful if you're using that, but it's also relatively trivial to create an io-ts middleware for express that will get you similar guarantees. For database interaction, assuming you're talking about relational data stores, this is a challenge. Personally, I'm using Mikro ORM and it has been great so far. The one blessing here is that you're probably not dealing with unknown data types when talking to a data store, so it hasn't felt like as much of a concerning surface area for me personally. HTTP is valid, but I actually like io-ts as an approach here possibly more than using Jackson with static types due to its failure model - but again I acknowledge this is a personal choice. * I guess it depends on your needs here, but base express can be great for simple apps, and NestJS is fantastic for more complex ones. You're 100% on point with ORMs, though, where I've been incredibly dissatisfied generally. As mentioned above, I've recently stumbled on Mikro ORM which takes a unit of work pattern similar to Hibernate, without the painful startup time. You can tell it's not perfect, and certainly not as feature rich as Hibernate, but also feels safe enough. I imagine if you tried to do everything through the ORM it could get painful, but most of my apps are structured as multiple modules where each module only controls the entities within that module. It keeps the reach of the ORM limited and abstracted behind "services" (in the modular monolith sense, not remote services). * Yeah I see both ends of this one. Historically been a JVM user and have a ton of appreciation for it, but also like TS's approach more than Kotlin in several ways. You're right about collections though, ES6 is a joke there.
  - sicromoft 6y ago
    Strongly agreed. I'll add that Typescript in general just has way more rough edges than Kotlin, in part because the type system is way more complex (due to the dynamic nature of Javascript). And dealing with third party libraries is way more of a pain, since everything requires type stubs.
akmarinov 6y ago
Here’s a quick summary of things - https://www.timc.dev/posts/future-of-server-side-swift https://www.timc.dev/posts/future-of-server-side-swift
- WoodenChair 6y ago
  Blog posts that are time-relevant should really be dated.
oflannabhra 6y ago
Probably one of the best, recent overviews of Swift on the server is by Tim Condon [0]. TLDR: nightly Docker images of Swift, shared libs (Swift Crypto an example), more Linux distros supported, Amazon's 2.0 release of Smoke [1] (which is probably involved in this runtime), all indicate that Swift's future on the server is probably bright, even if it is still early. [0] - https://www.timc.dev/posts/future-of-server-side-swift https://www.timc.dev/posts/future-of-server-side-swift [1] - https://github.com/amzn/smoke-framework https://github.com/amzn/smoke-framework
albertop 6y ago
This one is very interesting and unexpected. Swift for TensorFlow: The Next-Generation Machine Learning Framework: https://www.youtube.com/watch?v=s65BigoMV_I https://www.youtube.com/watch?v=s65BigoMV_I
- mpfundstein 6y ago
  anyone using it yet?
  - sk0g 6y ago
    I would doubt it! Macs aren't sold with NVIDIA cards, so I'd guess the support for them would be poor, if available at all. I don't think Swift has full releases to Windows or Linux yet? Fast.ai and the likes have been investigating Swift too, so there's some momentum/ desire to switch to Swift.
    - pjmlp 6y ago
      I don't believe it will go anywhere, Fortran, C++, Python and Julia are what matters in GPGPU. Even Java and .NET have better support for CUDA than Swift ever will.
sdkjfhskjfh 6y ago
> my small Javalin app uses four times the RAM at rest as my Express app did Are you looking at used heap space or just the amount of memory used by the Java process? I have a few small Java services using vert.x and they hover around 7-15 MB of used heap space. For small services I usually just restrict the maximum heap space size because the default is unnecessarily large.

technics256 6y ago

What about Kotlin make it a step above typescript in terms of productivity?

avolcano 6y ago
This is a blog post I've been putting off writing for a while; I'll try to tl;dr it best I can given it's somewhat off-topic: * TypeScript's lack of runtime types and stable reflection APIs make it hard to have any guarantees of type soundness without either code generation (e.g. schemats) or complex type programming to convert a runtime representation of a type to a static type (e.g. io-ts). I find this very frustrating when doing web backend programming, where you are constantly doing i/o with external services (whether HTTP APIs, or input from client requests, or database interaction). This is particularly maddening because there's no de facto standards (seriously, there are a lot of these libraries: https://github.com/moltar/typescript-runtime-type-benchmarks https://github.com/moltar/typescript-runtime-type-benchmarks), so it's not easy to e.g. find a DB library that will let you define an io-ts schema that a query should match without re-wrapping things yourself. Basically: if TypeScript had runtime types, and an `as` cast threw an exception when a value doesn't match the specified type, I'd be much more inclined to keep using it. I genuinely think that's table stakes for a type safe language. (and lest you think this has to be how TS works given the nature of how it's compiled to vanilla JS, I suggest you take a peek at Sorbet, which knew this was necessary: https://sorbet.org/docs/runtime https://sorbet.org/docs/runtime) * The TS ecosystem is generally underwhelming. I don't think any HTTP framework for it is particularly good, nor any ORM/query builder. I think there are a lot of really neat experiments still happening in this space, and it seems like every day GitHub's little "explore repositories" sidebar shows me another cool library someone's built for TS trying to solve some of these problems, but it's all early stage stuff with a bus factor of 1 and a long todo list. To be fair, _Kotlin's_ ecosystem actually has a lot of these problems; the semi-official Jetbrains-maintained Kotlin web framework and DB access library both have a ton of untriaged issues and seemingly little production use. The good news is, at least on the server, you can completely ignore the "Kotlin" ecosystem in favor of the Java ecosystem, and this is _shockingly_ effective. Just about every JVM framework I've seen has some kind of officially-maintained Kotlin adapter, presumedly because it's not hard to sell Java developers on "what if you could keep using the exact same tools with a nicer language." These adapters aren't even needed, mind you, they just provide nicer APIs that can use Kotlin language features. Javalin + JDBI is infinitely nicer out of the box than trying to turn Express and Knex into a production-ready API with anything approaching type safety. * This isn't a make-or-break thing, but Kotlin is just generally _nicer_ than JS or TS in a lot of ways, while still having a very similar programming style. For example, the collection types are far more robust than something like Lodash (let alone the absolute joke that is the ES6 Map/Set API).
- colinmorelli 6y ago
  I actually went back and forth with these exact same options recently. To the extent any of this is helpful: * Agreed with the problem, although I've found io-ts to be great. For incoming client requests: GraphQL is helpful if you're using that, but it's also relatively trivial to create an io-ts middleware for express that will get you similar guarantees. For database interaction, assuming you're talking about relational data stores, this is a challenge. Personally, I'm using Mikro ORM and it has been great so far. The one blessing here is that you're probably not dealing with unknown data types when talking to a data store, so it hasn't felt like as much of a concerning surface area for me personally. HTTP is valid, but I actually like io-ts as an approach here possibly more than using Jackson with static types due to its failure model - but again I acknowledge this is a personal choice. * I guess it depends on your needs here, but base express can be great for simple apps, and NestJS is fantastic for more complex ones. You're 100% on point with ORMs, though, where I've been incredibly dissatisfied generally. As mentioned above, I've recently stumbled on Mikro ORM which takes a unit of work pattern similar to Hibernate, without the painful startup time. You can tell it's not perfect, and certainly not as feature rich as Hibernate, but also feels safe enough. I imagine if you tried to do everything through the ORM it could get painful, but most of my apps are structured as multiple modules where each module only controls the entities within that module. It keeps the reach of the ORM limited and abstracted behind "services" (in the modular monolith sense, not remote services). * Yeah I see both ends of this one. Historically been a JVM user and have a ton of appreciation for it, but also like TS's approach more than Kotlin in several ways. You're right about collections though, ES6 is a joke there.
- sicromoft 6y ago
  Strongly agreed. I'll add that Typescript in general just has way more rough edges than Kotlin, in part because the type system is way more complex (due to the dynamic nature of Javascript). And dealing with third party libraries is way more of a pain, since everything requires type stubs.

akmarinov 6y ago

Here’s a quick summary of things - https://www.timc.dev/posts/future-of-server-side-swift https://www.timc.dev/posts/future-of-server-side-swift

WoodenChair 6y ago
Blog posts that are time-relevant should really be dated.

oflannabhra 6y ago

Probably one of the best, recent overviews of Swift on the server is by Tim Condon [0]. TLDR: nightly Docker images of Swift, shared libs (Swift Crypto an example), more Linux distros supported, Amazon's 2.0 release of Smoke [1] (which is probably involved in this runtime), all indicate that Swift's future on the server is probably bright, even if it is still early. [0] - https://www.timc.dev/posts/future-of-server-side-swift https://www.timc.dev/posts/future-of-server-side-swift [1] - https://github.com/amzn/smoke-framework https://github.com/amzn/smoke-framework

albertop 6y ago

This one is very interesting and unexpected. Swift for TensorFlow: The Next-Generation Machine Learning Framework: https://www.youtube.com/watch?v=s65BigoMV_I https://www.youtube.com/watch?v=s65BigoMV_I

mpfundstein 6y ago
anyone using it yet?
- sk0g 6y ago
  I would doubt it! Macs aren't sold with NVIDIA cards, so I'd guess the support for them would be poor, if available at all. I don't think Swift has full releases to Windows or Linux yet? Fast.ai and the likes have been investigating Swift too, so there's some momentum/ desire to switch to Swift.
  - pjmlp 6y ago
    I don't believe it will go anywhere, Fortran, C++, Python and Julia are what matters in GPGPU. Even Java and .NET have better support for CUDA than Swift ever will.

sdkjfhskjfh 6y ago

> my small Javalin app uses four times the RAM at rest as my Express app did Are you looking at used heap space or just the amount of memory used by the Java process? I have a few small Java services using vert.x and they hover around 7-15 MB of used heap space. For small services I usually just restrict the maximum heap space size because the default is unnecessarily large.