17 ms·

Swift Programming Language Evolution

175 points by rufus42 10y ago

Someone1234 10y ago
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?
- untog 10y ago
  I've been playing around with it a little and it's... fine? Very capable. Not run into any moments that have blown my mind, but neither have I found any that disgusted me. In a weird way it actually reminds me most of TypeScript - JavaScript-y, but with types and stronger enforcement of rules.
  - tomelders 10y ago
    I've been quipping that Swift is the Javascript of tomorrow, today!
- supster 10y ago
  I'm a big fan. I love the statically inferred type system, generics, & optionals. Also really like a lot of the functional programming concepts + value types but still enjoy being able to fall back on OOP. It feels like the best of both worlds. I can't wait till we have language native concurrency techniques, so I can start writing swift in backend code.
  - RotsiserMho 10y ago
    I was disappointed to see that concurrency support won't be in Swift 3.0.
    - thramp 10y ago
      Me too, but I’d I realized that I’d rather the Swift team not half-ass such a big feature, especially when they’re working on ABI stability and translation of Foundation API’s. Plus, I bet one of the things that’s holding proper concurrency back are Apple’s frameworks. I’d rather deal with callbacks for another year or two than use a rushed language feature.
    - chrisamanse 10y ago
      Concurrency is done with libdispatch library, which is also open source. Right now, it's only compatible with OS X, but int their post, they said that "For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries." https://swift.org/blog/swift-3-0-release-process/ https://swift.org/blog/swift-3-0-release-process/
- thedevil 10y ago
  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.
  - thevibesman 10y ago
    > 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.
- kris-s 10y ago
  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 could have been a fly on the wall when they were discussing ARC versus GC.
  - quux 10y ago
    I think they had to go with ARC due to the requirement that swift interoperates with Objective-C. If that hadn't been a constraint, yeah it would be an interesting decision.
    - deleted 10y ago
      [deleted]
    - zepto 10y ago
      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 you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life). I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs."
      - quux 10y ago
        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.
- matt4077 10y ago
  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 server as well as the client. Considering almost any Web API also has an IOS client, Swift has the same potential.
  - lorenzhs 10y ago
    Do you have a link to some benchmarks at hand? Your "possibly faster than C" claim sounds too good to be true without a source, but I'd very much like to be proven wrong :)
    - thomasahle 10y ago
      By http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html 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 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?lang=swift&lang2=gcc 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 than Java, because Swift supports 'UnsafeMutablePointers': http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=5 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... Edit: This Quora question mentions the performance of Swift before and after unsafe programs were included: https://www.quora.com/In-terms-of-performance-speed-is-Swift-faster-than-Java https://www.quora.com/In-terms-of-performance-speed-is-Swift... The memory safe version used to be about 24x slower than C.
      - igouy 10y ago
        >> I suppose they were able to do the binary-tree benchmark so much better than Java, because … because it's faster to use a memory pool than GC for that … ditto C Rust Ada Fortran C++ … http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees http://benchmarksgame.alioth.debian.org/u64q/performance.php...
- skrowl 10y ago
  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 12 months, that might not be the best position to put yourself in long term, career-wise.
  - beerwulf 10y ago
    That's rich coming from a C# developer looking at mobile...
    - skrowl 10y ago
      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 we also offer" and web is our main presence though, so your mileage may vary (especially if you're mobile-only or mobile-centric).
      - neppo 10y ago
        90%+ shared code is a bold claim, Xamarin.com states 60-90%. In my experience it's closer to 60%.
      - danielrhodes 10y ago
        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 few years ago. It was a total nightmare. These newer cross platform frameworks may no longer use webviews, but under the hood things are just as gross. What is true though is that these cross platform frameworks always oversell themselves (with the exception of Unity3D). You end up trading in one problem for another. Among the many problems you will encounter: 1. You miss a lot of newer features in the native platforms. If you want to incorporate those features somehow, the code becomes a conditional mess. 2. Performance is very meh and your hands are mostly tied in optimization. In both Android and iOS, getting performance correct (for example in a table view) requires a lot of tweaking. All of the cross platform frameworks I've used, including React Native, work for basic cases but quickly start dropping frames after that. 3. The majority of a mobile app's code is front-end, and this is not the place where you want to share code. Users on each platform expect different types of interactions and behaviors, not to mention UI aesthetics. 4. These different platforms all have their own characteristics and ways of doing things. These differences are not easily abstracted out. At the point where you are coding around these differences, you might as well have two different code bases. For all the complaining about differences between WebKit/Chrome/IE etc, the behavior is remarkably similar -- mobile platforms are far more diverged. 5. Native third-party libraries are very difficult to use because there is never the same library on the other platform. If there is, say with Facebook, they are not in sync. 6. You end up writing a lot of bridge code between iOS/Android and the framework. It's never pretty and painful to debug. 7. Getting locked into a third-party's framework is a bad place to be later on. Once it's in there, it's never coming out. I could go on... If you absolutely need to go cross platform early on, the best thing you can do for yourself is to lock down a common API/data model as early as possible, and create an aesthetic and design that is simple to implement on both platforms.
