Our journey with Swift thus far - some notes and reflections

# Major challenges Much of issues are centered around richer dynamic library support, API packaging and Linux platform support, something we need for packaging products properly. - Dynamic Library support on Linux with library evolution - even a limited officially supported package with clear limitations would be useful (as our customers will have a completely controlled environment, it's possible to mandate specific library versions and patch levels for OS etc). - Library support for artifact bundles (we are currently running with a custom toolchain that supports xcframeworks on Linux to work around it, but that's not long term sustainable). - Concurrency runtime analytics tools could be richer, especially for Tasks - while we have some of the tooling in Instruments, it would be fantastic to also have support for accessing similar task information (async task stack backtraces etc, for creation/running/sleeping) in LLDB (especially import on Linux that lacks Instruments...), including inspecting Task locals. - Compile and runtime availability checking support for third party APIs is not available currently. - Fundamental support for dynamic libraries overall as a first class citizen, e.g. targets can't be linked dynamically . # Minor challenges ### Concurrency and testing - The Concurrency story is a bit unfinished, e.g. non-reentrant actor support and `send` support for Actors (including in the distributed case). The good thing is that we're seeing some things like e.g. Mutex trickle in, hoping for the remaining pieces (e.g. Semaphore alternatives, in the meantime we use the Task Semaphore)to come in place too as the lack of them lead to various more-or-less ugly workarounds currently. … ### Tooling and platform support - Linux support has been lagging at times (e.g. Macro support), which has postponed adoption of newer releases for us and it hasn't always been transparent . - Build times on Linux when using the new Foundation are quite painful (we need to not only build swift-foundation, but also swift-syntax due to use of macros - it's a well-known problem of course, but just wanted to mention it as it causes long CI turnaround for us). - Build Stability and Performance - we *very* often need to nuke `.build` or SwiftPM caches or Xcodes derived data due to weird issues (like missing Packages in Xcode), e.g. things seem to rebuild more than expected (e.g. this example for Benchmark). - SwiftPMs model with products/targets is a bit problematic for larger projects; targets are exposed to downstream projects, targets can't depend products in the same package, target name conflicts (aliasing doesn't always work out there) with module names (perhaps not SwiftPM exactly). - Local development of dependencies is a bit clunky, Swift package edit only solves this partially. We end up with a sometimes convoluted and non-ideal project structure with some tools / workaround on top of it. - LLDB support has been spotty with many crashes on Linux especially (and little updates on issues reported), it is improving over time though. … ### Performance - Performance issues are sometimes a bit hard to diagnose and address (e.g. unnecessary copying, we can get tons of metadata lookups when using existensial/generics if not getting the incantations right, ARC traffic, etc) - and need workarounds that allow the compiler to specialize properly. It feels like some sort of instrument for analyzing anti-patterns in Swift could help, would be happy to discuss details. - Generics, while having improved over time, still is not without friction and it is fairly complex at times to get the desired behavior. From a performance point of view it's a bit of hit-or-miss. It's challenging to guarantee that things will get specialised, and it is easy to make a nice generic refactoring that just runs over a performance cliff that you don't expect. It would be great with improvements in this area, e.g. there have been discussions about various annotations (e.g. to guarantee specialization). - KeyPath performance is problematic - unfortunately the performance of KeyPaths has forced us to do workarounds even in fairly simple cases like sort comparators as they would take over samples completely - it'd be nice if they could be used without fear. - Deeper documentation and hints on best practices for performance when using generics and protocol oriented programming (related to the previous point). Basically a follow up to the older performance best practices, but with a bit of more focus on cross-module considerations. - Analyzing program behaviour is missing some runtime hooks to better understand runtime behaviour and perform better benchmarks. Overall, we'd welcome further investment in runtime performance, compile times and overall robustness (SwiftPM / Toolchain / Linux support on par). … > Build Stability and Performance - we *very* often need to nuke `.build` or SwiftPM caches or Xcodes derived data due to weird issues (like missing Packages in Xcode), e.g. things seem to rebuild more than expected The same is true on macOS. I love Swift but working on a large codebase can be really painful.