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

51–60 of 207 posts

Re: Swift Regrets

#51

Post by novok »

ardit33 wrote: post #30
jshier wrote: post #23

Earlier quoted context omitted.

This just isn't true. Given equal familiarity, Swift will be vastly more productive at any skill level. Of course you can always tunnel deeper into more sophisticated solutions using Swift, since Obj-C lacks most of its capabilities, but that's hardly an equal comparison.

You are talking out of your arse… and so am I. Unless we have well researched data, it is just a opinion. My opinion and experience is definitely different than yours, and I have seen that objective c leads to more productive teams if they are mostly senior people. (With a couple of libraries (just some helper categories on strings and arrays) and some sparse macros objective c becomes a very productive language. But…

Nullability isn't that big of an issue in practice. Every call in objective-c is equivalent to a variable?.thing call anyway, and in swift codebases most things become non-null fairly quick. It's probably the top feature of swift for me, which is ironic because it's relatively cheap (in compile time) to implement compared to many other things swift has.

And if you're doing nullability, you might as well add ADT enums, since that is usually how it's implemented.

Re: Swift Regrets

#52

Post by protomyth »

jshier wrote: post #47
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.

> The Swift syntax is more characters than ObjC's syntax. How so?

well, no - Swift's call syntax actually results in the same or more characters:

  somePoint.moveBy(x: 2.0, y: 3.0)

  [somePoint moveByX: 2.0 y: 3.0];

  somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0)

  [somePoint moveByX: 2.0 y: 3.0 z: 4.0];

Re: Swift Regrets

#53

Post by azakai »

zozbot234 wrote: post #33
jshier wrote: post #29

Earlier quoted context omitted.

The main point of Swift was to create a memory-safe language Apple could use across its OSes. Trying to change Obj-C's syntax doesn't help with that goal.

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 resort to things like indexes-in-an-array), which you can do safely in Swift and Go. So there are interesting tradeoffs all around - our industry has not found a perfect solution here yet.

Re: Swift Regrets

#54

Post by kitsunesoba »

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.

Strong agree here. This is also tied into the "batteries included" approach of Apple platforms, because many if not the majority of Swift/Obj-C libraries are mainly wrappers around system frameworks that either bring them to a higher level (in the case of C or C++ APIs) or add a sprinkle of syntactic sugar and light-to-moderate gap filling functionality. So naturally, these libraries are easier to maintain in the long term simply because they're doing so much less.

Re: Swift Regrets

#55

Post by azakai »

novok wrote: post #34
jshier wrote: post #29

Earlier quoted context omitted.

The main point of Swift was to create a memory-safe language Apple could use across its OSes. Trying to change Obj-C's syntax doesn't help with that goal.

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.

Re: Swift Regrets

#56

Post by kyralis »

msoad wrote: post #2

Swift has way too many shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. In larger codebases a lot of shorthands are forbidden by the organizations for consistency. So I'm not sure who's the real beneficiary for all those shorthands?

Very much this. The original discussions around Swift talked about the value of being explicit rather than implicit and reducing surface area (for instance, no ++/-- increment/decrement operators). That goal appears to have been completely lost recently.

Re: Swift Regrets

#57

Post by adamnemecek »

spijdar wrote: post #41
pjmlp wrote: post #27

Earlier quoted context omitted.

NeXT had another point of view on that matter though, the original DriverKit was Objective-C. Objective-C++ main point of existence, just like POSIX, was only to bring other software into the platform. It is quite telling that only old timers have access to Objective-C++ docs.

Are you and GP talking about the same thing? The obj-c drivers from next/OpenStep were replaced with a restricted subset of C++ (not objective-C++) IOKit system. I'm not sure what system GP is referring to based off Obj-C++ but I assume it's not the drivers?

E.g. AVFoundation.

Re: Swift Regrets

#58

Post by pjmlp »

spijdar wrote: post #41
pjmlp wrote: post #27

Earlier quoted context omitted.

NeXT had another point of view on that matter though, the original DriverKit was Objective-C. Objective-C++ main point of existence, just like POSIX, was only to bring other software into the platform. It is quite telling that only old timers have access to Objective-C++ docs.

Are you and GP talking about the same thing? The obj-c drivers from next/OpenStep were replaced with a restricted subset of C++ (not objective-C++) IOKit system. I'm not sure what system GP is referring to based off Obj-C++ but I assume it's not the drivers?

Not really, I am talking about NeXTSTEP and DriverKit.

Ironically I think IO Kit userspace replacement, DriverKit, got its name as homage to the Objective-C one in NeXTSTEP.

Re: Swift Regrets

#59

Post by novok »

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…

If I had Go's build speed in Swift, I wouldn't have minded a clean break language like Swift.

Re: Swift Regrets

#60

Post by novok »

tialaramex wrote: post #48
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…

C++ pays an extraordinary price for the fully parallel builds, concealed in the "One Definition Rule". The price is, if you violate the ODR the standard says your program is not valid C++ (and thus has no defined meaning) but there is no requirement for a diagnostic (ie a compile or link error) and the build might complete. This has sometimes been described as "False positives for the question is this a program?" and…

Could you have ODR and proper warnings / errors handling the issue when it pops up without much penalty?
Post reply on HN