12 ms·

Swift is a more convenient Rust

242 points by mpweiher 2y ago

talldayo 2y ago
> Swift is better for writing UI and servers and some parts of compilers and operating systems. Swift is better for some UI and some servers/operating systems. A considerable problem with Swift's adoption is that zero attention has been given to ergonomics on other platforms which has left it as the Xserve of programming languages for quite a while now. If the Foundation framework and SwiftUI paid serious attention to non-Apple platforms, then Swift itself might have a chance. Until then, even C# is going to look more attractive for cross-platform devs that don't want to drown their software in ifdefs.
- amichail 2y ago
  Can't you use Qt with Swift's bidirectional C++ interoperability?
  - neonsunset 2y ago
    You can. But you can also use Avalonia*, Uno Platform* , Gir.Core or whatever currently maintained Qt binding library is for .NET. The FP and syntax advantages listed in the article exist in equal measure in C#, and so do zero-cost Rust-style abstractions. Swift is a language with a lot of potential, but it has a lot of work ahead of it, the work that was done for .NET's performance, cross-platform support, tooling ecosystem and OSS-focused development process. *both of which have SwiftUI style extensions for declarative UI definition and MVU patterns. Avalonia even has the F# version of that.
  - talldayo 2y ago
    I mean, you can use all of POSIX with C FFI if you wanted. But that goes for most languages, and it's a far cry from the convenience of a well-made standard library. People want Apple to stop pretending like it's impossible to support other OSes, it's really that simple. If they want their language to have serious popularity, they have to act like a real Open Source maintainer and not a business. Swift's adoption outside of Apple developers forced into using it is more or less sabotaged by Apple's decisions. Whether they realize it or not, this behavior is undermining Swift's credibility and likely pushing people onto C++/Rust where they can use LLVM without limitations.
- Someone 2y ago
  > If the Foundation framework and SwiftUI paid serious attention to non-Apple platforms They started late, but isn’t https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation paying serious attention to non-Apple platforms now? SwiftUI, I think, isn’t as essential, as it isn’t really possible to create a good cross-platform Ui library (and yes, that means I think running iOS apps on MacOS can’t provide an optimal experience)
  - talldayo 2y ago
    I'm just calling it like it is. I'm a Rust dev that really doesn't look at Swift with much hope. It's not a language that performs consistently across platforms, which is documented well in the repo's Issues tab. I just don't have the time or patience to work with a language that treats me as a platform adversary. If Apple doesn't go the extra mile to make their language attractive outside their ecosystem, they're just not going to compete in the greater programming community. Rejecting it on principle is a no-brainer for any cross-platform project. The case for Swift is shallow, even if you're a Mac-native dev. The worst part is, Swift is a perfectly fine language on paper. It's got Lattner behind it, it's got literal trillion-dollar corporation funding behind it, and interfaces with LLVM to boot. It's lovely! My problem with Swift has always been Apple's attitude towards their own language and how desperate they are to reject non-ecosystem users. My life is too short to put up with nonworking language primitives in 2024. It pains me to say it, since Swift is so cool, but there are several better languages.
- deleted 2y ago
  [deleted]
high_priest 2y ago
Yes! And C# is just more convenient C.
- dbfa 2y ago
  JavaScript is just a more convenient x86-assembly. :P
- neonsunset 2y ago
  Closer to convenient C++ probably :)
  - pjmlp 2y ago
    Definitely, Windows development would be so much more fun, had Native AOT been there since day one, and WinDev wasn't so much siloed into their C++ toys.
nicce 2y ago
> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting. They did it well, but not invented? There very many kinds of influeces: https://www.reddit.com/r/rust/comments/le7m54/is_it_fair_to_say_rust_parentage_can_be_traced_to/gmb4zgc/ https://www.reddit.com/r/rust/comments/le7m54/is_it_fair_to_... Especially Cyclone, I think: https://en.m.wikipedia.org/wiki/Cyclone_(programming_language) https://en.m.wikipedia.org/wiki/Cyclone_(programming_languag...
- mananaysiempre 2y ago
  The best review of the relevant research that I know is Pottier’s presentation[1]. It’s from 2007, but then again as far as fundamental concepts it doesn’t seem to me that Rust is state-of-the-art even as of then. (To be fair, that’s not due to ignorance, Rust’s type system is deliberately conservative.) [1] https://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-linear-bestiary.pdf https://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-...
lukeh 2y ago
I don’t know Rust, but I’m loving Swift for systems programming. Most recent project was an 802.1Q SRP implementation and I couldn’t imagine going back to C. Higher up the stack, I’ve also used it with a custom runner to build the business logic for an embedded Flutter app. My only beef is that the binaries are quite large. I’m hoping the new Foundation will improve things, in the interim I’m trying to eliminate my Foundation dependencies.
- neonsunset 2y ago
  You can get much smaller native binaries with .NET's NativeAOT nowadays: https://github.com/MichalStrehovsky/sizegame https://github.com/MichalStrehovsky/sizegame Funnily enough, I'm using C# to solve quite a similar type of tasks. It's a really pleasant experience.
  - pjmlp 2y ago
    Native AOT needs to get better tooling ergonomics though, the whole publish process is a bit convoluted versus toolchains that have AOT compilation as their default. Not counting having to learn about IL trimming, and the whole AOT compatible libraries.
    - neonsunset 2y ago
      What kind of issues did you have with the build process? (as in, if you had a specific case, it might be worth submitting an issue or updating documentation) It's a very straightforward process - you pass a single flag, maybe specify optimization preference and instruction set target, and it gives you the binary upon 'dotnet publish'ing the project. The process of static linking (if you care about this scenario), with other static dependencies written in C/C++/Rust is not too different from other toolchains - you specify `DirectPInvoke` and `NativeLibrary` properties in .csproj, and they are linked into the final product as a part of the build process. You may need to forward linker arguments[0] for the imports referenced by those however, but this is expected regardless of .NET. I think it's fair to criticize the additional compatibility effort required for high-level user libraries that rely on un-analyzable reflection, reflection emit or assembly loading, but none of these features usually have any relevance in the domain of systems programming. When you write a project from scratch, you never have to think about whether it's native compilation or "JIT+CIL assemblies sandwich" executable, or anything else. It just works. For example https://github.com/codr7/sharpl https://github.com/codr7/sharpl - the author was pretty much learning C# on the go and it needed exactly 0 changes besides adding `PublishAot` property to make it output a native executable. [0]: https://github.com/U8String/U8String/blob/main/Examples/Interop/CSharp/CSharp.csproj#L31 https://github.com/U8String/U8String/blob/main/Examples/Inte...
