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

61–70 of 207 posts

Re: Swift Regrets

#61

Post by slavapestov »

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 credible design or implementation of "incrementally evolve Objective-C and drop the C part" beyond stating that it's trivial, etc.

Re: Swift Regrets

#62

Post by saagarjha »

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…

> 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.

Re: Swift Regrets

#63

Post by ChrisMarshallNY »

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.…

> Bringing a new language into the world requires massive amounts of high quality documentation.

Very much agree. Not just a new language. Any complex endeavor requires this. I have written a server-based framework, including spending a great deal of time developing API documentation, and was relatively recently introduced to Postman. I have been using Postman to communicate the API to another engineer that is not RTFM (I've come to learn that folks don't like reading stuff, these days. I am looking at ways of communicating information in formats other than longform text).

I like Postman. The main issue with using it as a documentation source, is that it can easily become "cluttered"; especially as I use it in "back-and-forths," over particular commands.

I would have been lost, in my Swift education, without StackOverflow, although I hardly ever consult it anymore (mostly because it's rapidly becoming less useful; not because I don't need the help).

SwiftUI has some of the worst documentation I've ever encountered. Obviously, it was headerdoc-style, and no one was writing header docs, so I was constantly encountering empty pages. It was so bad, a generous individual developed this site and companion app[0]. I understand that the SwiftUI documentation is being rapidly improved. I haven't really started into a big learning drive on SwiftUI, yet, so I hope it is in better shape, by the time I get to it.

[0] https://swiftui-lab.com

Re: Swift Regrets

#64

Post by saagarjha »

azakai wrote: post #55
novok wrote: post #34

Earlier quoted context omitted.

What do you mean specifically about memory safety? A clean break new-syntax Objective C could have dropped the C part of ObjC, added strict nullability, dropped header files, add non ABI breaking features like enum ADTs and a bunch of other tweaks and still kept most of the same language compiler code without all the downsides of swift. Swift became a silver bullet homer car as far as languages go.

That would not have helped with use-after-free, though, which Swift does solve.

That's solved by ARC, not Swift.

Re: Swift Regrets

#65

Post by jorgemf »

jshier wrote: post #37
rapsey wrote: post #26

Earlier quoted context omitted.

From my outside looking in perspective: * Android studio is reliable and just works. * Kotlin is simple, easy to learn and productive. * xcode is buggy and with their rapid pace of development it is just getting worse. * Swift is complex. They had to rethink and redesign multiple times. Also the language was constantly changing under them.

Swift hasn't changed much in the last 2.5 years, and was stable for the year before that, so it really shouldn't be an issue any more.

Yes, but kotlin has been much more stable for more years.

Re: Swift Regrets

#66

Post by saagarjha »

azakai wrote: post #53
zozbot234 wrote: post #33

Earlier quoted context omitted.

Swift does not provide memory safety for concurrent code. It has comparable pitfalls to Go. (You can use Thread Sanitizer to try and diagnose these issues, but that's best-effort and runtime-only; it does not make your code totally safe.)

That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety. I'd also say they are in a reasonable space in the state of the art of safety in general. While they do not make concurrency safe and Rust does, in Rust you need to use unsafe to write things like doubly-linked lists and graphs (or…

In my experience post-ARC almost all memory safety issues are thread-safety related.

Re: Swift Regrets

#67

Post by iainmerrick »

saagarjha wrote: post #62
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…

> 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.

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?

Re: Swift Regrets

#68

Post by iainmerrick »

jbluepolarbear wrote: post #49
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.

No it’s not. If you have multiple parameters Obj-C is much longer and ugly.

Where are you getting this from?

Swift’s mandatory named parameters come from Objective-C. For the most part only the bracket placement is different.

Re: Swift Regrets

#69

Post by ace2358 »

iainmerrick wrote: post #67
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.

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?

Because the original iPhone was so stripped down that it could run on that thinly little slow cpu. It took Apple years and years to add features back into iOS frameworks. Every one very considered and every attempt to not destroy the battery of the iPhone. Multi tasking only around in iOS 4 right? Like on iPhoneOS 1 every app was closed when you hit that home button. That it worked so smoothly was the result of extremely focused UX.

Re: Swift Regrets

#70

Post by iainmerrick »

dhritzkiv wrote: post #42
kitsunesoba wrote: post #36

Earlier quoted context omitted.

I haven't had a chance to use Jetpack Compose yet but this roughly tracks with my experience. Needing to hunt down third-party libs for everything slows development down considerably and makes for complications down the road when those libraries inevitably stop being supported.

Totally. To add to this: when looking for third party libraries (Swift/Objective-C or Kotlin/Android Java), aside from those from large organizations (Square, Airbnb, etc.), I've found the selection and quality of those available for iOS to be better, on average.

I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages.

Unless things have changed a lot recently, C/C++ sort-of-works on Android but it’s a pain to use and the tooling support is very weak.

Post reply on HN