Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Regrets

belkadan.com

Post reply on HN
Print view View original

101–110 of 207 posts

Re: Swift Regrets

#101

Post by mpweiher »

zionic wrote: post #11
protomyth wrote: post #10

I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language. A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile.…

> I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilitie…

> > and made the calling syntax much more complicated.

> How is this true? Swift is very straightforward, and similar to other languages

Swift is objectively one of the most complex languages out there[1]. Just recently, they adopted basically the entirety of Smalltalk syntax as an edge case of an edge case[2].

Just the rules for initialisers are more complex than many languages and still don't cover all the cases[3].

> Meanwhile Objective-C is slow,

The only people who believe this are those who have never measured (and have uncritically accepted Apple propaganda on this topic)[4]. Objective-C is a language you can easily write very fast code in (languages by themselves aren't fast or slow)[5]. Objective-C code is almost invariably faster than Swift code, and often by quite a lot.[6]

> unsafe by default,

Also not true. The id subset is quite safe[7] (and pretty fast), as are primitives. The parts that make C dangerous, particularly strings and other raw pointer accesses are abstracted away behind safe NSString, NSArray, NSData and friends.

> ugly syntax

Keyword syntax is actually highly elegant (Smalltalk's fits on a postcard) and extremely functional. So functional that Swift just recently added pretty much all of it as an edge case of an edge case of its closure syntax. Oh, did I already mention that?

> More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC

Citation needed. Also: way more than half of the OS is still written in Objective-C, so you'd expect that.

[1] https://www.quora.com/Which-features-overcomplicate-Swift-Wh...

[2] https://blog.metaobject.com/2020/06/the-curious-case-of-swif...

[3] https://blog.metaobject.com/2020/04/swift-initialization-swi...

[4] https://blog.metaobject.com/2014/09/no-virginia-swift-is-not...

[5] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...

[6] https://blog.metaobject.com/2020/04/faster-json-support-for-...

[7] https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...

Re: Swift Regrets

#102

Post by mpweiher »

Someone wrote: post #91
iainmerrick wrote: post #67

Earlier quoted context omitted.

Right! If it’s so slow, how did the original iPhone work so slickly, when all the apps and most of the frameworks were written in Objective-C?

For the same reason python is fast for machine learning: because the performant parts were written in C. Ignoring slick animations (which were written in C, if not in hand-tuned assembly) typical UIs of apps on the original iPhone could have run (a bit slowly and in monochrome) on an original Mac, that is in 128kB RAM on a 8MHz CPU.

> because the performant parts were written in C

Objective-C is C. More specifically a strict superset of C.

> Ignoring slick animations (which were written in C, if not in hand-tuned assembly)

Nope. The reason the animations were smooth (not necessarily fast) is that they were processed by the GPU and orchestrated by a separate process.

Re: Swift Regrets

#103

Post by mpweiher »

zozbot234 wrote: post #46
protomyth wrote: post #43

Earlier quoted context omitted.

How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.

C++ is of course a vastly more complex language than Swift. I don't think anyone would want to code in C++ these days if they can avoid it.

a) I wouldn't be so sure that C++ is actually more complex at all, never mind vastly. It may be less forgiving... :-)

b) With C++, you're at least getting something for all that complexity: performance and control.

Re: Swift Regrets

#104

Post by rsfinn »

Apocryphon wrote: post #86
zionic wrote: post #11

Earlier quoted context omitted.

> I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilitie…

> I mean that's the vast majority of people Maybe... https://news.ycombinator.com/item?id=15421073 It's an old article by now, but check out the responders- Marco Arment, Steve Troughton-Smith, Marcel Weiher- pretty eminent iOS devs among them.

Yes, that article is nearly four years old. Since then, Swift has evolved considerably.

Steve Troughton-Smith has tweeted recently about his work in converting all of his apps to Swift over the last year [1]. "I will remember ObjC and the times we had together fondly, but after a year of being Swift-only I prefer making apps with it" [2]. "I also wouldn’t change the timeline in which I adopted Swift ... I don’t feel I lost out on anything positive by waiting" [3].

[1] https://twitter.com/stroughtonsmith/status/14392341761636638... [2] https://twitter.com/stroughtonsmith/status/14216157982091100... [3] https://twitter.com/stroughtonsmith/status/14216193780265820...