robjwells 2y ago
One way that Swift is certainly not more convenient than Rust is the tooling. I use a 2018 MacBook Air, using macOS 12, which is now unsupported by Xcode. Meanwhile SourceKit-LSP is treated as very much a second-class citizen. But Rust 1.81 and rust-analyzer build and run just fine.
- arghwhat 2y ago
  Not to praise Swift, but Swift and Xcode are unrelated projects. Saying that Swift is inconvenient because of Xcode issues is like saying C++/C# is inconvenient because of Visual Studio. You can install Swift on Linux if you want and code away, just like with Rust - but as it hasn't really caught on for anything other than building apps for the Apple ecosystem, it's not a particularly normal thing to do.
  - yunohn 2y ago
    I’m pretty sure you need Xcode to compile Swift on macOS.
    - acar_rag 2y ago
      Absolutely not, you just need to use swiftc: https://theswiftdev.com/the-swift-compiler-for-beginners/ https://theswiftdev.com/the-swift-compiler-for-beginners/
    - robjwells 2y ago
      You can install a Swift toolchain on macOS without Xcode, but Xcode is the “blessed” route and listed first on the swift.org getting started instructions. https://www.swift.org/install/macos https://www.swift.org/install/macos However, it can be a bumpy ride. For example: “swift test” (via the CLI) doesn’t work if Xcode is not installed. https://github.com/swiftlang/swift-package-manager/issues/4396 https://github.com/swiftlang/swift-package-manager/issues/43... I would just emphasise that the OP was about _convenience_ and Swift-without-Xcode on macOS is not smooth sailing.
    - latexr 2y ago
noelwelsh 2y ago
Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the first language to bring non-GC automatic memory management to the mainstream. It won't be the last and it might well be the worst. Other languages in this space include Swift (as in OP's post), OCaml[1], and Scala[2]. These alternatives take the approach that tracking ownership is not the default, which is fine for the majority of programs and far more ergonomic. There's also a corollary 3. The age of Smalltalk is over. It's now the age of ML. (Amusingly, going backwards in time, from 1983 to 1975). The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk (everything is an object! dynamic types! runtime metaprogramming!) The new languages (Rust, Scala, Swift, Kotlin, etc.) are ML family languages. Similarly, back in the day you could learn, say, Ruby, and still be reasonably proficient in Python or JS. Now you can learn, say, Scala, and pick up Rust or Swift reasonably easily. [1]: https://blog.janestreet.com/oxidizing-ocaml-locality/ https://blog.janestreet.com/oxidizing-ocaml-locality/ [2]: https://dl.acm.org/doi/full/10.1145/3618003 https://dl.acm.org/doi/full/10.1145/3618003
- the_duke 2y ago
  Ad 3) Scala is quite a bit older than the others, I'd put it in a previous generation. I always saw Kotlin as a more convenient Java, without Scalas heavy tilt towards FP. Java also added the equivalent of sum types with sealed interfaces and exhaustive pattern matching, does that make Java an ML language? Many older languages by now have incorporated valuable parts of FP/ML (including Javascript, Java, C++, ...) Borrowing some concepts from ML doesn't put these languages in the ML family.
  - SSLy 2y ago
    > does that make Java an ML language? not really, the type-system-sublanguage is still modelled like classy OOP, not more like MLy modules.
seanalltogether 2y ago
I keep trying to get into rust but I always hit a brick wall when looking at examples and the code looks so complicated. Examples like this straight from the rust website just make my eyes glaze over struct Task { future: Mutex<Option<BoxFuture<'static, ()>>>, task_sender: SyncSender<Arc<Task>>, }
- swiftcoder 2y ago
  I'll grant you that is probably too complicated an example to appear early in the docs, but how often are you actually building multithreaded job dispatch systems from scratch (which appears to be what this example is doing), and how simple would it be in other languages?
  - diggan 2y ago
    This is how simple it would be in Clojure, for comparison: (defrecord Task [future task-sender]) Probably used something like this: (defn create-task [] (let [future (atom nil) task-sender (async/chan)] (->Task future task-sender))) Not sure it makes sense but a pretty much direct translation as far as it goes.
    - galangalalgol 2y ago
      Having never used a lisp outside an AI class a quarter century ago, that isn't comprehensible to me, and I don't think it is just my lack of caffeine. The rust example makes more sense, but I've used rust for almost a decade at this point and c++ for over three. Familiarity matters.
      - diggan 2y ago
        Yeah, of course. If you show me Brainfuck or APL code I won't be able to make head or tails of it either. But familiarity should never stop one from learning new things, otherwise we miss out on a lot of simple, interesting and useful stuff :)
      - 2y ago
BiteCode_dev 2y ago
Swift won't be able to compete with rust until it has a great scripting story. Rust is currently the defactor choice if you want to make something with js/python bindings, of id you want to speed up a dynamic bottleneck because it makes it super easy. Swift doesn't even have a good ffi.
- pjmlp 2y ago
  Try to make Rust interop with C++, C and Objective-C as easy as Swift does it.
  - sgt 2y ago
    This is a big deal. In reality, most of the code that powers your systems (phones, tablets, any computers) is built using C and C++, regardless what OS you use.
    - galangalalgol 2y ago
      Agreed, and rust-c interop is as good as any other I've used. The c++ interop was clunky but getting much better with crates like zngur. That is what was holding back its use on chrome for a while. Oddly its python interop is way better with pyo3 and maturin making it super easy.
  - Klonoar 2y ago
    C++ is (IME) an order of magnitude more annoying from Rust than C or Objective-C. I've dealt with interop of the latter two on a number of projects and frankly found them to be fine. (Though I wouldn't fault anyone for making an argument that Swift is still more ergonomic here)
- lukeh 2y ago
  Swift can import C (and C++) modules directly, and it's fairly straightforward to wrap existing C APIs with callbacks to be usable from structured concurrency. Here's an example I just worked on. [1] [1] https://github.com/PADL/NetLinkSwift https://github.com/PADL/NetLinkSwift
mangeshbankar21 2y ago
[flagged]
tromp 2y ago
> it gives you utilities such as Rc, Arc and Cow to do reference counting and “clone-on-right” Not quite right: [1] https://en.wikipedia.org/wiki/Copy-on-write https://en.wikipedia.org/wiki/Copy-on-write
- steveklabnik 2y ago
  Cow in Rust does mean “Clone on write,” because Copy is a term of art in Rust (as is Clone).
dist1ll 2y ago
The tree example is quite contrived. Most Rust programmers would use indices for indirection, pointing into flat buffers.
- MereInterest 2y ago
  It’s also incorrect. There’s no need to use both Vec and Box, as either is sufficient to provide indirection.
K0nserv 2y ago
I love both Rust and Swift, they have their respective strengths. I would say Swift has a less noisy surface syntax, but instead uses more dedicated keywords and compiler magic. This is nicer, but means some areas are "compiler only territory". In many cases Swift would be a better choice than Rust, when the convenience and developer experience is worth trading for some performance. However, Swift's biggest problem is that any usage outside of the Apple ecosystem is a second(or third) class citizen. Until this is solved, Swift will remain mostly an Apple only language, regardless of how nice it is.
- zer0zzz 2y ago
  > However, Swift's biggest problem is that any usage outside of the Apple ecosystem is a second(or third) class citizen. Until this is solved, Swift will remain mostly an Apple only language, regardless of how nice it is. I think a time goes on this is more and more only a perception and not a reality. However perception is really important because it’ll mean even if it’s a great language with a great set of tools and libraries for all platforms it will not have a community of developers outside of the Apple ecosystem.
  - knighthack 2y ago
    The issue is not "as time goes on". The issue is now - the use of Swift outside of the Apple ecosystem is remarkably stifled, given the lack of Apple support. A language truly acquires mainstream mindshare and community, only if it can extend its use beyond Apple's OSes.
    - zer0zzz 2y ago
      > given the lack of Apple support. It’s an open source project that’s more and more detached from Apple itself every release, with lots of contributors making it better and better on Android and windows all the time. It is possible to get a vscode ide environment working for cross platform development and debugging today, which was not that easy or possible even a few years ago. There is at least one pretty sizable software project that has shipped a product on Android and windows using swift. I think swift 6 is going to be great for cross platform uses, but convincing folks to try it still won’t be easy.
