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

111–120 of 145 posts

Re: The Decade of Swift

#111

Post by lokedhs »

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…

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.

Re: The Decade of Swift

#112

Post by developer2 »

skohan wrote: post #37
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…

Can you go into any specifics? Personally I've found Swift to be incredibly easy to read and write, and that it largely delivers in terms of rolling out complexity through progressive disclosure. Most of the complexity is only there if you need it in my experience.

Has Swift improved their text handling? Last time I looked, it took way too many lines of code and temporary variables just to extract a substring range from a string. Their convoluted idea that a string can't be directly sliced with integer indexes–by bytes, let alone by Unicode code points or graphemes–was so frustrating I swore I would never look in Swift's general direction again. It was such a joke just to try to extract x UTF-8 characters starting from position y. I liked the overall feel of the language, but the fact I ran into such a horrible wall trying to perform the most basic of string manipulations was unforgivable.

Swift came out at a time where UTF-8 was already the standard. They talked a lot of talk about grapheme clusters being the most accurate representation, and then failed to deliver a coherent API to back it up. Any chance that has changed?

Re: The Decade of Swift

#113

Post by skohan »

zozbot234 wrote: post #107
skohan wrote: post #105

Earlier quoted context omitted.

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…

> Perhaps you haven't programmed in Java. Or even C++, for that matter

I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages.

I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level.

For example, Swift’s copy-on-write makes it very easy to reason about value types, but comes at the cost of performance since there will be a lot of copies which aren’t strictly necessary. You can get essentially the same behavior in Rust by cloning everything, but it takes a lot more typing and adds visual noise to your code, because Rust has made the default to be more parsimonious with memory usage.

At some level trade offs have to be made. No one language can be all thing a to all people.

Re: The Decade of Swift

#114

Post by skohan »

tonyedgecombe wrote: post #109
geophile wrote: post #92

Earlier quoted context omitted.

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.

What would it have to do with Objective-C?

Re: The Decade of Swift

#115

Post by pjmlp »

codr7 wrote: post #94
6700417 wrote: post #88

Earlier quoted context omitted.

I’ve never worked at a startup. I know very few people who have been involved in the startup world. I have exclusively used C and C++ in my professional work (with a tiny bit of python for scripting). Yet I haven’t know anybody who primarily or even occasionally used C in their work for over a decade. I know they exist but the majority of C programmers moved on to C++ a long time ago. There are areas like kernel and…

Except the entire world runs on top of C and will continue to do so for quite some time, it's not all about new or user facing projects. Linux is pretty popular.

C compiled with compilers and standard library written in C++.

My world runs on top of C++.

C is only relevant on constrained embedded hardware and FOSS UNIX clones.

Re: The Decade of Swift

#116

Post by pjmlp »

skohan wrote: post #113
zozbot234 wrote: post #107

Earlier quoted context omitted.

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

> Perhaps you haven't programmed in Java. Or even C++, for that matter I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages. I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level. For example, Swift’s copy-on-write makes it ve…

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?

Re: The Decade of Swift

#117

Post by pjmlp »

6700417 wrote: post #70
skohan wrote: post #65

Earlier quoted context omitted.

Swift for Tensorflow also isn't at 1.0 AFAIK and hasn't been deemed "ready for primetime". I think it's going to be hard to get data-scientists using anything other than Python any time soon, but I'm hopeful it will take off at some point, since it's really painful to work with scripting languages once you get used to a decent type system. It's also a super interesting project to follow. The stuff they are doing with…

Yes it’s not at 1.0, but my point when I mention to people actually doing deep learning that Swift is coming and has support for native differentiation and static typing, the response is underwhelming to the point that I wonder if either of those features provide enough pull to get people to ever drop Python for Swift.

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.

Re: The Decade of Swift

#118

Post by pjmlp »

lokedhs wrote: post #111
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…

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.

Re: The Decade of Swift

#119

Post by skohan »

pjmlp wrote: post #117
6700417 wrote: post #70

Earlier quoted context omitted.

Yes it’s not at 1.0, but my point when I mention to people actually doing deep learning that Swift is coming and has support for native differentiation and static typing, the response is underwhelming to the point that I wonder if either of those features provide enough pull to get people to ever drop Python for Swift.

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.

Re: The Decade of Swift

#120

Post by skohan »

pjmlp wrote: post #116
skohan wrote: post #113

Earlier quoted context omitted.

> Perhaps you haven't programmed in Java. Or even C++, for that matter I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages. I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level. For example, Swift’s copy-on-write makes it ve…

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.
Post reply on HN