Skip to content

Instantly share code, notes, and snippets.

@seanparsons
Last active September 12, 2019 05:25
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save seanparsons/e80f2c65a3cbc8c36c21632a0eaeed88 to your computer and use it in GitHub Desktop.
Save seanparsons/e80f2c65a3cbc8c36c21632a0eaeed88 to your computer and use it in GitHub Desktop.
Swift Problems
It suffers from similar problems to Scala, where it tries to blend OO concepts in with FP concepts.
Variance is where this flares up terribly because it doesn't provide any explicit support for covariance or contravariance.
You end up with invariance and subtyping in a bunch of places which is not a nice combination.
Protocols like Equatable and Hashable are implemented with compiler magic for arrays and tuples.
Which means that you run into trouble with generic functions that say accept two instances of the same type which is Equatable if you pass an array of ints.
You can't say "for a List if the elements are Equatable the List is equatable" IIRC.
This one annoys me no end as we've had to fudge our way around it several times on the same project.
For some reason that eludes me, Optional<T> is given all sorts of special case syntax ("if let" and "guard let") which is like a crap version of "for yield" from Scala or do notation in Haskell that only works on that.
As a result a lot of convenient abstractions are just not possible you end up writing all kinds of horrid looking chained map/flatMap calls instead.
Whereas if you wrote the same thing in Haskell it would be one do block and that's it.
Concurrency and parallelism support is effectively Grand Central Dispatch.
You're just calling the old Objective-C API and the language doesn't help at all there.
It's a statically typed "FP" language which doesn't have higher kinded types which means a bunch of handy abstractions are a real pain.
See the Swiftz project for how they have to define things like monads as an example.
Compiler crashes from valid code, gotta spend time unwinding changes until it works and write the code differently.
Simple things like "a + b +...+ n" cause compile times to balloon exponentially, which means for arrays you end up refactoring concatenation of immutable arrays into a mutable array you call appendContentsOf on a bunch of times.
SourceKit on the surface sounds great, but in truth it's a simple text parser that doesn't understand type aliases for example.
The compiler _really_ struggles with anything beyond very simple generics,
first the type inference starts to fail and then it'll refuse to compile until you break the code apart and add type ascriptions.
The compile errors are often absolute nonsense, pointing nowhere near the actual errors or are like the Magic 8-ball coming up "ask again later".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment