16 ms·

Swift Static Linux SDK

339 points by mannuch 2y ago

palata 2y ago
> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right? Still, it's cool that Swift provides static linking. But like in any language, the best IMHO is when the Linux distribution can choose how it wants to distribute a package. I tend to like shared libraries, and already Rust seems to be interfering and imposing its preferences. I am happy if Swift doesn't.
- e63f67dd-065b 2y ago
  It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions here: vendor all the dependencies, and distros can't mess with them. Makes it easier for upstream and the distro. Modern languages are not like C/C++: a single non-trivial rust program can easily depend on 100+ crates, and re-creating crates.io in your package manager is just a bad idea, even putting aside that there's probably major version incompatibilities the moment you go beyond a handful of programs. Look at the disaster that's python package management, that's not where you want to end up.
  - School-Cotton 2y ago
    Some distros do actually break out rust dependencies into separate packages (e.g. Guix does this). It's just that a lot of rust software isn't distributed primarily by distros.
    - frankjr 2y ago
      Fedora and Debian do this too. That's why it sometimes takes longer for a project to be packaged - you literally have to recursively package all of the dependencies first.
      - palata 2y ago
        Which is a feature, and not a bug: some of us want our distro maintainers to actually have a look at what they distribute.
        prmoustache 2y ago
        Yes and it doesn't prevent anyone to build software separately, being written in rust or any other language.
      - NekkoDroid 2y ago
        > Fedora and Debian do this too. IIRC Arch does as well (or at least tries to).
        frankjr 2y ago
        Arch does for quite a few ecosystems (Python, Ruby, Haskell, ...) but currently not for Rust.
  - frankjr 2y ago
    > Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't respect the lock file (or the project doesn't use it) and you just fetch the latest compatible dependencies at the time of build, you now have no idea if you're affected or not by the vulnerability because you don't have the exact resolved versions stored anywhere (https://github.com/rust-lang/rfcs/pull/2801 https://github.com/rust-lang/rfcs/pull/2801).
    - palata 2y ago
      I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary. Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.
    - josephg 2y ago
      > Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.
      - palata 2y ago
        > It would make this sort of vulnerability scanning much easier to do. Scanning, sure. Fixing... surely much harder than with shared libraries.
        josephg 2y ago
        Only because the build tooling is less mature. It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.
  - palata 2y ago
    As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.
    - akira2501 2y ago
      You're not forced to with Go. CGO exists and requires dynamic linking.
      - deleted 2y ago
        [deleted]
    - newZWhoDis 2y ago
      More software should “enforce” their preferences, many decisions are objectively superior and this “anything goes” attitude has done nothing but hurt OSS/Linux adoption. Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.
      - palata 2y ago
        I couldn't disagree more. > Everything about the shared lib model is stupid I don't think we can discuss if that's you're stance. But also I don't think you understand the shared lib model if you think like that.
      - lmz 2y ago
        Dynamic linking seems to work fine for Windows or OSX. Maybe it's open source + dynamic linking that's the problem.
        palata 2y ago
        Honestly a problem is that most developers just don't understand how it works. Docker / static linking solves a lack of understanding, mostly. That's why they are popular.
  - lynndotpy 2y ago
    I feel the same. A huge part of the pleasure of Go and Rust are that I never run into dependency problems. I'm happy to pay the "Hello World is 4MB" tax.
    - LtWorf 2y ago
      And the "I now have to evaluate thousands of libraries instead of 10 well established framework" tax? I've seen plenty of bad go libraries. For example their authors will be unaware of isatty() so they will output control codes when piped. If you factor in the time to find a competently written library (and quite possibly write one yourself) it starts to be less convenient.
  - LtWorf 2y ago
    > the disaster that's python package management, that's not where you want to end up The one where the only sane option is using distribution packages or conda and ignoring anything that the python community comes up with?
    - j1elo 2y ago
      I had my Python and pip installed from distribution packages. One day I needed to build something from source, but it needed Meson... Ok installed Meson also from my distro packages! But no, the project required a newer Meson version. Ok let's install Meson with pip! But no, it turns out pip packages themselves can require a minimum pip version!! Go figure. So I couldn't build that program without first pip-installing Meson, and I couldn't pip-install Meson without first pip-installing a more modern version of pip itself. Guess how well it worked when I upgraded pip. Spoiler: not a smooth way to discover that Python packaging is a joke.
      - icedchai 2y ago
        Were you using a virtualenv? Or were you pip installing into your distro / system python, like a true savage?
        j1elo 2y ago
        I just knew the basics. So I was just following commands from stack overflow or similar. Silly me, thinking that it would work logically like other languages do! Later I ended up learning about all that stuff with venvs and whatnot, not to mention it's not even a unified solution but there are multiple alternatives, adding to the confusion... All this, no doubt, is a consequence of how terrible the Python packaging story is. Rust, Go, Ruby, Node, and more, I had used without remotely similar hassles.
        icedchai 2y ago
        You are right. It's not a good experience for new developers, especially given how long Python has been around.
  - OKThatWillDo 2y ago
    "vendor all the dependencies" What does that mean?
    - PaulDavisThe1st 2y ago
      It means "add the source for your dependencies to your own codebase and build them with your build system".
      - OKThatWillDo 2y ago
        Thanks. Not an appropriate use of the noun "vendor," so I would never have guessed that.
        mkl 2y ago
        It's the verb vendor: https://en.wiktionary.org/wiki/vendor#Verb https://en.wiktionary.org/wiki/vendor#Verb
        deleted 2y ago
        [deleted]
        OKThatWillDo 2y ago
        "Vendor" isn't the verb. The verb is "vend."
        mkl 2y ago
        That's a different verb, with a different meaning.
        spacechild1 2y ago
        Did you read the link?
  - PaulDavisThe1st 2y ago
    > Modern languages are not like C/C++ I think there's a bit of a misconception here. Ardour is written in C++ and depends on 80+ other libraries. The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.
    - palata 2y ago
      I started a small project both in C++ and Rust. When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive). In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies. > but it is by no means determined by language or even context. Not sure what you mean there. My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help. If you have to manually handle every single dependency, first it forces you to look at them (that's a good thing), and second it encourages you to minimize them.
      - PaulDavisThe1st 2y ago
        > My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help What is it that makes you think that C/C++ does not do this also? [ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]
        palata 2y ago
        > What is it that makes you think that C/C++ does not do this also? My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.
        PaulDavisThe1st 2y ago
        I would suggest that this caused more by ideas about the appropriate scope and scale of libraries in the 2020s than anything specifically connected to the language in use.
- mshockwave 2y ago
  > Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? More of a shared library issue I believe. > Say my Linux distribution distributes some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right? That's correct
- manmal 2y ago
  A Swift program for a particular distribution will dynamically link some system libraries from the distro, and these libs might change on every distro update. They mention in the post that dynamic linking can cause versioning issues. > Say my Linux distribution distributes some Swift runtime That runtime would need to be compatible with the Swift program. Nowadays that’s not a big issue due to ABI stability (https://www.swift.org/blog/abi-stability-and-apple/ https://www.swift.org/blog/abi-stability-and-apple/), but this would close the door on new features that need runtime support (need an OS update then, or the OS must come with multiple runtimes).
  - Longhanks 2y ago
    AFAIK they claim ABI stability only for Apple platforms, explicitly neither Linux, nor Windows. Has that changed?
    - BodkinsOdds 2y ago
      Nope. For the foreseeable future, stable ABI on other platforms is basically only going to happen if a distro starts supporting an ABI stable standard library on their own.
- School-Cotton 2y ago
  Dynamic linking works fine for software that is distributed by distros, but lots of software isn't.
  - palata 2y ago
    Sure. It's great to have the possibility to link statically. My beef with the "static linking trend" is that many people (or languages, e.g. Rust) don't want to let me link dynamically, for some reason. Just let me choose!
    - tux3 2y ago
      But they do. They do let you choose. Debian's build of rust packages are linked dynanically, for instance. It's a build setting, you can turn it on.
      - LtWorf 2y ago
        No, crates will be statically linked anyway in general.
        kibwen 2y ago
        Rust supports dynamic linking, it's just not the default, so you need to configure a given crate to use it at build time.
        LtWorf 2y ago
        Rust supports compiling each crate as a separate .so and then linking all of them? That's not at all how debian packages written in rust are linked. So the person I replied to is incorrect. I suspect you're incorrect as well and what you claim doesn't exist at all, but you're claiming a different thing.
        School-Cotton 2y ago
Vt71fcAqt7 2y ago
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.)
- Mandelmus 2y ago
  It's a beautiful language that's a joy to write. It's safe and ergonomic, and has an extremely powerful type system. I'd say those are good reasons to use Swift.
  - oddevan 2y ago
    I'm really interested in exploring it for building web app backends because of this. Being able to have a drag-and-drop distribution is even better.
    - _mlbt 2y ago
      I haven't used it yet, but I've heard really good things about Vapor as far as server side Swift goes... https://vapor.codes https://vapor.codes
      - OKThatWillDo 2y ago
        Thanks. What is a "protocol server?"
        potatolicious 2y ago
        Not a super-expert but I've used Vapor on some personal projects. Do you have a link to the mention for "protocol server"? I'm not familiar with the concept but might be able to help.
        Redoubts 2y ago
        I'm guessing they clicked onto the Built with SwiftNIO link and saw this at https://github.com/apple/swift-nio https://github.com/apple/swift-nio.
autoexecbat 2y ago
I guess this means it can compete with golang on ease of distribution. Pushes all the complexity away from the end user
- e63f67dd-065b 2y ago
  Yeah, I'm really glad for the trend of statically linked binaries that came with Rust/Go. No more version incompatibilities, fights with downstream packagers, weird build configs, etc, just distribute the binary and that's it.
  - School-Cotton 2y ago
    Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.
    - Cyph0n 2y ago
      Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2-with-host-tools https://doc.rust-lang.org/rustc/platform-support.html#tier-2...
      - MrDrMcCoy 2y ago
        I've had a 0% success rate compiling other people's Rust apps statically. I always end up with a shared binary or a failed build, even when building with musl.
        kibwen 2y ago
        What problems did you have? As someone who's never in his life used musl before, I just now ran `rustup target add x86_64-unknown-linux-musl` and then built ripgrep with `cargo build --release --target=x86_64-unknown-linux-musl` and it worked without a problem. ldd confirms that it's statically linked. I'm surprised it was as painless as it was, I thought I'd have to install musl separately.
jkelleyrtp 2y ago
Swift 6 is amazing - I say this as a big Rust person. It seems like Swift is now its own entity outside the Apple bubble and has a few very interesting features: - An "embedded" mode that turns off reflection for kilobyte-sized binaries - An upcoming WASM target - An LSP for VSCode - Native C++ interop - Typed "throws" - Static linking on linux and the linux sdk - Porting a number of "core foundation" / foundation primitives to nix platforms - Distributed actors for concurrency that run on distant machines - Data-race free by default - non-copy RAII generic types Watch the video on Swift 6: https://developer.apple.com/videos/play/wwdc2024/10136/ https://developer.apple.com/videos/play/wwdc2024/10136/. IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for. Swift has shipped stuff that Rust has been sitting on its hands over for years: - Anonymous enums/structs in parameters/match statements - Named function arguments - A type of `Send` bound that allows Rcs to be sent between threads (not Arcs) - Swift preview hotreloading - autoclones (without GC) Swift also took a bunch of goodies from Rust *[1] - No garbage collector - Traits via "protocol" - ADT for Option/Result - macros - non-copy types enforcing RAII I really really wish Rust had been keeping up with Swift's ergonomics because it's looking like Swift is going to catch up to Rust's cross-platform story much faster. Swift really could end up as the "do it all" language for frontend/backend/app dev. [1] By "took" I mean if you like these things in Rust you'll see them in Swift
- christophilus 2y ago
  How’s the compilation speed?If it’s going to replace Go, that’s gotta be sub second for a medium sized project on my clunky old laptop.
  - coldtea 2y ago
    Why, would you care if it's a full second or even 5 seconds? Go hyped their compilation speed a lot in its early years, but unless it's C++ templates level slugginess it's not like it's that big of deal.
    - square_usual 2y ago
29athrowaway 2y ago
Why should I use Swift instead of Rust?
- manmal 2y ago
  The concurrency story is quite good now with Swift 6, and it’s arguably easier to handle than the borrow checker, but still very safe.
  - Sytten 2y ago
    The way I view it as a Rust experienced programmer: Its kinda like if everything in your program was Arc<dyn Trait> and we didnt have the mess that are the async executors. But I might be wrong. Love rust but god that sometimes I curse the choices that were made and how slow it evolves.
    - manmal 2y ago
      I don't have a lot of experience with Rust, but that sounds about right.
    - msk-lywenn 2y ago
      And supposedly, the compiler transforms the Arc in Rc or even removes it entirely if it can prove to be fine. I still did not check if there is a tool that tells you what was optimized and the reason why something wasn't.
- singularity2001 2y ago
  Swift is elegant, beautiful and concise, whereas Rust is an ugly verbose sigil mess.
  - 29athrowaway 2y ago
    Would it be fair to say that Rust is a better C++ and Swift is a better Objective-C?
anothername12 2y ago
Can I make Gtk GUI with this like you can with cocoa on macOS?
- square_usual 2y ago
  Yes: https://www.swift.org/blog/adwaita-swift/ https://www.swift.org/blog/adwaita-swift/
zshrc 2y ago
Crazy that they’re still offering CentOS 7 images. PLEASE DONT USE THEM
w10-1 2y ago
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.
- hugodan 2y ago
  Wasm? Care to provide source for that?
  - andrewjl 2y ago
    https://swiftwasm.org https://swiftwasm.org https://github.com/swiftwasm/swift https://github.com/swiftwasm/swift https://github.com/swiftwasm/WasmKit https://github.com/swiftwasm/WasmKit
  - mannuch 2y ago
    https://github.com/apple/swift-for-wasm-examples?tab=readme-ov-file https://github.com/apple/swift-for-wasm-examples?tab=readme-...
  - deleted 2y ago
    [deleted]
- janice1999 2y ago
  Wow, I had no idea people were using Swift for Embedded: https://github.com/apple/swift-embedded-examples https://github.com/apple/swift-embedded-examples
  - favorited 2y ago
    It's relatively new. Apple put out a WWDC session video about embedded Swift today: "Go small with Embedded Swift" <https://developer.apple.com/videos/play/wwdc2024/10197/ https://developer.apple.com/videos/play/wwdc2024/10197/>
  - 2y ago
thowdfasdfq 2y ago
[flagged]
- janice1999 2y ago
  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.
  - glibc_free 2y ago
    A language having many speakers doesn't objectively make it a well-designed language.
- mardifoufs 2y ago
  I get rust and swift (maybe) but kotlin is basically on par with java at this point. Maybe 2.0 will create a wider gap but if Java 21 has nice things that kotlin doesn't have, and when you add those up there's no clear winner imo.
  - tadfisher 2y ago
    Java 21 can't have things that Kotlin doesn't have, because you can call any Java method from Kotlin. On the other hand, Kotlin can target native, JS, and WASM platforms as well as the JVM, which is something Java does not do (barring alternative VMs like Graal).
- deleted 2y ago
  [deleted]
JackYoustra 2y ago
Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.
- rescripting 2y ago
  Could you elaborate?
  - JackYoustra 2y ago
    Yes! See my reply above
- gh123man 2y ago
  I'd love to hear some specific examples. Ive built several iOS apps and a whole backend (on linux) with Swift and other than lack of OSS library support for some SaaS APIs, it's been quite nice. Sure Swift itself has some sharp edges, but not any more (or worse) than many other popular languages.
  - JackYoustra 2y ago
    Sure! I love talking about this stuff :) here's a few: - if you want to manager your Package.swift target, you mostly have to deal with .target enum (can't figure out how to paste the URL) You can really only do a define or unsafeFlags, which leads to a couple issues... 1) There's only Debug and Release configurations! What if you want more? What if you want a nice flow where you emit and consume pgo data and re-ingest it? 2) What if you want to use a define for another language managed by SPM, such as metal? 3) What if you want to put in a portable path into a linker argument? SPM blocks use of build-time environment variables, so you can't do that either. All of these things seem contrived, but I ran into all three of them at my current job (shameless NanoFlick plug). All of these can be handled by cmake or xcodebuild (although probably better to use rules_xcodeproj). - Swift compiler feedback and performance in builders is absolutely atrocious, to the point where binary searching a view to find the actual source of a type error over ~30 second build times isn't very unusual! - It's very overly conservative with build times, and because there's only module-level import, it's very easy to accidentally have a long dependency chain which makes building one file imply building many files, further tanking your build time. There are some forum posts I can dig up on this if you're curious more on this point. - POD structs are default-Sendable at module-level visibility, but lose that if they're public, which means if you try modularizing your app into different small packages to restore some notion of compilation units to fight against the above two points, you end up having to go around and mark all of your different classes with default protocols (usually just Sendable) to reimplement! - Not a huge deal, but no way to have macro_rules! like you can in rust: macros are kinda hard to use and have to be in another package. This is just my thoughts on tooling, I have many more thoughts about the language itself that I'd be happy to share. Honestly though it's much better with vscode. I do hope that it makes progress in the right direction, Swift has a lot of things going for it!
dzonga 2y ago
Swift could've easily replaced python. but the language got complex and is now a baby C++.
- azinman2 2y ago
  Those are pretty different languages. One you just run as a script with no compilation and no static typing, the other is fully compiled and linked into a binary. How could they replace each other? And what’s the complexity now that even remotely approaches c++?
  - dagmx 2y ago
    Fwiw, you can use Swift in a very Python like way. If you give a Swift file a shebang, it’ll execute as a standalone script. I still don’t agree they’re necessarily as overlapped as the other person claims but there is a decent area where Swift is easy enough to replace Python tooling
- guestbest 2y ago
  Does swift still lack a built in package management system?
  - dagmx 2y ago
    https://swift.org/documentation/package-manager/ https://swift.org/documentation/package-manager/
  - newdee 2y ago
    No, this came with Swift 3 back in 2016.
- pzo 2y ago
  I think it's too late which is sad since Swift is not a bad language even though I agree it got complex since the last 5 years. Python is mostly used not because of its language features but for cross-platform ecosystem. This is hard and slow to build especially these days (comparing to 10 years ago) since there are many languages and winner takes all or most of the cake. The only way is 1) to provide something really groundbreaking at the time (e.g. ruby on rails) 2) piggyback on other ecosystem by providing great interop (e.g. maybe mojo in the future) 3) slowly grind and hustle until something eventually catchup (e.g. maybe rust in the future) The problem with apple is they are too much focused to wall garden you instead of build ecosystem. Their IBM partnership failed to make something like Rails or Spring Framework for backend. Tensorflow for Swift failed even though it was google project. They don't have cross platform support in their DNA. You don't even get Xcode on Windows or iPad - this is dealbreaker for many people. I would bet more on kotlin (native) / java even though I'm iOS dev myself. Embedded is the exception that they still might win the game since the only competition there is pretty much: C, C++, Rust and sometimes python, js more as a glue.
