In my experiences playing with Swift it has roughly two design goals—make a modern feeling ObjC and jam it into ML/Haskell ADTs. Almost every moment of using th

In my experiences playing with Swift it has roughly two design goals—make a modern feeling ObjC and jam it into ML/Haskell ADTs. Almost every moment of using the language feels like a tug-of-war between those two sides. I'm personally hugely excited about this in the same way I was hugely excited about this feeling in Scala. I don't think FP and OO ought to stay on their own side of the fence—I think they're mutually useful. But I think the OO in Swift goes way too far in order to have ObjC compatibility (perhaps). I think that perhaps the biggest challenge that Swift falls the furthest on is managing combining immutable and mutable code. `let` and `var` are very thin veneers and it's easy to have things "change underneath you" even while writing a lot of let-like code. I think this is mainly driven by the highly mutability-dependent ObjC bindings Swift must support in order to be useful to Apple. I also think it's a bit tragic. My hope is that this being the early days for Swift its influence will drive more immutability through these APIs as they evolve.