pjmlp 2y ago
What Rust did great was bringing affine type systems into mainstream culture. However outside very specific use cases, where no kind of automatic resource management is allowed, no matter what, like in high integrity computing, or critical kernel code, approaches that mix and match both solutions are much more ergonomic. Swift isn't the only one going down this route, we see it as well in D, Chapel, Linear Haskell, OCamml Effects, Mojo, Hylo, Koka, Veronica, and probably many other research languages being born during the last 5 years. Because in the end, programming language ergonomics and expressiveness really matters for wide scale adoption.
- DasIch 2y ago
  Rust is more popular than all of these languages except swift combined. So it seems empirically that ergonomics and expressiveness don't matter that much or these languages don't manage to do significantly better than rust.
  - pjmlp 2y ago
    It appears more popular, which isn't the same thing.
    - tialaramex 2y ago
      If you have better metrics then that's interesting, otherwise it just looks bitter. Yeah, maybe chicken nuggets only appear more popular than broccoli. But I think since we don't have any actual evidence to say otherwise we can assume that's because they are in fact more popular than broccoli.
- naman34 2y ago
  There’s lots of interesting ideas in languages but most of them fail to be mainstream at all. When comparing new languages at the level of Rust, Swift, Go and maybe Kotlin are the only real competitors.
agubelu 2y ago
> In fact, Swift treats enums as more than just types and lets you put methods directly on it You can do the exact same thing in Rust: impl Coin { fn valueInCents(&self) -> u8 { match self { Self::Penny => 1, Self::Nickel => 5, Self::Dime => 10, Self::Quarter => 25, } } }
- tialaramex 2y ago
  Also they probably have their understanding upside down. What's going on here isn't that either Swift or Rust treats the enum types as "more than just types" but that they are indeed first class types, whereas in C and C++ what you get isn't a type at all, it's just a strange way to spell an integer. I don't think Swift has union types, but Rust does and so does C++ and in both languages the unions, just like their main product type (C++ class, Rust struct) can have methods defined on them. The enumeration "types" in the C-like languages are special and it's because they really aren't proper types at all, they're just integers wearing a funny hat. One of Rust's most important post 1.0 types MaybeUninit<T> is actually a union, lots of Rust's important types, in 1.0 and since, are enums.
  - secondcoming 2y ago
    C++'s scoped enums are strict types.
    - jb1991 2y ago
      They are still a long way from the features of enums in Swift.
    - tialaramex 2y ago
      Scoped enums ("enum class") are a very small improvement on the previous enum, the main thing they deliver is that they don't pollute your namespace as badly thanks to the scoping. Their notional status as "strict types" means nothing in a language which doesn't really care anyway, that's why memory_order::relaxed < cv_status::timeout is true In Rust if you write nonsense like that it doesn't compile, these aren't comparable things. In C++ they're just integers, so of course you can see that relaxed (the integer zero) is less than timeout (the integer one) ... They are just integers wearing funny hats.
hardwaresofton 2y ago
Am I the only one that dislikes the dot syntax for variants? Zig and Swift do it and I feel like it makes things harder to read, not easier. `.variant` vs `Type::Variant` IIRC the syntax is optional (you can include the type name) but it seems obvious that in any sufficiently long or complex code, not having the type name close would be annoying, especially if you didn’t have IDE like capabilities in your editor.
- Klonoar 2y ago
  I've said it in other comments on HN over the years, but yes - I agree. That `.variant` syntax is annoying as hell to dig through when you don't have an IDE to rely on for jumping around. Rust (or your choice of other more explicit language) is just generally way more clear about what's being used. The way I usually settle on describing it is that this feature solved for people writing code, but code is read more than it's written, and thus I don't believe this tradeoff was worthwhile.
  - afdbcreid 2y ago
    You will probably be sad to hear that allowing to omit the type in Rust is considered, and has been proposed many times.
    - Klonoar 2y ago
      I can only hope that it's been proposed many times and not actioned on before means there's been enough pushback, considering one of the entire points of the language is the explicit nature of it. Do you have a link for an RFC or GitHub issue or anything? Would be curious to see.
- robjwells 2y ago
  Fortunately in Rust you can have it both ways, as in `Type::Variant` most of the time and `use Type::Variant; … Variant …` in cases where the type name just causes noise. Example in the playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=455792818473fba5587d8876b8d4e87d https://play.rust-lang.org/?version=stable&mode=debug&editio...
neonsunset 2y ago
And C# is a cross-platform and faster Swift :)
- pjmlp 2y ago
  Unfortunely, without any mobile OS to call its own, and if only WinDev was so found of adopting .NET, as Apple keeps embracing and pushing Swift, or Google with Java/Kotlin on Android. With the recent C# focus given to WinUI and WinAppSDK, despite C++/WinRT underpinnings, maybe caused by failure to deliver VS tooling for C++/WinRT after almost a decade, or ongoing cybersecurity considerations, maybe WinDev attitute will change, although I see them more eager to adopt Rust than C#, across the Microsoftshpere blogs and technical notes.
- naman34 2y ago
  C# is a faster Java.
SneakerXZ 2y ago
> Swift use value-types by default with copy-on-write semantics. This isn't true. Copy-on-write semantics are implemented only for arrays, dictionaries, and strings. Swift value-types are copied immediately. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/classesandstructures/#Structures-and-Enumerations-Are-Value-Types https://docs.swift.org/swift-book/documentation/the-swift-pr...
- naman34 2y ago
  The documentation uses “copied” for value types that are copy-on-write. The documentation has oversimplified a bunch of the mental model and it causes incorrect understanding. Swift’s documentation is quite bad TBH. The biggest thing that still needs to be improved a lot.
rich_sasha 2y ago
My interest in Rust stems from a very good Python interop. There's a very small handful of compiled languages with that property: Rust, C++, Nim (which is itself quite niche)... That's basically it as far as I know. Swift doesn't seem to tick that box. I would happily have something 50-100% slower than C++/Rust with good interop, alas there seems to be very little / nothing. Cython for various reasons isn't ideal.
- pzo 2y ago
  There used to be Swift for Tensorflow but google killed it and then Chris Lattner created Mojo. AFAIR the punchline was that Swift was either too complicated for data scientists or they just preferred to use python that already knew.
- naman34 2y ago
  Seift has great C, C++ and Rust interop. And despite Swift for Tensorflow being killed, there’s still decent python interop. Now, setting up a project for that is probably quite hard because the documentation is non-existent.
prmoustache 2y ago
Unrelated to the blogpost in question but I don't understand why the author is not using its own certificate if he is using his own domain. Using an browser set to autodirect to https by default, all I get is some huge warning because the host use a certificate for svbtle, the service used to host this blog. I know some people think that because some blogpost is public it can be served without ssl, but I think it is still nice to leave the choice of the reader to disclose or not to his provider and everyone in between what he is reading or not without seeing horrible warnings.
- alabhyajindal 2y ago
  Exactly. Very annoying!
- naman34 2y ago
  Good to know. It’s an old blog and I’ll be moving it away soon. This just makes that work more urgent for me.