- yousry 10y ago
  The neat syntax is sometimes butchered by unnecessary casting orgies. Swifts outstanding feature is its simple C interoperability. The compilation times (Xcode) are lengthy compared to C or C++. Example: https://youtu.be/mgpAmqdiPKE https://youtu.be/mgpAmqdiPKE
- nv-vn 10y ago
  Semantically, it's probably closest to Rust (from my limited exposure). The syntax is slightly changed, but most things have a direct parallel between the two languages. Although Swift doesn't do ownership/borrow checking like Rust does and is a lot more relaxed in that department.
  - valarauca1 10y ago
    Apple actually directly cites Rust as inspiration for Swift.
- iheart2code 10y ago
  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.
- Koshkin 10y ago
  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/ https://www.natashatherobot.com/swift-guard-better-than-if/
  - jkubicek 10y ago
    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.
  - protomyth 10y ago
    I've used ObjC since NeXTSTEP 3.3, and I'm trying to work with Swift. At this point, I've classified it in the same vein as Transact-SQL, a language I need to learn and use, but one I will not love. I guess I love the selector syntax too much. Shame that F-Script never caught on.
- jaegerpicker 10y ago
  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 been bitten by in the past. We are in a Java, PHP, Node.js, and Swift shop. Swift is BY far the least bug prone and most stable code. It's fast and easy to understand. It's not perfect, Generics and Protocols are fuzzy at best and if you aren't careful with optionals you can actively harm the stability of your code base. It has a long way to go on the server side but I do believe that it will and should be a great server side language platform. That said in my opinion it's the best language I've worked with professionally. For reference I've professional written a decent amount of code in: Python Java C# C++/C Objective-C Perl PHP Node.js/JavaScript VB6/VB.net Ruby Groovy Scala
  - danappelxx 10y ago
    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.
    - jaegerpicker 10y ago
      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.
      - Razengan 10y ago
        Isn't that somewhat possible with extensions and constraints? At least that was the impression given by last year's WWDC talk [1], unless you're thinking of something else? [1]: https://developer.apple.com/videos/play/wwdc2015/408/ https://developer.apple.com/videos/play/wwdc2015/408/
- corford 10y ago
  For me the most exciting thing about Swift is the recent rumour that Google are looking at adopting it as a first class language for Android. If that happened, you'd finally have an open, fast, expressive, modern language that you could use on the server and on the fronted for iOS and Android. Couple that with Typescript & Aurelia for the web frontend and I'd be in programming nirvana.
  - deleted 10y ago
    [deleted]
Karunamon 10y ago
Are there any plans in place for locking down the syntax? Major release 3 is coming and developers are still being expected to hit a moving target. One of the nice things about C is that K&R era C is just as valid as C written nowadays, but Swift appears to be going in the opposite direction, every major release adding and removing bits of syntax. As someone unfamiliar with the language, it makes me not want to pick it up, since guides and documentation I read now will be incompatible with the newer release when it happens. Some early toying around during Swift's original announcement led to hard-to-debug errors (in part, caused by terribly useless error messages) when trying identical code on newer releases.
- wlesieutre 10y ago
  Certainly a problem they're aware of, and they're trying to get as many breaking changes done in 3.0 as possible. There may or may not be more in 4.0, but they will definitely be smaller. > What does this mean looking forward? Well, Swift 2 to Swift 3 is going to be an unavoidably disruptive change for code since Cocoa renamification is going to land, and we’re going to be building impressive migration technology again. As such, we should try to get the “rearrange all the deckchairs” changes into Swift 3 if possible, to make Swift 3 to 4 as smooth as possible. While our community has generally been very kind and understanding about Swift evolving under their feet, we cannot keep doing this for long. While I don’t think we’ll want to guarantee 100% source compatibility from Swift 3 to Swift 4, I’m hopefully that it will be much simpler than the upgrade to Swift 2 was or Swift 3 will be. http://ericasadun.com/2016/02/29/getting-ready-for-swift-to-stop-breaking-code/ http://ericasadun.com/2016/02/29/getting-ready-for-swift-to-...
- jamamp 10y ago
  I believe Swift 3.0 is the last breaking release. Version after this will avoid breaking the API and language as much as possible, and I imagine allow backwards compatibility for changes they do make. I'm okay with the fast-moving nature of Swift. It's a very young language that obviously needed a lot of changes, and if they had to take the time to make the earliest features available all the way in version 3, Swift would already be bloated. But they have been able to do away with backwards compatibility which is difficult in the industry, and I think it allowed them to make a richer language, not held back by anything. Side note: For at least some of the changes they've made, they've also built into the compiler and Xcode smart error messages that see the old syntax, and allow you to click one button to fix it to the latest syntax. Such as the old `for i in 0..10 {}` to the new `for i in 0..<10 {}`, Xcode will tell you to basically insert the `<` for the new operator.