deleted 2y ago
[deleted]
1vuio0pswjnm7 2y ago
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 in that case one can disable compression by sending a Viewport-Width header.
- cqqxo4zV46cp 2y ago
  There is, in reality, nothing unusual about that.
- 1vuio0pswjnm7 2y ago
  They have now fixed it after I submitted this comment. No longer sending gzip by default. Thanks for that. Someone tell Amazon they should do the same.
- 1vuio0pswjnm7 2y ago
  In addition to viewport-width www.amazon.com also requires a user-agent header in order to disable compression
- 1vuio0pswjnm7 2y ago
  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.
stephen_g 2y ago
This is awesome, and I believe opens up what I and a bunch of people were wanting which is the ability to run Swift binaries in Alpine containers! I'd seen work on musl support going in but I didn't realise it would all be going so soon. Cross compilation is very nice too to not need your runtime platform to necessarily support the whole toolchain. I'm really glad there's finally support for vanilla Debian and from what I've seen it looks like there are initial Swift packages finally being added in the Debian testing version, which will be nice. Debian is more and more my go-to for development VMs where Ubuntu used to be, so I'm excited for official support! With all this and embedded, I'm really excited about Swift! I've done a lot of embedded in C and I'm super keen to try out Swift on my STM dev boards!
prophesi 2y ago
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.
- easeout 2y ago
  In iOS 18, there is now a SwiftUICore framework that's separate from SwiftUI, which I imagine consumes it. I don't see the new one on the documentation site. If that becomes public in a year or so, maybe you'd be able to replace one of the two frameworks to implement your own view system atop the attribute graph and data flow bits.
  - saagarjha 2y ago
    It's unlikely this will ever be made public. It's probably just there for organizational reasons, just like UIKit got made an umbrella framework for UIKitCore a while back.
