5 ms·

This is a nice critique of the Swift toolchain UX on Linux, but perhaps not of the server-side Swift developer experience in general. Each of these problems loo

This is a nice critique of the Swift toolchain UX on Linux, but perhaps not of the server-side Swift developer experience in general. Each of these problems looks like the sort of thing that you solve quickly once and move on from. I have recently been developing a server-side Swift application, a few months of sporadic evenings and weekends. My starting point was having a year or so of professional iOS experience and a ton of web/server/infra experience. My experience with it has certainly been mixed, but in many ways a breath of fresh air compared to some web development ecosystems. At work I'm mostly using Java on the backend and I think Swift could be a really nice replacement for that for larger systems – the type system is better, the ergonomics are better, the developer tooling is much better at the lower end (although there's plenty of specialist JVM tooling that is better). Ecosystem-wise, Swift has few but high quality libraries available in general. Apple's first party libraries are exceptional. Vapor is in a weird place though. Some parts are really mature and well considered for their relatively young age (e.g. parts of the ORM, async stack), others feel very early days for things that have been around for a number of years now (e.g. queues). Others feel like an impedance mismatch in the framework design – I find the Content system both too limiting and not providing enough. Overall, I'm loving it for a personal project. Would I use it as the foundation of a new startup? Probably not. Would I use it in a iOS heavy company? Yeah probably. I think you can do productive, high-quality backend engineering in Swift, today.

joe_fishfish 3y ago
Have you looked at Kotlin? Very, very similar to Swift and interoperates very well with Java.
- danpalmer 3y ago
  Briefly. There are Kotlin areas in the codebases I work on, particularly in Android code. It's not something I've needed to use yet, but I've heard good things and I'm interested to get into it once we start using it more.
  - foobarian 3y ago
    Strongly second the GP. I ramped up over the past year and I compare it to C# or TypeScript as far as the type safety and async features go. That whole time I kept running into QoL features and sugar that were just a joy to use. The best side benefit for our Java heavy org was that the migration risk is very low due to excellent JVM/Java integration.
  - flakes 3y ago
    I started using Kotlin in Java 8 before the "record" keyword existed to be able to use "data class" instances. This provided very nice semantics for defining immutable structures, and the resulting classes could be imported into the existing Java codebase. As the project progressed we started adding more in Kotlin and it massively improved developer experience.
cvwright 3y ago
Agreed on all points. I’ve been using Vapor for a small work project for a couple of years and overall it’s been a good experience. I think a lot of the author’s problems started when he bailed on Vapor and went down into the depths of SwiftNIO. I’m not really sure this was necessary. I could be wrong, but it feels to me like Vapor should let you do pretty much everything that you would need for an ActivityPub server. Writing request handlers in Vapor with async/await is delightful - it’s really not any harder than writing Flask code. But going down below that level is pain. Lots and lots of pain.
- danpalmer 3y ago
  I've actually tried to write an ActivityPub server in Vapor! I must admit I didn't get very far on the outbound part using Vapor, as the inbound part took up most of my time. My impression was that ActivityPub is way too poorly specified for a good ecosystem to develop, which is probably why we see a monoculture of Mastodon for post-based ActivityPub, and similar semi-independent monocultures for things like Reddit replacements (Lemmy?). You're right about the NIO part. I've had to dig into it a few times, but rarely found it productive in solving problems. Vapor is pretty flexible if you drop past it's first layer of abstractions, and as long as you pick one of futures/async and stick to it, it's fairly straightforward.
kagakuninja 3y ago
If you work in Java and like the syntax of Swift, then you should consider using Scala. Of course convincing coworkers and managers to use it can be a problem.
- danpalmer 3y ago
  Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages. I see your point about Scala, there are niceties to it in my (brief) experience, however it's not so much the syntax as it is the way that software tends to be written in Swift given the language features – I didn't find the same in Scala, it tended to be more complex than I wanted.
  - lmm 3y ago
    > Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages. Most Java tooling works with Scala out of the box or at most needs a plugin added, and interop when calling Java from Scala is very smooth. Even if it wouldn't be acceptable for production code you might consider trying it for migration scripts, admin tools, testing etc. (though personally I'd stay away from ScalaTest et al) - that's how I got my start with Scala many years ago.
    - danpalmer 3y ago
      I'm at Google and we have a very consistent set of tooling across a large engineering org. I can certainly "play" with Scala, but realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with, and anything else is going to need so much work to integrate with our frameworks and systems that it's unlikely to happen.
      - lmm 3y ago
        > realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with FWIW Scala can actually be pretty useful in that space with Zeppelin - it's not quite as smooth as some of the Python-only notebooks out there, but sometimes being able to use your Java libraries in your notebooks makes up for a bit of clunkiness.