astazangasta 10y ago
There are too many projects named 'swift'.
DonFromWyoming 10y ago
The removal of prefix and postfix ++ and -- operators and the removal of C-style for loops are mistakes, IMO.
- deleted 10y ago
  [deleted]
- RotsiserMho 10y ago
  As a C++14 programmer, I disagree. for..in syntax is so much clearer and being able to simply specify the range without having to manually increment makes more sense to me. I would love to see something like Swift's stride in C++.
- lanestp 10y ago
  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.
  - warmwaffles 10y ago
    ++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.
    - whatever_dude 10y ago
      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.
ryandev 10y ago
I've never understood the fascination with Swift. What's wrong with Objective C?
- wyldfire 10y ago
  Objective-C likely suffers from similar problems of C and C++. It's just too easy to shoot yourself in the foot with these languages. Rust, D, golang, swift all appear to share a common goal of having a mid-to-low-level imperative/OO language that has learned from C/C++/ObjC's mistakes.
- vbezhenar 10y ago
  Swift is much more type-safe (and modern overall). Also its OO-model similar to C++ with direct method calls instead of sending messages which results to better performance.
- mikeash 10y ago
  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. They also can't contain methods, so you end up writing associated code in global functions. Protocols are extremely limited. They're basically just collections of method declarations. There's no way to add functionality to every class which conforms to a protocol. Objective-C is often verbose to the point of painful redundancy. Consider: NSString *x = [NSString stringWithFormat: @"%d", number]; Versus: let x = String(format: "%d", number) Other examples include having to write the signature of every public method twice (once in the header and once in the implementation) and the need to do an annoying `self = [super init]` dance in every initializer. There's almost no functional programming stuff available, like map and reduce. This is not strictly a language complaint, but since the standard libraries are pretty tightly woven in, I think it still counts. Generics support is really limited. What's there was only added to interoperate better with Swift, anyway! That's a quick overview of some of the ways Swift improves on ObjC. I'm sure there's more.
