I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.
If you run into trouble, you can usually improve the dev experience by declaring types. This is usually only an issue if you're using a lot of generics or overloaded methods.
let x = y.fruit(ripeness: 0.9) // <- instead of this
let x: Banana = y.fruit(ripeness: 0.9) // <- do this
Related to the above, generics are powerful, but I strongly feel they should only be used if they clarify the code. Often they obfuscate and complicate what's going on, especially if you have the interaction of two generic types.
Maybe, but in my most recent attempt to use vapor (~a year ago?), the project it created with `vapor new` had inscrutable compilation errors off the bat, and so I immediately gave up.
It's actually very surprising they managed to get that language work at all given the size of it. In that regard, i wouldn't say execution was bad. It was just unrealistic, and too much was asked from it.
My recent point of comparison is rust, which feels like a much much smaller language, despite sharing a lot of the philosophy (struct + trait, which is very similar to what swift recommends to use nowadays, and limit the use of class).
I’m not sure of the “worst execution” part. Is it even possible to make a Swift compiler that doesn’t occasionally hit those “humans immediately see what this code does, but it takes ages to compile this” moments?
I think there’s something about Swift’s type system that makes those moments unavoidable. If so, Swift is more “good idea, but too flexible to build a compiler for”, and they should have killed some of their darlings to get a better language.