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

81–90 of 181 posts

Re: Swift Programming Language Evolution

#81

Post by [deleted] »

quux wrote: post #9
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 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]

Re: Swift Programming Language Evolution

#82

Post by quux »

zepto wrote: post #18
quux wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Swift Programming Language Evolution

#84

Post by Koshkin »

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?

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/

Re: Swift Programming Language Evolution

#85

Post by criley2 »

danielhooper wrote: post #66
skrowl wrote: post #19

Earlier quoted context omitted.

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

So abiding by that same logic, would you not agree that developing for Android has been a poor career decision up until say, 12 months ago?

What is Google-only about Java code?

Re: Swift Programming Language Evolution

#86

Post by jallmann »

itsbits wrote: post #70
matthewmacleod wrote: post #41

Earlier quoted context omitted.

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.

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.

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

Re: Swift Programming Language Evolution

#87

Post by danielrhodes »

skrowl wrote: post #24
beerwulf wrote: post #20

Earlier quoted context omitted.

That's rich coming from a C# developer looking at mobile...

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

If there was a common native language between Android/iOS, it would make things easier for sure. But using a third language to solve the existing problem is a rookie error.

> 90+% of your mobile code can be shared between Android and iOS

This stat depends on how complex your app is, but it usually only applies to gaming. Otherwise it's almost always false.

We've already been down this path with the webview craze a 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.

Re: Swift Programming Language Evolution

#88

Post by igouy »

thomasahle wrote: post #25
lorenzhs wrote: post #15

Earlier quoted context omitted.

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 :)

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…

>> Edit: This Quora question mentions the performance of Swift before and after unsafe programs were included

That Quora answer makes claims which are not true.

The Swift benchmarks game programs were always compiled with -Ounchecked (since Dec 7 2015).

The before was naive transliterations (from other programming languages) of single-core programs -- just to demonstrate that Swift was installed.

The after was someone doing the work and contributing programs written for Swift and written for multi-core.

Re: Swift Programming Language Evolution

#89

Post by jaegerpicker »

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

Re: Swift Programming Language Evolution

#90

Post by thramp »

RotsiserMho wrote: post #35
supster wrote: post #6

Earlier quoted context omitted.

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.

I was disappointed to see that concurrency support won't be in Swift 3.0.

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.

Post reply on HN