itsbits 10y ago
Am I the only one as a JS dev, who find it hard with types & casting in Swift?
- matthewmacleod 10y ago
  Probably not. Types and casting seem complex to people coming from more dynamic languages – that's okay though! It formalises something that you generally don't have to think about in Javascript – the tradeoff being that you have more consistent, less buggy software at the expense of more effort while writing it.
  - itsbits 10y ago
    Agreed. I am yet to formally make my app available but had tough times mainly while doing Ajax calls, typecasting the JSON i got. Infact took time to understand some concepts like ARC, Optional Chaining when you are from JS background.
    - jallmann 10y ago
      > typecasting the JSON i got This is where a typed serialization comes in handy. (Protobufs, Thrift, Cap'n Proto, etc.) It is also possible to use an IDL to generate a type-safe API to deal with JSON -- although I don't know of any tools that emit Swift. Interfacing with third-party JSON APIs can be a pain though.
- tyingq 10y ago
  Maybe typescript would be a good thing to experiment with first? You could then get used to types in a familiar language first.
sickbeard 10y ago
Don't compare objective-c to c/c++. Objective-c is a different level of retard.
- mcCafe 10y ago
  What do you mean by different level of retard? You mean it's easier to shoot yourself in the foot with Obj-C?
- dang 10y ago
  You've been posting quite a few unsubstantive comments to HN. Please don't do that. We're looking for civil, thoughtful discussion here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=11660700 https://news.ycombinator.com/item?id=11660700 and marked it off-topic.
bitL 10y ago
How does Swift compare to D?
tyingq 10y ago
Does "will be portable" include any notion of a cross-platform UI?
- matthewmacleod 10y ago
  Languages don't have UIs - frameworks do. I realise it's a pedantic distinction, but it's an important one.
  - tyingq 10y ago
    I get the distinction, but there appears to be a deliberate direction to make Swift more portable. Thus, I was curious if that effort might include something UI related in the future. The interest level would certainly spike up if something were available.
    - allsystemsgo 10y ago
      But, that wouldn't make any sense to include UI components in a programming language. And I think the interest level is already "spiked".
      - tyingq 10y ago
        Okay. I was under the (perhaps not true) impression that the vast majority of swift apps were iphone apps, with the apple specific UI bindings. Such that one of the first questions on a new platform (Linux, Android, etc) would be "how do I create the UI?". It sounds like instead, the cross platform appeal is that back end or background services can now be written on non-apple platforms?
        allsystemsgo 10y ago
        That's correct. UIKit isn't like, baked into Swift. Whatever platform you're writing for would need to provide to you UI components and then some.
- 10y ago
Keyframe 10y ago
A bit too late for wider adoption, isn't it? Are there examples of similar path to openness?
- matthewmacleod 10y ago
  I don't see why that would be the case. The language has been public for less than two years, and I don't see any reason it wouldn't become widely adopted for situations where it's a good fit.
- proyb2 10y ago
  Not so, every years students and millennials are graduated and users are relied heavily on mobile on the move and oversea. Get ready to watch WWDC 2016, the demand is still very much active. Actionscript did open source, it create lot of unhappiness in the community and poor IDE performance but Swift is a different story, I'm looking forward to have Swift for server as long as the vendors contribution are growing, MS could be keen.
twoodfin 10y ago
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.
- danappelxx 10y ago
  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 https://github.com/VeniceX/Venice [1] https://github.com/Zewo/Zewo https://github.com/Zewo/Zewo
  - proyb2 10y ago
    Yes, if Swift team could continue from Zewo and Venice, it will save lot of resources to build from ground up.
- Matthias247 10y ago
  I think whether to deeply integrate concurrency into a framework or not is quite an interesting tradeoff. Without a preferred concurrency solution (like Swift, C++, Java, ...) users of the language are can leverage from a lot of different concurrency solutions, from real threads to eventloops/Rx and everything in between. However I think in the meantime that this hurts the ecosystem around the language. When some libraries built around primitive 1 (which might require an eventloop or async/await) and others around primitive 2 (M:N scheduled fibers) these libraries might not be easily combinable in your application. Languages with a preset solution (like Go or Erlang) avoid this problem.
Polish_Secret 10y ago
This definitely affects React Native a lot
jsonninja 10y ago
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.
- rimantas 10y ago
  I will be happy without that "largest developer base" brought to iOS. Anyone whos thinks Javascript it the best language ever deserves to keep programming in it.
  - jsonninja 10y ago
    The 'best' language is subjective. There are many apps where JavaScript could be one of many 'best' choices and some where it certainly couldn't be. Either way, you don't have the choice today.
- DerekL 10y ago
  Starting with OS X Yosemite, you can use JavaScript for writing Mac apps and scripts. https://developer.apple.com/library/mac/releasenotes/InterapplicationCommunication/RN-JavaScriptForAutomation/Articles/Introduction.html https://developer.apple.com/library/mac/releasenotes/Interap...
  - jsonninja 10y ago
    Using JS for automation is a great start. I don't think they have a way to build a JS app that leverages the full capabilities of either Mac or iOS yet.
    - robterrell 10y ago
      You can write full OS X apps in JavaScript: http://tylergaw.com/articles/building-osx-apps-with-js http://tylergaw.com/articles/building-osx-apps-with-js JavaScript bridging works on iOS too!
dang 10y ago
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'.)
- Razengan 10y ago
  Agreed. Please, don't let HN become Reddit.
- grayrest 10y ago
  Enforcement of this particular policy is one of the things I dislike most about HN. The current title is awful. It gives no information that the URL itself does not and doesn't explain why I'd care about the contents now given I've visited the repo in the past. I'm not opposed to the removal of editorializing but it should get replaced with something neutral that still captures why the URL was submitted, e.g. "Swift 3 Roadmap Update".
b123400 10y ago
While the language is nice, I find it hard to work with existing frameworks, given they are designed for a language as dynamic as objective-c. For example, NSError, NSNotification's userInfo is a `[AnyObject:AnyObject]`, but its member types are specified in documentation. It would be nice if we can have specific error will typed userInfo. Working with storyboard is the same story, there is no type check for VC and segue because identifier is a string, instead of something like `R.id.view` on android. Working with this kind of API requires lots of casting, I wonder will Apple design Swift-centric API later.
- rsmoz 10y ago
  Apple has already done a lot to make this sort of thing nicer. They added lightweight generics to Objective-C, so arrays are typed now. NSError bridges to ErrorType. They've also announced further plans to Swift-ify existing Objective-C APIs.
merb 10y ago
It would still be great if everything would be a value.
rezashirazian 10y ago
Swift is fun. I'm having a great time playing around with it. There are some nuances that take some getting used to, but overall, it's a powerful, fast and fun language to work with. If you are interested, I have taken on implementing all major design patterns in Swift. I've gone through about 10 of them right now, (7 published on my blog). If you've never worked with Swift but wish to get a feel for it without going through overly simple tutorials, check them out: https://shirazian.wordpress.com/2016/04/11/design-patterns-in-swift/ https://shirazian.wordpress.com/2016/04/11/design-patterns-i...
bouiaw 10y ago
Quite surprised to see no mention of Kotlin here since both languages are very similar, main difference is Swift is LLVM based while Kotlin run on the JVM and has excellent Java interoperability. See http://fr.slideshare.net/andrzej_sitek/swift-and-kotlin-presentation http://fr.slideshare.net/andrzej_sitek/swift-and-kotlin-pres... for more details ...

175 points by rufus42 10y ago

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?

untog 10y ago
I've been playing around with it a little and it's... fine? Very capable. Not run into any moments that have blown my mind, but neither have I found any that disgusted me. In a weird way it actually reminds me most of TypeScript - JavaScript-y, but with types and stronger enforcement of rules.
- tomelders 10y ago
  I've been quipping that Swift is the Javascript of tomorrow, today!
supster 10y ago
I'm a big fan. I love the statically inferred type system, generics, & optionals. Also really like a lot of the functional programming concepts + value types but still enjoy being able to fall back on OOP. It feels like the best of both worlds. I can't wait till we have language native concurrency techniques, so I can start writing swift in backend code.
- RotsiserMho 10y ago
  I was disappointed to see that concurrency support won't be in Swift 3.0.
  - thramp 10y ago
    Me too, but I’d I realized that I’d rather the Swift team not half-ass such a big feature, especially when they’re working on ABI stability and translation of Foundation API’s. Plus, I bet one of the things that’s holding proper concurrency back are Apple’s frameworks. I’d rather deal with callbacks for another year or two than use a rushed language feature.
  - chrisamanse 10y ago
    Concurrency is done with libdispatch library, which is also open source. Right now, it's only compatible with OS X, but int their post, they said that "For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries." https://swift.org/blog/swift-3-0-release-process/ https://swift.org/blog/swift-3-0-release-process/
thedevil 10y ago
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.
- thevibesman 10y ago
  > 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.
kris-s 10y ago
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 could have been a fly on the wall when they were discussing ARC versus GC.
- quux 10y ago
  I think they had to go with ARC due to the requirement that swift interoperates with Objective-C. If that hadn't been a constraint, yeah it would be an interesting decision.
  - deleted 10y ago
    [deleted]
  - zepto 10y ago
    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 you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life). I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs."
    - quux 10y ago
      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.