afavour 2y ago
As someone that’s recently been working on integrating Rust into an iOS Swift app I do agree with a lot of this. I love Rust but the more I’ve used Swift the more I find myself wishing I was just using Swift all the time. That said, the difference between the two has a lot less to do with the language itself than the world surrounding it. You can use Swift cross platform but it’s very obvious that Apple platforms are the primary target. Rust has a rich and varied package system, about the only assumption most packages make is that you’re using the Rust standard library. By comparison lot of Swift packages (which is a much smaller ecosystem anyway that’s slowly transitioning away from Cocapods, Carthage etc) will lean on OS APIs that won’t work if you compile for Linux or WASM[1]. I want Swift to be a more convenient Rust but it just isn’t there. e.g look at IBM abandoning Swift on the server not that long ago. [1] for example, this blog post: https://swiftrocks.com/weak-dictionary-values-in-swift https://swiftrocks.com/weak-dictionary-values-in-swift Discusses making a dictionary with weak values in Swift. It has a homegrown Swift version then discusses using NSMapTable… which isn’t available on Linux. But you wouldn’t know that reading the article because the assumption is that you’re running on an Apple platform.
- 369548684892826 2y ago
  Swift is in its .NET Framework stage. I’m looking forward to Swift Core!
  - afavour 2y ago
    I like that comparison! But it might require Apple’s perspective as a company to shift in the same way Microsoft’s did. We’ll see, I guess…
  - lolinder 2y ago
    The difference is that Microsoft very intentionally decided it was going to make .NET cross-platform as a strategic play. Apple has recently shown a willingness to get out of the way of cross-platform Swift, but I haven't yet seen evidence that they're throwing any significant weight behind it. They have an even worse track record than Microsoft did of investing heavily in locking developers into their ecosystem, so I'll have to see quite a bit of evidence to believe they're actually serious about cross-platform Swift.
andrewstuart 2y ago
If only it wasn't so heavily tied to Apple.
mogoh 2y ago
Always, when I read those postings that praise Swift, I wonder how good is the developer experience is if you don't use any of the Apple/MacOS ecosystem (except Swift, of course). I have not met any Swift developer who is not developing on macOS, usually for macOS. That makes me very skeptical that non-Mac devs are treated as second-class citizens. I am not only talking about the standard library, but also about the tooling, LSP, libraries, tutorials and so on. I totally believe that Swift is a good language, but I guess it is only good if you are on macOS. If you are developing with Swift but not using a Mac at all, I would love to hear how your experience has been.
- bryancoxwell 2y ago
  I recently went through the Swift tutorial for building a REST API using Vapor[0]. I used VSCode, compiled and run on Ubuntu. It’s the only Swift I’ve ever written, and obviously far from a production app, but I did enjoy it enough that it made me want to continue playing with Swift outside of the XCode/Mac ecosystem. [0]: https://www.swift.org/getting-started/vapor-web-server/ https://www.swift.org/getting-started/vapor-web-server/
  - mogoh 2y ago
    It's not much, but it's something. Thanks
- pzo 2y ago
  And even on MacOS you are limited - you cannot avoid not using Xcode pretty much. So in practice you cannot just only use VSCode or Jetbrains IDEs. There is been a talk in WWDC 2024 that apple invest with Swift for embedding systems and some language servers but not sure how mature it is. Apple doesn't have crossplatform in their DNA.
__jonas 2y ago
Does Swift make it as easy as Go or Rust to produce a single binary for any target platform? Would it be a good choice for a CLI application? It sounds kind of intriguing but I know very little about the language.
- naman34 2y ago
  The feature exists, but it’s not so easy because there is a lack of documentation.
tkz1312 2y ago
I mean basically everything is a more convenient rust...
jb1991 2y ago
> But when you need extra speed you can opt into an ownership system and “move” values to avoid copying. I've been using Swift a long time and don't quite get what this is referring to. Also: > Swift too gives you complete type-safety without a garbage collector. Type-safety and memory-safety are two entirely different things; this is an odd sentence.
- nicce 2y ago
  > I've been using Swift a long time and don't quite get what this is referring to. Latest Swift release (June 11th) added ownership system.
  - iknowstuff 2y ago
    Seems odd for an article which is comparing rust and Swift not to delve into the new Swift ownership system...
- naman34 2y ago
  That second things is a typo.
singularity2001 2y ago
'Swift is the better rust' inspired by the why-ruby-is-an-acceptable-lisp debate: http://www.randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/ http://www.randomhacks.net/2005/12/03/why-ruby-is-an-accepta...
dangoodmanUT 2y ago
Clone-on-write...
lame-lexem 2y ago
Rust's `Vec` already allocate values on the heap, so there is no need for another inderection with `Box`. this works: enum TreeNode<T> { Leaf(T), Branch(Vec<TreeNode<T>>), } https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4a116692a383e08d4dbe2e343529fa80 https://play.rust-lang.org/?version=stable&mode=debug&editio... otherwise if it was just tuple of `TreeNode` there would be E0072 https://doc.rust-lang.org/stable/error_codes/E0072.html https://doc.rust-lang.org/stable/error_codes/E0072.html
- nicce 2y ago
  Box takes less space in stack, and you can use Box to move pointer to Vec contents easier, without mem::take. So if you want to min-max things, you could still use Box.
