Poll: what do you strongly dislike about Swift?

And the lack of namespaces. I *so* would like C#-style namespaces. And the lack of namespaces. I "Hate" wasn't actually that powerful a word in this context because it wasn't literal. But now the word "strongly" is here, so it's more accurate, but also more negative. - Using Swift in Xcode is just unpleasant. The compiler is slow, the debugger breaks far more often than it works, and the app overall just has too much focus on annual new Features they can trot out on a WWDC keynote slide, and not enough emphasis on the fundamental developer experience. sourcekit-lsp does not yet seem to be reliable enough for a user of VSCode or vim or whatever to be able to have their project Just Work without fussing. - Building any large project effectively requires a lot of excessive modularization (which means a lot of developer time on overhead spent on modules). - Unit testing not allowing access to private members. "But you're supposed to test the API, not the internals" is an idea that doesn't work when you need to be able to write a test for a bug fix, or for feature flagging, or whatever. I have to bend my code into pretzels adding nonsense to an interface to test things in Swift, and it is a significant waste of time that would be avoidable if I could just test a private variable. - Also in JavaScript land, you can set up your unit tests to run in real-time when you change files. That would be nice to have. Especially if tests could live alongside files, rather than in a separate module because that's how Objective-C decided to do it 20 years ago. Agree here, though to be fair the server-side Swift experience seems smoother overall, at least debugging is faster and more reliable. Swift's awkwardness on iOS (and macOS?) is likely coming from the fact that it should deal with a few gigantic ObjC frameworks. I’m sure I could think of a list of annoyances about Swift as a language but I can’t think of a single annoyance about the language that harms my productivity more than what Steve mentioned a few posts up…the compiler speed and Xcode performance. Yes, I know Xcode isn’t Swift and so I guess this is off topic, but honestly most people write Swift code in Xcode and the developer experience has got steadily worse over recent years. Whilst I can recognise some of the improved features in Xcode is is slow, buggy and unstable. The last few releases have been particularly terrible for crashes and the Xcode release cycle is too long. Can we have a “snow leopard” release for Xcode please? i would agree that this is one of the largest things bottlenecking my productivity, but i am not sure what, if anything, could possibly be done about the compilation speed. personally i have made peace with the compile times. i suppose it is one of the necessary tradeoffs of using a language that tries to be expressive and performant at the same time. Absolutely agree. Making enums, when you just need a namespace, makes me sad It must be very difficult to implement the “.” command in Xcode. That’s why it’s not implemented. It’s not vi without this. I really love vim mode because I know vi from so long ago my finger just do it without thinking. But when things do not work, it’s WTF! … Lack of abstract classes once was a big challenge for me. I had a use case where clients must inherit implementation from the base class provided by the framework, and they must implement few abstract methods. I was lucky in my case to be able to decompose into concrete base class and protocol, but resulting generic signatures were complicated, required a lot of experiments to figure out, and were crashing compiler from time to time. … community-provided vim extension supports it perfectly, plus many other non-trivial vim features (like macros). That's why I really wish that Apple would work on providing a safe plugin API, so that the community could solve all of these problems themselves, and they could work on other things, instead of re-implementing vim inside Xcode. Not being able to to declare **static variables** within a **function**. The only option is to litter the app with globals. … Then I'll rephrase my "dislike"... Not being able to declare a **thread safe long-living local variable** within a **function**. I know we can do this, but I don't know if its thread safe.