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

51–60 of 145 posts

Re: The Decade of Swift

#51

Post by fauigerzigerk »

dmitriid wrote: post #11

> That’s why Swift’s expressive and very lightweight syntax And a few paragraphs later: extension Array { func sorted ( by keyPath: KeyPath ) -> Self { sorted { $0[keyPath: keyPath] I can't say this is lightweight any longer. My greatest gripe with Swift comes not from Swift itself but from its standard library. When most new languages start with their own standard libraries that are usually interfaces towards C APIs…

>I can't say this is lightweight any longer.

Compared to what? What this code does can be rather convoluted and/or unsafe in many statically typed languages.

Re: The Decade of Swift

#52

Post by skohan »

ncmncm wrote: post #19

I can't really imagine Swift ever breaking out of Apple's walled garden. It's a pretty big garden, but the language concedes so much to Objective-C compatibility, it is hard to see any role for it where Objective-C never got a foothold. Where am I wrong?

> the language concedes so much to Objective-C compatibility

Such as?

Personally I've taken to using Swift basically in every use-case where I can, largely because it's so nice to work with. It strikes a very nice balance between productivity (lack of tedium) and strong compile-time guarantees of correctness.

From my perspective, there are a few obstacles preventing Swift from achieving wide adoption:

1. Tooling and support outside Apple platforms has a long way to go. The story is better than it was even a year or two ago, but when compared to Rust, for example, Swift is massively lacking in this area.

2. Swift is still viewed as an iOS-only language. Even though there are now mature libraries for things like writing a webserver, and it's quite possible to write software for Linux using Swift, the developer perception is not there, and thus adoption is slow. This contributes to the lack of tooling and support.

3. Performance needs some improvement. ARC and copy-on-write are great for writing correct code easily, but they lead to some serious and sometimes unpredictable performance cliffs with Swift. There is a lot of low-hanging fruit here, but this needs to be addressed before Swift could ever find a place as a systems programming language for example.

So I would not quite say I'm bullish with respect to Swift's chances of breaking out as a general purpose programming language, but objectively speaking I would say that all the problems preventing Swift reaching that state are solvable problems, and Objective-C compatibility has little to do with it.

Re: The Decade of Swift

#53

Post by cableshaft »

dmitriid wrote: post #32
cableshaft wrote: post #23

Earlier quoted context omitted.

The directory thing is more due to sandboxing than anything else. They don't want someone to be able to write an app that can read anything anywhere on your phone, so it has specific directories that have different levels of access and temporality (i.e. one is a temp folder that gets flushed each time you quit the app, if I remember correctly). It's not that complicated once you look it up, and like most of this stuf…

> They don't want someone to be able to write an app that can read anything anywhere on your phone, And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else. > It's not that complicated once you look it up, and like most of this stuff Yeah, I tried to look it up.…

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 concepts), in order to do file i/o "right", requires knowing about all sorts of other things.

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 thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS.

That's not too much different than having to specify a type of directory for Swift, and has the same types of reasons for why it exists, for safety, but it just doesn't let you do something potentially dumb like open('blah.txt') for something quick and dirty, like Python does, which I admit I do abuse if I'm trying to write something quick and dirty myself.

EDIT: This link here shows how you can write a helper function to basically turn the file i/o into a 2-liner, and I'm sure there's ways to make this even simpler: https://www.hackingwithswift.com/example-code/strings/how-to...

Re: The Decade of Swift

#54

Post by skohan »

lazyjones wrote: post #27

Swift doesn't seem to be a bad language, but during my brief adventures with it I encountered a major drawback: differences between versions are so great, that searching the web for examples is problematic and you end up with many fruitless attempts and compiler errors. Apple's documentation isn't nearly as useful and readable as that of the Go team.

This is not nearly as much of a problem as it once was. Especially with ABI stability, a lot of the language feels much more "nailed down" and language changes now tend to be additive rather than breaking.

Re: The Decade of Swift

#55

Post by wlesieutre »

willyt wrote: post #44
ncmncm wrote: post #19

I can't really imagine Swift ever breaking out of Apple's walled garden. It's a pretty big garden, but the language concedes so much to Objective-C compatibility, it is hard to see any role for it where Objective-C never got a foothold. Where am I wrong?

To install swift on a raspberry pi: curl -s " rel="nofollow">https://packagecloud.io/install/repositories/swift-arm/relea... | sudo bash sudo apt-get install swift5=5.0.2-v0.4 [0] https://lickability.com/blog/swift-on-raspberry-pi/

HN truncates long URLs, you’ll need to indent with spaces for a code block to show the whole thing

Re: The Decade of Swift

#56

Post by shmerl »

jbverschoor wrote: post #35
shmerl wrote: post #14

Earlier quoted context omitted.

I think Rust supersedes it in most aspects, especially in not being Apple driven.

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

Re: The Decade of Swift

#57

Post by m45t3r »

cableshaft wrote: post #53
dmitriid wrote: post #32

Earlier quoted context omitted.

> They don't want someone to be able to write an app that can read anything anywhere on your phone, And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else. > It's not that complicated once you look it up, and like most of this stuff Yeah, I tried to look it up.…

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 thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS.

There is pathlib nowadays that allows you to navigate in very complex situations using a quite nice OOP API.

Re: The Decade of Swift

#58

Post by willyt »

wlesieutre wrote: post #55
willyt wrote: post #44

Earlier quoted context omitted.

To install swift on a raspberry pi: curl -s " rel="nofollow">https://packagecloud.io/install/repositories/swift-arm/relea... | sudo bash sudo apt-get install swift5=5.0.2-v0.4 [0] https://lickability.com/blog/swift-on-raspberry-pi/

HN truncates long URLs, you’ll need to indent with spaces for a code block to show the whole thing

Probably best just to follow the cite link and learn more about what you might be installing. Its a random blog post I found on the internet.

Re: The Decade of Swift

#59

Post by geophile »

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 parameters? In just about every other language, a function has parameters, period. Those names are used inside the function. Depending on the language they may be used outside the function too. Swift separates those inside and outside views, permitting different names for both. And then allows for no names at all! I don't care. $n parameters seem to come from primitive languages like sh, and should have stayed there.

get/set/didSet introduces ridiculous complications just so we can pretend that a large number of function invocations look like assignment statements. This was a cool idea in C++, briefly, and then we discovered that having arbitrary code hide behind what looks like an ordinary assignment statement was a bad idea.

Extensions also remind me of C++ excesses. It is difficult to look at a piece of code involving a variable some type and be sure that I understand how that type works. The problem is that the code implementing the type is not in one place. There is the type definition, but then there are extensions. Possibly many of them. Defined all over the place.

I really dislike the irregularity surrounding let. In one context in unwraps an Optional. In another context it does not. Why?

I got off the Swift train at the release in which associated types were introduced. I'm sure it solves some actual problem, but it sure wasn't clear at the time. (The project ended -- it's not that I decided to go back to Objective C.)

Reference counting is far too intrusive, and it is easy to get it wrong in subtle ways. I find Java's (!) memory model relatively simple, and that's saying something. I understand why reference counting was chosen over GC. I don't have a good answer, but reference counting is just ugly. I actually think I prefer the C/C++ model of explicitly freeing memory.

Re: The Decade of Swift

#60

Post by leonidasv »

rb808 wrote: post #13
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.

> 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 codebases are already messing with it (and not only for Android).

Post reply on HN