Marco Arment has talked about using Swift in new development for Overcast, although I don't believe he's rewriting existing code. He seems more open to Swift these days than when that article was written. (Can't find a quotable source at present)

Marcel Weiher has continued working on a language now called Objective-S, which sounds like the "more Smalltalk-y" language that other commenters have wished for: "Objective-S includes an Objective-C compatible runtime model, but using a much simpler and consistent Smalltalk-based syntax." [4]

[4] http://objective.st/About

Re: Swift Regrets

#105

Post by Apocryphon »

slavapestov wrote: post #61
novok wrote: post #24

I'm surprised he doesn't bring up minor features that lead to huge compile time issues, like operator overloading and imports being module sized vs file or folder wide and type inference in some cases. Not to mention how the language doesn't actually scale that well with core count vs. many, many other programming languages. Throwing 64 cores / 128 threads at a C++ code base speeds up builds in a linear fashion durin…

> Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. This is a common talking point I hear in the Objective-C community, but nobody has come up with a credibl…

Hypothetical designs are bandied about all the time

https://medium.com/@mattmass/the-alternative-reality-of-obje...

https://twitter.com/tolmasky/status/1401972686037913601

https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-...

https://web.archive.org/web/20141224114850/https://swiftopin...

Re: Swift Regrets

#107

Post by slavapestov »

Apocryphon wrote: post #105
slavapestov wrote: post #61

Earlier quoted context omitted.

> Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. This is a common talking point I hear in the Objective-C community, but nobody has come up with a credibl…

Hypothetical designs are bandied about all the time https://medium.com/@mattmass/the-alternative-reality-of-obje... https://twitter.com/tolmasky/status/1401972686037913601 https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-... https://web.archive.org/web/20141224114850/https://swiftopin...

“Hypothetical” being the key word here, though. These proposals are all thin on details, and if it was so easy someone would’ve made such a language by now.

Re: Swift Regrets

#108

Post by mpweiher »

zionic wrote: post #93
saagarjha wrote: post #62

Earlier quoted context omitted.

> Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC, Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Most of Apple's CVEs come from code written in C or C++, not Objective-C.

This shouldn’t be true, ObjC’s only innate advantage is compile time, because the compiler is simply doing less and is capable of producing far worse (unsafe) code. At runtime Swift can utilize static dispatch, where objective C is mostly dynamic. Good swift code should generally be faster.

> This shouldn’t be true

Performance isn't about what you believe should be true, but about what actually is true. Kinda like science. (versus religion)

> ObjC’s only innate advantage is compile time

Objective-C has a bunch of advantages. Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile.

And there are languages with very comparable feature sets to Swift that are way faster to compile.

> At runtime Swift can utilize static dispatch

"can"

> where objective C is mostly dynamic.

Not true. The C part of Objective-C (it is most of the actual language) is very static.

Also, Swift has some pretty amazing dynamic performance pitfalls. For example protocols. You see, protocols in Swift can be adopted by both structs and classes. Meaning that when you call a function via a protocol, the compiler doesn't even know the size of the arguments or how to access them or copy them into the function's scope. So even that has to be handled by a small vtable, and you haven't actually done anything with that argument yet!

As this is one of the many places where Swift can lose a cool few orders of magnitude of performance, you obviously need the optimiser to specialise the function for specific callers. Which it can do, sometimes, at some cost, as long as it can actually see the caller and callee at the same time, in the same compilation unit.

IIRC, Uber had an OOPSLA paper describing the extra compiler pass they had to write to get their app's performance to at least somewhat acceptable levels, because the existing optimiser wasn't good enough.

And when you want to do separate compilation, you're sort of hosed, because you don't have access to the caller when you compile the callee.

> Good swift code should generally be faster.

That turns out not to be the case.

Re: Swift Regrets

#109

Post by dekhn »

I remember when the creator of Swift joined google and there was a lot of noise about Swift and Tensorflow. i told people while it seemed like a nice idea, it was never going to replace Python/C++. Eventually Lattner lost interest and the project died.

Re: Swift Regrets

#110

Post by Apocryphon »

iainmerrick wrote: post #71
kennywinker wrote: post #12

Earlier quoted context omitted.

I find it hard to believe that anybody is faster coding in objc than swift, if you control for garbage code. It was easy to quickly write buggy messes in objc - swift made that a lot harder, and is also a much more ergonomic and productive language in my experience. I feel like there has to be some other factors at play if that’s the results you’re seeing. (Source: I’ve been doing objc since 2009, and swift since ver…

I prefer Swift on balance, but there’s still a lot I miss from Obj-C. For one thing, Obj-C compiles much faster. Swift compilation is ludicrously slow.

Debugging with LLDB often feels broken or incomplete in Swift than with Objective-C, as well.
Post reply on HN