Live data from Hacker News

“Swift will be open source later this year”

apple.com

91–100 of 573 posts

Re: “Swift will be open source later this year”

#92
post #51

People who talk about swift compare it to Rust and Go. I can see how the syntax is to ObjC what Go is to C++. Else but that, in what way is Swift anything like Go or Rust? To me (someone who does Lisp & JS, so none of these all) go seems cool for concurrency and being 'boring' (in a great way). Rust seems cool for being very robust and 'safe' (or hard to screw up with), while still doing concurrency nicely and lettin…

It's very familiar to Objective C but also very different. Strong type system and generics as well as functions being first class citizens add up to make it a great language. My only complaint is the IDE support, which is bound to improve.

Re: “Swift will be open source later this year”

#93
post #61
post #33

Earlier quoted context omitted.

I think Rust fills a slightly different niche with its safety-first principle, but Swift should eventually be a really attractive choice for anyone building cross-platform stuff that also needs to run on iOS.

Besides iOS/OSX support, what are Swift's features that make it interesting compared to other languages?

It appeals to the functional crowd; according to Apple's textbyte [here](http://www.apple.com/live/2015-june-event/eda6e3f7-0fda-4b46...), Swift 2 will have support for ObjC-style generics, pattern matching, and (presumably) an updated FFI for C.

I doubt it will be more attractive to functional programmers than Haskell, though; although the fact that it's an open source language that lets you do functional programming for iOS is pretty huge, IMO.

Re: “Swift will be open source later this year”

#94
post #90
post #57

Earlier quoted context omitted.

I'll second that when Apple and MS will support Vulkan on their OSes and open codecs in their browsers. Or to put it another way, when they'll stop using sickening lock-in to make life harder for everyone.

They support Unreal and Unity. Much better than supporting an API that requires 600 LOC for drawing a triangle and isn't available anywhere besides the reference platforms.

Supporting particular engines does not equal supporting open standards. It's not any better than zero rated services with ISPs. I.e. why should Apple or MS be gatekeepers for what engine should work and which shouldn't?

Apple at least is interested in Vulkan to some degree (they participate in Khronos). Whether it will show up on iOS is another question. But MS didn't show any interest. So claims that they changed their ways are premature.

Re: “Swift will be open source later this year”

#95
post #23

Earlier quoted context omitted.

As far as HN comments go, this one sets a pretty low bar. Is there even one doubt that this will happen? If not, the pedantic distinction between "announce they intend to" and "doing it" is extremely worthless...

We've been waiting ~5 years for the facetime open standard, so yes, there is some doubt.

That was a last-minute uninformed decision about a completely new product. Swift's open sourcing is clearly planned ahead of time and has actual the full backing of the company.

Re: “Swift will be open source later this year”

#96
post #85
post #35

Earlier quoted context omitted.

Apple also said they would make FaceTime an open and interoperable protocol "later this year". So being sceptical of Apple's promises of openness are justified.

For the nth time, this wold put on hold after a patent dispute.

His comment is older than any of the comments mentioning the lawsuit.

Re: “Swift will be open source later this year”

#100
post #51

People who talk about swift compare it to Rust and Go. I can see how the syntax is to ObjC what Go is to C++. Else but that, in what way is Swift anything like Go or Rust? To me (someone who does Lisp & JS, so none of these all) go seems cool for concurrency and being 'boring' (in a great way). Rust seems cool for being very robust and 'safe' (or hard to screw up with), while still doing concurrency nicely and lettin…

ObjC is really just plain C, plus some Smalltalk-like semantics within the square brackets. This means you end up with all the "footguns" of C, plus dynamic OO behavior.

Swift is like Rust in that it's intended to be fast, "safer", and compiles to LLVM bytecode. Also, Swift and Rust both use Option types for error reporting rather than exceptions or error codes.

In the same sense that Rust is a way to leave behind old C++ baggage, Swift is a way to leave behind old ObjC baggage such as header files, null pointer errors, and lack of real namespaces.

Post reply on HN