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

101–110 of 181 posts

Re: Swift Programming Language Evolution

#101

Post by thevibesman »

thedevil wrote: post #7
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 made an app with Swift (my only iOS app). I like it. I like clean, easy-to-read languages where I can get stuff done quickly and reading code isn't a huge pain and using a new library isn't a huge pain. Swift seems to fit those preferences so far. The debug messages were confusing. I never used Obj-C so I'm not sure if that's iOS or Swift that causes confusing error messages.

> The debug messages were confusing. I never used Obj-C so I'm not sure if that's iOS or Swift that causes confusing error messages.

While it has gotten a little better, it is Swift.

(EDIT:) But I've been loving Swift so far! I've found that there is some consistency to the weird errors, so eventually you can start to map them to past experiences.

Re: Swift Programming Language Evolution

#102

Post by Gankro »

steveklabnik wrote: post #48
snuxoll wrote: post #39

Earlier quoted context omitted.

Generally data lifetime in rust is fully deterministic and the borrow checker can statically determine when data should be deallocated. If for whatever reason you do need reference counted semantics there are options in the stdlib (alloc::rc).

And to elaborate on this, there's a namespace clash: Arc in Rust is _atomic_ reference counting, and Swift is _automatic_ reference counting, which, even more confusingly, is implemented using atomic reference counting in my understanding. Automatic reference counting inserts all of the refcount bumps. In Rust, you have to write the up count yourself, but not the downcount. But, reference counting isn't used very oft…

As far as I can tell, the impl of Arc and ARC are actually basically identical at the high level, with the only major diff being ARC only keeps 32-bit counts on 64-bit (so they only waste one pointer of space).

Everything else is just where retain/release (clone/drop) calls are made. Rust is insanely good at not frobbing counts because you can safely take internal pointers and move pointers into a function without touching the counts at all. Swift has lots of interesting optimizations to avoid touching the counts, but it's hard to compete with a system that has so much great static information related to liveness of pointers and values.

As a simple example, consider this code (which is conveniently valid Swift and Rust, modulo snake_vsCamel):

    let x = make_refcounted_thing();
    foo(x);
This code in isolation will always not frob counts for Rust. This code may not frob counts in Swift, depending on what follows `foo`. In particular if foo is in tail position (or at least tail-position-for-the-life-of-x), then we can avoid frobbing, because we know foo's final operations will be to release its function args. foo may in turn punt releasing its function args to anyone it passes them to as a tail call. Note that Swift and Rust both have the usual caveats that "less is a tail call than you think" thanks to side-effecting destructors.

The takeaway is that Rust's default semantics encourage releasing your memory earlier, which in turn means less traffic on the reference counts. Particularly interesting is that in Rust, you can run a function arg's destructor earlier than the end of the function by moving it in to a local variable. In Swift, I do not think this is possible (but I wouldn't be too surprised to be wrong -- Swift has tons of special attributes for these little things).

Re: Swift Programming Language Evolution

#103

Post by dang »

Submitters: Please don't rewrite titles to say what you think is important about an article. Cherry-picking a single detail is a form of editorializing, which HN doesn't allow in story titles. The guidelines ask you to change titles only when they're misleading or linkbait, which wasn't the case here.

If you think one detail is most important, you're welcome to comment on that in the thread. Then your opinion is on the same level as other users'.

(Submitted title was 'Swift 3 will be portable / be able to run on more platforms'.)

Re: Swift Programming Language Evolution

#104

Post by oscargrouch »

tyingq wrote: post #47

Does "will be portable" include any notion of a cross-platform UI?

I think not, but im working on a application platform where the sdk is in swift. Im using the chrome runtime, so im binding into the chrome compositor, the same rendering engine that the webkit uses. This part is almost finished, and is rendering properly , i just need to finish creating the finished components(buttons, etc..) over the ui view.

Im trying to create a distributed application platform, using the bittorrent DHT for that.. so this is the part im working on right now.

I hope i can launch this in a couple of months from now, so swift can have a multiplatform UI and where applications can be distributed in a decentralized way.

Re: Swift Programming Language Evolution

#105

Post by thevibesman »

gagege wrote: post #64
lanestp wrote: 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.

Exactly. I am disappointed they're removing function currying/partial application syntax though :(

This was my first reaction as well, but then I realized I hadn't done much currying in Swift and half forgot it was a feature.

Maybe you can bring it back when we get hygienic macros (Swift 4.0? fingers crossed)

Re: Swift Programming Language Evolution

#106

Post by thevibesman »

hedgehog wrote: post #96
mikeash wrote: post #51

Earlier quoted context omitted.

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".

I may steal that quote; I think I like it better than calling Objective-C the "wild west of OOP".

Re: Swift Programming Language Evolution

#107

Post by pcwalton »

api wrote: post #17
kris-s wrote: post #8

Earlier quoted context omitted.

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…

I'm always a bit fascinated when what everyone knows is the next thing turns out not to be. RISC is a classic example. (ARM is light CISC compared to the sort of true minimal RISC I'm talking about.) GC is borderline but it feels like it might be one of those. In retrospect one giveaway is how easy it is to avoid almost all memory problems in C++ with RAII and STL.

