> On Jun 8, 2016, at 4:07 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > > https://swift.org/about/ <https://swift.org/about/> has some pretty good > verbiage about this. In particular: > > "Swift is a safe language." > > in that the obvious thing should be safe, and unsafe things should require a > bit of reaching. That's more important to me than a lot of other things that > happen to be true.
Yes, the opt-out safety is a distinguishing feature. I’m sure Haskell’s designers would give a grandly worded rebutted to just “Swift is safe,” since Swift allows race conditions, forced unwraps, unsafe memory access, etc. What distinguishes Swift for me is the particular way it emphasizes safety and high-level abstraction, but weighs those against static optimization. I can’t articulate it as crisply as Jordan did, but my Swift description would be something like this: • It provides a high-level programmer model. • It provides pervasive, opt-out safety. • It compiles to native binaries. • The compiler can optimize its abstractions to C-like performance most of the time. The interplay of the first two and the last two is what makes the language unique. For example, structs have a simple, high-level programmer model — “pass by value semantics” — but the compiler jumps through all those COW hoops to make them perform _most_ of the time as if they were C structs statically allocated and then passed by pointer. Why isn’t Swift Haskell or ML? Because of that constraint of providing only abstractions that allow aggressive static optimization. Why isn’t Swift C or Eagle? Because of the goal of making the abstractions as high-level as possible, and making the language’s safety features opt-out instead of opt-in. Why isn’t Swift Go? Because of the goal of making the abstractions as high-level as possible, and the distaste for a heavyweight runtime. Why isn’t Swift Rust? Because it doesn’t insist on zero-cost abstraction; instead, it weighs having a high-level programmer model and readability against abstraction cost. Cheers, Paul
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