deleted 2y ago
[deleted]
StewardMcOy 2y ago
As someone who has worked on large projects in both Swift and Rust, I have to disagree with the author about error handling. It's not perfect, but Rust's use of Result and syntactic sugar is probably the best solution to error handling I've ever used. try/catch (or in Swift's case do/catch) is more disruptive to the program flow. And prior to Swift 6, throws in Swift were untyped. (Yes, there's arguments that untyped throws are better for library code because it leaves you more room to add more errors as you become aware of the need for them without breaking the contract with your users, but really, client code is going to be written to the errors you're throwing anyway (i.e. Hyrum's Law). I much prefer my errors to be typed so that if an error is added, the library version has to be bumped to indicate the new incompatibility with old code. And for my own, non-library code, typed errors make sure I'm handling all the error cases.)
lostmsu 2y ago
The article is outright wrong at times (like the need for Box or special status of enums), and is missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time. So no, Swift is not a "more convenient Rust". It is not Rust at all. It is more of a variant of C#/Java. And I haven't seen any indication that it is an improvement over either. The only reason to use Swift is having to deal with Apple.
- Terretta 2y ago
  > missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time Article may have overlooked this since it's been available in recent 5.x and becomes default in 6: Swift 6 brings complete concurrency enabled by default By far the biggest change is that complete concurrency checking is enabled by default. Unless you're very fortunate indeed, there's a very good chance your code will need some adjustment – it's no surprise the Swift team made it optional in earlier versions to give folks time to evaluate what's changing. Swift 6 improves concurrency checking further, and the Swift team say it "removes many false-positive data-race warnings" that were present in 5.10. It also introduces several targeted changes that will do wonders to make concurrency easier to adopt – if you tried with 5.10 and found things just too gnarly to figure out, hopefully some of the changes in Swift 6 will help. Easily the biggest is SE-0414, which defines isolation regions that allow the compiler to conclusively prove different parts of your code can run concurrently. https://www.hackingwithswift.com/articles/269/whats-new-in-swift-6 https://www.hackingwithswift.com/articles/269/whats-new-in-s...
  - lostmsu 2y ago
    Is there a better description of this change? How does it work internally? Is thread safety guaranteed or best effort warning? How does it work with immutable objects?

242 points by mpweiher 2y ago

> Swift is better for writing UI and servers and some parts of compilers and operating systems. Swift is better for some UI and some servers/operating systems. A considerable problem with Swift's adoption is that zero attention has been given to ergonomics on other platforms which has left it as the Xserve of programming languages for quite a while now. If the Foundation framework and SwiftUI paid serious attention to non-Apple platforms, then Swift itself might have a chance. Until then, even C# is going to look more attractive for cross-platform devs that don't want to drown their software in ifdefs.

amichail 2y ago
Can't you use Qt with Swift's bidirectional C++ interoperability?
- neonsunset 2y ago
  You can. But you can also use Avalonia*, Uno Platform* , Gir.Core or whatever currently maintained Qt binding library is for .NET. The FP and syntax advantages listed in the article exist in equal measure in C#, and so do zero-cost Rust-style abstractions. Swift is a language with a lot of potential, but it has a lot of work ahead of it, the work that was done for .NET's performance, cross-platform support, tooling ecosystem and OSS-focused development process. *both of which have SwiftUI style extensions for declarative UI definition and MVU patterns. Avalonia even has the F# version of that.
- talldayo 2y ago
  I mean, you can use all of POSIX with C FFI if you wanted. But that goes for most languages, and it's a far cry from the convenience of a well-made standard library. People want Apple to stop pretending like it's impossible to support other OSes, it's really that simple. If they want their language to have serious popularity, they have to act like a real Open Source maintainer and not a business. Swift's adoption outside of Apple developers forced into using it is more or less sabotaged by Apple's decisions. Whether they realize it or not, this behavior is undermining Swift's credibility and likely pushing people onto C++/Rust where they can use LLVM without limitations.
Someone 2y ago
> If the Foundation framework and SwiftUI paid serious attention to non-Apple platforms They started late, but isn’t https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation paying serious attention to non-Apple platforms now? SwiftUI, I think, isn’t as essential, as it isn’t really possible to create a good cross-platform Ui library (and yes, that means I think running iOS apps on MacOS can’t provide an optimal experience)
- talldayo 2y ago
  I'm just calling it like it is. I'm a Rust dev that really doesn't look at Swift with much hope. It's not a language that performs consistently across platforms, which is documented well in the repo's Issues tab. I just don't have the time or patience to work with a language that treats me as a platform adversary. If Apple doesn't go the extra mile to make their language attractive outside their ecosystem, they're just not going to compete in the greater programming community. Rejecting it on principle is a no-brainer for any cross-platform project. The case for Swift is shallow, even if you're a Mac-native dev. The worst part is, Swift is a perfectly fine language on paper. It's got Lattner behind it, it's got literal trillion-dollar corporation funding behind it, and interfaces with LLVM to boot. It's lovely! My problem with Swift has always been Apple's attitude towards their own language and how desperate they are to reject non-ecosystem users. My life is too short to put up with nonworking language primitives in 2024. It pains me to say it, since Swift is so cool, but there are several better languages.
deleted 2y ago
[deleted]

high_priest 2y ago

Yes! And C# is just more convenient C.

dbfa 2y ago
JavaScript is just a more convenient x86-assembly. :P
neonsunset 2y ago
Closer to convenient C++ probably :)
- pjmlp 2y ago
  Definitely, Windows development would be so much more fun, had Native AOT been there since day one, and WinDev wasn't so much siloed into their C++ toys.

nicce 2y ago

> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting. They did it well, but not invented? There very many kinds of influeces: https://www.reddit.com/r/rust/comments/le7m54/is_it_fair_to_say_rust_parentage_can_be_traced_to/gmb4zgc/ https://www.reddit.com/r/rust/comments/le7m54/is_it_fair_to_... Especially Cyclone, I think: https://en.m.wikipedia.org/wiki/Cyclone_(programming_language) https://en.m.wikipedia.org/wiki/Cyclone_(programming_languag...

mananaysiempre 2y ago
The best review of the relevant research that I know is Pottier’s presentation[1]. It’s from 2007, but then again as far as fundamental concepts it doesn’t seem to me that Rust is state-of-the-art even as of then. (To be fair, that’s not due to ignorance, Rust’s type system is deliberately conservative.) [1] https://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-linear-bestiary.pdf https://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-...

lukeh 2y ago

I don’t know Rust, but I’m loving Swift for systems programming. Most recent project was an 802.1Q SRP implementation and I couldn’t imagine going back to C. Higher up the stack, I’ve also used it with a custom runner to build the business logic for an embedded Flutter app. My only beef is that the binaries are quite large. I’m hoping the new Foundation will improve things, in the interim I’m trying to eliminate my Foundation dependencies.

neonsunset 2y ago
You can get much smaller native binaries with .NET's NativeAOT nowadays: https://github.com/MichalStrehovsky/sizegame https://github.com/MichalStrehovsky/sizegame Funnily enough, I'm using C# to solve quite a similar type of tasks. It's a really pleasant experience.
- pjmlp 2y ago
  Native AOT needs to get better tooling ergonomics though, the whole publish process is a bit convoluted versus toolchains that have AOT compilation as their default. Not counting having to learn about IL trimming, and the whole AOT compatible libraries.
  - neonsunset 2y ago
    What kind of issues did you have with the build process? (as in, if you had a specific case, it might be worth submitting an issue or updating documentation) It's a very straightforward process - you pass a single flag, maybe specify optimization preference and instruction set target, and it gives you the binary upon 'dotnet publish'ing the project. The process of static linking (if you care about this scenario), with other static dependencies written in C/C++/Rust is not too different from other toolchains - you specify `DirectPInvoke` and `NativeLibrary` properties in .csproj, and they are linked into the final product as a part of the build process. You may need to forward linker arguments[0] for the imports referenced by those however, but this is expected regardless of .NET. I think it's fair to criticize the additional compatibility effort required for high-level user libraries that rely on un-analyzable reflection, reflection emit or assembly loading, but none of these features usually have any relevance in the domain of systems programming. When you write a project from scratch, you never have to think about whether it's native compilation or "JIT+CIL assemblies sandwich" executable, or anything else. It just works. For example https://github.com/codr7/sharpl https://github.com/codr7/sharpl - the author was pretty much learning C# on the go and it needed exactly 0 changes besides adding `PublishAot` property to make it output a native executable. [0]: https://github.com/U8String/U8String/blob/main/Examples/Interop/CSharp/CSharp.csproj#L31 https://github.com/U8String/U8String/blob/main/Examples/Inte...

robjwells 2y ago

One way that Swift is certainly not more convenient than Rust is the tooling. I use a 2018 MacBook Air, using macOS 12, which is now unsupported by Xcode. Meanwhile SourceKit-LSP is treated as very much a second-class citizen. But Rust 1.81 and rust-analyzer build and run just fine.

