3 ms·
I was very happy when swift was introduced and it solved many classes of bugs that were very popular in Obj-C. It was very much a big help for external develope
by thealistra 4y ago
I was very happy when swift was introduced and it solved many classes of bugs that were very popular in Obj-C. It was very much a big help for external developers.
Swift apps are not crashing randomly, you don't have nils running rampant because of type safety.
You can create types that nicely convey reality using rich enums and you don't have to define objects with 18 fields that are mostly always nil, but when propertyA == 16, then this field has some value.
Swift also is not an official superset of C, like Objective-C, so you don't have all the footguns of C language, like integer promotions and assignment being an expression.
You just have so much improvements over objective-C if you want to ship an app to hundreds of thousands of users and be sure that it works correctly and that unhandled edge cases won't blow up.
Maybe it is more complex to write a compilable piece of swift, that a compilable piece of Objective-C, but I am happy that this is the case, because it means that the compiler has my back and finds bugs and issues for me.
- tl 4y agoI agree with the premise "you don't have nils running rampant because of type safety" but the reality "Swift apps are not crashing randomly" is far from the truth. Right now, I have a research project using Swift Charts and it definately "crashes randomly" partially because Charts expects a subset of type-safe values and does not communicate which subset except by chucking EXC_BAD_ACCESS with no usable error. Sure, that's example of a beta framework. However, SwiftUI is the proposed Swift-y replacement to Objective-C's UIKit and is loaded with examples of "the type system we moved to should catch this but can't" followed by the even more common "the type system will catch this error in 11,000 years when it's finished failing to compile code on an M1".