Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Numerics

swift.org

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Swift Numerics

#31

Post by jchb »

pjmlp wrote: post #26
zapzupnz wrote: post #23

Earlier quoted context omitted.

Swift has no GC, just ARC (automatic refcounting).

Swift has a GC, what it doesn't have is a tracing GC.

Technically it is a form of garbage collection. However, garbage collection is a very broad term that arguably encompasses even C++ smart pointers. Typically one refers to a garbage collector in the meaning of a separate process that runs independent of the application. Either in the background or “stopping the world” to collect. ARC is part of the application code. It is also visible to the compilers optimizer, which can optimize away redundant redundant reference count operations.

Re: Swift Numerics

#32

Post by fulafel »

jchb wrote: post #31
pjmlp wrote: post #26

Earlier quoted context omitted.

Swift has a GC, what it doesn't have is a tracing GC.

Technically it is a form of garbage collection. However, garbage collection is a very broad term that arguably encompasses even C++ smart pointers. Typically one refers to a garbage collector in the meaning of a separate process that runs independent of the application. Either in the background or “stopping the world” to collect. ARC is part of the application code. It is also visible to the compilers optimizer, whic…

In your division, ARC is stop-the-world variety because things like cascading deallocations cause unbounded work.

Re: Swift Numerics

#33

Post by mbroncano »

vyshane wrote: post #13
bsder wrote: post #10

Personally, 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 :(

There’s an open source implementation that can be worth exploring:

https://github.com/broadwaylamb/OpenCombine

Re: Swift Numerics

#34

Post by zelly »

fulafel wrote: post #20
zelly wrote: post #12

Earlier quoted context omitted.

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

No, but ARC does not have to pause all threads. Also this exists:

https://developer.apple.com/documentation/swift/unsafemutabl...

Re: Swift Numerics

#35

Post by Stubb »

Cybiote wrote: post #18
zelly wrote: post #12

Earlier quoted context omitted.

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

Can you expand on F# not being functional enough for the other 1%?

Re: Swift Numerics

#36

Post by igouy »

Cybiote wrote: post #5
jph00 wrote: post #2

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

> Setting aside the problems of microbenchmarks and unidiomatic code …

We don't get to set aside problems when they would undermine a premise of your conclusion.

Use of the benchmarks game as evidence must imply that you have confidence in that evidence.

Re: Swift Numerics

#37

Post by favorited »

ynx wrote: post #27
favorited wrote: post #24

Earlier quoted context omitted.

Honestly that's no different than realizing that AVFoundation or CoreGraphics is Apple-platform-only... Network.framework is an Objective-C framework (I'm honestly surprised I don't seen any C++ symbols in the binary) – it was never supposed to be a cross-platform framework. SwiftNIO is the official base of the OSS Swift cross-platform networking toolchain. It's the equivalent of Java's Jetty package.

Netty, not Jetty.

Right, thanks!

Re: Swift Numerics

#38

Post by pjmlp »

jchb wrote: post #31
pjmlp wrote: post #26

Earlier quoted context omitted.

Swift has a GC, what it doesn't have is a tracing GC.

Technically it is a form of garbage collection. However, garbage collection is a very broad term that arguably encompasses even C++ smart pointers. Typically one refers to a garbage collector in the meaning of a separate process that runs independent of the application. Either in the background or “stopping the world” to collect. ARC is part of the application code. It is also visible to the compilers optimizer, whic…

Typically one refers to the CS definition of automatic memory management, using accredited references like "The Garbage Collection Handbook: The Art of Automatic Memory Management".

Everything from "ARC" is there on chapter 5.

Re: Swift Numerics

#39

Post by pjmlp »

manojlds wrote: post #16
zelly wrote: post #11

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.

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

Still no Windows binaries.

Re: Swift Numerics

#40

Post by bluk »

zelly wrote: post #11

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.

I've pushed a few admittedly minor backend services in Swift to production. It is ok.

You basically have one viable non-Apple OS platform (Ubuntu) to deploy on. This means that your basic Golang service is a 10MB Docker image while it can be over 100MB for a basic Swift service. There are frameworks like Swift NIO which is based on Java's Netty (and there are some Apple developers who work on Netty also working on Swift NIO). It works well enough but in most benchmarks, Swift is not even close to Netty ( https://www.techempower.com/benchmarks/#section=data-r18&hw=... ), so if you're pushing the code expecting high performance, I would think twice. Swift gRPC (latest version based on Swift NIO) is also available, and while I think it works very well, it is still relatively new.

As far as tooling, Swift is very immature IMO if you step outside Xcode. There are efforts to get a LSP service fully working (SourceKit-LSP), but I find it to be ok at best (performance and code completion suggestions are often very hit or miss). From benchmarking to diagnostics/backtraces to logging and metrics frameworks to shared common knowledge/answers on Stack Overflow, it is still very early days for Swift. Golang is so far ahead here that I personally think (at least today) the only reason you should launch a Swift service into production is because you want to reuse code that you have in your app.

If you like Swift's type system and want a backend service equivalent, I would strongly recommend looking into Rust. IMO, Rust is a version of Swift where the programmer is given more control of what the code is actually doing (along with the associated responsibility). It sounds like a lot of trouble, but I find most Swift code naturally translates to Rust code (especially if you follow the "value vs reference" semantics ideology that the Swift compiler team advocates). At worst, if you learn Rust, you will understand Swift a lot better (like what really is an escaping vs. non-escaping closure or what is the difference if I use a generic versus a dynamic protocol type (dyn trait in Rust) in a function definition).

Post reply on HN