- lukeh 2y ago
  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 [7] which is working well. That enables me to write the UI in Dart and the business logic in Swift. I looked at all the other options below (that's how I know about them, indeed [3] I wrote as part of my research), in the end I felt that none of them were at the time of investigating sufficiently mature to base a product around. [1] https://github.com/rhx/SwiftGtk https://github.com/rhx/SwiftGtk [2] https://github.com/Longhanks/qlift https://github.com/Longhanks/qlift [3] https://github.com/PADL/LVGLSwift https://github.com/PADL/LVGLSwift [4] https://github.com/TokamakUI/Tokamak https://github.com/TokamakUI/Tokamak [5] https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui [6] https://github.com/AparokshaUI/adwaita-swift https://github.com/AparokshaUI/adwaita-swift [7] https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift
cryptonector 2y ago
> Cons of static linking: Not listed is that ASLR either doesn't work at all or you get just one object (the PIE's) randomized. For a memory safe language this may not be a con at all. Also, when many executables can share common objects then there can be a reduction in I/O (reads) needed to load those the next time that one of those executables runs. In 2004 when the Solaris 10 (then a work in progress) unified process model delivered, and all system executables were dynamically linked, boot times went down by a lot.
- deleted 2y ago
  [deleted]
darthrupert 2y ago
How good is the LSP? In another like-Rust-but-better language (Kotlin), that part is just abysmal.
- saagarjha 2y ago
  It's fine, not quite great. It does autocomplete and jump to definition, but some stuff (e.g. refactoring) isn't implemented yet.
huyegn 2y ago
Swift for all its niceties still suffers from a habit of inherently tying its conventions to Apple and its "appleisms" when coding. Tasks that should be relatively straightforward to do e.g. iterating through a file line-by-line still requires an awkward amount of code. It's especially noticeable when compared to languages like Go or Python: https://forums.swift.org/t/text-streaming-in-standard-library/19328 https://forums.swift.org/t/text-streaming-in-standard-librar... While these things are not difficult to solve with some minor additions to the standard library and documentation that emphasizes some basic conventions, the fact that we're on Swift6 and things like this aren't just available speaks to how much further the community needs to evolve to get the language ergonomics right for non apple-y things.
- saagarjha 2y ago
  What's wrong with for try await line in file.lines ?

