Live data from Hacker News

Swift Programming Language Evolution

github.com

71–80 of 181 posts

Re: Swift Programming Language Evolution

#71
post #29

Earlier quoted context omitted.

I love go but if one thing that it is not is - expressive, especially when compared to its dynamic cousins like Ruby/Python. That is a tradeoff I am willing to live with, but there is no need to get starry eyed over it.

Can you give an example? I've been writing a bunch of swift recently and I actually find it somewhat more expressive than either of those.

GP was talking about Go. Not to beat a dead horse, but not having generics results in writing similar code over and over again, eg working with collections

Re: Swift Programming Language Evolution

#72

Earlier quoted context omitted.

Can you give an example? I've been writing a bunch of swift recently and I actually find it somewhat more expressive than either of those.

GP was talking about Go. Not to beat a dead horse, but not having generics results in writing similar code over and over again, eg working with collections

ah, apparently i'm blind. yeah, swift generics are nice even though they can be somewhat tricky to work with.

Re: Swift Programming Language Evolution

#73
post #21

Earlier quoted context omitted.

I'd put Go at the top of the languages to compare it to. Maybe Java as well. The ecosystem still needs some time, but Swift's potential on the server is excellent: - It is incredibly fast compared to current interpreted languages (i. e. factor 30+ vs. Python, possibly faster than C) - Linux & OS X, open source - Typed, safe People like node.js mostly b/c it allows some code to be written once and run on both the serv…

Every new language has someone claim it's faster than C. I'll believe it when I see it.

C used to be very slow for 8 and 16 bit home micros to the point hobby Assembly coders could write much better code.

It arrived where it is today thanks to 40 years of research and exploring UB in optimizations.

Re: Swift Programming Language Evolution

#74

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-style iterators?

Re: Swift Programming Language Evolution

#75

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?

Having developed in Objective-C since iPhone was released, I am very appreciative of Swift. It really puts in a lot of effort to make it hard/impossible to write code that crashes. Swift is such a safe language to develop in, I was able to switch from ObjC to my first Swift project and release builds to my client for months without any reported crashes in my code.

Re: Swift Programming Language Evolution

#76
post #49

Earlier quoted context omitted.

I gotta disagree with this one. Those operators have always been confusing and unnecessary. j = i++ being different from j = ++i alone is enough to convince me it's gotta go.

++i and i++ have their uses. Just because it is confusing to you doesn't mean it is confusing to others. There are things about swift that are confusing to me, but I don't out right say that it has to go. Chalk this one up to shit hacker news says.

I believe something can be easy to understand (as is i++/++i) but also confusing.

Things that require a double take to read and parse do not help. Additional solutions to the same problem do not help.

There's a lot of cleverness that can come up in programming that may make for neat/short writing but that makes reading and purpose less clear. i++/++i helps with that with no special benefits.

I like how the Swift team approached the decision to remove them: thinking on whether it would make sense to add them had they not been there. And it doesn't, as they solve no particular problem; they're just a special, (not much) shorter solution to something that's already solved.

Re: Swift Programming Language Evolution

#77
Swift is great language and an enormous leap forward in the apple-sphere. I'd like to see a bigger investment in JavaScript everywhere. I'd like to see apple make a push to allow writing 100% javascript apps for iOS and mac. I think it could be a huge differentiator for iOS and Mac development and it would bring to Apple the largest developer base out there.

Re: Swift Programming Language Evolution

#78
post #56

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.

Agreed. Swift is quite high-level compared to C or C++, for examples. As with any languages, there are tradeoffs with performance.

Re: Swift Programming Language Evolution

#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 have it that for a systems & application language designed in 2014, a good concurrency story would be close to job #1.

Post reply on HN