Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Decade of Swift

swiftbysundell.com

Post reply on HN
Print view View original

101–110 of 145 posts

Re: The Decade of Swift

#101

Post by jcelerier »

pavlov wrote: post #21
ardit33 wrote: post #10

I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Sw…

For a language whose nearly exclusive use case is writing Cocoa applications, it’s odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.

That is the first time in my life I hear objc and good in the same sentence. Every UI developer I know who has worked in it actively despised it.

Re: The Decade of Swift

#102

Post by skohan »

geophile wrote: post #92
skohan wrote: post #86

Earlier quoted context omitted.

> Swift separates those inside and outside views, permitting different names for both. The named parameter handling is one of my favorite features of Swift. It makes Swift code self-documenting in a way most languages aren't.

I actually don't mind that feature too much. I do appreciate that it clarifies code with even a few arguments of the same type. Although there are other ways to clarify such situations in other languages. The Swift approach does lead to exceptionally verbose code, but that's obviously subjective. It's the $n syntax that I think is overkill. Do we really need three different ways to name parameters?

Yeah to each her own I guess, but I don't mind the $n syntax either. It's only relevant in closures, and in my experience it's mostly used in simple, short closures where the identity of the parameter is obvious. So for example if you are doing a simple map:

    let incremented = myArray.map { $0 + 1 }
the $n syntax just lets you save a little bit of typing. In my opinion it often makes the intent clearer when reading a line of code, since having to explicitly name the variable here adds noise which isn't really meaningful, especially in the case where you have a chain of map/reduce/filter operations.

I would put it in the same category as Rust's `?` operator, which saves you from typing a bunch of unwraps or match statements everywhere.

Re: The Decade of Swift

#103

Post by skohan »

panpanna wrote: post #98
skohan wrote: post #33

Earlier quoted context omitted.

I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.

Go? Kotlin?

Go is a nice language for some use-cases, but a bit too light on abstractions for my needs.

When I tried Kotlin a couple years ago, it seemed to be marginally behind Swift in terms of the power of the type system and some of the cool things you can do in Swift, and I'm not wild about targeting JVM, but I understand that situation has been evolving so maybe I should give it a second look at some point.

Re: The Decade of Swift

#104

Post by fauigerzigerk »

setpatchaddress wrote: post #68
geophile wrote: post #59

I like a lot about Swift: strong typing, good support for closures, reasonable abstractions. But there's a lot that I dislike too. A lot. In general, I find the language to be far too trendy and fussy. I get the impression the design was guided by the goal of streamlining snippets of code meant to highlight cool features, gaining undesirable complexity as a result. One example: Do we really need $n function parameter…