339 points by mannuch 2y ago

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right? Still, it's cool that Swift provides static linking. But like in any language, the best IMHO is when the Linux distribution can choose how it wants to distribute a package. I tend to like shared libraries, and already Rust seems to be interfering and imposing its preferences. I am happy if Swift doesn't.

e63f67dd-065b 2y ago
It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions here: vendor all the dependencies, and distros can't mess with them. Makes it easier for upstream and the distro. Modern languages are not like C/C++: a single non-trivial rust program can easily depend on 100+ crates, and re-creating crates.io in your package manager is just a bad idea, even putting aside that there's probably major version incompatibilities the moment you go beyond a handful of programs. Look at the disaster that's python package management, that's not where you want to end up.
- School-Cotton 2y ago
  Some distros do actually break out rust dependencies into separate packages (e.g. Guix does this). It's just that a lot of rust software isn't distributed primarily by distros.
  - frankjr 2y ago
    Fedora and Debian do this too. That's why it sometimes takes longer for a project to be packaged - you literally have to recursively package all of the dependencies first.
    - palata 2y ago
      Which is a feature, and not a bug: some of us want our distro maintainers to actually have a look at what they distribute.
      - prmoustache 2y ago
        Yes and it doesn't prevent anyone to build software separately, being written in rust or any other language.
    - NekkoDroid 2y ago
      > Fedora and Debian do this too. IIRC Arch does as well (or at least tries to).
      - frankjr 2y ago
        Arch does for quite a few ecosystems (Python, Ruby, Haskell, ...) but currently not for Rust.
