Hacker News new | comments | show | ask | jobs | submit login

Am I the only one who finds the rapid source incompatibilities problematic? Like maybe a language shouldn’t move so fast or be better nailed down before production.

You have two choices: bake the language fully before release, or push out what you have and get the community involved.

I’d argue the second option is almost universally better.

Reasoning about effect aside, I walked away from an iOS project (personal) primarily because the language moved so fast it lot me.

Swift changed less between 3 and 4 than between 1.0 and 1.1.

The last two years or so have been fine for me.

I would say that a lot of people jumped on board with Swift before it should really have been used so widely. Objective C was - and still is! - a totally acceptable way to build an app for iOS.

You could do it Objective-C.

I don't think you're the only one.

Steve Troughton-Smith, Michael Lauer, Dan Leivers, Peter Molnar, Todd Thomas, Ian McDowell, Simon Wolf, Marco Arment all didn't seem (2017-10-04) in a particular hurry to adopt Swift. [0]


I feel most of the developers there more more unhappy about the lack of ABI stability, poor tooling, and learning a new language than the constant changes that Swift has.

Fair point, that's more precise. You're clearly better informed than me.

The following quote from Steve Troughton-Smith in the article that I linked was enough for me - I'm not going to beta test Swift for Apple either.

>I'm not yet convinced of Apple's level of participation in the language — four years on, Swift is not used for important pieces of iOS, OS or frameworks (I maintain a running list of Swift apps from Apple on Twitter, and macOS is definitely less shy about adopting it for new features than iOS). I understand why that is the case (ABI stability, etc), but if Apple's not using it for everything I don't see why I need to be beta-testing on their behalf. I lose nothing from waiting until Swift is 'ready', and I gain all the benefits of Objective-C in the meantime.

Apple has actually gotten quite good at adopting Swift for new projects where ABI stability is not an issue. Off the top of my head, Picture-in-Picture, Dock, and Touch Bar on macOS, and Calculator and parts of the WWDC app on iOS are mostly Swift. New developer tools, such as Playgrounds and parts of Xcode are Swift as well. Of course, you’ll notice that none of the uses I mentioned were core frameworks, since these are places where Apple cannot use Swift code.

launchd is also written in Swift now.

Huh, I wasn't aware of that. Are you sure? launchd doesn't seem to link against any Swift libraries:

  $ otool -L `which launchd`
  	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
  	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
  	/usr/lib/libauditd.0.dylib (compatibility version 1.0.0, current version 1.0.0)
  	/usr/lib/libbsm.0.dylib (compatibility version 1.0.0, current version 1.0.0)
  	/usr/lib/libdz.dylib (compatibility version 1.0.0, current version 110.50.29)

That was part of the message at WWDC 2017, Dock and launchd ported to Swift.

I guess we can go through the videos to track down where it was communicated.

Like another commenter has mentioned, Swift is now almost nearly source compatible. The compiler already provides support for any version of Swift back to version 3.2.

Unfortunately, if what others here are stating is true, many of the examples date to Switch version 1 and 2...

> others

You might want to check the username on that comment ;)

LOL. I was actually referring to your specifics and protomyth's general statements about much of it not compiling, but it's obvious you are familiar with whatever the situation is. :)

Getting it out to be used by as many devs as possible is also a valid way of "nailing gown".

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact