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

Swift Static Linux SDK

swift.org

Post reply on HN
Print view View original

271–274 of 274 posts

Re: Swift Static Linux SDK

#271

Post by saagarjha »

vips7L wrote: post #234
mannuch wrote: post #221

Earlier quoted context omitted.

First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and pave the way for greater compile time optimizations. ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java. Second, yes, ARC is a GC method. But when the language says "no garbage collector", they just mean no tr…

> traditional (tracing) GCs require more expensive runtimes and consume much more memory Not really no. Look at go, D, nim, or any ahead of time compiled language. > ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and Hot…

The ixy examples were definitely nowhere near being idiomatic code.

Re: Swift Static Linux SDK

#272

Post by vips7L »

saagarjha wrote: post #271
vips7L wrote: post #234

Earlier quoted context omitted.

> traditional (tracing) GCs require more expensive runtimes and consume much more memory Not really no. Look at go, D, nim, or any ahead of time compiled language. > ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and Hot…

The ixy examples were definitely nowhere near being idiomatic code.

Right. They spend a lot of time in pure swift and not within its C++ runtime, but when you want to compare garbage collection algorithms that doesn't really matter. The fact is that ARC is slow and you spend a ton of time counting references. Something an alternative algorithm wouldn't have to do.

Re: Swift Static Linux SDK

#273

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #116

This website is sending gzip _and_ ignoring the client Accept-Encoding header. Specifiying "identity" has no effect. Ignoring the Accept-Encoding header is common but sending gzip compressed response body and _also_ ignoring the header, thereby making it impossible for the client to disable compression using Accept-Encoding: identity, is relatively rare. Another example that comes to mind is www.amazon.com. However i…

Sadly another example is now www.sec.gov.

They require a value of "deflate, gzip" for Accept-Encoding.

Other sec.gov subdomains do not have this restriction.

FTC, who also uses Akamai, does not have it.

Weird.

Re: Swift Static Linux SDK

#274

Post by BodkinsOdds »

jimbobthrowawy wrote: post #115
Vt71fcAqt7 wrote: post #6

Genuine question: is there any reason to use Swift without iOS/SwiftUI? (Outside of devs who are primarily Swift developers that want to use something they already know for a small project or similar.)

Has nobody made a polyfill for swiftUI on other platforms yet? Or is it too tied to apple OS-level APIs? The language itself is pretty nice, last I used it. Even if some of the method (argument?) names in most SDKs are absurdly long.

There's a couple:

https://github.com/stackotter/swift-cross-ui (Linux + Windows)

https://github.com/TokamakUI/Tokamak (WASM + MacOS + some Ubuntu support)

They both had to rewrite the entire backend from scratch, because SwiftUI is very, very closed source. But Tokamak does have an import that just forwards to SwiftUI on Apple platforms.

Post reply on HN