- frankjr 2y ago
  > Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't respect the lock file (or the project doesn't use it) and you just fetch the latest compatible dependencies at the time of build, you now have no idea if you're affected or not by the vulnerability because you don't have the exact resolved versions stored anywhere (https://github.com/rust-lang/rfcs/pull/2801 https://github.com/rust-lang/rfcs/pull/2801).
  - palata 2y ago
    I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary. Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.
  - josephg 2y ago
    > Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.
    - palata 2y ago
      > It would make this sort of vulnerability scanning much easier to do. Scanning, sure. Fixing... surely much harder than with shared libraries.
      - josephg 2y ago
        Only because the build tooling is less mature. It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.
- palata 2y ago
  As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.
  - akira2501 2y ago
    You're not forced to with Go. CGO exists and requires dynamic linking.
    - deleted 2y ago
      [deleted]
  - newZWhoDis 2y ago
    More software should “enforce” their preferences, many decisions are objectively superior and this “anything goes” attitude has done nothing but hurt OSS/Linux adoption. Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.
    - palata 2y ago
      I couldn't disagree more. > Everything about the shared lib model is stupid I don't think we can discuss if that's you're stance. But also I don't think you understand the shared lib model if you think like that.
    - lmz 2y ago
      Dynamic linking seems to work fine for Windows or OSX. Maybe it's open source + dynamic linking that's the problem.
      - palata 2y ago
        Honestly a problem is that most developers just don't understand how it works. Docker / static linking solves a lack of understanding, mostly. That's why they are popular.
- lynndotpy 2y ago
  I feel the same. A huge part of the pleasure of Go and Rust are that I never run into dependency problems. I'm happy to pay the "Hello World is 4MB" tax.
  - LtWorf 2y ago
    And the "I now have to evaluate thousands of libraries instead of 10 well established framework" tax? I've seen plenty of bad go libraries. For example their authors will be unaware of isatty() so they will output control codes when piped. If you factor in the time to find a competently written library (and quite possibly write one yourself) it starts to be less convenient.
- LtWorf 2y ago
  > the disaster that's python package management, that's not where you want to end up The one where the only sane option is using distribution packages or conda and ignoring anything that the python community comes up with?
  - j1elo 2y ago
    I had my Python and pip installed from distribution packages. One day I needed to build something from source, but it needed Meson... Ok installed Meson also from my distro packages! But no, the project required a newer Meson version. Ok let's install Meson with pip! But no, it turns out pip packages themselves can require a minimum pip version!! Go figure. So I couldn't build that program without first pip-installing Meson, and I couldn't pip-install Meson without first pip-installing a more modern version of pip itself. Guess how well it worked when I upgraded pip. Spoiler: not a smooth way to discover that Python packaging is a joke.
    - icedchai 2y ago
      Were you using a virtualenv? Or were you pip installing into your distro / system python, like a true savage?
      - j1elo 2y ago
        I just knew the basics. So I was just following commands from stack overflow or similar. Silly me, thinking that it would work logically like other languages do! Later I ended up learning about all that stuff with venvs and whatnot, not to mention it's not even a unified solution but there are multiple alternatives, adding to the confusion... All this, no doubt, is a consequence of how terrible the Python packaging story is. Rust, Go, Ruby, Node, and more, I had used without remotely similar hassles.
        icedchai 2y ago
        You are right. It's not a good experience for new developers, especially given how long Python has been around.
- OKThatWillDo 2y ago
  "vendor all the dependencies" What does that mean?
  - PaulDavisThe1st 2y ago
    It means "add the source for your dependencies to your own codebase and build them with your build system".
    - OKThatWillDo 2y ago
      Thanks. Not an appropriate use of the noun "vendor," so I would never have guessed that.
      - mkl 2y ago
        It's the verb vendor: https://en.wiktionary.org/wiki/vendor#Verb https://en.wiktionary.org/wiki/vendor#Verb
        deleted 2y ago
        [deleted]
        OKThatWillDo 2y ago
        "Vendor" isn't the verb. The verb is "vend."
        mkl 2y ago
        That's a different verb, with a different meaning.
        spacechild1 2y ago
        Did you read the link?
- PaulDavisThe1st 2y ago
  > Modern languages are not like C/C++ I think there's a bit of a misconception here. Ardour is written in C++ and depends on 80+ other libraries. The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.
  - palata 2y ago
    I started a small project both in C++ and Rust. When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive). In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies. > but it is by no means determined by language or even context. Not sure what you mean there. My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help. If you have to manually handle every single dependency, first it forces you to look at them (that's a good thing), and second it encourages you to minimize them.
    - PaulDavisThe1st 2y ago
      > My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help What is it that makes you think that C/C++ does not do this also? [ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]
      - palata 2y ago
        > What is it that makes you think that C/C++ does not do this also? My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.
        PaulDavisThe1st 2y ago
        I would suggest that this caused more by ideas about the appropriate scope and scale of libraries in the 2020s than anything specifically connected to the language in use.
mshockwave 2y ago
> Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? More of a shared library issue I believe. > Say my Linux distribution distributes some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right? That's correct
manmal 2y ago
A Swift program for a particular distribution will dynamically link some system libraries from the distro, and these libs might change on every distro update. They mention in the post that dynamic linking can cause versioning issues. > Say my Linux distribution distributes some Swift runtime That runtime would need to be compatible with the Swift program. Nowadays that’s not a big issue due to ABI stability (https://www.swift.org/blog/abi-stability-and-apple/ https://www.swift.org/blog/abi-stability-and-apple/), but this would close the door on new features that need runtime support (need an OS update then, or the OS must come with multiple runtimes).
- Longhanks 2y ago
  AFAIK they claim ABI stability only for Apple platforms, explicitly neither Linux, nor Windows. Has that changed?
  - BodkinsOdds 2y ago
    Nope. For the foreseeable future, stable ABI on other platforms is basically only going to happen if a distro starts supporting an ABI stable standard library on their own.
School-Cotton 2y ago
Dynamic linking works fine for software that is distributed by distros, but lots of software isn't.
- palata 2y ago
  Sure. It's great to have the possibility to link statically. My beef with the "static linking trend" is that many people (or languages, e.g. Rust) don't want to let me link dynamically, for some reason. Just let me choose!
  - tux3 2y ago
    But they do. They do let you choose. Debian's build of rust packages are linked dynanically, for instance. It's a build setting, you can turn it on.
    - LtWorf 2y ago
      No, crates will be statically linked anyway in general.
      - kibwen 2y ago
        Rust supports dynamic linking, it's just not the default, so you need to configure a given crate to use it at build time.
        LtWorf 2y ago
        Rust supports compiling each crate as a separate .so and then linking all of them? That's not at all how debian packages written in rust are linked. So the person I replied to is incorrect. I suspect you're incorrect as well and what you claim doesn't exist at all, but you're claiming a different thing.
        School-Cotton 2y ago

Vt71fcAqt7 2y ago

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

Mandelmus 2y ago
It's a beautiful language that's a joy to write. It's safe and ergonomic, and has an extremely powerful type system. I'd say those are good reasons to use Swift.
- oddevan 2y ago
  I'm really interested in exploring it for building web app backends because of this. Being able to have a drag-and-drop distribution is even better.
  - _mlbt 2y ago
    I haven't used it yet, but I've heard really good things about Vapor as far as server side Swift goes... https://vapor.codes https://vapor.codes
    - OKThatWillDo 2y ago
      Thanks. What is a "protocol server?"
      - potatolicious 2y ago
        Not a super-expert but I've used Vapor on some personal projects. Do you have a link to the mention for "protocol server"? I'm not familiar with the concept but might be able to help.
        Redoubts 2y ago
        I'm guessing they clicked onto the Built with SwiftNIO link and saw this at https://github.com/apple/swift-nio https://github.com/apple/swift-nio.

autoexecbat 2y ago

I guess this means it can compete with golang on ease of distribution. Pushes all the complexity away from the end user

e63f67dd-065b 2y ago
Yeah, I'm really glad for the trend of statically linked binaries that came with Rust/Go. No more version incompatibilities, fights with downstream packagers, weird build configs, etc, just distribute the binary and that's it.
- School-Cotton 2y ago
  Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.
  - Cyph0n 2y ago
    Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2-with-host-tools https://doc.rust-lang.org/rustc/platform-support.html#tier-2...
    - MrDrMcCoy 2y ago
      I've had a 0% success rate compiling other people's Rust apps statically. I always end up with a shared binary or a failed build, even when building with musl.
      - kibwen 2y ago
        What problems did you have? As someone who's never in his life used musl before, I just now ran `rustup target add x86_64-unknown-linux-musl` and then built ripgrep with `cargo build --release --target=x86_64-unknown-linux-musl` and it worked without a problem. ldd confirms that it's statically linked. I'm surprised it was as painless as it was, I thought I'd have to install musl separately.

jkelleyrtp 2y ago

Swift 6 is amazing - I say this as a big Rust person. It seems like Swift is now its own entity outside the Apple bubble and has a few very interesting features: - An "embedded" mode that turns off reflection for kilobyte-sized binaries - An upcoming WASM target - An LSP for VSCode - Native C++ interop - Typed "throws" - Static linking on linux and the linux sdk - Porting a number of "core foundation" / foundation primitives to nix platforms - Distributed actors for concurrency that run on distant machines - Data-race free by default - non-copy RAII generic types Watch the video on Swift 6: https://developer.apple.com/videos/play/wwdc2024/10136/ https://developer.apple.com/videos/play/wwdc2024/10136/. IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for. Swift has shipped stuff that Rust has been sitting on its hands over for years: - Anonymous enums/structs in parameters/match statements - Named function arguments - A type of `Send` bound that allows Rcs to be sent between threads (not Arcs) - Swift preview hotreloading - autoclones (without GC) Swift also took a bunch of goodies from Rust *[1] - No garbage collector - Traits via "protocol" - ADT for Option/Result - macros - non-copy types enforcing RAII I really really wish Rust had been keeping up with Swift's ergonomics because it's looking like Swift is going to catch up to Rust's cross-platform story much faster. Swift really could end up as the "do it all" language for frontend/backend/app dev. [1] By "took" I mean if you like these things in Rust you'll see them in Swift

christophilus 2y ago
How’s the compilation speed?If it’s going to replace Go, that’s gotta be sub second for a medium sized project on my clunky old laptop.
- coldtea 2y ago
  Why, would you care if it's a full second or even 5 seconds? Go hyped their compilation speed a lot in its early years, but unless it's C++ templates level slugginess it's not like it's that big of deal.
  - square_usual 2y ago

29athrowaway 2y ago

Why should I use Swift instead of Rust?

manmal 2y ago
The concurrency story is quite good now with Swift 6, and it’s arguably easier to handle than the borrow checker, but still very safe.
- Sytten 2y ago
  The way I view it as a Rust experienced programmer: Its kinda like if everything in your program was Arc<dyn Trait> and we didnt have the mess that are the async executors. But I might be wrong. Love rust but god that sometimes I curse the choices that were made and how slow it evolves.
  - manmal 2y ago
    I don't have a lot of experience with Rust, but that sounds about right.
  - msk-lywenn 2y ago
    And supposedly, the compiler transforms the Arc in Rc or even removes it entirely if it can prove to be fine. I still did not check if there is a tool that tells you what was optimized and the reason why something wasn't.
singularity2001 2y ago
Swift is elegant, beautiful and concise, whereas Rust is an ugly verbose sigil mess.
- 29athrowaway 2y ago
  Would it be fair to say that Rust is a better C++ and Swift is a better Objective-C?

anothername12 2y ago

Can I make Gtk GUI with this like you can with cocoa on macOS?

square_usual 2y ago
Yes: https://www.swift.org/blog/adwaita-swift/ https://www.swift.org/blog/adwaita-swift/

zshrc 2y ago

Crazy that they’re still offering CentOS 7 images. PLEASE DONT USE THEM

w10-1 2y ago

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.

hugodan 2y ago
Wasm? Care to provide source for that?
- andrewjl 2y ago
  https://swiftwasm.org https://swiftwasm.org https://github.com/swiftwasm/swift https://github.com/swiftwasm/swift https://github.com/swiftwasm/WasmKit https://github.com/swiftwasm/WasmKit
- mannuch 2y ago
  https://github.com/apple/swift-for-wasm-examples?tab=readme-ov-file https://github.com/apple/swift-for-wasm-examples?tab=readme-...
- deleted 2y ago
  [deleted]
janice1999 2y ago
Wow, I had no idea people were using Swift for Embedded: https://github.com/apple/swift-embedded-examples https://github.com/apple/swift-embedded-examples
- favorited 2y ago
  It's relatively new. Apple put out a WWDC session video about embedded Swift today: "Go small with Embedded Swift" <https://developer.apple.com/videos/play/wwdc2024/10197/ https://developer.apple.com/videos/play/wwdc2024/10197/>
- 2y ago

thowdfasdfq 2y ago

[flagged]

janice1999 2y ago
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.
- glibc_free 2y ago
  A language having many speakers doesn't objectively make it a well-designed language.
mardifoufs 2y ago
I get rust and swift (maybe) but kotlin is basically on par with java at this point. Maybe 2.0 will create a wider gap but if Java 21 has nice things that kotlin doesn't have, and when you add those up there's no clear winner imo.
- tadfisher 2y ago
  Java 21 can't have things that Kotlin doesn't have, because you can call any Java method from Kotlin. On the other hand, Kotlin can target native, JS, and WASM platforms as well as the JVM, which is something Java does not do (barring alternative VMs like Graal).
deleted 2y ago
[deleted]

JackYoustra 2y ago

Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.

rescripting 2y ago
Could you elaborate?
- JackYoustra 2y ago
  Yes! See my reply above
gh123man 2y ago
I'd love to hear some specific examples. Ive built several iOS apps and a whole backend (on linux) with Swift and other than lack of OSS library support for some SaaS APIs, it's been quite nice. Sure Swift itself has some sharp edges, but not any more (or worse) than many other popular languages.
- JackYoustra 2y ago
  Sure! I love talking about this stuff :) here's a few: - if you want to manager your Package.swift target, you mostly have to deal with .target enum (can't figure out how to paste the URL) You can really only do a define or unsafeFlags, which leads to a couple issues... 1) There's only Debug and Release configurations! What if you want more? What if you want a nice flow where you emit and consume pgo data and re-ingest it? 2) What if you want to use a define for another language managed by SPM, such as metal? 3) What if you want to put in a portable path into a linker argument? SPM blocks use of build-time environment variables, so you can't do that either. All of these things seem contrived, but I ran into all three of them at my current job (shameless NanoFlick plug). All of these can be handled by cmake or xcodebuild (although probably better to use rules_xcodeproj). - Swift compiler feedback and performance in builders is absolutely atrocious, to the point where binary searching a view to find the actual source of a type error over ~30 second build times isn't very unusual! - It's very overly conservative with build times, and because there's only module-level import, it's very easy to accidentally have a long dependency chain which makes building one file imply building many files, further tanking your build time. There are some forum posts I can dig up on this if you're curious more on this point. - POD structs are default-Sendable at module-level visibility, but lose that if they're public, which means if you try modularizing your app into different small packages to restore some notion of compilation units to fight against the above two points, you end up having to go around and mark all of your different classes with default protocols (usually just Sendable) to reimplement! - Not a huge deal, but no way to have macro_rules! like you can in rust: macros are kinda hard to use and have to be in another package. This is just my thoughts on tooling, I have many more thoughts about the language itself that I'd be happy to share. Honestly though it's much better with vscode. I do hope that it makes progress in the right direction, Swift has a lot of things going for it!