I certainly don't disagree that there's too much C++ in Swift (the Swift architects write C++ for a living, not ObjC, so it's hardly surprising) but it's not due to trendiness. Most of the features you mention derive from direct experience with Objective-C. Function arguments, property accessors (get/set/didSet), extensions (categories), etc. Every one of these things solves a real problem in the field. I don't under…

>I don't understand your comment about reference counting being intrusive.

It's intrusive because you can never really stop thinking about it if you want to write correct code. Here's an example from a very interesting article by Mark Sands [1]:

How quickly can you tell whether or not this piece of code has a reference cycle?

    class ServiceLayer {
        // ...
        private var task: URLSessionDataTask?

        func foo(url: URL) {
            task = URLSession.shared.dataTask(with: url) { data, response, error in
                let result = // process data
                DispatchQueue.main.async { [weak self] in
                    self?.handleResult(result)
                }
            }
            task?.resume()
        }

        deinit {
            task?.cancel()
        }
    }
In my view, reference counting does not combine very well with heavy use of closures.

[1] This is an interesting read: http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

Re: The Decade of Swift

#105

Post by skohan »

zozbot234 wrote: post #96
skohan wrote: post #33

Earlier quoted context omitted.

I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.

Rust can be quite usable and productive if you know the right shortcuts. The tradeoff is somewhat lowered performance (and Rust makes sure that you're aware of where you're choosing that tradeoff) but that's just the way it goes. It's not like Swift is any different.

I think Rust is a fine language, but it's undeniable that it involves more tedium than other languages to use.

If there is some tradeoff between safety, performance, and usability, Rust has prioritized safety and performance, where swift has chosen safety and usability. And that's perfectly fine. I am glad that Rust exists for those use-cases where the performance is important, but there are also cases where it's more important to be able to write a lot of code quickly with less friction.

It doesn't devalue Rust to admit that there are places where it is not the optimal choice.

Re: The Decade of Swift

#106

Post by fauigerzigerk »

geophile wrote: post #89
setpatchaddress wrote: post #68

Earlier quoted context omitted.

I certainly don't disagree that there's too much C++ in Swift (the Swift architects write C++ for a living, not ObjC, so it's hardly surprising) but it's not due to trendiness. Most of the features you mention derive from direct experience with Objective-C. Function arguments, property accessors (get/set/didSet), extensions (categories), etc. Every one of these things solves a real problem in the field. I don't under…

I don't agree that get/set/didSet solve actual problems. Languages without property accessors do just fine, but then they don't overload the getting and setting of variables. I would much rather right thing.setField(123), and have setField do whatever actions need to accompany the assignment; than write thing.field = 123, and then have the actions be hidden. What is so f'ing special about x = thing.field and thing.fi…

I agree. Here's an article that has really opened my eyes on how subtle reference cycles can be:

http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

I have pasted the most egregious example here: https://news.ycombinator.com/item?id=21919728

Re: The Decade of Swift

#107

Post by zozbot234 »

skohan wrote: post #105
zozbot234 wrote: post #96

Earlier quoted context omitted.

Rust can be quite usable and productive if you know the right shortcuts. The tradeoff is somewhat lowered performance (and Rust makes sure that you're aware of where you're choosing that tradeoff) but that's just the way it goes. It's not like Swift is any different.

I think Rust is a fine language, but it's undeniable that it involves more tedium than other languages to use. If there is some tradeoff between safety, performance, and usability, Rust has prioritized safety and performance, where swift has chosen safety and usability. And that's perfectly fine. I am glad that Rust exists for those use-cases where the performance is important, but there are also cases where it's mor…

> more tedium than other languages

Perhaps you haven't programmed in Java. Or even C++, for that matter (modern "Core C++" programming can be quite tedious at times).

I'd say the jury is still out when it comes to Rust vs. "higher level languages", yes, even Swift. The point of my comment is that the "friction" you're pointing to need not be an inherent property of something like Rust, any more than it is in C++. It remains to be seen if the 'tradeoff' you mention is a binding one.

Re: The Decade of Swift

#108

Post by lokedhs »

panpanna wrote: post #98
skohan wrote: post #33

Earlier quoted context omitted.

I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.

Go? Kotlin?

Kotlin Native is nice, but its compile times are absolutely horrible. I guess some of this comes from Gradle, which is another mess in itself, but when it takes over half a minute to compile Hello World, there is a problem.

Re: The Decade of Swift

#109

Post by tonyedgecombe »

geophile wrote: post #92
skohan wrote: post #86

Earlier quoted context omitted.

> Swift separates those inside and outside views, permitting different names for both. The named parameter handling is one of my favorite features of Swift. It makes Swift code self-documenting in a way most languages aren't.

I actually don't mind that feature too much. I do appreciate that it clarifies code with even a few arguments of the same type. Although there are other ways to clarify such situations in other languages. The Swift approach does lead to exceptionally verbose code, but that's obviously subjective. It's the $n syntax that I think is overkill. Do we really need three different ways to name parameters?

I assumed it was there for compatibility with Objective-C, I can't imagine any other justification.

Re: The Decade of Swift

#110

Post by lokedhs »

6700417 wrote: post #71
m_ke wrote: post #48

Earlier quoted context omitted.

But wasn't open source till the end of 2015 ( https://developer.apple.com/swift/blog/?id=34 ) Kotlin was open sourced around 2012 and people were using it in Android apps before Google officially started supporting it in 2016.

Kotlin announcement 2017/5/17: https://android-developers.googleblog.com/2017/05/android-an... Swift open source 2015/12/3: https://developer.apple.com/swift/blog/?id=34

That was the official support from Google. Kotlin had been around for a long time before that. I used to write Android applications using it before Google officially supported it.
Post reply on HN