9 ms·
Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modific
by manmal 4y ago
Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modification.
I‘m a little sad though that they didn’t start this endeavor years ago, because IMO Rust has already built so much momentum that it will win (for the popular, medium to long term definition of „winning“).
- ChrisMarshallNY 4y agoI don't particularly care, whether or not Swift ever leaves the Apple ecosystem (like ObjC). In that domain, Rust will never "win." I think that Rust is an awesome server language, though, and I'm glad to see it gain traction. I just hope that it doesn't get trashed by a bunch of junk dependencies, written in it. I find using apps written, using hybrid systems, or PWAs, to be quite painful (on Apple devices -and that includes that awful JS TVOS system), so I am a big proponent of real native apps.
- manmal 4y agoI think whoever „wins“, it would be necessary to have good interop at least. Currently, Rust devs are integrating core libs into native iOS apps by going the C route. All this work to make everything memory safe, and then this.
- mrtesthah 4y agoSwift-based interop would provide richer type information. See how swift-bridge takes advantage of it: https://github.com/chinedufn/swift-bridge https://github.com/chinedufn/swift-bridge
- jen20 4y agoWhich direction are you talking? If you want to link against Rust there is little choice but to use a C layer because it doesn’t have a stable ABI.
- manmal 4y agoI‘m talking Swift > Rust. TIL about the unstable ABI, thanks!
- jen20 4y agoGot it - the other way is actually fine because Swift does have a stable ABI - swift-bridge [1] allows interop in terms of high level types instead of devolving to C. [1]: https://github.com/chinedufn/swift-bridge https://github.com/chinedufn/swift-bridge
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- incrudible 4y agoWhat is a real native app? Most operating systems have multiple graphics interfaces, ui toolkits and other abstractions with varying levels of inconsistency. They could all be driven by various languages, compiled or interpreted.
- steve1977 4y agomacOS and iOS not so much. Which is probably one of the reasons why apps for these platforms are often much better (or at least more polished) than say Windows apps.
- incrudible 4y agoIn my view, "polish" is rather orthogonal. For trivial apps that just assemble the building blocks that come out of the box, I'd agree. Otherwise, I find the "native" developer experience (XCode, Swift compiler) to be rather unpleasant. Moreover, the economics of developing "natively" limit the amount of polish you can actually justify.
- ChrisMarshallNY 4y agoThe way to deal with that, is develop (or buy|integrate) dependencies that natively implement polish and chrome. For example, a UI framework may implement good transition animations. That’s pretty typical. Write an extension to UINavigationController, or UIViewController (if you use UIKit) that implements these transitions, package it as a standalone project, and integrate it, or simply have project-specific baseline framework extensions. That’s what I do. I have a ton of these packages[0]. It’s a fair bit of work, to do it yourself, but there are package[1] and extension[2] indexes. Caveat emptor. [0] https://riftvalleysoftware.com/work/open-source-projects/ https://riftvalleysoftware.com/work/open-source-projects/ [1] https://swiftpackageindex.com/ https://swiftpackageindex.com/ [2] https://swifterswift.com/ https://swifterswift.com/
- mplewis9z 4y ago> Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modification. This is already pretty much true today, aside from the few, mostly down-in-the-weeds holes in Foundation on Linux that will be solved once this rewrite is complete. Cross-platform command-line tools, web backends, and things like AWS Lambdas are all possible and pretty easy to do today.
- password1 4y agoWhy do you think Swift and Rust are competing on the same grounds or for the same objective? Genuinely curious, i don't know much about Rust.
- msk-lywenn 4y agoI used rust for a while. When I saw and read about swift, my immediate thought was: "hey, this looks like rust's easy mode"
- nicoburns 4y agoAside from Swift having automatic reference counting, and Rust relying more heavily on its borrow checker, Swift and are super similar languages. If what you want is an ergonomic language that lets you combine the best of ML type systems with C family imperative programming then they’re the two obvious choices.
- kybernetyk 4y agoI would not describe Rust as being particularly ergonomic. While it is a suitable replacement for C++, that is not necessarily a high standard to meet.
- yazaddaruvala 4y agoReading the super majority of Rust code is equally easy or easier than reading Python, or Typescript, or even Ruby. Writing Rust applications is also very ergonomic. The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks. The only Rudy lacking ergonomics is writing net new frameworks or missing framework pieces, or when std is not available. 95%+ of all new Rust code will fall into the bucket of “ergonomic to write and read”.
- sidlls 4y agoThis isn't really the case. Rust code is almost as complex as C or C++ for any non-trivial application.
- howinteresting 4y agoSwift would never have won, and will never win, while it's so closely associated with Apple. Many people in positions of power believe (correctly) that Apple will always put its own needs above everyone else's. Those are the people who have chosen Rust.
- cellularmitosis 4y agoSwift will never win against Rust for a much simpler reason: performance. Invariably, rust is chosen where performance is critical, and Swift’s reference counting GC ensures it will never compete with Rust in those scenarios.
- jurip 4y agoRust is pretty often chosen also in places where performance is not that critical. It has a good ecosystem, a good type system, native builds and great performace. Those factors make it a good choice in places where you'd be just fine even if it was slightly slower. If Swift loses by a small margin — and Swift is a high performance language too — it could very well edge out Rust with ergonomics.
- Zababa 4y agoAlso great build tool and IDE support. Cargo and rust-analyzer by themselves make me not miss a GC that much.
- jupp0r 4y agoYou don't need ultra performant memory management for most of your code. Swift compiles to machine code and ARC is fine for most use cases and you can use unsafe raw pointers etc for your occasional hot code path where you want to optimize memory management.
- cellularmitosis 4y agoI would love to see what this looks like in practice if you can point me to a link. (I’m now curious if the unowned keyword would have similar performance characteristics)