arghwhat 2y ago
Not to praise Swift, but Swift and Xcode are unrelated projects. Saying that Swift is inconvenient because of Xcode issues is like saying C++/C# is inconvenient because of Visual Studio. You can install Swift on Linux if you want and code away, just like with Rust - but as it hasn't really caught on for anything other than building apps for the Apple ecosystem, it's not a particularly normal thing to do.
- yunohn 2y ago
  I’m pretty sure you need Xcode to compile Swift on macOS.
  - acar_rag 2y ago
    Absolutely not, you just need to use swiftc: https://theswiftdev.com/the-swift-compiler-for-beginners/ https://theswiftdev.com/the-swift-compiler-for-beginners/
  - robjwells 2y ago
    You can install a Swift toolchain on macOS without Xcode, but Xcode is the “blessed” route and listed first on the swift.org getting started instructions. https://www.swift.org/install/macos https://www.swift.org/install/macos However, it can be a bumpy ride. For example: “swift test” (via the CLI) doesn’t work if Xcode is not installed. https://github.com/swiftlang/swift-package-manager/issues/4396 https://github.com/swiftlang/swift-package-manager/issues/43... I would just emphasise that the OP was about _convenience_ and Swift-without-Xcode on macOS is not smooth sailing.
  - latexr 2y ago

noelwelsh 2y ago

Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the first language to bring non-GC automatic memory management to the mainstream. It won't be the last and it might well be the worst. Other languages in this space include Swift (as in OP's post), OCaml[1], and Scala[2]. These alternatives take the approach that tracking ownership is not the default, which is fine for the majority of programs and far more ergonomic. There's also a corollary 3. The age of Smalltalk is over. It's now the age of ML. (Amusingly, going backwards in time, from 1983 to 1975). The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk (everything is an object! dynamic types! runtime metaprogramming!) The new languages (Rust, Scala, Swift, Kotlin, etc.) are ML family languages. Similarly, back in the day you could learn, say, Ruby, and still be reasonably proficient in Python or JS. Now you can learn, say, Scala, and pick up Rust or Swift reasonably easily. [1]: https://blog.janestreet.com/oxidizing-ocaml-locality/ https://blog.janestreet.com/oxidizing-ocaml-locality/ [2]: https://dl.acm.org/doi/full/10.1145/3618003 https://dl.acm.org/doi/full/10.1145/3618003

the_duke 2y ago
Ad 3) Scala is quite a bit older than the others, I'd put it in a previous generation. I always saw Kotlin as a more convenient Java, without Scalas heavy tilt towards FP. Java also added the equivalent of sum types with sealed interfaces and exhaustive pattern matching, does that make Java an ML language? Many older languages by now have incorporated valuable parts of FP/ML (including Javascript, Java, C++, ...) Borrowing some concepts from ML doesn't put these languages in the ML family.
- SSLy 2y ago
  > does that make Java an ML language? not really, the type-system-sublanguage is still modelled like classy OOP, not more like MLy modules.

seanalltogether 2y ago

I keep trying to get into rust but I always hit a brick wall when looking at examples and the code looks so complicated. Examples like this straight from the rust website just make my eyes glaze over struct Task { future: Mutex<Option<BoxFuture<'static, ()>>>, task_sender: SyncSender<Arc<Task>>, }

swiftcoder 2y ago
I'll grant you that is probably too complicated an example to appear early in the docs, but how often are you actually building multithreaded job dispatch systems from scratch (which appears to be what this example is doing), and how simple would it be in other languages?
- diggan 2y ago
  This is how simple it would be in Clojure, for comparison: (defrecord Task [future task-sender]) Probably used something like this: (defn create-task [] (let [future (atom nil) task-sender (async/chan)] (->Task future task-sender))) Not sure it makes sense but a pretty much direct translation as far as it goes.
  - galangalalgol 2y ago
    Having never used a lisp outside an AI class a quarter century ago, that isn't comprehensible to me, and I don't think it is just my lack of caffeine. The rust example makes more sense, but I've used rust for almost a decade at this point and c++ for over three. Familiarity matters.
    - diggan 2y ago
      Yeah, of course. If you show me Brainfuck or APL code I won't be able to make head or tails of it either. But familiarity should never stop one from learning new things, otherwise we miss out on a lot of simple, interesting and useful stuff :)
    - 2y ago

BiteCode_dev 2y ago

Swift won't be able to compete with rust until it has a great scripting story. Rust is currently the defactor choice if you want to make something with js/python bindings, of id you want to speed up a dynamic bottleneck because it makes it super easy. Swift doesn't even have a good ffi.

pjmlp 2y ago
Try to make Rust interop with C++, C and Objective-C as easy as Swift does it.
- sgt 2y ago
  This is a big deal. In reality, most of the code that powers your systems (phones, tablets, any computers) is built using C and C++, regardless what OS you use.
  - galangalalgol 2y ago
    Agreed, and rust-c interop is as good as any other I've used. The c++ interop was clunky but getting much better with crates like zngur. That is what was holding back its use on chrome for a while. Oddly its python interop is way better with pyo3 and maturin making it super easy.
- Klonoar 2y ago
  C++ is (IME) an order of magnitude more annoying from Rust than C or Objective-C. I've dealt with interop of the latter two on a number of projects and frankly found them to be fine. (Though I wouldn't fault anyone for making an argument that Swift is still more ergonomic here)
lukeh 2y ago
Swift can import C (and C++) modules directly, and it's fairly straightforward to wrap existing C APIs with callbacks to be usable from structured concurrency. Here's an example I just worked on. [1] [1] https://github.com/PADL/NetLinkSwift https://github.com/PADL/NetLinkSwift

mangeshbankar21 2y ago

[flagged]

tromp 2y ago

> it gives you utilities such as Rc, Arc and Cow to do reference counting and “clone-on-right” Not quite right: [1] https://en.wikipedia.org/wiki/Copy-on-write https://en.wikipedia.org/wiki/Copy-on-write

steveklabnik 2y ago
Cow in Rust does mean “Clone on write,” because Copy is a term of art in Rust (as is Clone).

dist1ll 2y ago

The tree example is quite contrived. Most Rust programmers would use indices for indirection, pointing into flat buffers.

MereInterest 2y ago
It’s also incorrect. There’s no need to use both Vec and Box, as either is sufficient to provide indirection.

K0nserv 2y ago

I love both Rust and Swift, they have their respective strengths. I would say Swift has a less noisy surface syntax, but instead uses more dedicated keywords and compiler magic. This is nicer, but means some areas are "compiler only territory". In many cases Swift would be a better choice than Rust, when the convenience and developer experience is worth trading for some performance. However, Swift's biggest problem is that any usage outside of the Apple ecosystem is a second(or third) class citizen. Until this is solved, Swift will remain mostly an Apple only language, regardless of how nice it is.

zer0zzz 2y ago
> However, Swift's biggest problem is that any usage outside of the Apple ecosystem is a second(or third) class citizen. Until this is solved, Swift will remain mostly an Apple only language, regardless of how nice it is. I think a time goes on this is more and more only a perception and not a reality. However perception is really important because it’ll mean even if it’s a great language with a great set of tools and libraries for all platforms it will not have a community of developers outside of the Apple ecosystem.
- knighthack 2y ago
  The issue is not "as time goes on". The issue is now - the use of Swift outside of the Apple ecosystem is remarkably stifled, given the lack of Apple support. A language truly acquires mainstream mindshare and community, only if it can extend its use beyond Apple's OSes.
  - zer0zzz 2y ago
    > given the lack of Apple support. It’s an open source project that’s more and more detached from Apple itself every release, with lots of contributors making it better and better on Android and windows all the time. It is possible to get a vscode ide environment working for cross platform development and debugging today, which was not that easy or possible even a few years ago. There is at least one pretty sizable software project that has shipped a product on Android and windows using swift. I think swift 6 is going to be great for cross platform uses, but convincing folks to try it still won’t be easy.

