Live data from Hacker News

Swift Programming Language Evolution

github.com

111–120 of 181 posts

Re: Swift Programming Language Evolution

#111

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

A bit of justification would be nice why you think Swift can be faster than C.

Re: Swift Programming Language Evolution

#112
post #84

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?

For people coming from C/C++/ObjC, some things in Swift can take some time to get used to, e.g. if case .Success(let person) = personResult { ... } My first thought when I saw this was, "only mother could love this syntax", but later you come to appreciate and enjoy the syntax. Link: https://www.natashatherobot.com/swift-guard-better-than-if/

I love guard statements, but Swift's `if case...` syntax is horrendous. I'm approaching a year of full-time Swift and I still struggle to get the syntax right on the first try.

Re: Swift Programming Language Evolution

#113
post #8

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…

>I wish I could have been a fly on the wall when they were discussing ARC versus GC.

Apple shipped a tracing GC (RC is a form of GC) for a while, but couldn't get it to work reliably or with adequate performance. ARC was a bit of a "Hail Mary" and is problematic in its own right, but certainly better than the GC it replaced.

Marcel

Re: Swift Programming Language Evolution

#114

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

> prefix and postfix ++ and -- operators

IMHO, these operators are the worst features of C. Particularly I never understand the necessity of both i++ and ++i operators in language at the same time.

Re: Swift Programming Language Evolution

#115
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…

Not just is reference counting a form of garbage collection (as pcwalton pointed out), it is also not the case that you had to retain/release stuff yourself, certainly not since Objective-C 2.0's properties.

Here is the code to define and use a property pre ARC with properties:

   @property NSString *name;
   ...
   object.name = @"Marcel";
And here is the same code with ARC:

   @property NSString *name;
   ...
   object.name = @"Marcel";

Spot the difference? Now it turns out that there are some differences, such as automatic generation of -dealloc methods and weak references and some cosmetic stuff. But overall, it's at best a subtle difference and for most code you won't be able to tell the difference.

Pre Objective-C 2.0, there were solutions such as AccessorMacros[1], which handled the same use-cases except without the dot syntax (which is somewhat questionable) and have the advantage of being user-defined and user-extensible, so for example if you want a lazy accessor, you don't have to wait for your liege lord, er language supplier to add them, or create a whole new language to do the trick. Instead, you just write 4-5 lines of code and: done!

[1] https://github.com/mpw/MPWFoundation/blob/master/Classes/Acc...

Re: Swift Programming Language Evolution

#116

Earlier quoted context omitted.

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…

Not just is reference counting a form of garbage collection (as pcwalton pointed out), it is also not the case that you had to retain/release stuff yourself, certainly not since Objective-C 2.0's properties. Here is the code to define and use a property pre ARC with properties: @property NSString *name; ... object.name = @"Marcel"; And here is the same code with ARC: @property NSString *name; ... object.name = @"Marc…

This is one of the most uninformed posts I have read in a while. As someone who has been developing in Objective C for the last 6 years, and been through the transition of MRC to ARC, none of what is stated in this post is accurate.

Re: Swift Programming Language Evolution

#117
post #108
post #94

Earlier quoted context omitted.

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. T…

I apologize, as I seem to be failing to convey my message to you.

My assertion: Apple is dropping. Be careful about investing in Apple-only techs like Swift.

Your argument (I think): Apple is not dropping like a rock.

To support your argument, please provide a sources for the following:

- The last time Apple stock was down 30% from same day prior year.

- iPhone sales are not dropping > 10% (hence 'like a rock') .

- Mac sales are not dropping > 10% (hence 'like a rock').

- iPad sales are not dropping > 10% (hence 'like a rock').

- How iPhone + Mac + iPad all being down over 10% from prior year doesn't support my conclusion.

Re: Swift Programming Language Evolution

#118
post #108
post #94

Earlier quoted context omitted.

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. T…

This "dropping like a rock" quarter was Apple's third most profitable Q2 of all time and they made more money than Alphabet, Microsoft, and Facebook combined. The Apple Watch so-called "flop" is estimated to have outsold Rolex by $1.5 billion in the past 12 months. Their services revenue grew by 20% year-on-year.

At some point you have to realise that there's nothing Apple can do that would count as a success in some people's eyes. They are the most successful total failure I've ever heard of.

Re: Swift Programming Language Evolution

#119
post #82
post #18

Earlier quoted context omitted.

No - they already had GC working with Objective-C and could have chosen it for swift if they had thought it was the best technology. Here's a quote from Chris Lattner: "GC also has several huge disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted much more memory than the process is actually using. Generally, unless yo…

Yes, they had GC working with Objective-C but there were so many problems with it that they dropped the GC in favor of ARC years ago. By the time Swift came along, GC with Objective-C was no longer an option.

And it was only an option on OS X, never on iOS.

Re: Swift Programming Language Evolution

#120
post #33

Earlier quoted context omitted.

Lots of languages ARE faster than C, including older languages than C, like Fortran and Forth. Being faster than C is not anything special in itself. Most things being equal (typed, optimized, compiled, no runtime etc) C is mostly faster when it does something with a lower overhead than some other language (e.g. a specially written hashmap algorithm targeted to some program vs C++ std map type), not because of its pr…

Fortran especially. Forth seems to depend on processor characteristics. I seem to remember that Ada compilers routinely produce faster code than C compilers.

Ada and Rust are both significantly easier to perform aliasing analysis on, so frequently you can get much better code. Both languages have slight overhead for bounds checking and such, but you can turn it off (at least in Ada) if it's a problem (hint: it isn't).

Same reason Fortran is fast actually: it just disallows pointer aliasing entirely¹, meaning you get none of the flexibility of C pointers (heck, you don't even have pointers, basically), but if you're multiplying matrices it flies.

¹ I recall newer Fortrans have pointers, but as I'm not a Fortran programmer I don't actually know.

Post reply on HN