[HN Gopher] Swift Static Linux SDK
___________________________________________________________________
Swift Static Linux SDK
Author : mannuch
Score : 138 points
Date : 2024-06-11 20:25 UTC (2 hours ago)
(HTM) web link (www.swift.org)
(TXT) w3m dump (www.swift.org)
| palata wrote:
| > 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 wrote:
| 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.
| umanwizard wrote:
| 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.
| jiripospisil wrote:
| 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 wrote:
| 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 wrote:
| Yes and it doesn't prevent anyone to build software
| separately, being written in rust or any other language.
| jiripospisil wrote:
| > 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).
| palata wrote:
| 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 wrote:
| > 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 wrote:
| > It would make this sort of vulnerability scanning much
| easier to do.
|
| Scanning, sure. Fixing... surely much harder than with
| shared libraries.
| josephg wrote:
| 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 wrote:
| > It should be pretty easy to programmatically update a
| lock file, run the tests, and rebuild a package.
|
| You still fundamentally need to rebuild (or at least
| relink) and re-distribute all the packages, whereas with
| shared libraries... well you just update that one
| package.
| LtWorf wrote:
| > Packages get rebuilt all the time. This is fine.
|
| You forgot to link the image with the dog sitting in the
| fire.
| dolmen wrote:
| > 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.
|
| Go binaries have that. You can apply "go version -m" to
| any recent Go binary.
|
| Also "govulncheck".
|
| Examples: go version -m $(which go)
| go install golang.org/x/vuln/cmd/govulncheck@latest
| go version -m $(which govulncheck) govulncheck
| -mode=binary $(which govulncheck) for b in $(go
| env GOPATH)/bin/*; do govulncheck -mode=binary "$b"; done
| palata wrote:
| 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 wrote:
| You're not forced to with Go. CGO exists and requires
| dynamic linking.
| lynndotpy wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Were you using a virtualenv? Or were you pip installing
| into your distro / system python, like a true savage?
| icedchai wrote:
| Have you tried "poetry"?
| LtWorf wrote:
| Yes. Having tried it led me to write that comment.
| OKThatWillDo wrote:
| "vendor all the dependencies"
|
| What does that mean?
| mshockwave wrote:
| > 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 wrote:
| 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/), 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).
| umanwizard wrote:
| Dynamic linking works fine for software that is distributed by
| distros, but lots of software isn't.
| palata wrote:
| 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 wrote:
| 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 wrote:
| No, crates will be statically linked anyway in general.
| Vt71fcAqt7 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dlachausse wrote:
| 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
| OKThatWillDo wrote:
| Thanks. What is a "protocol server?"
| e63f67dd-065b wrote:
| The main reason is that Apple has effectively deprecated
| Objective-C for ios/macos development going forward. It's not
| going away for probably another decade+, but all documentation
| is now in Swift, new APIs are written with Swift in mind, etc.
|
| Think of it this way: in 5-10 years, ObjC will be the python2
| of Apple development.
| hbn wrote:
| The GP was asking specifically about non-Apple development
| righthand wrote:
| Not really no, there are far better languages with better cross
| platform support.
| criddell wrote:
| Out of curiosity, which language works best for you and your
| use case?
| josephg wrote:
| Which languages do you think are both better and have better
| cross platform support?
| petereddy wrote:
| There are definitely languages with better cross platform
| support. But far better _languages_? I think Swift is a
| pretty good language and I like to know what you think is far
| better than it.
| airstrike wrote:
| No language feels more pleasurable to write in. It's incredibly
| expressive and things are just dead simple 99% of the time
|
| It's not perfect, but I hope it continues to flourish because
| it gets a lot right
| autoexecbat wrote:
| I guess this means it can compete with golang on ease of
| distribution. Pushes all the complexity away from the end user
| e63f67dd-065b wrote:
| 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.
| umanwizard wrote:
| Rust binaries (at least on Linux) are not statically linked
| by default. They depend on libc.
| jkelleyrtp wrote:
| 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/.
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Compiling fast has ripple effects throughout your workflow.
| Having your iteration time go from 1s to 5s is a _massive_
| difference: it can mean you break out of the flow state
| when you restart your server to test your code.
| manmal wrote:
| As someone dealing with Swift everyday (and, before that,
| faster langs like Elixir and Typescript), I can only
| agree. Sometimes my incremental builds take 20-30 seconds
| and it feels like a huge toll. Waiting on the CI (which
| is a weak machine) is up to 25 minutes until the test
| suite has passed - a large chunk of that being
| compilation time. Releases take 5-10 minutes.
|
| I really like Swift, but I'd highly appreciate faster
| compilation times.
| jkelleyrtp wrote:
| Supposedly faster in Swift 6 but I don't have any big swift
| projects to throw at it. It uses LLVM so it's not going to be
| as fast as Go's.
|
| In Swift 6 they:
|
| - Improved parallelism via compilation pipelining (ie top-
| level object files are referencing not-yet-compiled symbols
| but can still proceed while those compile in the background)
|
| - Parallelized and pipelined debug symbol generation (lazy
| debug symbols)
| josephg wrote:
| Assuming my experience with Swift 5 is still accurate,
| compilation speed is at least an order of magnitude slower
| than Go.
|
| It's a much more powerful language. In my opinion slower
| compilation is worth it for all of its great features. (Does
| Go even have parametric enums?). But its definitely a trade
| off.
| MBCook wrote:
| That's the one big loss from moving off Objective-C.
| Because the language was so stupidly simple to parse and
| didn't have a lot of "we'll figure that out for you from
| what you wrote" it could be compiled incredibly quick on
| today's machines.
|
| I know they're working on improving it. I'm glad they are.
| But that speed is something I definitely miss.
| coldtea wrote:
| > _Swift also took a bunch of goodies from Rust - No garbage
| collector - Traits via "protocol"_
|
| I'd say they took them from Apple's own Objective-C additions
| who had those for decades before Rust (ARC and protocols).
| Klonoar wrote:
| This is correct.
| favorited wrote:
| Yeah, Objective-C Protocols are so old that they influenced
| Interfaces in Java 1.0.
| e63f67dd-065b wrote:
| I'm primarily a C++ developer these days, and if the C++
| interop is actually good then I'm very excited for the future.
| For app-dev type stuff it really does seem like it's better
| than Rust, and I can definitely see a world where we start
| migrating some code into Swift.
|
| Edit: back from watching the video, and a few observations:
|
| - Swift does not suffer from Rust's refusal to add things into
| the standard library. _gasp_ regex support in stdlib? Async
| /await runtimes?
|
| - Default testing framework is a godsend, especially when
| integrated into the build system
|
| - Rust but better for everything that's not low-level systems
| development is the impression I get
| jkelleyrtp wrote:
| The default testing framework made my jaw drop a bit - I have
| a very hard time seeing Rust have the enthusiasm or momentum
| to implement something like that right now.
| glhaynes wrote:
| Why do you think they wouldn't? (I don't keep up with
| Rust+its community closely enough to know.)
| glhaynes wrote:
| I'm not a (direct) user of the C++ interop, but everything
| I've heard about it has been quite positive. A few hopefully
| relevant resources, first a couple of videos:
|
| - "Introducing a Memory-Safe Successor Language in Large C++
| Code Bases" (John McCall; CppNow 2023)
| https://www.youtube.com/watch?v=lgivCGdmFrw
|
| - "Swift as C++ Successor in FoundationDB" (Konrad Malawski;
| Strange Loop 2023)
| https://www.youtube.com/watch?v=ZQc9-seU-5k
|
| And then a series of blog posts by Doug Gregor:
|
| - "Swift for C++ Practitioners"
| https://www.douggregor.net/posts/
|
| And finally:
|
| - "Mixing Swift and C++" (Swift.org)
| https://www.swift.org/documentation/cxx-interop/
| dagmx wrote:
| As another huge rust fan myself, Swift 6 has really won me
| over.
|
| I find myself reaching for Swift as the default for a lot of
| things rather than Rust, especially with the advent of C++
| Interoperability and the new Swift embedded stack and ownership
| model.
|
| The only thing I really need is a UI story on other platforms,
| but it's an area Rust is lacking great solutions too. I suspect
| the C++ interop might eventually make Swift have great Qt
| bindings to compete with PySide as an accessible way to make
| multi platform UIs.
| square_usual wrote:
| Swift and Go are on polar ends of the language complexity
| spectrum. Someone who enjoys Go for what it is, i.e. a dead
| simple, straightforward language, would not see Swift as being
| "better".
| jkelleyrtp wrote:
| Some people want generics and ADTs in Go. If you're using go
| because it's
|
| 1) fast
|
| 2) expressive
|
| 3) concurrent
|
| 4) compiles natively
|
| then I think Swift is the better of the two.
|
| If you just want a very simple language, then sure, Go is
| there. But I don't think that's necessarily what makes Go,
| Go.
| beanjuiceII wrote:
| after using swift extensively i did not find it better of
| the two, in fact it is a complex keyword ridden language
| that seems bolted together at very many angles, each swift
| codebase i enter is like a new mystery to unfold because of
| its extremely rocky evolution
| Klonoar wrote:
| One thing that bugs me to this day is reading Swift code
| without an IDE can be an exercise in "let me build up a
| mountain of context first", due to the way enums and
| types can get shortened.
|
| It's nice to write but a pain to review. Meanwhile if I
| read Rust or Go, it's more or less what you see is what
| you get.
|
| I do agree in general that it's frustrating that Rust
| hasn't kept up with some of Swift's pushes, but then
| again that's the difference when you have the richest
| company in the world involved.
|
| For context, I've written many apps in Swift, deployed a
| backend in Vapor, and worked with teams who use the
| language. I always thought I'd get over it but it just
| never fully clicked.
| square_usual wrote:
| I would say that yes, in fact, simplicity is characteristic
| of Go. That is clear from how the go team considers the
| impact of every new language feature, often choosing not to
| do things that would've been considered obvious in other
| languages. Many parts of the community still resent
| generics, and there is widespread backlash to the new
| iterators proposal. Most Go enthusiasts wouldn't be fans of
| Swift and vice versa.
| arthur-st wrote:
| I think it depends on the person. My anecdotal experience is
| that I'm using Go for hobby projects because with Python at
| my day job, I wanted a modern language with fancy-ish static
| typing. Additionally, I wanted it to be equally practical on
| Win/Mac/Linux, and to not run inside a VM.
|
| The obvious first candidate was Rust, but the low-level
| features were unnecessary overhead. A "higher-level Rust" is
| literally Swift, but the portability is not there. The search
| basically ended here, so I went with Go as a consolation
| prize - I don't get a fancy type system to play with, but the
| development ergonomics, especially with the v2 modules
| system, are the best I've experienced yet.
| manmal wrote:
| Have you checked out the static linking option announced
| yesterday? Portability has increased a lot.
| cube2222 wrote:
| Agreed that Swift looks quite amazing. There's some cool talks
| on how they're trying to move FoundationDB to Swift and their
| approach.
|
| I think the main problem, and this is a really big problem, is
| that based on a very shallow investigation I did a couple
| months back, the ecosystem for server-side stuff barely exists.
|
| And in my opinion, the ecosystem is one of the deciding factors
| when picking a language.
| jkelleyrtp wrote:
| I have a slight inkling that Apple internally is using Swift
| for backend stuff somewhere, especially with all the ML stuff
| they just shipped. Word on the street is their datacenters
| are full of M-series chips. I could see those servers running
| Swift + distributed actors + mlx.
|
| The move to make swift run on Linux could be part of that
| work - their sysadmins, devops, and backend folks probably
| use Vim/VSCode and deploy on Linux.
|
| We might see the release of a very good backend framework by
| apple for Swift that works on Mac/Linux.
|
| The new macros they added kinda bolt on serde into the
| language too - and the distributed actor stuff is basically
| RPC in the language.
| manmal wrote:
| Yes their "private cloud" runs on Swift, which supposedly
| increases security because they believe Swift has things
| nailed by now.
| Klonoar wrote:
| I believe it's confirmed that they're doing it with Swift,
| buried somewhere in the ML post IIRC.
| MBCook wrote:
| Apple deploys a ton of their server stuff on Linux. Plus
| they appear to be doing all new code in Swift and moving
| old code over slowly.
|
| They're also using embedded Swift in the Secure Enclaves
| and other small processors due to its safety, though I
| think they have an extra layer of automated security
| checking that they use internally that doesn't exist in the
| public builds.
|
| But in short, yes. I believe they're trying to use Swift
| for everything at this point and getting away from
| C/C++/whatever even for kernel work.
| KurtMueller wrote:
| Algebraic data types are not a Rust invention and aren't
| exclusive to that language.
| MBCook wrote:
| I don't think they were trying to claim that, just that it
| was a feature that was in Rust that they liked and wanted to
| keep using.
|
| Just like Rust didn't invent not using garbage collection.
| mdhb wrote:
| You almost caught up to Dart.
|
| - Built for embedded devices and already has RISC-V support
|
| - Already has WASM was a compilation target
|
| - Not just an LSP but amazing VSCode tooling
|
| - Native C, C++, Java, Rust and JavaScript interop and a .NET
| bridge is in the works it seems.
|
| - Typed "throws"
|
| - Static linking (in development)
|
| - Data-race free by default
|
| Unique features to Swift:
|
| - Distributed actors for concurrency that run on distant
| machines. (This is doable but not native to the language)
|
| - non-copy RAII generic types (not actually sure what this is
| so I assume it's not in Dart)
| almostgotcaught wrote:
| > - Native C, C++, Java, Rust and JavaScript interop
|
| dart doesn't do C++ interop
| manmal wrote:
| Isn't "data-race free" in Dart achieved by just not really
| sharing mutable memory between isolates? Probably because the
| web version needs to map isolates to web workers, right?
| mdhb wrote:
| For now but this is in the pipeline too.
|
| https://github.com/dart-
| lang/language/blob/main/working/333%...
| heavyset_go wrote:
| Given there is native C++ interop, is exporting a C ABI still a
| seemingly experimental/niche feature? Same question with
| interop between C and Swift.
|
| Recently went with using Kotlin Native over Swift on macOS for
| this reason, the C ABI export and C interop were painless.
| vips7L wrote:
| > - No garbage collector
|
| ARC is a GC, and a slower one than most traditional tracing
| GC's.
| lll-o-lll wrote:
| > No garbage collector
|
| No _tracing_ gc. Ref counting is the other kind of garbage
| collector.
| 29athrowaway wrote:
| Why should I use Swift instead of Rust?
| manmal wrote:
| 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 wrote:
| 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.
| singularity2001 wrote:
| Swift is elegant, beautiful and concise, whereas Rust is an
| ugly verbose sigil mess.
| anothername12 wrote:
| Can I make Gtk GUI with this like you can with cocoa on macOS?
| square_usual wrote:
| Yes: https://www.swift.org/blog/adwaita-swift/
| zshrc wrote:
| Crazy that they're still offering CentOS 7 images. PLEASE DONT
| USE THEM
| w10-1 wrote:
| 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 wrote:
| Wasm? Care to provide source for that?
| janice1999 wrote:
| Wow, I had no idea people were using Swift for Embedded:
| https://github.com/apple/swift-embedded-examples
| thowdfasdfq wrote:
| Are we going to live to see the industry adopt Swift, Kotlin, &
| Rust?
|
| I can't take any more Python/Java/Go/JS. We need to upgrade
| immediately.
| janice1999 wrote:
| 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.
| JackYoustra wrote:
| 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.
| dzonga wrote:
| Swift could've easily replaced python.
|
| but the language got complex and is now a baby C++.
___________________________________________________________________
(page generated 2024-06-11 23:00 UTC)