Does anyone use Swift (in production) for backend services not related at all to the Apple ecosystem? It seems like a better Golang to me, but the tooling space only targets Apple stuff.
Swift Numerics
11–20 of 46 posts
Re: Swift Numerics
#12You may find this article I wrote useful background for understanding the capabilities of numerical computing in Swift, including details about a library which provides features overlapping with the new Swift package: https://www.fast.ai/2019/01/10/swift-numerics/
Thanks, it is a well written article. The only part which tarnishes an otherwise excellent article is the language comparisons portion. Such things are best avoided as they almost always reflect the biases of or where the author has the most experience. As you acknowledge, you were unfair to Julia. Julia has excellent support for general purpose programming. It has support for multiple dispatch, a quite powerful orga…
> JVM issues
stop the world GC (my car ran you over because of a random unpredictable pause!)
its bytecode is object-oriented
impossible at the moment to do CUDA style GPU programming without horrible JNI calls
> F# on .net core can be distributed without installing a runtime nor does garbage collection limit its expressiveness
F# has two big crippling factors: (1) the .NET at the end of its name and (2) functional programming, which is a huge barrier for 99% of developers (and it's not functional enough for the other 1%). F# is dead in the water--I mean that respectfully. To replace Python for deep learning, you need a language that other people will actually use, not should.
Re: Swift Numerics
#13Personally, I'd rather get the Swift equivalent of java.util.concurrent.
How about the equivalent of RxJava instead: https://developer.apple.com/documentation/combine
Unfortunately not available on Linux, so server side is out :(
Re: Swift Numerics
#14I am also happy to see that sometime in the last several years slices of arrays became views rather than copies. https://developer.apple.com/documentation/swift/arrayslice
Yes, and it makes working with Data so fast and easy.
Re: Swift Numerics
#15Does anyone use Swift (in production) for backend services not related at all to the Apple ecosystem? It seems like a better Golang to me, but the tooling space only targets Apple stuff.
I recently tried to use Swift for a UDP server that was meant to run on Linux. I quickly realized the Network Framework is for iOS/MacOS/iPadOS only.
I ended up using Go and I'm happy with it. I really wanted to do full stack Swift though. Just so I could become better at the language.
Re: Swift Numerics
#16Does anyone use Swift (in production) for backend services not related at all to the Apple ecosystem? It seems like a better Golang to me, but the tooling space only targets Apple stuff.
There's a lot of work being done to make Swift a good choice for ML.
TensorFlow for Swift for example - https://www.tensorflow.org/swift
Re: Swift Numerics
#17Does anyone use Swift (in production) for backend services not related at all to the Apple ecosystem? It seems like a better Golang to me, but the tooling space only targets Apple stuff.
The issue with swift on the server currently is that it’s an entirely different compilation toolchain to that run on MacOS and iOS, so the language has different bugs than those that exist for app development, and gets less attention from swift developers.
If you want to take a stab at server side swift, I’d recommend looking at the swift port of Netty that Apple released called swift-nio (after the name “swetty” was nixed by Apple marketing and communications) - https://github.com/apple/swift-nio
Re: Swift Numerics
#18Earlier quoted context omitted.
Thanks, it is a well written article. The only part which tarnishes an otherwise excellent article is the language comparisons portion. Such things are best avoided as they almost always reflect the biases of or where the author has the most experience. As you acknowledge, you were unfair to Julia. Julia has excellent support for general purpose programming. It has support for multiple dispatch, a quite powerful orga…
> JVM issues stop the world GC (my car ran you over because of a random unpredictable pause!) its bytecode is object-oriented impossible at the moment to do CUDA style GPU programming without horrible JNI calls > F# on .net core can be distributed without installing a runtime nor does garbage collection limit its expressiveness F# has two big crippling factors: (1) the .NET at the end of its name and (2) functional p…
> stop the world GC (my car ran you over because of a random unpredictable pause!)
Given a certain baseline of available resources and for the places where GC issues can be problematic (regimes I do not believe common) unpredictability of GC is the main issue, which can be readily addressed. You can for example, allocate and then manually manage or opt for a specialized JVM. If startup-time is an issue there are native compilation options. Or just not use the JVM, that's an option too.
I'll also note that Automatic reference counting is no panacea either and Python is no better suited for the scenario you've given. Personally, I've not found this to be an issue given modern low pause concurrent GC but your mileage may vary.
> its bytecode is object-oriented
> impossible at the moment to do CUDA style GPU programming without horrible JNI calls
I don't think these are deal breakers. More easily writing kernels in a high level language is very much an open problem. Even Tensorflow faces this issue, with most workflows optimized for a handful of prewritten kernels. On the JVM there are options such as https://index.scala-lang.org/thoughtworksinc/compute.scala/b... or http://aparapi.com/ for GPU backed ND-arrays or JVM translation.
> F# has two big crippling factors: (1) the .NET at the end of its name and (2) functional programming, which is a huge barrier for 99% of developers (and it's not functional enough for the other 1%). F# is dead in the water--I mean that respectfully. To replace Python for deep learning, you need a language that other people will actually use, not should.
I don't think (1) is true or even if so, see its technical relevance. If you're doing numeric/array-based differentiable programming then you shouldn't have any problem with functional programming. I'd even argue functional programming makes things easier as you get many things free from existing combinators. Many concepts are naturally expressed with the features such languages tend to have.
I don't think Python needs replacement, I'd much more rather see interoperability and language agnosticism. I can tell you that for each of Julia, Haskell, Scala, Kotlin, Ocaml, Nim, F#, Rust and of course Swift, at least one fascinating machine learning library is being built. I think that's a great thing.
Re: Swift Numerics
#19Earlier quoted context omitted.
Thanks, it is a well written article. The only part which tarnishes an otherwise excellent article is the language comparisons portion. Such things are best avoided as they almost always reflect the biases of or where the author has the most experience. As you acknowledge, you were unfair to Julia. Julia has excellent support for general purpose programming. It has support for multiple dispatch, a quite powerful orga…
On paper F# seems pretty great. Unfortunately, in practice it was the first and so far the only language I've ever used that I never found myself enjoying. I wrote a simple, but relatively robust toy language interpreter in it, so the time I put in wasn't trivial and I kept thinking it would get better, but no such luck. This is just my anecdotal experience though, I know some companies have been wildly successful wi…
Certainly, not every language will fit everyone's preferred style of thinking and approach to breaking down problems. This is why I think a diversity in available options is so useful.
Re: Swift Numerics
#20Earlier quoted context omitted.
Thanks, it is a well written article. The only part which tarnishes an otherwise excellent article is the language comparisons portion. Such things are best avoided as they almost always reflect the biases of or where the author has the most experience. As you acknowledge, you were unfair to Julia. Julia has excellent support for general purpose programming. It has support for multiple dispatch, a quite powerful orga…
> JVM issues stop the world GC (my car ran you over because of a random unpredictable pause!) its bytecode is object-oriented impossible at the moment to do CUDA style GPU programming without horrible JNI calls > F# on .net core can be distributed without installing a runtime nor does garbage collection limit its expressiveness F# has two big crippling factors: (1) the .NET at the end of its name and (2) functional p…
Is Swift's GC real-time, then? I thought it's just normal refcounting with unbounded stop times.