pjmlp 2y ago

What Rust did great was bringing affine type systems into mainstream culture. However outside very specific use cases, where no kind of automatic resource management is allowed, no matter what, like in high integrity computing, or critical kernel code, approaches that mix and match both solutions are much more ergonomic. Swift isn't the only one going down this route, we see it as well in D, Chapel, Linear Haskell, OCamml Effects, Mojo, Hylo, Koka, Veronica, and probably many other research languages being born during the last 5 years. Because in the end, programming language ergonomics and expressiveness really matters for wide scale adoption.

DasIch 2y ago
Rust is more popular than all of these languages except swift combined. So it seems empirically that ergonomics and expressiveness don't matter that much or these languages don't manage to do significantly better than rust.
- pjmlp 2y ago
  It appears more popular, which isn't the same thing.
  - tialaramex 2y ago
    If you have better metrics then that's interesting, otherwise it just looks bitter. Yeah, maybe chicken nuggets only appear more popular than broccoli. But I think since we don't have any actual evidence to say otherwise we can assume that's because they are in fact more popular than broccoli.
naman34 2y ago
There’s lots of interesting ideas in languages but most of them fail to be mainstream at all. When comparing new languages at the level of Rust, Swift, Go and maybe Kotlin are the only real competitors.

agubelu 2y ago

> In fact, Swift treats enums as more than just types and lets you put methods directly on it You can do the exact same thing in Rust: impl Coin { fn valueInCents(&self) -> u8 { match self { Self::Penny => 1, Self::Nickel => 5, Self::Dime => 10, Self::Quarter => 25, } } }

tialaramex 2y ago
Also they probably have their understanding upside down. What's going on here isn't that either Swift or Rust treats the enum types as "more than just types" but that they are indeed first class types, whereas in C and C++ what you get isn't a type at all, it's just a strange way to spell an integer. I don't think Swift has union types, but Rust does and so does C++ and in both languages the unions, just like their main product type (C++ class, Rust struct) can have methods defined on them. The enumeration "types" in the C-like languages are special and it's because they really aren't proper types at all, they're just integers wearing a funny hat. One of Rust's most important post 1.0 types MaybeUninit<T> is actually a union, lots of Rust's important types, in 1.0 and since, are enums.
- secondcoming 2y ago
  C++'s scoped enums are strict types.
  - jb1991 2y ago
    They are still a long way from the features of enums in Swift.
  - tialaramex 2y ago
    Scoped enums ("enum class") are a very small improvement on the previous enum, the main thing they deliver is that they don't pollute your namespace as badly thanks to the scoping. Their notional status as "strict types" means nothing in a language which doesn't really care anyway, that's why memory_order::relaxed < cv_status::timeout is true In Rust if you write nonsense like that it doesn't compile, these aren't comparable things. In C++ they're just integers, so of course you can see that relaxed (the integer zero) is less than timeout (the integer one) ... They are just integers wearing funny hats.

hardwaresofton 2y ago

Am I the only one that dislikes the dot syntax for variants? Zig and Swift do it and I feel like it makes things harder to read, not easier. `.variant` vs `Type::Variant` IIRC the syntax is optional (you can include the type name) but it seems obvious that in any sufficiently long or complex code, not having the type name close would be annoying, especially if you didn’t have IDE like capabilities in your editor.

Klonoar 2y ago
I've said it in other comments on HN over the years, but yes - I agree. That `.variant` syntax is annoying as hell to dig through when you don't have an IDE to rely on for jumping around. Rust (or your choice of other more explicit language) is just generally way more clear about what's being used. The way I usually settle on describing it is that this feature solved for people writing code, but code is read more than it's written, and thus I don't believe this tradeoff was worthwhile.
- afdbcreid 2y ago
  You will probably be sad to hear that allowing to omit the type in Rust is considered, and has been proposed many times.
  - Klonoar 2y ago
    I can only hope that it's been proposed many times and not actioned on before means there's been enough pushback, considering one of the entire points of the language is the explicit nature of it. Do you have a link for an RFC or GitHub issue or anything? Would be curious to see.
robjwells 2y ago
Fortunately in Rust you can have it both ways, as in `Type::Variant` most of the time and `use Type::Variant; … Variant …` in cases where the type name just causes noise. Example in the playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=455792818473fba5587d8876b8d4e87d https://play.rust-lang.org/?version=stable&mode=debug&editio...

neonsunset 2y ago

And C# is a cross-platform and faster Swift :)

pjmlp 2y ago
Unfortunely, without any mobile OS to call its own, and if only WinDev was so found of adopting .NET, as Apple keeps embracing and pushing Swift, or Google with Java/Kotlin on Android. With the recent C# focus given to WinUI and WinAppSDK, despite C++/WinRT underpinnings, maybe caused by failure to deliver VS tooling for C++/WinRT after almost a decade, or ongoing cybersecurity considerations, maybe WinDev attitute will change, although I see them more eager to adopt Rust than C#, across the Microsoftshpere blogs and technical notes.
naman34 2y ago
C# is a faster Java.

SneakerXZ 2y ago

> Swift use value-types by default with copy-on-write semantics. This isn't true. Copy-on-write semantics are implemented only for arrays, dictionaries, and strings. Swift value-types are copied immediately. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/classesandstructures/#Structures-and-Enumerations-Are-Value-Types https://docs.swift.org/swift-book/documentation/the-swift-pr...

naman34 2y ago
The documentation uses “copied” for value types that are copy-on-write. The documentation has oversimplified a bunch of the mental model and it causes incorrect understanding. Swift’s documentation is quite bad TBH. The biggest thing that still needs to be improved a lot.

rich_sasha 2y ago

My interest in Rust stems from a very good Python interop. There's a very small handful of compiled languages with that property: Rust, C++, Nim (which is itself quite niche)... That's basically it as far as I know. Swift doesn't seem to tick that box. I would happily have something 50-100% slower than C++/Rust with good interop, alas there seems to be very little / nothing. Cython for various reasons isn't ideal.

pzo 2y ago
There used to be Swift for Tensorflow but google killed it and then Chris Lattner created Mojo. AFAIR the punchline was that Swift was either too complicated for data scientists or they just preferred to use python that already knew.
naman34 2y ago
Seift has great C, C++ and Rust interop. And despite Swift for Tensorflow being killed, there’s still decent python interop. Now, setting up a project for that is probably quite hard because the documentation is non-existent.

prmoustache 2y ago

Unrelated to the blogpost in question but I don't understand why the author is not using its own certificate if he is using his own domain. Using an browser set to autodirect to https by default, all I get is some huge warning because the host use a certificate for svbtle, the service used to host this blog. I know some people think that because some blogpost is public it can be served without ssl, but I think it is still nice to leave the choice of the reader to disclose or not to his provider and everyone in between what he is reading or not without seeing horrible warnings.

alabhyajindal 2y ago
Exactly. Very annoying!
naman34 2y ago
Good to know. It’s an old blog and I’ll be moving it away soon. This just makes that work more urgent for me.

afavour 2y ago

