> Can you be specific? I would love to understand which type of problem you are speaking about. As someone who also got into Swift because it is the only game i

> Can you be specific? I would love to understand which type of problem you are speaking about. As someone who also got into Swift because it is the only game in town for iOS, it's become my go-to language for everything from tooling/orchestration to back-end infrastructure simply because I find it very nice to work with. Sorry I tried to look through my browser history for a specific example but couldn't find one... All I found was a page on AlamoFire (https://stackoverflow.com/questions/29131253/swift-alamofire-how-to-get-the-http-response-status-code https://stackoverflow.com/questions/29131253/swift-alamofire...) that I think I was looking up when trying to help debug some iOS mobile code. I think I was looking over the shoulder of an iOS dev on my team and just didn't like the code I was seeing... I also saw an SO thread on JSON parsing in swift (https://stackoverflow.com/questions/24013410/how-to-parse-a-json-file-in-swift https://stackoverflow.com/questions/24013410/how-to-parse-a-...) so maybe I was annoyed with how seemingly not-easy parsing JSON into a known class was? might make sense with the AlamoFire thing). I don't think I can defend that point very well but it's just a feeling I've held on to over time. > Admittedly I'm not an expert in Rust, but the best way to explain why I prefer working in Swift is that I find it to be a permissive language, where Rust is an opinionated language. Well I'm not either -- I've been writing it for fun but it's not my main workhorse at this point (nevermind finding a corporate codebase in it). This might make it a bit clearer were we differ -- I'm really into opinionated/not-permissive languages right now. The more feedback I can get from a compiler/type system the better as far as I'm concerned as long as the language lives up to it's promises to make me better/safer/whatever (for Rust & Haskell they mostly deliver). > Swift, by contrast, has deep toolbox which you can use to implement OO patterns, functional patterns, Protocol Oriented design etc. I personally don't actually want OO design in backend languages I use if I can avoid it -- I've found that a good type system along with typeclasses(haskell)/traits(rust)/protocols(swift)/duck-type interfaces(golang) and basic structs is all I need. If the language allows constraints on the generics (i.e. requiring one typeclass/trait/protocol to satisfy another) that's all the composability I need without all the OO boilerplate and cruft. Swift might be the more flexible language since it doesn't have the ownership/borrowing system but I also don't feel like I spend my time reaching for too many design patterns per say -- maybe I write too many of the same kind of application (backend web services). I generally use the component model (like in https://github.com/stuartsierra/component https://github.com/stuartsierra/component), sprinkle some DDD and I'm good to go for most things. > So I think Swift and Rust have slightly different goals, and where the worst piece of Rust code you can write which will compile will be a bit safer/more performant etc than similar with Swift, to me Swift strikes that balance where it's still giving me a huge advantage over most languages in terms of compile-time checking, but I can be incredibly productive and expressive. Personally the langauge (if you can call it that) which fits this mold for me is Typescript. Of course Javascript is the wild wild west where the most reckless code seems to be written but Tyepscript gives me just enough of a type system and some assurance that everything isn't going to break at runtime. The projects where I'd use node (basically so I can ensure smooth hand off to another developer) I can't use Swift, and the projects where I might use Swift I'd rather use Rust or Haskell. I think the biggest difference is that I don't write Objective-C/Swift iOS apps, if I was maybe I'd have a chance to give Swift a more thorough look over. That said, I basically never intend to write fully native apps because I'd rather pick "close-enough"/"good-enough" options like Nativescript.