Hacker News Reader

Comment by ilovecaching | Hacker News Reader

Is anyone using Swift outside of Apple specific stuff professionally? When they first announced swift it felt like it might catch on as general purpose gced language. The language itself is quite beautiful in a lot of ways (although being OO was obviously an awful step backwards). But it feels like it's still just the crazy language Apple uses, just like Objective-C was.

View on HN

We've been eye-ing it for a while at remind.com. Our hangup has been that we're heavily aws focused, but https://github.com/amzn/smoke-aws is looking promising.

We're interested because it's one of a handful of statically typed functional programming languages. Haskell/Ocaml are great as ML type languages, but it's a big paradigm shift for a team to jump into. Rust still has a pretty decent learning curve. Swift seems to have landed nicely in the "anyone can pick it up" territory. Kotlin is also in that territory, but the JVM is a beast.

For now, we're heavily focused on Typescript as the statically typed functional language, and we leverage types pretty aggressively (conditional types, discriminant unions, etc). Our iOS devs bring a lot of the Swift style over to our backend Typescript systems and from what I've experienced I think Swift absolutely will have a place in backend development.

Swift is a nice language but I think the reliance on ref counting is going to limit its adoption. You have to work a lot harder to avoid reference cycles in Swift than you do in a garbage collected language. Unless GC latency is a deal breaker for your problem domain it’s not worth the extra effort.

My money is on Rust for really low level stuff and Kotlin for anything where JVM overhead is acceptable.

It really depends on what you're doing. A lot of the time, neither garbage collection pauses nor reference cycles are an issue; and when they are it's typical that one or the other will solve the issue.

If GC pauses aren't an issue for your app then you're better off with a full-blown GC because it's a lot easier to code for. Reference counting, as used in Swift, forces you to think a lot about cases where you might be creating reference cycles and memory leaks. GCs can figure this out for you and take that burden off the programmer.

Yes, but reference counting doesn't have unpredictable pauses, which can be important in certain situations. That's what I was trying to say above.

One of the major advantages of reference counting is that it's easier to integrate with other languages. For example you can manipulate Swift objects from C via CoreFoundation, which then allows them to be used from C++, Rust, whatever.

GC'd languages have some support (JNI, etc) but they require handles, pinning, write barriers, etc. which ends up being more complicated and less flexible.

Right, which is one of the reasons it makes sense for Apple to use it, since they have a lot of lower level C API to interact with.

For more general purpose backend work this is not usually a major consideration though, which is one of the reasons I predict most backend work will continue to be done in a GC language.

What do you see as the advantage of Rust or ref counting?

I've just read the Rust docs and not written any code so I'm probably the wrong person to ask but Rust's ownership rules seem to make it possible to eliminate a lot of dynamic allocations in the first place.

Ref counting can beat GC if you're in a domain where GC pauses can be an issue. Things like games, for example. Although I understand state-of-the-art GCs can also be fast enough to use for these kinds of applications in some cases now. Ref counting can also be more memory efficient than GCs.

Ref counting can also be slower than tracing GC when getting rid of complex data structures, heavy multi-threaded code and can lead to stack overflows if destructors are incorrectly written.

> You have to work a lot harder to avoid reference cycles in Swift

It depends on how you use it. As I understand it, if you use enums everywhere it all sort of works out. If you start mixing in structs, there are certainly a lot of minefields.

I would assume good debug-tooling should make spotting such cycles quite easy, why is this even considered a problem?

It’s not easy and iOS developers spend a lot of time explicitly breaking ref cycles in code and tracking down resource leaks. I’ve seen a lot of code from experienced iOS devs that gets it wrong.

What kinds of mistakes do you see? Forgetting to use capture lists entirely? Using them improperly? Not making delegates weak properties?

I don't really consider a language to be functional without a concise application and composition operator (also automatic currying and partial application). How can you be functional if you don't have the basic operators for combining and applying functions?

It looks like Swift has automatic currying though, so that's pretty close.

It doesn't have automatic currying. What code/docs are you getting that impression from?

Swift used to have a special syntax for defining automatically curried functions, but it was removed in Swift 3: https://github.com/apple/swift-evolution/blob/master/proposa...

Indeed, and the compiler still had the relicts of that functionality at least until Swift 4. I'm wondering how they got the impression Swift still has currying, given it sounded like a recent "discovery".

If you have automatic partial application you lose the ability to have multi-arity functions. Functional programming is about functions, not operators. In Clojure you can compose and partially apply functions with the normal functions "comp" and "partial".

https://github.com/clojure/clojure/blob/clojure-1.9.0/src/cl...

