Live data from Hacker News

The Decade of Swift

swiftbysundell.com

121–130 of 145 posts

Re: The Decade of Swift

#121

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

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

I'm curious. Does it? I would have guessed the "weak self" would have prevented it.

> In my view, reference counting does not combine very well with heavy use of closures.

It's one of the area where one has to be careful for sure! C++ with smart pointers and callbacks exhibits the same problem. And GC based languages make the pattern easier for sure. However I think this is not even the most critical error source in callback based designs. I think threading issues due to callbacks being executed on different threads cause the most trouble.

Therefore I think languages like Javascript and Dart - which only offer a single thread AND GC - are the the easiest to use for callback based designs.

Re: The Decade of Swift

#122

Earlier quoted context omitted.

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

> How quickly can you tell whether or not this piece of code has a reference cycle? I'm curious. Does it? I would have guessed the "weak self" would have prevented it. > In my view, reference counting does not combine very well with heavy use of closures. It's one of the area where one has to be careful for sure! C++ with smart pointers and callbacks exhibits the same problem. And GC based languages make the pattern…

Yes, there's still a reference cycle because the outer closure implicitly captures self as well. The article explains it in greater detail.

I agree that threading is another big gotcha, arguably a bigger one. Rust has some mitigations against that sort of thing.

Re: The Decade of Swift

#123
post #119
post #117

Earlier quoted context omitted.

Julia is the only sound alternative to Python. If they want to make an Apple only version of Tensorflow, so be it, but don't expect it to take off on Linux and Windows research labs.

What’s with the FUD? You can already run S4TF notebooks on Colab, and it’s trivial to spin up S4TF in any environment using Docker.

How do you spin S4TF on Windows Containers or any kind of Linux distribution in-house?

Re: The Decade of Swift

#124
I’ve recentried tried google trends to see if swift was gaining popularity overall :

https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

Imho There’s definitely an issue in the strategy for this language ( or for ios native development since the two are tied).

My guess is cross platform development is eating mobile, and swift has nothing in that area.

Re: The Decade of Swift

#125
post #120
post #116

Earlier quoted context omitted.

Thing is, yes it might cost performance, but does it matter? It all boils down to, does it deliver what the customer of an application written in Swift is asking for?

Yeah that is exactly my point. In many cases all the extra work you put into writing Rust code for the additional performance is just that: extra. It doesn’t add any meaningful value to the final product, and it comes at the opportunity cost of that time you could have spent adding or improving features in a more productive language.

Yeah, while Rust is paving the way for affine type systems among mainstream languages, and it already influenced design decisions on other system programming languages, including Swift (memory ownership manifest), it isn't the first on my list for UI or distributed computing applications.

Re: The Decade of Swift

#126
post #13

Earlier quoted context omitted.

> dart or kotlin? ... ocaml, SML, or F# + scala, go, rust, elixir/erlang Yeah its so much time to learn all this stuff. Its a good reason they probably will all fade, better stick to js/python/java/C#/C++ like everyone else and wait.

> better stick to js/python/java/C#/C++ like everyone else I would change Java to Kotlin here, since Kotlin has a 1:1 interop with Java while having goodies like null safety, type inference and functional programming without the academicism of Scala (and its slow compilation time). If you also account for the smooth learning, Kotlin is probably the safest bet from these 9 mentioned. A lot of businesses with Java code…

Yeah I like Kotlin. The problem is I liked Scala, Erlang and Go as well and I spent a lot of time learning those and eventually discarding them.

Re: The Decade of Swift

#127
post #118

Earlier quoted context omitted.

Why was refcounting chosen? It seems to me it was only done because the designers were so used to C++ that they don't understand the drawbacks of not having it.

Easy, interoperability with Objective-C runtime and Cocoa refcounting patterns.

But didn't some version of Objective-C use a GC? My understanding was that the reason it didn't work well was because of issues with the language and not the libraries. So they could still have used a GC for Swift?

Re: The Decade of Swift

#128
post #118

Earlier quoted context omitted.

Easy, interoperability with Objective-C runtime and Cocoa refcounting patterns.

But didn't some version of Objective-C use a GC? My understanding was that the reason it didn't work well was because of issues with the language and not the libraries. So they could still have used a GC for Swift?

The reason it did not work was indeed the language, given the underlying C semantics of Objective-C.

However Objective-C ARC is basically the compiler taking care of Cocoa retain/release patterns.

Swift needed to provide a seemless path forward to integrate with Objective-C libraries so reference counting was the easist way forward.

Microsoft has chosen another way to interoperate with COM from .NET, which requires an additional layer.

https://docs.microsoft.com/en-us/dotnet/standard/native-inte...

https://docs.microsoft.com/en-us/dotnet/standard/native-inte...

Although is is quite alright to use, it adds an additional complexity that most likely Apple wasn't willing to make use of.

Re: The Decade of Swift

#129
post #123
post #119

Earlier quoted context omitted.

What’s with the FUD? You can already run S4TF notebooks on Colab, and it’s trivial to spin up S4TF in any environment using Docker.

How do you spin S4TF on Windows Containers or any kind of Linux distribution in-house?

Using Docker

Edit: or on Ubuntu just download the toolchain.

Re: The Decade of Swift

#130
post #125
post #120

Earlier quoted context omitted.

Yeah that is exactly my point. In many cases all the extra work you put into writing Rust code for the additional performance is just that: extra. It doesn’t add any meaningful value to the final product, and it comes at the opportunity cost of that time you could have spent adding or improving features in a more productive language.

Yeah, while Rust is paving the way for affine type systems among mainstream languages, and it already influenced design decisions on other system programming languages, including Swift (memory ownership manifest), it isn't the first on my list for UI or distributed computing applications.

Yeah to me Rust almost feels like the prototype for the next great programming language. There are a lot of great ideas there, but there are also a lot of awkward edges. Like what it accomplishes from a technical perspective is super impressive, but it would be great if somebody could synthesize all of those concepts behind a cleaner front-end which really nails the ergonomics.
Post reply on HN