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

Swift Programming Language Evolution

github.com

Post reply on HN
Print view View original

91–100 of 181 posts

Re: Swift Programming Language Evolution

#91

Post by igouy »

kzaher wrote: post #56
thomasahle wrote: post #25

Earlier quoted context omitted.

By http://benchmarksgame.alioth.debian.org/u64q/which-programs-... Swift's performance is similar to Java's, but quite a bit faster when working with many objects: http://benchmarksgame.alioth.debian.org/u64q/swift.html On a few benchmarks it's faster than C as well: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... though not most. I suppose they were able to do the binary-tree benchmark so much better…

I don't think these benchmarks are realistic. Yes, you can use UnsafePointers, but that's not the real world case. ARC, runtime generics and structs have a huge cost in real world programs. Swift is unfortunatelly usually an order of magnitude slower then Java and C# in real world according to last benchmarks I've made. I'm hoping that will change because I really love Swift.

Please contribute Swift programs that you think are "the real world case":

http://benchmarksgame.alioth.debian.org/play.html

Re: Swift Programming Language Evolution

#92

Post by DonFromWyoming »

andybak wrote: post #74
DonFromWyoming wrote: post #26

The removal of prefix and postfix ++ and -- operators and the removal of C-style for loops are mistakes, IMO.

With regard to C-style for loops - other than familiarity - why? It always struck me as a fairly warty syntax. Consider Python where you usually do: for item in iterator If you want an integer sequence it's: for integer in range(1, 100) and for those rare occurrences where you need an integer index as well: for index, item in enumerate(iterator) Swift seems to have a similar approach. Why would you ever want the C-st…

For the simple case with a single iterator, yes the C-style for loop isn't as concise. However, there are lots of real-world situations where there is not a single iterator (e.g. looping through 2 arrays). Having to go back to 'while(boolean) { }' loops with initializers outside of the loop and incrementors at strange places inside the loop is much more confusing and error prone.

Re: Swift Programming Language Evolution

#93

Post by jsingleton »

kris-s wrote: post #8
Someone1234 wrote: post #2

