4 ms·

I recently spent a couple of weeks in Swift land to see what it's all about; but from my experience it's still a mine field of exceptions and hoop jumping. I fe

I recently spent a couple of weeks in Swift land to see what it's all about; but from my experience it's still a mine field of exceptions and hoop jumping. I feel that the problem with both Rust and Swift is that they're aiming so hard for perfection that they're missing the point of the exercise; which is to make it easier to write good code, period. Wasting half your energy-budget on spoon feeding the compiler is just as bad as spending it on managing memory manually in C.

yxhuvud 9y ago
Hmm, Have you looked at Crystal? It comes so very close to the sweet spot for me that I don't really know the difference.
thewayfarer 9y ago
> Wasting half your energy-budget on spoon feeding the compiler is just as bad as spending it on managing memory manually in C. This isn't quite a fair comparison. Manual memory management increases the risk of producing incorrect or buggy programs. Satisfying a strict compiler increases the chance that your program is written correctly. And for what it's worth, this boilerplate dance for "type erasure" will be solved with what the Swift team calls generalized existentials, where you'll be able to use nominal types like Any<Sequence where .Iterator.Element == String>. "Type erasure" isn't the result of "aiming so hard for perfection" as you say, but because Swift is still a young language and there is only so much the creators can work on at any one time. Most Swift devs (think iOS apps) aren't running up against this problem much, and I haven't seen a single situation in an app where implementing a "type erased" generic type was necessary. At this point in the Swift timeline, just making Swift code compile faster would make devs much happier. > it's still a mine field of exceptions Unlike languages that actually use exceptions, which really are mine fields of exceptions in a different sense :P
bsaul 9y ago
I think the reason swift and rust are mine fields of hoop jumping are opposite : rust took a few very opinionated design decisions (eg : strong safety in concurrency), and derived everything else from those principles, trying to reach something "user friendly" in the end, and is not there yet. Swift always claimed to be a very "pragmatic" language, not sacrificing user convenience to purity. The problem is that they grabbed good ideas a bit everywhere, but still struggle to reach enough power in the language to become truly user friendly when the user start using all those bits to solve their particular problem (eg : generics and protocols, or concurrency, or typed exception, or result type, etc.).

yxhuvud 9y ago

Hmm, Have you looked at Crystal? It comes so very close to the sweet spot for me that I don't really know the difference.

thewayfarer 9y ago

> Wasting half your energy-budget on spoon feeding the compiler is just as bad as spending it on managing memory manually in C. This isn't quite a fair comparison. Manual memory management increases the risk of producing incorrect or buggy programs. Satisfying a strict compiler increases the chance that your program is written correctly. And for what it's worth, this boilerplate dance for "type erasure" will be solved with what the Swift team calls generalized existentials, where you'll be able to use nominal types like Any<Sequence where .Iterator.Element == String>. "Type erasure" isn't the result of "aiming so hard for perfection" as you say, but because Swift is still a young language and there is only so much the creators can work on at any one time. Most Swift devs (think iOS apps) aren't running up against this problem much, and I haven't seen a single situation in an app where implementing a "type erased" generic type was necessary. At this point in the Swift timeline, just making Swift code compile faster would make devs much happier. > it's still a mine field of exceptions Unlike languages that actually use exceptions, which really are mine fields of exceptions in a different sense :P

bsaul 9y ago

I think the reason swift and rust are mine fields of hoop jumping are opposite : rust took a few very opinionated design decisions (eg : strong safety in concurrency), and derived everything else from those principles, trying to reach something "user friendly" in the end, and is not there yet. Swift always claimed to be a very "pragmatic" language, not sacrificing user convenience to purity. The problem is that they grabbed good ideas a bit everywhere, but still struggle to reach enough power in the language to become truly user friendly when the user start using all those bits to solve their particular problem (eg : generics and protocols, or concurrency, or typed exception, or result type, etc.).