> In retrospect one giveaway is how easy it is to avoid almost all memory problems in C++ with RAII and STL.

Not at all. It's easy to think you're avoiding those memory problems, but they invariably crop up again and again.

Re: Swift Programming Language Evolution

#108

Post by zepto »

skrowl wrote: post #94
zepto wrote: post #69

Earlier quoted context omitted.

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…

There have been 30% stock price drops multiple times during the 13 years of continuous growth. They are clearly not correlated with the actual growth prospects, and if the stock market actually thought that Apple was dropping like a rock as you claim, you would expect to see a far higher discounting.

You mention the Mac, which as declined in absolute terms but has continued to grow relative to the declining market.

The same is true of the iPad, and there is evidence that it's decline is actually halting - I.e. it is reaching a plateau that is lower than its peak. Whether it will return to growth or not is an open question, but it is clearly not dropping like a rock.

So - the stock market story doesn't support your conclusion, nor does the iPad or Mac.

That leaves the iPhone. It is possible that the iPhone has reached a peak in terms of revenue.

Is it possible that it has reached an all time high in terms of active user base? That seems extremely unlikely.

For one thing, the total number of iPhones sold per year is still astronomical, and the devices have a long useful life. Even without a change of strategy, there will still be a huge number of new iPhone customers over the coming years.

Secondly there are many possible strategic solutions to a reduction in sales. Apple is selling far more SE devices than they anticipated, suggesting that there is pent-up demand for cheaper iPhones. They can address this segment easily, which will continue to increase the user base of IOS, even if revenue growth stagnates as a result of lower ASPs. This is just one possible strategy adjustment that would address the concern.

As I said, there has been a decline, but nothing supports your conclusion that Apple is 'dropping like a rock'. As such this is a bad conclusion on which to make a choice about whether to learn Swift or not.

Re: Swift Programming Language Evolution

#109

Post by riyadparvez »

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…

Can you elaborate more on Swift vs Scala? What are the strong and weak sides of each language?

Re: Swift Programming Language Evolution

#110

Post by pcwalton »

jsingleton wrote: post #93
kris-s wrote: post #8

Earlier quoted context omitted.

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 devic…

There are hybrid systems that combine the prompt deallocation of pure reference counting with the superior throughput of tracing garbage collection.

Part of the reason I really dislike the "reference counting vs. garbage collection" debate, and keep emphasizing that reference counting is garbage collection, is that it sets up this false dichotomy. In reality, there are all sorts of automatic memory management schemes that combine aspects of reference counting with tracing in different ways, most of which were created in the 80s and 90s. Sadly, almost nobody in industry is aware of this enormous body of work, and the simplistic "RC vs. GC" model has stuck in everyone's heads. :(

Post reply on HN