dzonga 2y ago

Swift could've easily replaced python. but the language got complex and is now a baby C++.

azinman2 2y ago
Those are pretty different languages. One you just run as a script with no compilation and no static typing, the other is fully compiled and linked into a binary. How could they replace each other? And what’s the complexity now that even remotely approaches c++?
- dagmx 2y ago
  Fwiw, you can use Swift in a very Python like way. If you give a Swift file a shebang, it’ll execute as a standalone script. I still don’t agree they’re necessarily as overlapped as the other person claims but there is a decent area where Swift is easy enough to replace Python tooling
guestbest 2y ago
Does swift still lack a built in package management system?
- dagmx 2y ago
  https://swift.org/documentation/package-manager/ https://swift.org/documentation/package-manager/
- newdee 2y ago
  No, this came with Swift 3 back in 2016.
pzo 2y ago
I think it's too late which is sad since Swift is not a bad language even though I agree it got complex since the last 5 years. Python is mostly used not because of its language features but for cross-platform ecosystem. This is hard and slow to build especially these days (comparing to 10 years ago) since there are many languages and winner takes all or most of the cake. The only way is 1) to provide something really groundbreaking at the time (e.g. ruby on rails) 2) piggyback on other ecosystem by providing great interop (e.g. maybe mojo in the future) 3) slowly grind and hustle until something eventually catchup (e.g. maybe rust in the future) The problem with apple is they are too much focused to wall garden you instead of build ecosystem. Their IBM partnership failed to make something like Rails or Spring Framework for backend. Tensorflow for Swift failed even though it was google project. They don't have cross platform support in their DNA. You don't even get Xcode on Windows or iPad - this is dealbreaker for many people. I would bet more on kotlin (native) / java even though I'm iOS dev myself. Embedded is the exception that they still might win the game since the only competition there is pretty much: C, C++, Rust and sometimes python, js more as a glue.