wiseowise 3y ago
> the developer tooling is much better at the lower end Haha, what?
- danpalmer 3y ago
  I find the performance tooling and package management situation in Swift via Xcode and Instruments is, in my experience, much better than a typical out-of-the-box Java setup with a popular IDE. IDE features may be better in something like Intellij (I'm not a fan personally), but the language tooling isn't better in my experience. The swift+llvm+lldb setup is nice, Swift Package Manager is really nice, much nicer than Maven/Gradle in my experience. So yeah, better at the low end. Linux/Windows tooling is lacking, I'll give you that, but given where Swift started from I feel like they're already outside the norm for Swift development and debatably "low end" on complexity (although not deployment, I haven't had a problem with Linux deployment). By "high end" I mean anything that is trying to do complex runtime analysis, and the sort of tuning that you can do on the JVM that is way outside my comfort zone.
  - enterprise_cog 3y ago
    You should probably list some concrete examples of how it is better. Otherwise it’s just an opinion with no insights.
    - danpalmer 3y ago
      Concretely, the whole Instruments suite is far beyond anything I've managed to get out of a JetBrains IDE. I realise they have some of this stuff, but in my experience it's far from easy to use, and it costs money, which Xcode/Instruments do not.
  - eviks 3y ago
    I thought the "low end" would mean the ability to skip the huge XCode and building your project with a popular text editor/ide (that's also where Linux/Windows wouldn't have to lack)
nicoburns 3y ago
Adding to the recommendations for other languages you're already getting on this thread: have you tried Rust? It's type system and syntax are very similar to Swifts. You do have to deal with the borrow checker, but that typically isn't too challenging for backend web development work where logic tends to be pretty linear anyway, and in return you get a much more developed ecosystem.
- jwells89 3y ago
  Maybe I just haven't looked at the right codebases, but most of the Rust I've seen reminds me more of C++, being more dense, technical, and "noisy". The language most similar in syntax to Swift I've seen is Kotlin, but it's still more quirky and rigid than Swift is.
  - dagmx 3y ago
    I write a lot of Swift and Rust, and personally I find them to be very similar languages, and most of my code ends up identical. They have a lot of shared ideas and even shared developers. Swift is effectively ref counted rust imho
    - danpalmer 3y ago
      I think this does a disservice to Rust, but I do agree with the thrust of your point. Rust appeals to my desire for perfect engineering, Swift appeals to that side enough, but with a healthy dose of pragmatic engineering. On a perfect to pragmatic scale, Swift is in a better place than Rust in my opinion.
pphysch 3y ago
> Overall, I'm loving it for a personal project. Would I use it as the foundation of a new startup? Probably not. I know of a medium-size startup that is (attempting) building an industrial/IoT software stack on just Swift. Last I heard things weren't going great...
- sulam 3y ago
  What language you write in doesn’t seem like a great place to use your few innovation tokens for that kind of startup.
hedgehog 3y ago
That roughly matches my experience trying to use Swift outside Mac and iOS development. I really like the language but the tooling and library ecosystem just aren't there. Go or Rust are not as nice to write in different ways but much more easy to get work done with. On the Rust side the language is more fiddly than Rust but with the help of Copilot the gap is not that big.
usefulcat 3y ago
> Each of these problems looks like the sort of thing that you solve quickly once and move on from. Erm, including the apparent signal race and the illegal instruction?
- lmm 3y ago
  > Erm, including the apparent signal race and the illegal instruction? Yes. They're probably both caused by this person setting their CPU microarchitecture wrong.

joe_fishfish 3y ago

Have you looked at Kotlin? Very, very similar to Swift and interoperates very well with Java.

danpalmer 3y ago
Briefly. There are Kotlin areas in the codebases I work on, particularly in Android code. It's not something I've needed to use yet, but I've heard good things and I'm interested to get into it once we start using it more.
- foobarian 3y ago
  Strongly second the GP. I ramped up over the past year and I compare it to C# or TypeScript as far as the type safety and async features go. That whole time I kept running into QoL features and sugar that were just a joy to use. The best side benefit for our Java heavy org was that the migration risk is very low due to excellent JVM/Java integration.
- flakes 3y ago
  I started using Kotlin in Java 8 before the "record" keyword existed to be able to use "data class" instances. This provided very nice semantics for defining immutable structures, and the resulting classes could be imported into the existing Java codebase. As the project progressed we started adding more in Kotlin and it massively improved developer experience.

cvwright 3y ago

Agreed on all points. I’ve been using Vapor for a small work project for a couple of years and overall it’s been a good experience. I think a lot of the author’s problems started when he bailed on Vapor and went down into the depths of SwiftNIO. I’m not really sure this was necessary. I could be wrong, but it feels to me like Vapor should let you do pretty much everything that you would need for an ActivityPub server. Writing request handlers in Vapor with async/await is delightful - it’s really not any harder than writing Flask code. But going down below that level is pain. Lots and lots of pain.

danpalmer 3y ago
I've actually tried to write an ActivityPub server in Vapor! I must admit I didn't get very far on the outbound part using Vapor, as the inbound part took up most of my time. My impression was that ActivityPub is way too poorly specified for a good ecosystem to develop, which is probably why we see a monoculture of Mastodon for post-based ActivityPub, and similar semi-independent monocultures for things like Reddit replacements (Lemmy?). You're right about the NIO part. I've had to dig into it a few times, but rarely found it productive in solving problems. Vapor is pretty flexible if you drop past it's first layer of abstractions, and as long as you pick one of futures/async and stick to it, it's fairly straightforward.

kagakuninja 3y ago

If you work in Java and like the syntax of Swift, then you should consider using Scala. Of course convincing coworkers and managers to use it can be a problem.

danpalmer 3y ago
Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages. I see your point about Scala, there are niceties to it in my (brief) experience, however it's not so much the syntax as it is the way that software tends to be written in Swift given the language features – I didn't find the same in Scala, it tended to be more complex than I wanted.
- lmm 3y ago
  > Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages. Most Java tooling works with Scala out of the box or at most needs a plugin added, and interop when calling Java from Scala is very smooth. Even if it wouldn't be acceptable for production code you might consider trying it for migration scripts, admin tools, testing etc. (though personally I'd stay away from ScalaTest et al) - that's how I got my start with Scala many years ago.
  - danpalmer 3y ago
    I'm at Google and we have a very consistent set of tooling across a large engineering org. I can certainly "play" with Scala, but realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with, and anything else is going to need so much work to integrate with our frameworks and systems that it's unlikely to happen.
    - lmm 3y ago
      > realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with FWIW Scala can actually be pretty useful in that space with Zeppelin - it's not quite as smooth as some of the Python-only notebooks out there, but sometimes being able to use your Java libraries in your notebooks makes up for a bit of clunkiness.

wiseowise 3y ago

> the developer tooling is much better at the lower end Haha, what?

danpalmer 3y ago
I find the performance tooling and package management situation in Swift via Xcode and Instruments is, in my experience, much better than a typical out-of-the-box Java setup with a popular IDE. IDE features may be better in something like Intellij (I'm not a fan personally), but the language tooling isn't better in my experience. The swift+llvm+lldb setup is nice, Swift Package Manager is really nice, much nicer than Maven/Gradle in my experience. So yeah, better at the low end. Linux/Windows tooling is lacking, I'll give you that, but given where Swift started from I feel like they're already outside the norm for Swift development and debatably "low end" on complexity (although not deployment, I haven't had a problem with Linux deployment). By "high end" I mean anything that is trying to do complex runtime analysis, and the sort of tuning that you can do on the JVM that is way outside my comfort zone.
- enterprise_cog 3y ago
  You should probably list some concrete examples of how it is better. Otherwise it’s just an opinion with no insights.
  - danpalmer 3y ago
    Concretely, the whole Instruments suite is far beyond anything I've managed to get out of a JetBrains IDE. I realise they have some of this stuff, but in my experience it's far from easy to use, and it costs money, which Xcode/Instruments do not.
- eviks 3y ago
  I thought the "low end" would mean the ability to skip the huge XCode and building your project with a popular text editor/ide (that's also where Linux/Windows wouldn't have to lack)

nicoburns 3y ago

Adding to the recommendations for other languages you're already getting on this thread: have you tried Rust? It's type system and syntax are very similar to Swifts. You do have to deal with the borrow checker, but that typically isn't too challenging for backend web development work where logic tends to be pretty linear anyway, and in return you get a much more developed ecosystem.

jwells89 3y ago
Maybe I just haven't looked at the right codebases, but most of the Rust I've seen reminds me more of C++, being more dense, technical, and "noisy". The language most similar in syntax to Swift I've seen is Kotlin, but it's still more quirky and rigid than Swift is.
- dagmx 3y ago
  I write a lot of Swift and Rust, and personally I find them to be very similar languages, and most of my code ends up identical. They have a lot of shared ideas and even shared developers. Swift is effectively ref counted rust imho
  - danpalmer 3y ago
    I think this does a disservice to Rust, but I do agree with the thrust of your point. Rust appeals to my desire for perfect engineering, Swift appeals to that side enough, but with a healthy dose of pragmatic engineering. On a perfect to pragmatic scale, Swift is in a better place than Rust in my opinion.

pphysch 3y ago

> Overall, I'm loving it for a personal project. Would I use it as the foundation of a new startup? Probably not. I know of a medium-size startup that is (attempting) building an industrial/IoT software stack on just Swift. Last I heard things weren't going great...

sulam 3y ago
What language you write in doesn’t seem like a great place to use your few innovation tokens for that kind of startup.

hedgehog 3y ago

That roughly matches my experience trying to use Swift outside Mac and iOS development. I really like the language but the tooling and library ecosystem just aren't there. Go or Rust are not as nice to write in different ways but much more easy to get work done with. On the Rust side the language is more fiddly than Rust but with the help of Copilot the gap is not that big.

usefulcat 3y ago

> Each of these problems looks like the sort of thing that you solve quickly once and move on from. Erm, including the apparent signal race and the illegal instruction?

lmm 3y ago
> Erm, including the apparent signal race and the illegal instruction? Yes. They're probably both caused by this person setting their CPU microarchitecture wrong.