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

The Swift Programming Language

developer.apple.com

Post reply on HN
Print view View original

841–850 of 970 posts

Re: The Swift Programming Language

#841

Post by pjmlp »

seanalltogether wrote: post #51
Udo wrote: post #2

As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announcements are the most exciting in years. Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediat…

He mentioned the desire to drop the "C" from objective-c, but I'm curious what this means for using c/c++ libraries now. Do they need to be wrapped by objective-c before being visible in swift?

I hope so. Another stab on C's back.

Re: The Swift Programming Language

#842

Post by djhworld »

tptacek wrote: post #403
Udo wrote: post #2

As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announcements are the most exciting in years. Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediat…

I really don't see the Golang influence at all. The multiple- return- value semantic is closer to Ruby's than to Golang's; you're returning a tuple, which happens to have natural syntax in the language. Defining Golang features that don't exist in Swift: - Interface types with implicit adoption (Swift takes explicit protocols from ObjC) - Error types - Relatedly, the "damnable use requirement" and its interaction wit…

I think the style of defining functions is similar to Go. Not a carbon copy, but it "feels" Go-ish.

Re: The Swift Programming Language

#844

Post by pjmlp »

jernfrost wrote: post #686
angersock wrote: post #393

Earlier quoted context omitted.

I'm not really that impressed--it looks like a hodgepodge of ideas from ES6, Ruby, Go, and maybe Rust, with a bit of backend work done to let it work on their existing infrastructure. I dislike that Apple has continued the special snowflake approach, that for some reason we as developers need to learn yet another different-but-almost-the-same language to develop for them, instead of just adding proper support and doc…

There is already MacRuby and RubyMotion. They tried using Java years ago. It failed. Developers didn't like it. Existing stuff simply doesn't mix that well with Cocoa and that style of programming. That is why something like Swift was needed. I really don't get why you can bring up languages such as Rust and Go, and complain about Apple's special snowflake approach. Suddenly Apple is doing something developers have b…

That is not quite right.

The Java/Objective-C bridge existed in the early days as they weren't sure if developers would pick Objective-C, so they decided to bet on two horses.

As Objective-C eventually won the hearts of Mac OS X developers, the bridge was deprecated and a few years later the full Java support.

Re: The Swift Programming Language

#845

Post by Huperniketes »

jaydz wrote: post #313
Osmium wrote: post #254

Question: It sounds like the Xcode 6 beta is available on the dev center but I can't find it. Do you have to be a paying developer to have access to it, or does anyone know if it's going to be made available for free to (unpaid) registered developers?

I can't think of a reason why they wouldn't allow unpaid devs to play with Swift.

To get more devs to pay.

Re: The Swift Programming Language

#846

Post by pjmlp »

mantrax5 wrote: post #785
Pacabel wrote: post #782

Earlier quoted context omitted.

That's obviously not what I wrote, and you would know this had you bothered to read my comment. I'm saying that such features alone do not actually guarantee safety, if the language's implementation happens to have flaws. There hasn't been sufficient time and opportunity to see what Swift is like in practice. It's premature to say anything conclusive about it at this point, aside from stating that we don't yet have e…

The "flaws" discovered in Java aren't in the language, but in the most popular JVM implementations, most of which - surprise - are implemented in C (for the lack of a better alternative). Writing in Java still remains monumentally harder to fuck up in compared to writing all your code in C or C++. Furthermore, while Java relies on said relatively complicated interpreter + JIT virtual machine for its execution, Swift…

I am looking forward to see if Graal[1] replaces Hotspot in Java 9, thus replacing the amount of C/C++ code in the reference implementation.

[1] Oracle's JIT implemented in Java, from the meta-circular JVM Maxime

Re: The Swift Programming Language

#847

Post by pjmlp »

theseoafs wrote: post #588
xenadu02 wrote: post #330

Earlier quoted context omitted.

Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know tot…

> It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. And since memory-safe languages are written in non-memory-safe languages (i.e. C and C++), writing code in them is unethical as well, right?

Well, most implementations of Ada, Oberon and Modula-2 compilers among many others were boostraped, no C code in sight.

Re: The Swift Programming Language

#848

Post by toyg »

angersock wrote: post #800
jernfrost wrote: post #686

Earlier quoted context omitted.

There is already MacRuby and RubyMotion. They tried using Java years ago. It failed. Developers didn't like it. Existing stuff simply doesn't mix that well with Cocoa and that style of programming. That is why something like Swift was needed. I really don't get why you can bring up languages such as Rust and Go, and complain about Apple's special snowflake approach. Suddenly Apple is doing something developers have b…

Suddenly Apple is doing something developers have been demanding from them for years and something lots of other companies like Google, Mozila and Microsoft has already done. And yet they've decided to do it again, with yet another incompatible language! Joy of joys! (And as for Java, it was my understanding that Apple had hobbled it by refusing to release updates on a timely basis.)

> Apple had hobbled it by refusing to release updates on a timely basis.

I can see how they could get tired of being forced to ship almost-monthly updates just to support an extra language with very limited adoption. If you have to make that sort of effort, you'll probably do it for your native tools only (like Microsoft does with .Net). Besides, Java apps on OSX looked better than Java apps on Windows, but they were still recognizably different from Obj-C ones.

I wish somebody would write an OS in Python 3...

Re: The Swift Programming Language

#849

Post by pjmlp »

Pacabel wrote: post #646
xenadu02 wrote: post #330

Earlier quoted context omitted.

Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know tot…

So what other language can we use today on basically any imaginable platform, while still retaining the extreme degree of control, the excellent interoperability, and the near-optimal runtime performance of C? Some will say Rust, but we're years away from that being realistic. C++, using modern techniques, is perhaps the only feasible response. While there may be some validity to your claim about "billions of human b…

C is dead on Windows and I hope Microsoft does not change its mind.

C is almost dead on Android, with its minimal exposure on the NDK and I hope Google does not change its mind about it.

C is now being killed on MacOS X and I look forward to Swift's success.

So this leaves out the embedded industry (slowly moving to Ada and Java on IoT) and the hardcore UNIX guys.

Re: The Swift Programming Language

#850

Post by emn13 »

jacobevelyn wrote: post #450
angersock wrote: post #393

Earlier quoted context omitted.

I'm not really that impressed--it looks like a hodgepodge of ideas from ES6, Ruby, Go, and maybe Rust, with a bit of backend work done to let it work on their existing infrastructure. I dislike that Apple has continued the special snowflake approach, that for some reason we as developers need to learn yet another different-but-almost-the-same language to develop for them, instead of just adding proper support and doc…

Agreed that the lack of using an existing (and open-source!) language is annoying and frustrating to deal with (think of where we'd be if they invested that time and effort into improving Ruby/Python/whatever instead!). But because of the desire for compatibility with Objective-C, and Apple's general desire to call all the shots regarding their ecosystem, this move doesn't surprise me in the least.

The fact that this has static typing is a huge difference to "just improving" ruby/python. That approach couldn't come close to getting the same early-error-catching dev experience, and performance. And amongst static languages, Apple wasn't likely to recommend C++ as simple, were they? And Rust/D are also quite low level, nor do they have the Objective-C legacy to consider. So really, you're probably left with C# (or maybe Java), and those are so old and large (esp. the libraries) by now that they're unlikely to naturally port to Apple's environment.

Frankly, a bit of a clean up every decade or two is not exactly often, right?

Post reply on HN