Automatic currying and partial application are really just nice to haves though. You can manually do both as long as the language supports higher order functions.

The JVM is indeed a beast in available tooling, libraries and production monitoring.

Kotlin has an LLVM backend these days and can compile to native binaries. It's more Swift-like, then.

Google are beginning to use it for Tensorflow: https://www.youtube.com/watch?v=s65BigoMV_I

There's a course currently running in University of San Francisco run by Fast.ai which is using Swift-Tensorflow taught by Chris Lattner for two lessons: https://www.usfca.edu/data-institute/certificates/deep-learn...

Not exactly what you asked, but pertinent.

I don't expect that will do very well. ML is already crowded, and Python is already solidly at the top. Having worked in ML myself, no one would switch if it meant dealing with a real statically typed language they could hack away at easily in a repl or jupyter notebooks, or access mypy, numpy, scikit, etc. ML is an ecosystem of tools that are all in Python currently.

Just a side-note. Swift comes with an repl and has support in Jupyter and Google Colab for whatever that's worth. As you mentioned the numerical computing ecosystem is just not anywhere close to Python or even Julia. There is a silver lining in that Swift has pretty decent Python interoperability.

In Swift you can just write

import Python

var np = Python.import(“numpy”)

And can then use numpy as you would normally. Same goes for plotting.

Jeremy Howard and Chris Lattner are starting to push Swift for Tensorflow:

- https://www.github.com/tensorflow/swift

- https://www.fast.ai/2019/03/06/fastai-swift/

They must push it really well for it to ever be considered an alternative to Julia, ML.NET, Python/C++, Deeplearning4j on Windows.

Sibling comments mention Chris Lattner. For readers that might not know him, he's the main inventor of Swift. Him pushing Swift should not necessarily be taken as a sign of general community enthusiasm.

I would love to see more Swift on the backend. It's surprisingly hard to find a language that's concise, expressive, statically typed, and easily accessible to beginners. Swift checks all these boxes.

That being said, it's much easier to succeed on the front-end when the only competitor is Objective-C (see: JavaScript), than on the backend when the competitors are Go, Rust, Elixir, Python, Node, C++, Java and more, all with large ecosystems already in place.

Swift may succeed in a niche, and "Swift for TensorFlow" appears to be an attempt at that, but I don't think it will become ubiquitous (call it traditional HN negativity).

He started a podcast last year to promote Swift outside Apple platforms, it lasted three episodes.

Which podcast are you talking about?

This one https://www.swiftcommunitypodcast.org/

As far as I can tell, that podcast was started earlier this year, and is still active?

Right, I was wrong about the start date, on my mind it was started in December.

As for being active, no signs of life since 08th February, more than one month without updates.

There's still stuff going on on the GitHub repository: https://github.com/SwiftCommunityPodcast/podcast

So in one and half months they haven't found time nor a volunteer willing to do another podcast?

My favourite podcasts have weekly and bi-weekly updates.

Yeah, he can't even release a podcast episode whenever you want him to. Does he not know he won't make it to your list of favorite podcasts? Why does he even wake up? Lattner is such a loser.

If he cares about actually grooming a community outside Apple platforms, maybe.

Swift is a great language.

The main problem for me is that it's still very Apple centric. Other platforms are still very second class.

For Linux, there are only Ubuntu packages. Even on Arch which is usually front of the pack with these things, there are only brittle third party (AUR) packages.

Windows support is even worse.

For me, it's the best language for game development that I've seen ever since I wanted to make my own games as a kid.

They'll need to do an awful lot more on their IDE for that to happen.

That GUI drag'n'drop onto code... ugh.

That's just a convenience thing. I've worked in Xcode for nearly 10 years and I never use that feature. Good feature for teaching though. But if you hate it, just don't use it.

Unless you consider reference counting to be a form of GC¹, Swift is not a GC'ed language.

¹It technically is, but most people don't mean reference counting when they say GC.

It doesn't matter what people think, rather CS definition.

Software Engineering is not about what people think, rather what is technically correct.

Well.. what is technically correct depends on a definition. And there are customary/practical definitions too. And sometimes definitions are tainted by context, like in "is this gc or ref counting language".

Which should be "is this tracing GC or ref counting language".

Naturally when in some juriditions one is allowed to call themselves engineers after a 6 months bootcamp we land in such customary/practical definitions.

Even wikipedia admits that most people mean tracing GC when they say GC.

What exactly are you trying to accomplish here?

Advocating learning CS properly.

It certainly does matter because the question is what did the grandparent mean.

Some people want to improve their skills, others don't.

Reply on news.ycombinator.com