matt4077 10y ago
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 server as well as the client. Considering almost any Web API also has an IOS client, Swift has the same potential.
- lorenzhs 10y ago
  Do you have a link to some benchmarks at hand? Your "possibly faster than C" claim sounds too good to be true without a source, but I'd very much like to be proven wrong :)
  - thomasahle 10y ago
    By http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html 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 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?lang=swift&lang2=gcc 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 than Java, because Swift supports 'UnsafeMutablePointers': http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=5 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... Edit: This Quora question mentions the performance of Swift before and after unsafe programs were included: https://www.quora.com/In-terms-of-performance-speed-is-Swift-faster-than-Java https://www.quora.com/In-terms-of-performance-speed-is-Swift... The memory safe version used to be about 24x slower than C.
    - igouy 10y ago
      >> I suppose they were able to do the binary-tree benchmark so much better than Java, because … because it's faster to use a memory pool than GC for that … ditto C Rust Ada Fortran C++ … http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees http://benchmarksgame.alioth.debian.org/u64q/performance.php...
skrowl 10y ago
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 12 months, that might not be the best position to put yourself in long term, career-wise.
- beerwulf 10y ago
  That's rich coming from a C# developer looking at mobile...
  - skrowl 10y ago
    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 we also offer" and web is our main presence though, so your mileage may vary (especially if you're mobile-only or mobile-centric).
    - neppo 10y ago
      90%+ shared code is a bold claim, Xamarin.com states 60-90%. In my experience it's closer to 60%.
    - danielrhodes 10y ago
      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 few years ago. It was a total nightmare. These newer cross platform frameworks may no longer use webviews, but under the hood things are just as gross. What is true though is that these cross platform frameworks always oversell themselves (with the exception of Unity3D). You end up trading in one problem for another. Among the many problems you will encounter: 1. You miss a lot of newer features in the native platforms. If you want to incorporate those features somehow, the code becomes a conditional mess. 2. Performance is very meh and your hands are mostly tied in optimization. In both Android and iOS, getting performance correct (for example in a table view) requires a lot of tweaking. All of the cross platform frameworks I've used, including React Native, work for basic cases but quickly start dropping frames after that. 3. The majority of a mobile app's code is front-end, and this is not the place where you want to share code. Users on each platform expect different types of interactions and behaviors, not to mention UI aesthetics. 4. These different platforms all have their own characteristics and ways of doing things. These differences are not easily abstracted out. At the point where you are coding around these differences, you might as well have two different code bases. For all the complaining about differences between WebKit/Chrome/IE etc, the behavior is remarkably similar -- mobile platforms are far more diverged. 5. Native third-party libraries are very difficult to use because there is never the same library on the other platform. If there is, say with Facebook, they are not in sync. 6. You end up writing a lot of bridge code between iOS/Android and the framework. It's never pretty and painful to debug. 7. Getting locked into a third-party's framework is a bad place to be later on. Once it's in there, it's never coming out. I could go on... If you absolutely need to go cross platform early on, the best thing you can do for yourself is to lock down a common API/data model as early as possible, and create an aesthetic and design that is simple to implement on both platforms.