As someone that’s recently been working on integrating Rust into an iOS Swift app I do agree with a lot of this. I love Rust but the more I’ve used Swift the more I find myself wishing I was just using Swift all the time. That said, the difference between the two has a lot less to do with the language itself than the world surrounding it. You can use Swift cross platform but it’s very obvious that Apple platforms are the primary target. Rust has a rich and varied package system, about the only assumption most packages make is that you’re using the Rust standard library. By comparison lot of Swift packages (which is a much smaller ecosystem anyway that’s slowly transitioning away from Cocapods, Carthage etc) will lean on OS APIs that won’t work if you compile for Linux or WASM[1]. I want Swift to be a more convenient Rust but it just isn’t there. e.g look at IBM abandoning Swift on the server not that long ago. [1] for example, this blog post: https://swiftrocks.com/weak-dictionary-values-in-swift https://swiftrocks.com/weak-dictionary-values-in-swift Discusses making a dictionary with weak values in Swift. It has a homegrown Swift version then discusses using NSMapTable… which isn’t available on Linux. But you wouldn’t know that reading the article because the assumption is that you’re running on an Apple platform.

369548684892826 2y ago
Swift is in its .NET Framework stage. I’m looking forward to Swift Core!
- afavour 2y ago
  I like that comparison! But it might require Apple’s perspective as a company to shift in the same way Microsoft’s did. We’ll see, I guess…
- lolinder 2y ago
  The difference is that Microsoft very intentionally decided it was going to make .NET cross-platform as a strategic play. Apple has recently shown a willingness to get out of the way of cross-platform Swift, but I haven't yet seen evidence that they're throwing any significant weight behind it. They have an even worse track record than Microsoft did of investing heavily in locking developers into their ecosystem, so I'll have to see quite a bit of evidence to believe they're actually serious about cross-platform Swift.

andrewstuart 2y ago

If only it wasn't so heavily tied to Apple.

mogoh 2y ago

Always, when I read those postings that praise Swift, I wonder how good is the developer experience is if you don't use any of the Apple/MacOS ecosystem (except Swift, of course). I have not met any Swift developer who is not developing on macOS, usually for macOS. That makes me very skeptical that non-Mac devs are treated as second-class citizens. I am not only talking about the standard library, but also about the tooling, LSP, libraries, tutorials and so on. I totally believe that Swift is a good language, but I guess it is only good if you are on macOS. If you are developing with Swift but not using a Mac at all, I would love to hear how your experience has been.

bryancoxwell 2y ago
I recently went through the Swift tutorial for building a REST API using Vapor[0]. I used VSCode, compiled and run on Ubuntu. It’s the only Swift I’ve ever written, and obviously far from a production app, but I did enjoy it enough that it made me want to continue playing with Swift outside of the XCode/Mac ecosystem. [0]: https://www.swift.org/getting-started/vapor-web-server/ https://www.swift.org/getting-started/vapor-web-server/
- mogoh 2y ago
  It's not much, but it's something. Thanks
pzo 2y ago
And even on MacOS you are limited - you cannot avoid not using Xcode pretty much. So in practice you cannot just only use VSCode or Jetbrains IDEs. There is been a talk in WWDC 2024 that apple invest with Swift for embedding systems and some language servers but not sure how mature it is. Apple doesn't have crossplatform in their DNA.

__jonas 2y ago

Does Swift make it as easy as Go or Rust to produce a single binary for any target platform? Would it be a good choice for a CLI application? It sounds kind of intriguing but I know very little about the language.

naman34 2y ago
The feature exists, but it’s not so easy because there is a lack of documentation.

tkz1312 2y ago

I mean basically everything is a more convenient rust...

jb1991 2y ago

> But when you need extra speed you can opt into an ownership system and “move” values to avoid copying. I've been using Swift a long time and don't quite get what this is referring to. Also: > Swift too gives you complete type-safety without a garbage collector. Type-safety and memory-safety are two entirely different things; this is an odd sentence.

nicce 2y ago
> I've been using Swift a long time and don't quite get what this is referring to. Latest Swift release (June 11th) added ownership system.
- iknowstuff 2y ago
  Seems odd for an article which is comparing rust and Swift not to delve into the new Swift ownership system...
naman34 2y ago
That second things is a typo.

singularity2001 2y ago

'Swift is the better rust' inspired by the why-ruby-is-an-acceptable-lisp debate: http://www.randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/ http://www.randomhacks.net/2005/12/03/why-ruby-is-an-accepta...

dangoodmanUT 2y ago

Clone-on-write...

lame-lexem 2y ago

Rust's `Vec` already allocate values on the heap, so there is no need for another inderection with `Box`. this works: enum TreeNode<T> { Leaf(T), Branch(Vec<TreeNode<T>>), } https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4a116692a383e08d4dbe2e343529fa80 https://play.rust-lang.org/?version=stable&mode=debug&editio... otherwise if it was just tuple of `TreeNode` there would be E0072 https://doc.rust-lang.org/stable/error_codes/E0072.html https://doc.rust-lang.org/stable/error_codes/E0072.html

nicce 2y ago
Box takes less space in stack, and you can use Box to move pointer to Vec contents easier, without mem::take. So if you want to min-max things, you could still use Box.

deleted 2y ago

[deleted]

StewardMcOy 2y ago

As someone who has worked on large projects in both Swift and Rust, I have to disagree with the author about error handling. It's not perfect, but Rust's use of Result and syntactic sugar is probably the best solution to error handling I've ever used. try/catch (or in Swift's case do/catch) is more disruptive to the program flow. And prior to Swift 6, throws in Swift were untyped. (Yes, there's arguments that untyped throws are better for library code because it leaves you more room to add more errors as you become aware of the need for them without breaking the contract with your users, but really, client code is going to be written to the errors you're throwing anyway (i.e. Hyrum's Law). I much prefer my errors to be typed so that if an error is added, the library version has to be bumped to indicate the new incompatibility with old code. And for my own, non-library code, typed errors make sure I'm handling all the error cases.)

lostmsu 2y ago

The article is outright wrong at times (like the need for Box or special status of enums), and is missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time. So no, Swift is not a "more convenient Rust". It is not Rust at all. It is more of a variant of C#/Java. And I haven't seen any indication that it is an improvement over either. The only reason to use Swift is having to deal with Apple.

Terretta 2y ago
> missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time Article may have overlooked this since it's been available in recent 5.x and becomes default in 6: Swift 6 brings complete concurrency enabled by default By far the biggest change is that complete concurrency checking is enabled by default. Unless you're very fortunate indeed, there's a very good chance your code will need some adjustment – it's no surprise the Swift team made it optional in earlier versions to give folks time to evaluate what's changing. Swift 6 improves concurrency checking further, and the Swift team say it "removes many false-positive data-race warnings" that were present in 5.10. It also introduces several targeted changes that will do wonders to make concurrency easier to adopt – if you tried with 5.10 and found things just too gnarly to figure out, hopefully some of the changes in Swift 6 will help. Easily the biggest is SE-0414, which defines isolation regions that allow the compiler to conclusively prove different parts of your code can run concurrently. https://www.hackingwithswift.com/articles/269/whats-new-in-swift-6 https://www.hackingwithswift.com/articles/269/whats-new-in-s...
- lostmsu 2y ago
  Is there a better description of this change? How does it work internally? Is thread safety guaranteed or best effort warning? How does it work with immutable objects?