deleted 2y ago

[deleted]

1vuio0pswjnm7 2y ago

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 in that case one can disable compression by sending a Viewport-Width header.

cqqxo4zV46cp 2y ago
There is, in reality, nothing unusual about that.
1vuio0pswjnm7 2y ago
They have now fixed it after I submitted this comment. No longer sending gzip by default. Thanks for that. Someone tell Amazon they should do the same.
1vuio0pswjnm7 2y ago
In addition to viewport-width www.amazon.com also requires a user-agent header in order to disable compression
1vuio0pswjnm7 2y ago
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.

stephen_g 2y ago

This is awesome, and I believe opens up what I and a bunch of people were wanting which is the ability to run Swift binaries in Alpine containers! I'd seen work on musl support going in but I didn't realise it would all be going so soon. Cross compilation is very nice too to not need your runtime platform to necessarily support the whole toolchain. I'm really glad there's finally support for vanilla Debian and from what I've seen it looks like there are initial Swift packages finally being added in the Debian testing version, which will be nice. Debian is more and more my go-to for development VMs where Ubuntu used to be, so I'm excited for official support! With all this and embedded, I'm really excited about Swift! I've done a lot of embedded in C and I'm super keen to try out Swift on my STM dev boards!

prophesi 2y ago

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.

easeout 2y ago
In iOS 18, there is now a SwiftUICore framework that's separate from SwiftUI, which I imagine consumes it. I don't see the new one on the documentation site. If that becomes public in a year or so, maybe you'd be able to replace one of the two frameworks to implement your own view system atop the attribute graph and data flow bits.
- saagarjha 2y ago
  It's unlikely this will ever be made public. It's probably just there for organizational reasons, just like UIKit got made an umbrella framework for UIKitCore a while back.
lukeh 2y ago
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 [7] which is working well. That enables me to write the UI in Dart and the business logic in Swift. I looked at all the other options below (that's how I know about them, indeed [3] I wrote as part of my research), in the end I felt that none of them were at the time of investigating sufficiently mature to base a product around. [1] https://github.com/rhx/SwiftGtk https://github.com/rhx/SwiftGtk [2] https://github.com/Longhanks/qlift https://github.com/Longhanks/qlift [3] https://github.com/PADL/LVGLSwift https://github.com/PADL/LVGLSwift [4] https://github.com/TokamakUI/Tokamak https://github.com/TokamakUI/Tokamak [5] https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui [6] https://github.com/AparokshaUI/adwaita-swift https://github.com/AparokshaUI/adwaita-swift [7] https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift

cryptonector 2y ago

> Cons of static linking: Not listed is that ASLR either doesn't work at all or you get just one object (the PIE's) randomized. For a memory safe language this may not be a con at all. Also, when many executables can share common objects then there can be a reduction in I/O (reads) needed to load those the next time that one of those executables runs. In 2004 when the Solaris 10 (then a work in progress) unified process model delivered, and all system executables were dynamically linked, boot times went down by a lot.

deleted 2y ago
[deleted]

darthrupert 2y ago

How good is the LSP? In another like-Rust-but-better language (Kotlin), that part is just abysmal.

saagarjha 2y ago
It's fine, not quite great. It does autocomplete and jump to definition, but some stuff (e.g. refactoring) isn't implemented yet.

huyegn 2y ago

Swift for all its niceties still suffers from a habit of inherently tying its conventions to Apple and its "appleisms" when coding. Tasks that should be relatively straightforward to do e.g. iterating through a file line-by-line still requires an awkward amount of code. It's especially noticeable when compared to languages like Go or Python: https://forums.swift.org/t/text-streaming-in-standard-library/19328 https://forums.swift.org/t/text-streaming-in-standard-librar... While these things are not difficult to solve with some minor additions to the standard library and documentation that emphasizes some basic conventions, the fact that we're on Swift6 and things like this aren't just available speaks to how much further the community needs to evolve to get the language ergonomics right for non apple-y things.

saagarjha 2y ago
What's wrong with for try await line in file.lines ?