yousry 10y ago
The neat syntax is sometimes butchered by unnecessary casting orgies. Swifts outstanding feature is its simple C interoperability. The compilation times (Xcode) are lengthy compared to C or C++. Example: https://youtu.be/mgpAmqdiPKE https://youtu.be/mgpAmqdiPKE
nv-vn 10y ago
Semantically, it's probably closest to Rust (from my limited exposure). The syntax is slightly changed, but most things have a direct parallel between the two languages. Although Swift doesn't do ownership/borrow checking like Rust does and is a lot more relaxed in that department.
- valarauca1 10y ago
  Apple actually directly cites Rust as inspiration for Swift.
iheart2code 10y ago
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.
Koshkin 10y ago
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/ https://www.natashatherobot.com/swift-guard-better-than-if/
- jkubicek 10y ago
  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.
- protomyth 10y ago
  I've used ObjC since NeXTSTEP 3.3, and I'm trying to work with Swift. At this point, I've classified it in the same vein as Transact-SQL, a language I need to learn and use, but one I will not love. I guess I love the selector syntax too much. Shame that F-Script never caught on.
jaegerpicker 10y ago
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 been bitten by in the past. We are in a Java, PHP, Node.js, and Swift shop. Swift is BY far the least bug prone and most stable code. It's fast and easy to understand. It's not perfect, Generics and Protocols are fuzzy at best and if you aren't careful with optionals you can actively harm the stability of your code base. It has a long way to go on the server side but I do believe that it will and should be a great server side language platform. That said in my opinion it's the best language I've worked with professionally. For reference I've professional written a decent amount of code in: Python Java C# C++/C Objective-C Perl PHP Node.js/JavaScript VB6/VB.net Ruby Groovy Scala
- danappelxx 10y ago
  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.
  - jaegerpicker 10y ago
    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.
    - Razengan 10y ago
      Isn't that somewhat possible with extensions and constraints? At least that was the impression given by last year's WWDC talk [1], unless you're thinking of something else? [1]: https://developer.apple.com/videos/play/wwdc2015/408/ https://developer.apple.com/videos/play/wwdc2015/408/
corford 10y ago
For me the most exciting thing about Swift is the recent rumour that Google are looking at adopting it as a first class language for Android. If that happened, you'd finally have an open, fast, expressive, modern language that you could use on the server and on the fronted for iOS and Android. Couple that with Typescript & Aurelia for the web frontend and I'd be in programming nirvana.
- deleted 10y ago
  [deleted]

Karunamon 10y ago

Are there any plans in place for locking down the syntax? Major release 3 is coming and developers are still being expected to hit a moving target. One of the nice things about C is that K&R era C is just as valid as C written nowadays, but Swift appears to be going in the opposite direction, every major release adding and removing bits of syntax. As someone unfamiliar with the language, it makes me not want to pick it up, since guides and documentation I read now will be incompatible with the newer release when it happens. Some early toying around during Swift's original announcement led to hard-to-debug errors (in part, caused by terribly useless error messages) when trying identical code on newer releases.

wlesieutre 10y ago
Certainly a problem they're aware of, and they're trying to get as many breaking changes done in 3.0 as possible. There may or may not be more in 4.0, but they will definitely be smaller. > What does this mean looking forward? Well, Swift 2 to Swift 3 is going to be an unavoidably disruptive change for code since Cocoa renamification is going to land, and we’re going to be building impressive migration technology again. As such, we should try to get the “rearrange all the deckchairs” changes into Swift 3 if possible, to make Swift 3 to 4 as smooth as possible. While our community has generally been very kind and understanding about Swift evolving under their feet, we cannot keep doing this for long. While I don’t think we’ll want to guarantee 100% source compatibility from Swift 3 to Swift 4, I’m hopefully that it will be much simpler than the upgrade to Swift 2 was or Swift 3 will be. http://ericasadun.com/2016/02/29/getting-ready-for-swift-to-stop-breaking-code/ http://ericasadun.com/2016/02/29/getting-ready-for-swift-to-...
jamamp 10y ago
I believe Swift 3.0 is the last breaking release. Version after this will avoid breaking the API and language as much as possible, and I imagine allow backwards compatibility for changes they do make. I'm okay with the fast-moving nature of Swift. It's a very young language that obviously needed a lot of changes, and if they had to take the time to make the earliest features available all the way in version 3, Swift would already be bloated. But they have been able to do away with backwards compatibility which is difficult in the industry, and I think it allowed them to make a richer language, not held back by anything. Side note: For at least some of the changes they've made, they've also built into the compiler and Xcode smart error messages that see the old syntax, and allow you to click one button to fix it to the latest syntax. Such as the old `for i in 0..10 {}` to the new `for i in 0..<10 {}`, Xcode will tell you to basically insert the `<` for the new operator.

