3 ms·

> So now contrast that to Swift. First of all: Which question did it desire to answer? From Swift.org: Swift makes it easy to write software that is incredibly

by dwaite 8y ago

> So now contrast that to Swift. First of all: Which question did it desire to answer? From Swift.org: Swift makes it easy to write software that is incredibly fast and safe by design. Our goals for Swift are ambitious: we want to make programming simple things easy, and difficult things possible. > It should scale from App/UI language down to system language. I don't see how say Go can be a system language and Swift can't. Much of Apple's investment has been around making App and Framework development more productive on their platforms, but Swift is open and other companies like IBM have been focused on things like Web frameworks. >It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication. I assume they mean the standard Swift package as the standard library, since they listed Foundation separate. Swift is tiny, basically holding core types like Int, String, Optional, and pointers, Collections (Dictionary, Set, and Array), ranges like 1..<10, and essential common protocols like Equatable and Hashable. It isn't until you get to foundation that you get things like I/O / networking or binary data types. > It is functional, object-oriented and protocol oriented all at the same time. Several of the languages listed in the article as being above as positive (like Ruby) are also multi-paradigm. Swift is hardly a functional language, it just has functional influences - like nearly all the languages listed. > It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design. Since there wasn't an example given, all I can really say is there's nothing that requires you to use type inference. My experience from multiple languages is that usually such an expression is wrong, and the compiler cannot figure out any suggestions on how to fix it because a broken expression doesn't give any type inference hints. A dynamic language would just let it crash and burn at runtime, which (if you have a test suite capturing the issue) is such a different process for debugging from fixing type inference at compile-time that they are hard to compare. > It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't. REPL and Playgrounds are both for experimentation, not necessarily for scripting. You can do command-line swift scripts, but generally the compiler makes them a bit heavyweight for many things. > It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development. Can't say much here vs having a computer analyze your code is meant to be a boon, not a hinderance. My experience is that now when I write Java projects I wish I could get back the expressiveness, performance, and personal productivity I have writing Swift code. > It is meant offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex. If nothing else, someone is underestimating the effort of mastering C++.

mpweiher 8y ago
> incredibly fast and safe by design. Except it actually is incredibly slow, not fast. The only thing fast about it is the marketing, and that is mostly fast and loose. I ran a ton of benchmarks for my performance book, and despite the fact that I didn't expect much, I was still surprised by just how badly it misses on the performance front. As an example see how Kitura compares to other web frameworks in performance: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r16&hw=... And Kitura actually implements the central HTTP parser in C. Porting that same code to Swift made it (that code, not Kitura) 10x slower. As a second example, see JSON parsing. Putting Swift on top of NSJSONSerialization typically adds a 25x performance overhead. Yes, that's twenty-five. And NSJSONSerialization uses NSDictionary and friends to represent the parse result, which is already very, very slow. 25x on top of that is no mean feat. Anyway, the good folk from Big Nerd Ranch decided the problem was the interop and decided to write a parser in pure Swift, called Freddy. It was a "success", as Freddy is only 8x slower than NSJSONSerialization. Oh, and if you think Swift serialization fixes this: it doesn't. Still around an order of magnitude slower. And I didn't even go into the role of the optimizer. Unoptimized code is much, much slower relatively speaking, sometimes 100x to 1000x (yes, that's a thousand) slower than optimized code. Note that the default debug mode in Xcode is unoptimized and that 1000x is the difference between 1 second and 20 minutes. And of course you don't get a diagnostic if an optimization is not applied. The "Swift is fast" meme is pure Apple marketing at its most deceptive. It has never been true in the past and isn't true now. As to safety: there is very little to no evidence that static typing actually increases safety, studies go either way and when there is a positive effect it is tiny. See also: http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html http://blog.metaobject.com/2014/06/the-safyness-of-static-ty... > [type inference falling over] usually such an expression is wrong time swiftc too-complex.swift too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ real 1m20.639s user 1m12.459s sys 0m5.249s This compiles fine if you reduce the number of elements. But that's of course just one of the most egregious examples. Overall, compile times are horrendously slow, again we are talking order(s) of magnitude, and that is with the horrible C compilation model and its ridiculous header files as a baseline.

by dwaite 8y ago

mpweiher 8y ago

> incredibly fast and safe by design. Except it actually is incredibly slow, not fast. The only thing fast about it is the marketing, and that is mostly fast and loose. I ran a ton of benchmarks for my performance book, and despite the fact that I didn't expect much, I was still surprised by just how badly it misses on the performance front. As an example see how Kitura compares to other web frameworks in performance: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r16&hw=... And Kitura actually implements the central HTTP parser in C. Porting that same code to Swift made it (that code, not Kitura) 10x slower. As a second example, see JSON parsing. Putting Swift on top of NSJSONSerialization typically adds a 25x performance overhead. Yes, that's twenty-five. And NSJSONSerialization uses NSDictionary and friends to represent the parse result, which is already very, very slow. 25x on top of that is no mean feat. Anyway, the good folk from Big Nerd Ranch decided the problem was the interop and decided to write a parser in pure Swift, called Freddy. It was a "success", as Freddy is only 8x slower than NSJSONSerialization. Oh, and if you think Swift serialization fixes this: it doesn't. Still around an order of magnitude slower. And I didn't even go into the role of the optimizer. Unoptimized code is much, much slower relatively speaking, sometimes 100x to 1000x (yes, that's a thousand) slower than optimized code. Note that the default debug mode in Xcode is unoptimized and that 1000x is the difference between 1 second and 20 minutes. And of course you don't get a diagnostic if an optimization is not applied. The "Swift is fast" meme is pure Apple marketing at its most deceptive. It has never been true in the past and isn't true now. As to safety: there is very little to no evidence that static typing actually increases safety, studies go either way and when there is a positive effect it is tiny. See also: http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html http://blog.metaobject.com/2014/06/the-safyness-of-static-ty... > [type inference falling over] usually such an expression is wrong time swiftc too-complex.swift too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ real 1m20.639s user 1m12.459s sys 0m5.249s This compiles fine if you reduce the number of elements. But that's of course just one of the most egregious examples. Overall, compile times are horrendously slow, again we are talking order(s) of magnitude, and that is with the horrible C compilation model and its ridiculous header files as a baseline.