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

61–70 of 145 posts

Re: The Decade of Swift

#61

Post by RandallBrown »

melling wrote: post #20
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…

Nah, Swift is an easy language. I have a Cookbook here: http://www.h4labs.com/dev/ios/swift_cookbook.html I’m in the process of putting it on Github. https://github.com/melling/SwiftCookBook SwiftUI probably means that millions of apps will eventually move to Swift, making Swift a top 10 language. https://www.tiobe.com/tiobe-index/

Swift is already a top 10 language according to TIOBE.

Re: The Decade of Swift

#62

Post by skohan »

chc wrote: post #46
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…

I don't think there's any world where Swift is popular outside Apple's ecosystem. It's not anything wrong with the language that's the problem, it's that the primary reason you'd use Swift over similar languages like Rust or Nim is its integration into Apple's ecosystem. It has some unique features outside of that, but not enough to make up for how deep in the wilderness you'd be running Swift on non-Apple platforms.…

> I don't think there's any world where Swift is popular outside Apple's ecosystem.

I wouldn't go quite that far. I agree that Swift's cross-platform story is lacking, but as someone who follows the language closely, the story is improving all the time.

I see it as largely a chicken-and-egg problem: i.e. there's not enough activity outside the Apple ecosystem to improve the situation quickly, but I don't think it's impossible for it to get there.

For instance, it's already possible to use Swift in AWS Lambda, and some support for Azure's alternative offering, as well as Google's work on Swift for Tensorflow. All of these cases involve running Swift code in a very controlled environment, like a container, and this is very tenable even in Swift's current state. So even if it might be a bit of a pain to get Swift up and running on whatever exotic linux distro you run on your workstation, there are already starting to be some "easy" use-cases for Swift outside of Apple platforms. As the scope of these one-off use-cases grows, I think it's likely there will be increased demand to improve the cross-platform story in general.

Personally this is appealing to me, because while I agree that Rust is miles ahead in terms of cross-platform support, I find Swift so much more productive and pleasant to work with that I welcome more opportunities to use it.

Re: The Decade of Swift

#63

Post by cableshaft »

m45t3r wrote: post #57
cableshaft wrote: post #53

Earlier quoted context omitted.

It sounds to me like you're just asking for a quick and dirty default that's nice and pithy and short. That's fine, but file i/o tends to get messy and easy to exploit without some safeguards, and doing it "right" tends to be a bit more complicated. Like part of your complaint above is pathing, and even something as short and pithy as Python (at least in my opinion, that's why I keep going to it to write proof of con…

> One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html . Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another t…

Good to know, thanks :) I've only ever used Python for my own tinkering purposes so I haven't been too aware of any new developments.

But I assume the old ways are still valid code, so if you're working with Python code you may encounter any of now 3 different systems of just navigating paths for file i/o, what the parent claims should be dirt simple.

Re: The Decade of Swift

#64

Post by leonidasv »

hajile wrote: post #2

Can someone sell me on Swift over dart or kotlin? They seem to be direct competitors. Since we're talking about the future of programming, can someone sell me on Swift instead of ocaml, SML, or F#? I don't see a good reason to pick it outside of targeting Apple devices.

Excuse me, but what makes you think of OCaml, SML and F# as "future of programming"?

As much as I like OCaml, for example, I don't see it being mass-adopted in the near future, nor its tooling reaching the state of more established languages. All those languages you mentioned are most likely to continue being just niche ones.

The only mostly-functional language I can see being mass-adopted right now is Elixir, and it still has a long way to go.

Re: The Decade of Swift

#65

Post by skohan »

m_ke wrote: post #28
6700417 wrote: post #18

Earlier quoted context omitted.

This seems very unlikely to me. They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack. Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in…

I'm pretty sure they went with Kotlin before Swift was open sourced, but I agree with you that the likelihood of them doing it is very low. Swift for Tensorflow hasn't gotten much traction because the overlap between programmers who know swift and machine learning engineers is super tiny. Making the core language differentiable sounds very promising though .

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 automatic differentiation, and the stuff they are talking about with metaprogramming is truly fascinating stuff, with all kinds of applications outside of machine learning. I really hope they manage to get it off the ground.

Re: The Decade of Swift

#66

Post by skohan »

endorphone wrote: post #30
6700417 wrote: post #18

Earlier quoted context omitted.

This seems very unlikely to me. They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack. Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in…

Just to clarify Google's choice of Kotlin -- the maker of their IDE invented and did all of the heavy lifting with Kotlin, including building the JVM targeting compiler, and the IDE to develop it in (which is the foundation of Android Studio). Adopting Kotlin was very close to free for Android, and was really just rubber stamping what a lot of developers were doing regardless.

JetBrains is a plague on mobile development. Their current business model appears to be selling workflows which are totally dependent on their proprietary tooling, and make over-complex monstrosities of mobile applications

Re: The Decade of Swift

#67

Post by jbverschoor »

shmerl wrote: post #56
jbverschoor wrote: post #35

Earlier quoted context omitted.

So we’ll refuse go, typescript and react? Apple has the best engineering talent of all tech companies.

Hard to say if it's the best, but likely the worst attitude of the management on top when it comes to collaboration and general progress (which languages should enable).

Oh def. Apple has been too slow and/or conservative about opensource.

Re: The Decade of Swift

#68

Post by setpatchaddress »

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 understand your comment about reference counting being intrusive. Apple's implementation, ARC, used in Swift and modern ObjC, is essentially invisible to you if you're using native objects.

Re: The Decade of Swift

#69

Post by 6700417 »

m_ke wrote: post #28
6700417 wrote: post #18

Earlier quoted context omitted.

This seems very unlikely to me. They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack. Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in…

I'm pretty sure they went with Kotlin before Swift was open sourced, but I agree with you that the likelihood of them doing it is very low. Swift for Tensorflow hasn't gotten much traction because the overlap between programmers who know swift and machine learning engineers is super tiny. Making the core language differentiable sounds very promising though .

Swift was open-sourced 18 months before Google announced support for Kotlin.

There was probably several months or more of debate and work within Google by the time of the announcement, but it seems reasonable that during those 18 months they would have also considered and rejected Swift.

Re: The Decade of Swift

#70

Post by 6700417 »

skohan wrote: post #65
m_ke wrote: post #28

Earlier quoted context omitted.

I'm pretty sure they went with Kotlin before Swift was open sourced, but I agree with you that the likelihood of them doing it is very low. Swift for Tensorflow hasn't gotten much traction because the overlap between programmers who know swift and machine learning engineers is super tiny. Making the core language differentiable sounds very promising though .

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