astazangasta 10y ago

There are too many projects named 'swift'.

DonFromWyoming 10y ago

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

deleted 10y ago
[deleted]
RotsiserMho 10y ago
As a C++14 programmer, I disagree. for..in syntax is so much clearer and being able to simply specify the range without having to manually increment makes more sense to me. I would love to see something like Swift's stride in C++.
lanestp 10y ago
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.
- warmwaffles 10y ago
  ++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.
  - whatever_dude 10y ago
    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.

ryandev 10y ago

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

wyldfire 10y ago
Objective-C likely suffers from similar problems of C and C++. It's just too easy to shoot yourself in the foot with these languages. Rust, D, golang, swift all appear to share a common goal of having a mid-to-low-level imperative/OO language that has learned from C/C++/ObjC's mistakes.
vbezhenar 10y ago
Swift is much more type-safe (and modern overall). Also its OO-model similar to C++ with direct method calls instead of sending messages which results to better performance.
mikeash 10y ago
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. They also can't contain methods, so you end up writing associated code in global functions. Protocols are extremely limited. They're basically just collections of method declarations. There's no way to add functionality to every class which conforms to a protocol. Objective-C is often verbose to the point of painful redundancy. Consider: NSString *x = [NSString stringWithFormat: @"%d", number]; Versus: let x = String(format: "%d", number) Other examples include having to write the signature of every public method twice (once in the header and once in the implementation) and the need to do an annoying `self = [super init]` dance in every initializer. There's almost no functional programming stuff available, like map and reduce. This is not strictly a language complaint, but since the standard libraries are pretty tightly woven in, I think it still counts. Generics support is really limited. What's there was only added to interoperate better with Swift, anyway! That's a quick overview of some of the ways Swift improves on ObjC. I'm sure there's more.

itsbits 10y ago

Am I the only one as a JS dev, who find it hard with types & casting in Swift?