So Swift has been out awhile, what do people think of it? What other language would you compare it to (e.g. C#, C, C++, etc)? What about the libraries are they well laid out?

My favorite thing about Swift is that is seems to get out of the way - and when it gets in the way it's usually with a nifty language feature (like the { $0 + $1 } closure syntax). I'm very excited for the future - between Go and Swift we now have two compiled fast languages that are almost as expressive as their slower dynamic/interpreted cousins. As an aside, I like that Apple is betting the farm on ARC. I wish I c…

For anyone curious as to what ARC is in this context (not the dialect of Lisp HN is written in): https://en.wikipedia.org/wiki/Automatic_Reference_Counting

Last time I did any Objective-C you had to retain/release yourself so the auto stuff is interesting. As far as I can tell the benefit over Garbage Collection is that GC only works well when you have lots of excess spare memory, which is constrained on mobile devices.

Re: Swift Programming Language Evolution

#94

Post by skrowl »

zepto wrote: post #69
skrowl wrote: post #19

Earlier quoted context omitted.

I tried it an pretty quickly went back to C#. The Apple-only nature was the major downside to me, so maybe these kinds of changes will help (assuming it sees wide adoption outside of Apple-land). Check your local job boards, but if sell yourself as a Swift dev you're likely to be pigeon-holed into Apple-centric development for the foreseeable future. With Apple sales and market share dropping like a rock in the last…

Completely false. Neither sales nor market share have been dropping like a rock. Apple had had their first year on year revenue decline in 13 years of continuous growth, but there is no indication that that anything is 'dropping'.

I didn't really want to get into the reasons why. I was just pointing out that investing in an Apple-only tech might be a bad idea because it sure looks to me (and the stock market) that Apple has peaked and is now on the decline.

However, since you said my statement was completely false without a source, I felt compelled to show my sources.

51 million iPhones sold compared to 61 million the same quarter last year a DROP of 10 million. iPad an Mac also down double digit percentages, but iPhone is the only thing that really drives Apple. Overall sales DROP from $58B to $50B Source: http://money.cnn.com/2016/04/26/technology/apple-earnings/in...

iPhone market share also DROPPED from 18.3% to 15.3% in Q1. Source: https://www.idc.com/getdoc.jsp?containerId=prUS41216716

Sure Apple makes a ton of money and profit still, but you can't really argue that it's not dropping like a roick in the past 12 months. If you put $1,000 into Apple stock a year ago today, you'd have about $700 today. Source: https://finance.yahoo.com/echarts?s=AAPL+Interactive#{%22all...

Let me know where I went wrong, but I'm showing double digit sales drops, a large market share drop, and 30% stock value drops in the last 12 months. I'm not sure how my post is "completely false".

Re: Swift Programming Language Evolution

#95

Post by joewillsher »

DonFromWyoming wrote: post #92
andybak wrote: post #74

Earlier quoted context omitted.

With regard to C-style for loops - other than familiarity - why? It always struck me as a fairly warty syntax. Consider Python where you usually do: for item in iterator If you want an integer sequence it's: for integer in range(1, 100) and for those rare occurrences where you need an integer index as well: for index, item in enumerate(iterator) Swift seems to have a similar approach. Why would you ever want the C-st…

For the simple case with a single iterator, yes the C-style for loop isn't as concise. However, there are lots of real-world situations where there is not a single iterator (e.g. looping through 2 arrays). Having to go back to 'while(boolean) { }' loops with initializers outside of the loop and incrementors at strange places inside the loop is much more confusing and error prone.

You can use the zip function to loop through 2 collections.

`for (l, r) in zip(c1, c2) {`

It is not simply motivated by making code concise, I would say `for num in collection.reverse()` is less error prone and clearer than `for (var i = collection.count; i >= 0; i--) { var num = collection[i] ... }`

The reverse collection iterator is computed lazily too, so there is no little perf overhead

Re: Swift Programming Language Evolution

#96

Post by hedgehog »

mikeash wrote: post #51
ryandev wrote: post #27

I've never understood the fascination with Swift. What's wrong with Objective C?

Objective-C has no safe collections for non-object values. If you want an array of ints, for example, you either get to use a C array with lots of manual management and potential for error, or you use an NSArray of NSNumbers and pay for a bunch of overhead. It has very poor support for custom value types. Objective-C structs basically can't contain object pointers, so they're limited to simple things like CGRect. The…

I'd add typed enums to the list of notable bug-avoiding improvements in Swift. I sometimes describe Objective-C as "all of the memory safety of C with the type safety of SmallTalk".

Re: Swift Programming Language Evolution

#97

Post by danappelxx »

jaegerpicker wrote: post #89
Someone1234 wrote: post #2

So Swift has been out awhile, what do people think of it? What other language would you compare it to (e.g. C#, C, C++, etc)? What about the libraries are they well laid out?

I have a production app in the AppStore in 100% swift 2.2. To me it's the most exciting new language out right now. It does not have too many brand new features that other languages don't have but it's implemented most of those modern features in a very solid robust easy to understand and use way. It's functional but not purely, it's object oriented but has great ways to avoid the worst of the designs most of us have…

How are generics 'fuzzy at best'? I can understand why you could think that associated types in protocols can be a pain in the ass, but there are reasons why its done this way.

Re: Swift Programming Language Evolution

#98

Post by jaegerpicker »

danappelxx wrote: post #97
jaegerpicker wrote: post #89

Earlier quoted context omitted.

I have a production app in the AppStore in 100% swift 2.2. To me it's the most exciting new language out right now. It does not have too many brand new features that other languages don't have but it's implemented most of those modern features in a very solid robust easy to understand and use way. It's functional but not purely, it's object oriented but has great ways to avoid the worst of the designs most of us have…

How are generics 'fuzzy at best'? I can understand why you could think that associated types in protocols can be a pain in the ass, but there are reasons why its done this way.

Sorry was generalizing. I meant generics and protocols in combination. The ability to define a protocol based on a generic would be fantastic. It's something that is solved in Haskell fairly well.

Re: Swift Programming Language Evolution

#99

Post by danappelxx »

twoodfin wrote: post #79

To me, the most interesting empirical result of the Swift language evolution so far is the lack of urgency on language-level concurrency. If they think they can be competitive for years (at the very least vs. Objective-C) with only platform-level concurrency support, it makes me wonder whether concurrency is generally better provided by the platform instead of the language for most needs. Conventional wisdom would ha…

I'm not sure if Swift really needs language-level concurrency support. As it stands, you can wrap any C library which provides some sort of concurrency and make it feel like native functionality because of Swift's syntactic sugar such as trailing closures. For example, I'm a huge fan of the library Venice[0] which provides CSP by wrapping libmill (single-threaded like libuv, uses setjmp/longjmp instead of callbacks unlike libuv), essentially providing a Go-level api without language-level support. Its what Zewo[1] is built off of, and what allows all of its api's to be synchronous without any extra effort.

[0] https://github.com/VeniceX/Venice

[1] https://github.com/Zewo/Zewo

Re: Swift Programming Language Evolution

#100

Post by carlosrg »

danielrhodes wrote: post #87
skrowl wrote: post #24

Earlier quoted context omitted.

You may have missed the announcement where MS bought out Xamarin and is now giving it away for free. You owe it to yourself to at least give it a try while waiting for actual cross-platform Swift. 90+% of your mobile code can be shared between Android and iOS. Not sure if that's something currently possible with Swift or not, but it was worth keeping C# around for our needs. We're more of a "mobile app is something w…

If there was a common native language between Android/iOS, it would make things easier for sure. But using a third language to solve the existing problem is a rookie error. > 90+% of your mobile code can be shared between Android and iOS This stat depends on how complex your app is, but it usually only applies to gaming. Otherwise it's almost always false. We've already been down this path with the webview craze a fe…

I can see you have no idea what Xamarin is. With Xamarin, you still use UIKit and the native Android UI, the difference is that you program it in C# and thus the non-UI code can be shared seamlessly. Performance is not "very meh" as the UI is completely native and Xamarin compiles the C# to native code ahead-of-time. It has literally nothing to do with WebViews.
Post reply on HN