<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 4:07 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><a href="https://swift.org/about/" class="">https://swift.org/about/</a> has some pretty good verbiage about this. In particular:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">"Swift is a <i class="">safe</i> language."</div></blockquote><div class=""><br class=""></div>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.<br class=""></div></div></blockquote><br class=""></div><div>Yes, the opt-out safety is a distinguishing feature.</div><div><br class=""></div><div><div class="">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.</div><div class=""><br class=""></div><div class="">I can’t articulate it as crisply as Jordan did, but my Swift description would be something like this:</div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class="">• It provides a high-level programmer model.</blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class="">• It provides pervasive, opt-out safety.</blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class="">• It compiles to native binaries.</blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class="">• The compiler can optimize its abstractions to C-like performance most of the time.</blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Why isn’t Swift Haskell or ML? Because of that constraint of providing only abstractions that allow aggressive static optimization.</div><div class=""><br class=""></div><div class="">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-<i class="">out </i>instead of opt-<i class="">in</i>.</div><div class=""><br class=""></div><div class=""><div class="">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.</div><div class=""><br class=""></div></div><div class="">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.</div><div class=""></div></div><br class=""><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div></body></html>