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

251–260 of 274 posts

Re: Swift Static Linux SDK

#251

Post by Tainnor »

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

I was maintaining a server-side app written in Swift from 2018 to 2020 and we ran into tons of issues at least back then. I haven't looked into all the improvements they did since, but you might want to check.

My coworker wrote down some of the major issues we were facing: https://forums.swift.org/t/issues-learned-4-years-with-serve...

Personally, I've been soured enough that I don't ever want to write any server-side code in Swift again. It just seemed that Swift pretended to be open-source and cross-platform and then Apple would just unilaterally push some changes just because they wanted them for iOS (e.g. function builders for SwiftUI) without waiting for community feedback. It's fine to be a dictator for your PL, but not when you're claiming to have "open governance". All the while support for Linux was routinely being neglected.

I would rather recommend Kotlin. It's similar enough to Swift and it comes with the advantage of having the whole JVM ecosystem which can probably do most things you'd ever want to do on a server.

Re: Swift Static Linux SDK

#254

Post by kbolino »

developerDan wrote: post #243
kbolino wrote: post #227

Earlier quoted context omitted.

But that's the thing, we're comparing with Go, where all functions behave that way, and no async/await ceremony is required. Go has many weaknesses, but I don't think a language that treats async as unusual/special beats Go in that respect .

This is just a hunch but likely because of the application the two languages were originally designed for. Go is/was a purely backend lang (as I understand it) whereas Swift was built with the UI in mind which must be run on the main thread. So Swift has async/await for making clear boundaries between synchronous (aka UI) operations and asynchronous operations. I’m am not well educated on the subject though so take t…

This is a good point. It's possible to use Go this way too, but it gets tricky. You can lock the main goroutine to its O/S thread with runtime.LockOSThread and then do the heavy lifting on other goroutines, sending messages back to the main goroutine typically using channels. Given Swift's lineage, this is probably more ergonomic there than in Go.

Re: Swift Static Linux SDK

#255

Post by kbolino »

jkrejcha wrote: post #249
kbolino wrote: post #227

Earlier quoted context omitted.

But that's the thing, we're comparing with Go, where all functions behave that way, and no async/await ceremony is required. Go has many weaknesses, but I don't think a language that treats async as unusual/special beats Go in that respect .

This melding of the sync and the async is actually kinda interesting to me. I know that at least in lots of environments, the sync and async paths are effectively separate for things like I/O[1]. I wondered (and still do for some cases) how Go handles this. For those curious I looked at Windows and Linux, but not much else. Linux: no io_uring support. There's debate on even whether to use it as people are discussing…

Interesting. My understanding of how things get implemented is that all code runs essentially "async" by default, but the runtime scheduler can switch to running code synchronously when requested (runtime.LockOSThread) or necessary (e.g. "slow" calls to C via cgo).

I was not aware that file I/O isn't async on Linux. Even so, I'm pretty sure network I/O and channel operations (send/receive/select) are async via epoll. I'm not as sure about these, but I think time.Sleep and sync.Mutex.Lock suspend the goroutine as well.

Re: Swift Static Linux SDK

#256

Post by _mlbt »

OKThatWillDo wrote: post #225
Redoubts wrote: post #174

Earlier quoted context omitted.

I'm guessing they clicked onto the Built with SwiftNIO link and saw this at https://github.com/apple/swift-nio .

That's right. I did a search but this term does not seem to have a trendy or thorough definition.

In this instance they're talking about implementing network protocols, such as HTTP, where one end is the client and the other end of the connection is the server.

It's confusing because the Swift language also has the concept of "protocols" which are basically the equivalent of Java and C#'s interfaces if you're familiar with those languages.

Re: Swift Static Linux SDK

#257

Post by tracker1 »

palata wrote: post #215
tracker1 wrote: post #203

Earlier quoted context omitted.

For what it's worth, Rust uses libc by default in Linux. On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait fo…

> then it doesn't have to wait for the distro maintainers No, but it has to wait for each developer of each binary individually. Instead of relying on a team of maintainer, you now rely on all the developers. "Self-update" isn't something magical: someone has to do build the new version and ship it. With static linking you still have to build and ship for every. single. binary . With dynamic linking you just build an…

Of course... and I'm not suggesting that every app in a linux distro should be as such. You can dynamically link with Rust, Go, etc. That said, for one of the 3-4 GUI apps that most people use, the distro process tends to leave people with relatively old versions missing critical bug fixes or features.

I tend to keep my host OS pretty bare, and most of my runtime apps in Flatpak and the stuff I'm working on in Docker.

Re: Swift Static Linux SDK

#258

Post by cellularmitosis »

w10-1 wrote: post #68

This static SDK is just one example of Swift's new support for user-definable platforms, timed to amplify support for embedded and WASM. Along with the move to a non-Apple GitHub organisation, it represents real progress in extending swift to other platforms. It would be interesting to see if this is used for the AI OS that they are inviting researchers to validate for security purposes.

Speaking of Swift on other platforms, turbolent now has Swift running on PowerPC/Darwin via his wc2c project: https://forums.swift.org/t/retrocomputing-what-would-it-take...

Re: Swift Static Linux SDK

#259

Post by prophesi »

lukeh wrote: post #235
prophesi wrote: post #211

What might a cross-platform GUI app look like with Swift? I'm assuming SwiftUI can't be used? Regardless, I'll definitely be reaching for Swift for one-off scripts. I've enjoyed the times I needed to use Swift for a React Native extension.

There's not a consistent story but there are a bunch of options, principally divided into wrappers around existing libraries (SwiftGTK [1], Qlift [2], LVGLSwift [3]) and SwiftUI workalikes (Tokamak [4], SwiftCrossUI [5], AdwaitaSwit [6], there are others too). After exploring most of these for my use case (something that needs to run on an "embedded" RPi CM4 as well as iOS), I wrote a Swift bridge/runner for Flutter…

Late to respond, but thank you for the in-depth response! Your research into the different options judged by your use-case is greatly appreciated.

Re: Swift Static Linux SDK

#260

Post by glibc_free »

janice1999 wrote: post #86
thowdfasdfq wrote: post #80

[flagged]

Why though? They don't fulfill the same niches. None of those languages have a data science and ML ecosystem like Python. Rust and Swift lack mature cross platform GUI frameworks etc. Also Python is getting exciting again. 3.12 can optionally remove the GIL and add a JIT.

A language having many speakers doesn't objectively make it a well-designed language.
Post reply on HN