5 ms·

Swift could have been a big player in web development 9-10 years ago if they invested more in Linux support with a good standard library (and [0]package manager

Swift could have been a big player in web development 9-10 years ago if they invested more in Linux support with a good standard library (and [0]package manager). Nowadays I would say Go is more an alternative rather than Node, maybe for some extreme cases Rust. I wanted to love Swift, but there was (maybe still is) low Apple investment outside the Apple ecosystem. [0] Still not sure to this day why Swift has a package manager if Xcode is not using it (or at least was not using it a few years ago), I just followed lightly Swift development the past few years.

lukeh 2y ago
Xcode projects can have Swift package dependencies, and Xcode can open Swift packages directly.
jillesvangurp 2y ago
Apple just did not care enough about server development to invest in it. There are plenty of languages and frameworks out there. I wouldn't say Go and Rust are particularly logical choices for web development though. Of course they are being used for that but it's not necessarily the best fit. Rust is kind of restrictive and requires some serious skills to be effective in. And with Rust developers being in high demand, you end up paying a premium for them. So, if you need a simple backend, you might want to pick something more accessible. Go is of course very popular for all sorts of server stuff but you mostly find it lower in the stack in all sorts of middle ware. They both are a bit low level for web development. People seem to gravitate to more flexible/richer languages here. Which is why Java and Javascript are very popular and why e.g. Python, Php, and other scripting languages are still widely used for web development. On the native front you have things like Elixir, and a few others gaining traction. Swift being similar to Kotlin, which is popular for server stuff, could have stepped up easily. But it didn't happen. Mostly that's because Apple tightly controls its roadmap and just wasn't interested in it. Interestingly, Kotlin now has an IOS compiler and a native compiler for Linux. And there are some Kotlin server side frameworks that work on kotlin native (e.g. ktor). However, it's not a great option for native server development yet mostly for the same reasons Swift is not ideal either: library support is a bit lacking and server/linux support just isn't a huge priority in either community. So, you get compiler bugs, lack of features, performance issues, etc. On the JVM it's a different story. There Kotlin is a drop in replacement for Java in pretty much any Java framework (you can name) and there are a few kotlin specific ones as well. IMHO, it's a great fit with Spring Boot which comes with lots of Kotlin support. I've been using it for years for this and can highly recommend it. I'm interested in switching to Kotlin native for server stuff but right now it seems like I'd be a very early adopter. Swift is very much in the same boat. You can make it work probably but you'd be on your own.
- deleted 2y ago
  [deleted]
- jeremyjh 2y ago
  Elixir is not a native language. It compiles to Erlang's bytecode format (BEAM) for the Erlang VM.
mdhb 2y ago
I’ve been doing a lot of backend stuff recently with Dart after coming from a Node / Ruby background and I can’t begin to describe what a breath of fresh air it is. Insanely high quality of life improvement for development. The experience is very similar to what people here are describing that they wanted from Swift. Also in a similar vein to Typescript, it’s another language I can now comfortably use and share between front and backend but with a very different and I think for most use cases better set of trade offs. Honestly I think it’s the most underrated modern language out there at the moment because people still only associate it with Flutter which is unfortunate.
- bsaul 2y ago
  Problem with backend dev is that it's 99% about plumbing between components written by someone else ( db, cache, queue, other web services , etc). In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine.
  - mdhb 2y ago
    One of the nice things about Dart in particular is that they are actually very aware that they are currently a small community. In that sense they ended up making a big focus on having great interop with other languages. Currently they have C, C++, Rust, Swift, JavaScript (browser and node), Java, Kotlin and Objective C all more or less working and an upcoming goal of WASI will also open up that entire ecosystem. Plus all of your usual interop solutions for out of process communication. I.e anything that speaks gRPC like Ruby, C#, Go, PHP etc has strongly typed automatically generated code libraries for you.
    - lukeh 2y ago
      Many of those solutions rely on Flutter platform channels (ie. serialization) which may not suit high performance use cases. Plug: native Swift platform channel implementation which I’ve been working on lately. https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift
  - 2y ago
pjmlp 2y ago
The alternatives are .NET and Java platforms, with plenty of languages to chose from, and AOT is also part of the picture, if needed. Go only if one is feeling like I was coding in 1990's. Even node is better, thanks to Typescript, and if there are performance issues, native modules are an option.
- CharlieDigital 2y ago
  I was a long time Windows .NET Framework dev and switched to TypeScript + Node for a while because that's what all the startups were using and thoroughly enjoyed it. One thing that stood out to me in particular was just how fluid it is working with types in TS and also how good the unit testing story is on Node. Then switched back to .NET 6 when I joined another (rare) startup using C#/.NET for the backend. .NET now is a fantastic backend platform and I've been very pleasantly surprised. Part of it is that the base framework now feels really complete and well put together -- it feels "batteries included", but with the Duracell branded batteries and not the cheap knockoffs. The Entity Framework ORM didn't seem as competent in the .NET Framework days, but now EF Core is really, really good; highly performant and ergonomic to use. Part of it is that the multi-platform capabilities matured a lot since the 4.8 Framework days; the team I'm on is all macOS and we deploy to a mix of AWS t4g Arm64 instances. Part of it is that there's no longer a hard dependency on Visual Studio for most workloads; the team is a mix of VS Code and Rider. What really stood out to me after that stint with TS is how close TS and C# have become[0] and even more so with the more recent releases of C# 12. I think it's probably easier for teams that are working with TS + Node to add C#/.NET workloads than any other language/runtime like Go or Rust when there is a benefit to add multi-threading or get higher throughput from some backend system. [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp
  - can16358p 2y ago
    Maybe a bit going off topic, but I'm down the exact same route: used .NET Standard + EF as a Windows guy up until around 4.8, then I started TS development (not for backend but because of switching focus on frontend, also simultaneously switching to Apple ecosystem/iOS dev etc. but still) and still love it. If I were to start a new backend project today, I'd be going with node.js/TS but because that's what I'm used to as language/framework, not because it's necessarily better. But I loved C#/.NET/VS/EF/Azure stack just as it too back in the days. Would you recommend going in with .NET Core/Vscode/EF Core on macOS today, if you were to start a fresh backend project?
afavour 2y ago
Swift could have been a big player but equally I can’t see a particularly good reason why you'd choose it. I like it a lot as a language but unless I was really wedded to the idea of reusing code between server and native app client I wouldn’t be pushing it. For one it’s way too easy to create memory leaks compared to garbage collected languages.
- mst 2y ago
  Once you've worked with refcounting GC systems for a while avoiding leaks becomes pretty much second nature. It is absolutely a pain when you first come to it from a mark and sweep GC'ed language but once figuring out the right spot to use a weak reference becomes automatic creating leaks largely ceases to feel 'too easy' though occasionally throwing a cycle checker at your code is recommended nonetheless.
  - afavour 2y ago
    For sure. But the question still remains: when you’re running on a high performance server that’s more than capable of speedy garbage collection, why bother?
    - mst 2y ago
      My last comment was only addressing your 'too easy to' part (which, per sibling comment, may not be as universal an appearance as I thought). However, fair question. My answer here is that I am also really rather fond of timely destruction - in the same way as a Rust value's Drop happens as soon as the value is no longer required, a refcounting GC can fire destructors/finalizers immediately. That means that e.g. if code that's using an "external" resource (think file descriptor) throws an exception, the resource will automatically be released during the stack unwind rather than having to wait for the next GC pass. It also means that you can (and I, in fact, do) have a transaction object that can emit a warning at a useful point if you let it go out of scope without calling commit or rollback on it. You can absolutely get (close) equivalents to this with a mark and sweep GC language, go's 'defer' strikes me as something I could implement at the very least 90% of these patterns with, but it's still something you have to consciously implement. What's trickier is e.g. if you have N objects in flight sharing a resource but want the resource to go away when all of those are done - in a non-refcounting language you either have to track the count yourself (i.e. effectively implementing a mini-refcounter) or again rely on GC to sweep it up soon enough not to be a problem. So it's a trade-off between having to think about resource releases and having to think about breaking cycles, and I'm not at all arguing refcounting is -better- but I personally mostly find it just -different- and I'm definitely not convinced that getting used to it is (much) harder than getting used to the relevant dances to not temporarily leak file descriptors and similar.
lo_fye 2y ago
Swift was first released in June 2014, which is 1 month away from being exactly 10 years ago. So you wanted them to optimize it for web development as it was being birthed as a language?
mark_l_watson 2y ago
re: why does Swift have a package manager if Xcode doesn’t use it: I occasionally use Swift but almost never use Xcode. I find command line Swift tools, including the package manager, with either or both Emacs and VSCode makes for a nicer dev experience.
dagmx 2y ago
Xcode does support Swift Packages. https://developer.apple.com/documentation/xcode/swift-packages https://developer.apple.com/documentation/xcode/swift-packag...
- jwells89 2y ago
  And has for some time now. Haven’t used CocoaPods or Carthage in years (thank goodness).
deleted 2y ago
[deleted]
- deleted 2y ago
  [deleted]

lukeh 2y ago

Xcode projects can have Swift package dependencies, and Xcode can open Swift packages directly.

jillesvangurp 2y ago

Apple just did not care enough about server development to invest in it. There are plenty of languages and frameworks out there. I wouldn't say Go and Rust are particularly logical choices for web development though. Of course they are being used for that but it's not necessarily the best fit. Rust is kind of restrictive and requires some serious skills to be effective in. And with Rust developers being in high demand, you end up paying a premium for them. So, if you need a simple backend, you might want to pick something more accessible. Go is of course very popular for all sorts of server stuff but you mostly find it lower in the stack in all sorts of middle ware. They both are a bit low level for web development. People seem to gravitate to more flexible/richer languages here. Which is why Java and Javascript are very popular and why e.g. Python, Php, and other scripting languages are still widely used for web development. On the native front you have things like Elixir, and a few others gaining traction. Swift being similar to Kotlin, which is popular for server stuff, could have stepped up easily. But it didn't happen. Mostly that's because Apple tightly controls its roadmap and just wasn't interested in it. Interestingly, Kotlin now has an IOS compiler and a native compiler for Linux. And there are some Kotlin server side frameworks that work on kotlin native (e.g. ktor). However, it's not a great option for native server development yet mostly for the same reasons Swift is not ideal either: library support is a bit lacking and server/linux support just isn't a huge priority in either community. So, you get compiler bugs, lack of features, performance issues, etc. On the JVM it's a different story. There Kotlin is a drop in replacement for Java in pretty much any Java framework (you can name) and there are a few kotlin specific ones as well. IMHO, it's a great fit with Spring Boot which comes with lots of Kotlin support. I've been using it for years for this and can highly recommend it. I'm interested in switching to Kotlin native for server stuff but right now it seems like I'd be a very early adopter. Swift is very much in the same boat. You can make it work probably but you'd be on your own.

deleted 2y ago
[deleted]
jeremyjh 2y ago
Elixir is not a native language. It compiles to Erlang's bytecode format (BEAM) for the Erlang VM.

mdhb 2y ago

I’ve been doing a lot of backend stuff recently with Dart after coming from a Node / Ruby background and I can’t begin to describe what a breath of fresh air it is. Insanely high quality of life improvement for development. The experience is very similar to what people here are describing that they wanted from Swift. Also in a similar vein to Typescript, it’s another language I can now comfortably use and share between front and backend but with a very different and I think for most use cases better set of trade offs. Honestly I think it’s the most underrated modern language out there at the moment because people still only associate it with Flutter which is unfortunate.

bsaul 2y ago
Problem with backend dev is that it's 99% about plumbing between components written by someone else ( db, cache, queue, other web services , etc). In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine.
- mdhb 2y ago
  One of the nice things about Dart in particular is that they are actually very aware that they are currently a small community. In that sense they ended up making a big focus on having great interop with other languages. Currently they have C, C++, Rust, Swift, JavaScript (browser and node), Java, Kotlin and Objective C all more or less working and an upcoming goal of WASI will also open up that entire ecosystem. Plus all of your usual interop solutions for out of process communication. I.e anything that speaks gRPC like Ruby, C#, Go, PHP etc has strongly typed automatically generated code libraries for you.
  - lukeh 2y ago
    Many of those solutions rely on Flutter platform channels (ie. serialization) which may not suit high performance use cases. Plug: native Swift platform channel implementation which I’ve been working on lately. https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift
- 2y ago

pjmlp 2y ago

The alternatives are .NET and Java platforms, with plenty of languages to chose from, and AOT is also part of the picture, if needed. Go only if one is feeling like I was coding in 1990's. Even node is better, thanks to Typescript, and if there are performance issues, native modules are an option.

CharlieDigital 2y ago
I was a long time Windows .NET Framework dev and switched to TypeScript + Node for a while because that's what all the startups were using and thoroughly enjoyed it. One thing that stood out to me in particular was just how fluid it is working with types in TS and also how good the unit testing story is on Node. Then switched back to .NET 6 when I joined another (rare) startup using C#/.NET for the backend. .NET now is a fantastic backend platform and I've been very pleasantly surprised. Part of it is that the base framework now feels really complete and well put together -- it feels "batteries included", but with the Duracell branded batteries and not the cheap knockoffs. The Entity Framework ORM didn't seem as competent in the .NET Framework days, but now EF Core is really, really good; highly performant and ergonomic to use. Part of it is that the multi-platform capabilities matured a lot since the 4.8 Framework days; the team I'm on is all macOS and we deploy to a mix of AWS t4g Arm64 instances. Part of it is that there's no longer a hard dependency on Visual Studio for most workloads; the team is a mix of VS Code and Rider. What really stood out to me after that stint with TS is how close TS and C# have become[0] and even more so with the more recent releases of C# 12. I think it's probably easier for teams that are working with TS + Node to add C#/.NET workloads than any other language/runtime like Go or Rust when there is a benefit to add multi-threading or get higher throughput from some backend system. [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp
- can16358p 2y ago
  Maybe a bit going off topic, but I'm down the exact same route: used .NET Standard + EF as a Windows guy up until around 4.8, then I started TS development (not for backend but because of switching focus on frontend, also simultaneously switching to Apple ecosystem/iOS dev etc. but still) and still love it. If I were to start a new backend project today, I'd be going with node.js/TS but because that's what I'm used to as language/framework, not because it's necessarily better. But I loved C#/.NET/VS/EF/Azure stack just as it too back in the days. Would you recommend going in with .NET Core/Vscode/EF Core on macOS today, if you were to start a fresh backend project?

afavour 2y ago

Swift could have been a big player but equally I can’t see a particularly good reason why you'd choose it. I like it a lot as a language but unless I was really wedded to the idea of reusing code between server and native app client I wouldn’t be pushing it. For one it’s way too easy to create memory leaks compared to garbage collected languages.

mst 2y ago
Once you've worked with refcounting GC systems for a while avoiding leaks becomes pretty much second nature. It is absolutely a pain when you first come to it from a mark and sweep GC'ed language but once figuring out the right spot to use a weak reference becomes automatic creating leaks largely ceases to feel 'too easy' though occasionally throwing a cycle checker at your code is recommended nonetheless.
- afavour 2y ago
  For sure. But the question still remains: when you’re running on a high performance server that’s more than capable of speedy garbage collection, why bother?
  - mst 2y ago
    My last comment was only addressing your 'too easy to' part (which, per sibling comment, may not be as universal an appearance as I thought). However, fair question. My answer here is that I am also really rather fond of timely destruction - in the same way as a Rust value's Drop happens as soon as the value is no longer required, a refcounting GC can fire destructors/finalizers immediately. That means that e.g. if code that's using an "external" resource (think file descriptor) throws an exception, the resource will automatically be released during the stack unwind rather than having to wait for the next GC pass. It also means that you can (and I, in fact, do) have a transaction object that can emit a warning at a useful point if you let it go out of scope without calling commit or rollback on it. You can absolutely get (close) equivalents to this with a mark and sweep GC language, go's 'defer' strikes me as something I could implement at the very least 90% of these patterns with, but it's still something you have to consciously implement. What's trickier is e.g. if you have N objects in flight sharing a resource but want the resource to go away when all of those are done - in a non-refcounting language you either have to track the count yourself (i.e. effectively implementing a mini-refcounter) or again rely on GC to sweep it up soon enough not to be a problem. So it's a trade-off between having to think about resource releases and having to think about breaking cycles, and I'm not at all arguing refcounting is -better- but I personally mostly find it just -different- and I'm definitely not convinced that getting used to it is (much) harder than getting used to the relevant dances to not temporarily leak file descriptors and similar.

lo_fye 2y ago

Swift was first released in June 2014, which is 1 month away from being exactly 10 years ago. So you wanted them to optimize it for web development as it was being birthed as a language?

mark_l_watson 2y ago

re: why does Swift have a package manager if Xcode doesn’t use it: I occasionally use Swift but almost never use Xcode. I find command line Swift tools, including the package manager, with either or both Emacs and VSCode makes for a nicer dev experience.

dagmx 2y ago

Xcode does support Swift Packages. https://developer.apple.com/documentation/xcode/swift-packages https://developer.apple.com/documentation/xcode/swift-packag...

jwells89 2y ago
And has for some time now. Haven’t used CocoaPods or Carthage in years (thank goodness).

deleted 2y ago

[deleted]

deleted 2y ago
[deleted]