matthewmacleod 10y ago
Probably not. Types and casting seem complex to people coming from more dynamic languages – that's okay though! It formalises something that you generally don't have to think about in Javascript – the tradeoff being that you have more consistent, less buggy software at the expense of more effort while writing it.
- itsbits 10y ago
  Agreed. I am yet to formally make my app available but had tough times mainly while doing Ajax calls, typecasting the JSON i got. Infact took time to understand some concepts like ARC, Optional Chaining when you are from JS background.
  - jallmann 10y ago
    > typecasting the JSON i got This is where a typed serialization comes in handy. (Protobufs, Thrift, Cap'n Proto, etc.) It is also possible to use an IDL to generate a type-safe API to deal with JSON -- although I don't know of any tools that emit Swift. Interfacing with third-party JSON APIs can be a pain though.
tyingq 10y ago
Maybe typescript would be a good thing to experiment with first? You could then get used to types in a familiar language first.

sickbeard 10y ago

Don't compare objective-c to c/c++. Objective-c is a different level of retard.

mcCafe 10y ago
What do you mean by different level of retard? You mean it's easier to shoot yourself in the foot with Obj-C?
dang 10y ago
You've been posting quite a few unsubstantive comments to HN. Please don't do that. We're looking for civil, thoughtful discussion here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=11660700 https://news.ycombinator.com/item?id=11660700 and marked it off-topic.

bitL 10y ago

How does Swift compare to D?

tyingq 10y ago

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

matthewmacleod 10y ago
Languages don't have UIs - frameworks do. I realise it's a pedantic distinction, but it's an important one.
- tyingq 10y ago
  I get the distinction, but there appears to be a deliberate direction to make Swift more portable. Thus, I was curious if that effort might include something UI related in the future. The interest level would certainly spike up if something were available.
  - allsystemsgo 10y ago
    But, that wouldn't make any sense to include UI components in a programming language. And I think the interest level is already "spiked".
    - tyingq 10y ago
      Okay. I was under the (perhaps not true) impression that the vast majority of swift apps were iphone apps, with the apple specific UI bindings. Such that one of the first questions on a new platform (Linux, Android, etc) would be "how do I create the UI?". It sounds like instead, the cross platform appeal is that back end or background services can now be written on non-apple platforms?
      - allsystemsgo 10y ago
        That's correct. UIKit isn't like, baked into Swift. Whatever platform you're writing for would need to provide to you UI components and then some.
10y ago

Keyframe 10y ago

A bit too late for wider adoption, isn't it? Are there examples of similar path to openness?

matthewmacleod 10y ago
I don't see why that would be the case. The language has been public for less than two years, and I don't see any reason it wouldn't become widely adopted for situations where it's a good fit.
proyb2 10y ago
Not so, every years students and millennials are graduated and users are relied heavily on mobile on the move and oversea. Get ready to watch WWDC 2016, the demand is still very much active. Actionscript did open source, it create lot of unhappiness in the community and poor IDE performance but Swift is a different story, I'm looking forward to have Swift for server as long as the vendors contribution are growing, MS could be keen.

twoodfin 10y ago

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.

danappelxx 10y ago
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 https://github.com/VeniceX/Venice [1] https://github.com/Zewo/Zewo https://github.com/Zewo/Zewo
- proyb2 10y ago
  Yes, if Swift team could continue from Zewo and Venice, it will save lot of resources to build from ground up.
Matthias247 10y ago
I think whether to deeply integrate concurrency into a framework or not is quite an interesting tradeoff. Without a preferred concurrency solution (like Swift, C++, Java, ...) users of the language are can leverage from a lot of different concurrency solutions, from real threads to eventloops/Rx and everything in between. However I think in the meantime that this hurts the ecosystem around the language. When some libraries built around primitive 1 (which might require an eventloop or async/await) and others around primitive 2 (M:N scheduled fibers) these libraries might not be easily combinable in your application. Languages with a preset solution (like Go or Erlang) avoid this problem.

Polish_Secret 10y ago

This definitely affects React Native a lot

jsonninja 10y ago

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.

rimantas 10y ago
I will be happy without that "largest developer base" brought to iOS. Anyone whos thinks Javascript it the best language ever deserves to keep programming in it.
- jsonninja 10y ago
  The 'best' language is subjective. There are many apps where JavaScript could be one of many 'best' choices and some where it certainly couldn't be. Either way, you don't have the choice today.
DerekL 10y ago
Starting with OS X Yosemite, you can use JavaScript for writing Mac apps and scripts. https://developer.apple.com/library/mac/releasenotes/InterapplicationCommunication/RN-JavaScriptForAutomation/Articles/Introduction.html https://developer.apple.com/library/mac/releasenotes/Interap...
- jsonninja 10y ago
  Using JS for automation is a great start. I don't think they have a way to build a JS app that leverages the full capabilities of either Mac or iOS yet.
  - robterrell 10y ago
    You can write full OS X apps in JavaScript: http://tylergaw.com/articles/building-osx-apps-with-js http://tylergaw.com/articles/building-osx-apps-with-js JavaScript bridging works on iOS too!

dang 10y ago

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'.)

Razengan 10y ago
Agreed. Please, don't let HN become Reddit.
grayrest 10y ago
Enforcement of this particular policy is one of the things I dislike most about HN. The current title is awful. It gives no information that the URL itself does not and doesn't explain why I'd care about the contents now given I've visited the repo in the past. I'm not opposed to the removal of editorializing but it should get replaced with something neutral that still captures why the URL was submitted, e.g. "Swift 3 Roadmap Update".

b123400 10y ago

While the language is nice, I find it hard to work with existing frameworks, given they are designed for a language as dynamic as objective-c. For example, NSError, NSNotification's userInfo is a `[AnyObject:AnyObject]`, but its member types are specified in documentation. It would be nice if we can have specific error will typed userInfo. Working with storyboard is the same story, there is no type check for VC and segue because identifier is a string, instead of something like `R.id.view` on android. Working with this kind of API requires lots of casting, I wonder will Apple design Swift-centric API later.

rsmoz 10y ago
Apple has already done a lot to make this sort of thing nicer. They added lightweight generics to Objective-C, so arrays are typed now. NSError bridges to ErrorType. They've also announced further plans to Swift-ify existing Objective-C APIs.

merb 10y ago

It would still be great if everything would be a value.

rezashirazian 10y ago

Swift is fun. I'm having a great time playing around with it. There are some nuances that take some getting used to, but overall, it's a powerful, fast and fun language to work with. If you are interested, I have taken on implementing all major design patterns in Swift. I've gone through about 10 of them right now, (7 published on my blog). If you've never worked with Swift but wish to get a feel for it without going through overly simple tutorials, check them out: https://shirazian.wordpress.com/2016/04/11/design-patterns-in-swift/ https://shirazian.wordpress.com/2016/04/11/design-patterns-i...

bouiaw 10y ago

Quite surprised to see no mention of Kotlin here since both languages are very similar, main difference is Swift is LLVM based while Kotlin run on the JVM and has excellent Java interoperability. See http://fr.slideshare.net/andrzej_sitek/swift-and-kotlin-presentation http://fr.slideshare.net/andrzej_sitek/swift-and-kotlin-pres... for more details ...