Please don't post like this to HN. You may not owe better to "Zucker" but you owe the community better if you're participating here. Posts like this damage the container, which we all need to be stronger not weaker.
Who are you anyways? The saint of corporate assholes? Any time anyone says anything less than positive about anyone with a pile of money, you're always first in line to defend them and shoot down the discussion.
Good luck dealing with that karma moving forward...
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.
> 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
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.).
Farewell Zucker, make sure you don't stumble over Myspace on your way out.