Pretty much same issues for embedded. I have one board where ideally there’s just a 32-bit ARM and only a single Swift binary; static linking with no Foundation makes sense for this. The other is a Pi Compute Module, with a few different binaries (some of which need Foundation) and which have many dependencies in common, so shared libraries for all common dependencies would be preferred. I suppose the firmware build could identify the common dependencies and rewrite Package.swift.
it costs about $5.50 per month after factoring in savings plans, and including disk storage, but not including Elastic IPv4 addresses. however it also has first-party integration with S3 and other AWS services, so this makes managing the security rules a lot easier. the 1TB of free Cloudfront data transfer to the internet is also nice.
right, this brings us back to the “plugin” architecture we were discussing earlier in the thread. a lot of things you want to run in the cloud are not going to fit into neat increments of 500MB, 1GB, 2GB, 4GB RAM, etc., and don’t need dedicated IP addresses. so there’s a lot of value in being able to co-habit multiple apps on one host.
if you’re using the monolith deployment model, you’ve got to compile a new executable “image” containing all the apps you want to run on each node, for every single update.
2 Likes
for what it’s worth, i am actually using the monolith deployment model pretty much everywhere, for the same reason i suspect so many other people are.
i hate it, because most of my hosts run a mixture of free and proprietary “apps”, and the vast majority of the updates i push are updates to the open source components.
because i’m deploying monoliths, i have to recompile the free code along with the proprietary code, which means i have to rebuild a lot of executables in the “secret hanger” instead of just pulling artifacts from open distribution channels.
I think for non-indie, actual business focused projects, the SLA aspect is relevant here. You can get SLA's for common tech's but not for Swift, and that's a major pain point, to bring the thread back to the original context.
And the worst part is that it isn't just about the Swift stuff, it even replicates things we do have system level contracts for, like OpenSSL or libcurl. That is viable for Apple itself, but for almost no one else.
Language stability, ABI, all play into this. I don't see those things being addressed anytime soon. IBM was some hope here, but that didn't work out ...
1 Like
Right now the lack of GCP and Azure SDKs is very painful.
This list covers our biggest pain points quite well. (Although support for pre-built dependencies on Linux would lessen the pain of not supporting shallow git clones!)
Additionally, while sourcekit-lsp has come a long way, it is still frustratingly unstable. At least when used in combination with VSCode running in a Linux-based devcontainer, it is slow when it is working but often becomes unresponsive without crashing, necessitating a manual window re-load in VSCode to get going again.
4 Likes
Full GCP SDK - GitHub - vapor-community/google-cloud-kit
There's a Azure PoC that covers signing - GitHub - brokenhandsio/swift-azure-sdk
1 Like
I'd say compile times.
Building a Swift binary is just so slow compared to basically every other language used for backend development. Python and JS are interpreted, of course, so it's not an issue at all, but even Java compilers are so much faster than Swift.
I was just reading the announcement of Cultured Code using Swift for their new backend, and it all sounds awesome except for the bit about their 30,000 line server requiring 10 minutes to compile.
I haven't worked on Swift on the server in a couple of years, but the reason I abandoned it at the time was largely related to build times, and the lack of hot reload. Going from minutes per edit-compile-test cycle to seconds is a massive productivity boost.
7 Likes
While I—and apparently many others—share the sentiment about slow compile times (gosh, I was just jealous last week at a meetup, seeing how quickly Elixir works, with macros building instantly), to be fair, there are other statically typed languages with slow compilation that still manage to gain market share on the server side—especially Rust—while mentioned Elixir, despite its niche, remains relatively small.
Still, when I look at languages like OCaml, I do hope this can be improved somehow, though I’m not sure how, considering the challenges of Swift’s type system…
I agree with that. The Sourcekit LSP crashes on me at least once a day and many times multiple times a day. It's the worst pain point of developing Swift on Linux right now. I'm hoping some improvements can be made there, because it's embarrassing to have to admit that the LSP is crashing all the time to prospective Swift developers and others in my team (who are primarily C# devs, using Visual Studio).
4 Likes
Did you file issues when you hit the crashes or when it became unresponsive? It would help tremendously if you could file an issue on SourceKit LSP whenever you hit a crash or another bug. You can capture diagnostics with sourcekit-lsp diagnose in the terminal and attach it to issue. This helps troubleshooting a lot.
1 Like
The memory leak in SourceKit-LSP has been fixed for more than 4 month, they just didn't think it was important enough for a bugfix release. A couple more weeks and we would have had to wait until Swift 6.2 (Xcode 17), luckily it is being released with Swift 6.1 (Xcode 16.3): High memory usage · Issue #1541 · swiftlang/sourcekit-lsp · GitHub
5 Likes
Thank goodness. Good lord we need this desperately.