9 ms·

Ask HN: Rust or Swift for system programming?

61 points by rustyrose 10y ago

I've been looking at system programming languages. After years of web development with higher-level, dynamic, slow languages, I'd like to learn a language that is fast and suitable for system programming. Because let's face it, you aren't going to write a key-value database, web server, or the next docker in Ruby. I considered C, C++, Go, Rust, D, and Swift. I liked Rust and Swift the most. Rust is a bit nicer, I admit, but Swift feels more high-level. Taken in a vacuum, it's 50-50 for me. However, languages don't live in a vacuum. Swift has the added benefit of opening up a whole world of possibilities in the Apple ecosystem, not to mention readily available jobs. Because of this, I'd be inclined to invest in Swift rather than Rust. My question to you is, will I miss out? Are there classes of applications that are much better suited for Rust? And I mean in practical terms, not in a theoretical, both are Turing complete way. Because of my impression of the languages, I mentally classify Rust as lower level than Swift, and as a result I, probably mistakenly, tend to think that maybe Swift is still too high level for system programming. But performance wise they appear to be equivalent. I want to make sure I'm not overlooking something and dismissing Rust in favor of Swift too quickly.

notriddle 10y ago
Swift is more high-level. That's not an accident: Swift is designed to write the front end of an interactive application, while Rust is designed to build the back end thereof. But if you're coming from dynamic languages, Rust's biggest talking-point advantage over Swift is how easy it is to integrate Rust with other systems. Rust doesn't have "special integration" like Swift does with Cocoa, but it will talk to anything that will talk to C. Which is basically everything. It will talk to Java's JNI (including Android NDK), it will talk to Ruby's MRI, it will talk to CPython, it will talk to Node, and I can even integrate Rust with Swift. [It's pretty much just a matter of converting the function declarations and asking to have your project compiled into a C shared library.](https://doc.rust-lang.org/book/ffi.html https://doc.rust-lang.org/book/ffi.html) ("rust-bindgen" and "rust-cheddar" automate this)
Strom 10y ago
There is no single correct answer as it always depends on a huge amount of variables, many of which are in constant flux. You yourself will almost always have the most accurate information to make a decision what's best for you. Spend a year with Rust and a year with Swift. Then you'll be at a far superior position to choose which one of those to invest more years in, or to look for a third language. Which one to choose first? It doesn't matter, flip a coin if the decision is difficult. Learning many languages/frameworks/styles will make you a better programmer than just investing decades into some supposed unicorn. Peter Norvig has a great post on this called Teach Yourself Programming in Ten Years. [1] [1] http://norvig.com/21-days.html http://norvig.com/21-days.html
agmcleod 10y ago
Swift would be a good choice for job viability if you wanted to move over to iOS after exploring systems programming. In the systems world, C is probably the best choice in terms of systems programming. Personally I really like Rust, and more companies do seem to be picking it up. If your goal is really to just learn something, and potentially make something. More so than any other job prospects in the future, than I say choose what you like the most.
- bjz_ 10y ago
  > If your goal is really to just learn something, and potentially make something Yeah - Rust will most likely make you think more differently about programming than Swift will, and will give more scope in terms of systems programming. The advantage of Swift is that it simplifies things more, but that comes at a cost.
  - Manishearth 10y ago
    I will point out that for people used to languages like C++, Java, Python, JS, Ruby, or Go, Swift and Rust are both pretty good choices here. I mean, while Rust may make you think about ownership and memory management when programming (I have found this useful in all languages), both languages have a great type system and IMO learning to work with those is a far greater learning experience. So while Rust may teach you more, it doesn't teach you much more. On the other hand, if you come from Haskell or something, the type systems aren't what you're looking for :)
Jerry2 10y ago
>However, languages don't live in a vacuum. Swift has the added benefit of opening up a whole world of possibilities in the Apple ecosystem, not to mention readily available jobs. Because of this, I'd be inclined to invest in Swift rather than Rust. Rust & Swift are fairly similar but Swift has a much wider range of possible applications. Swift is also moving very fast (that's to be expected since it's backed by one of the most valuable companies on Earth). This is the primary reason why I picked Swift over Rust for a project I'm working on (I'm working on an open-source password key store for high-volume services).
- icebraining 10y ago
  Swift has a much wider range of possible applications Why?
- pcwalton 10y ago
  > Rust & Swift are fairly similar but Swift has a much wider range of possible applications. Can you elaborate on this? The languages seem very different to me--Swift is garbage collected (reference counting being a form of GC), for example.
  - Jerry2 10y ago
    >Can you elaborate on this? The languages seem very different to me--Swift is garbage collected (reference counting being a form of GC), for example. ARC is not garbage collection [0]. Swift doesn't have a separate processes managing memory during the runtime. In Swift, compiler analyzes the code during the static compilation pass and inserts release/retain code during the compile time. See this SO answer for more info [1]. And you don't have to use ARC if you don't want to [2]. GC in Java or Go or CLR, for example, is completely different. Obj-C 2.0 was garbage collected but Apple hated it because of GC pauses and they vowed to remove it and never use GC again. [3] Hence, they developed ARC. [0] https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting [1] http://stackoverflow.com/a/7894809 http://stackoverflow.com/a/7894809 [2] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html#//apple_ref/doc/uid/TP40014097-CH20-XID_88 https://developer.apple.com/library/ios/documentation/Swift/... [3] https://en.wikipedia.org/wiki/Objective-C#Garbage_collection https://en.wikipedia.org/wiki/Objective-C#Garbage_collection
ebbv 10y ago
I really like writing in Swift. To be honest I am strongly considering looking for jobs writing in it even though I have a great job, just because I want to write Swift.
MichaelGG 10y ago
Does Swift force GC (via AutoRC)? That might lower its utility as a systems language and should have a performance penalty that Rust does not.
- pcwalton 10y ago
  That's right. Swift is a garbage collected language.
- mikeash 10y ago
  You can avoid it, by using things like UnsafePointer for your references, but it's unnatural and inconvenient.
- bjz_ 10y ago
  Yes, unless you break out of it by using unsafe storage methods, which are purposefully made unergonomic to use. Due to its type system Rust has the advantage that you can safely choose by either thread-local or atomic reference counting - Swift has to default to the latter. And you actually don't really need RC all that much - most data in a program is short-lived and has a single owner. The flip-side is that because Swift's reference counting is implicit, it makes the type signatures simpler, and working with them more ergonomic.
- millstone 10y ago
  Both Swift and Rust use reference counting in different ways. Swift uses reference counting for all reference types (classes), but idiomatic Swift encourages using value types over reference types when possible. The chief reason to use a reference type is when you need shared ownership. Value types are not reference counted, though they may contain RC'd fields. Rust has reference counting implemented in a library (Rc and Arc), which is what Rust programmers reach for when they need shared ownership. Rust also has a 1-bit reference count called the drop flag, which is used to dynamically determine when an object's destructor should run.
  - pcwalton 10y ago
    The drop flag is not a reference count. It is an implementation detail, and we could eliminate it if we wanted to. Swift's value types are less flexible than those of Rust because of the need to maintain soundness in the presence of aliasing and mutation.
pcwalton 10y ago
Swift is GC'd and has a large runtime. (Reference counting is a form of garbage collection.) Rust is manually memory managed and effectively has no runtime. The languages are very different.
- winstonewert 10y ago
  "Rust is manually memory managed" Is it? As I understand it, memory is handled primarily by the ownership system, and sometimes by reference counting. That doesn't seem to be manual memory management to me.
  - spullara 10y ago
    It is basically implicit manual memory management. You make sure that your ownership is properly accounted for and it will then properly manage the memory they use. Unlike in GC languages, you pretty much have to understand everything about how your resources are managed, even in the API design phase.
    - winstonewert 10y ago
      Is reference counting not implicit manual memory management as well?
      - pcwalton 10y ago
        No! Reference counting is dynamic tracking of object lifetimes. If reference counting is implicit manual memory management, then so is tracing GC!
        winstonewert 10y ago
        Manual means "a thing operated or done by hand rather than automatically or electronically, in particular." It is very strange to me that you've decided the manual means: non-dynamic tracking of object lifetimes.
  - 10y ago
andrepd 10y ago
C or C++. One thing is how you want the world to be, another very different is how the world is. I want to live in a word where a nice language like rust or nim is the best choice for systems programing. But sadly, in our world, in 2016, the best choice is for many many reasons to go with a tried and tested tool like C or C++.
fsloth 10y ago
Otherwise I would suggest C++ but from what I gather it's really hard to learn to use it in a vacuum without triggering all sorts of footguns (i.e. unnecessary pain - speaking as a person who has written C++ for a decade). Rust's documentation looks really nice. Look at this page: https://doc.rust-lang.org/std/collections/ https://doc.rust-lang.org/std/collections/ Not only does it explain what the data structures do, it also contains pretty solid architectural guidelines on when it makes sense to use them. Also, Rust supports Windows (which is a high percentage of several markets), whereas Swift apparently, only unofficially (not an expert here, please correct me if I'm wrong). I really would not pick a language that does not run effortlessly on all three major home computing platforms at this day and age unless the constraints are really well understood.
JoshTriplett 10y ago
Rust is capable of lower-level programming than Swift; it's designed as a systems programming language capable of doing anything C can. It doesn't have a "runtime", and doesn't do any background processing like garbage collection, but still has automatic memory management, a fairly unique property among languages. If you specifically want to write iOS and OSX apps, especially GUI apps, that ecosystem and its libraries melds well with Swift. It's definitely more appealing than Objective C. Swift's ecosystem seems primarily focused there, even though Swift is capable of other uses. If you want to write cross-platform applications, services, systems, or libraries, try Rust.
bjz_ 10y ago
Swift abstracts away lots of memory management concerns by defaulting to thread-safe reference counting. Rust defaults to the stack and allows you to choose between a wide range of memory management options, and even build your own if necessary. Rust therefore gives you a great deal more room to move, and is much more flexible as a systems programming language. That said, Swift is a nice language, perhaps cleaner looking in syntax (although I prefer expression-oriented languages), and integrates nicely with the macOS/iOS ecosystems. I wouldn't say it's 'higher level' - Rust's upper bound on expressiveness is around the same - but it does hide away lots more of the minutia of thinking about how you manage memory.
- millstone 10y ago
  One way in which Swift is higher-level is in its support for dynamic constructs. For example, Swift allows you to dynamically check protocol conformance (e.g. in generics). I believe Rust does not allow this.
  - Manishearth 10y ago
    > Swift allows you to dynamically check protocol conformance (e.g. in generics) Could you explain more? Do you mean that Swift lets you arbitrarily downcast between protocol objects? I think Rust lets you do this too to some degree with Any. We generally stick to static bounds, though. I'd love to see if swift does something extra, and if it would be possible to add to Rust.
    - millstone 10y ago
      You can cast in any direction amongst protocol objects, concrete types, and generic types. You can also dynamically inspect the type itself (without needing an instance of it). For example, say we wish to write a function that builds an array from an arbitrary sequence. But as a fast path, if the sequence is already an array, just return it: func makeArray<T:SequenceType>(from values:T) -> [T.Generator.Element] { if let alreadyAnArray = values as? [T.Generator.Element] { return alreadyAnArray } else { return Array(values) } } or we can use a Golang-style technique to dispatch to a more specific protocol. See for example how debug descriptions are generated by checking conformance to a series of protocols in turn [1]: https://github.com/apple/swift/blob/1e2d192b61c9003d8b8a8593c2ef0fa6a524b8c0/stdlib/public/core/OutputStream.swift#L375 https://github.com/apple/swift/blob/1e2d192b61c9003d8b8a8593... My understanding is that this is more limited in Rust, though I'm not too familiar with how Any works - please correct if I'm wrong.
shams93 10y ago
It depends upon what you're interested in developing for. If you're a pure linux developer swift is not as exciting as rust. Just the fact that you need a bunch of Apple kit to fully enjoy it is a downer. WIth rust I can hack on my $35 pi3 box without having to go buy an ipad.
joshavant 10y ago
I've done a small amount of work for a Swift-based project that was packaged as CLI program. FWIW, it was a really difficult project to develop for. This mainly had to do with the fact that the project had to be built from a hacky Rakefile, not Xcode. This was because Xcode would embed the Swift runtime only into an .app or .ipa file (because projects need to be shipped with the same Swift version used to build it, thanks to lack of ABI stability). But, as a CLI tool, there was no .app bundle - only a single executable. One downfall. So, now that you're not using the Xcode IDE to build + run the project, you can't use the debugging IDE tooling in Xcode, making the development process that much harder. Another downfall. I haven't checked if this has been fixed in recent builds (this all happened back in January), but figure that these are the kind of issues you're going to encounter, until the Swift language is a little more stable + proper tooling evolves. That said, it seems pretty clear the future is Swift, so it would be better to start building experience with it sooner rather than later!
piotrjurkiewicz 10y ago
Neither.
broodbucket 10y ago
"you aren't going to write a key-value database, web server, or the next docker..." I don't consider any of those things to be "systems programming". Any language with a GC is utterly unsuitable for systems programming. If what you're actually looking for is somewhat performant application programming, then languages like Swift and Go become an option again.
chriskrycho 10y ago
Shameless plug that is directly related to the question: if you want a fairly detailed look at the two side by side, I've been comparing them as I work through learning both over the last 10 months. http://www.chriskrycho.com/rust-and-swift.html http://www.chriskrycho.com/rust-and-swift.html I think, because of the automatic reference counting, that your overall sense is roughly right—Swift is a little higher-level than Rust—but their overall ability to write many kinds of applications will be similar (Apple platform applications being the big exceptions for obvious reasons).
falcolas 10y ago
If you want to write systems programs, I'd probably focus on the programs you want to write first, and then pick out a language in which to write them - based on the features required and the community support you can gain. Sure, you may be capable of writing device drivers in Swift, but how much help are you going to get while doing so? How much help will you need? Will it be picked up and used by the community at large? Do any of those matter to you? Base your language choice off the project, not vice-versa. Remember, Docker was written in Go, zookeeper in Java, and Rails (a web server as well as a framework) in Ruby.

millstone 10y ago

Swift uses reference counting for reference types, but emphasizes value types. Rust supports reference counting for certain types, but emphasizes value types too. Also observe that Rust's drop flag is a form of (1-bit) reference counting. In this particular area, they are more similar than different.

Veedrac 10y ago
Rust's drop flag is quite different because it's local. Most pointers are not reference counted in Rust, whereas they are in Swift. Similar perhaps, but not that similar.
- millstone 10y ago
  Which pointers? Here's all the different pointers I know of in Rust, and their equivalents in Swift: Rc/Arc <-> class types Raw pointers <-> UnsafePointer/UnsafeMutablePointer References <-> inouts Trait objects <-> Protocol objects Box <-> indirect enum (arguably) Did I miss any? Of the core language features, protocol objects are the only case where Swift uses reference counting and Rust does not.
  - pcwalton 10y ago
    Swift doesn't have the borrow checker, which means that in order to ensure safety the expressiveness is really limited unless you use RC. That's why essentially all Swift code uses RC, and Rust code rarely does. There's a big difference between technically having manual memory management and having it actually widely used and practical.
    - millstone 10y ago
      Yes, RC is the primary way to safely manage lifetimes of reference types in Swift. You can drop down to unsafe constructs to avoid RC overhead, and I sometimes do that in hot loops. Using unsafe to improve performance is not unfamiliar in Rust either, though Rust gives you better tools for building safe abstractions around it. Shared ownership is routine in UI programming - think event handlers, etc. These are the apps most commonly written in Swift. Does Rust avoid needing shared ownership for these types of apps? If so, how?
pcwalton 10y ago
Rust's drop flag is totally unlike Swift's atomic heap reference counting. The drop flag is just an implementation detail that procedures sometimes use to determine whether to run the destructor. It is usually optimized away. It is quite feasible to program without drop flags if you really don't want them, though they never show up in profiles (unlike swift_retain). We could statically eliminate drop flags if we wanted to, via tail duplication. (But we don't, because the drop flags have effectively zero runtime overhead, unlike RC.)

winstonewert 10y ago

It is silly to equate drop flags with atomic reference counting on the heap. It would be sillier to define automatic memory management in terms of conditional releases, (as you seem to have done) and then insist that Rust's conditional releases don't really count. Clearly, it is not really the fact that the releases are conditional that makes the difference. What is your actual definition of automatic memory management? What, in your view, is the actual semantic difference between a language that has automatic memory management and one that does not?

Manishearth 10y ago
Swift cannot implement ARC without conditional releases. Rust can. What Rust effectively does is compile an if statement into something a tiny bit more complicated (two if statements, really), in certain conditions. It doesn't need to. The if statement uses function-local information known statically, so it could be compiled in a different way without the drop flag. Basically, the condition already existed, Rust just inserts another one instead of piggybacking on the one inserted by the programmer. ARC needs new conditionals everywhere, and whether or not something will be cleared is often not obvious without looking at the whole program, and even then it could be undecidable. I can't answer for Patrick, but I don't see the term "automatic memory management" as useful as distinction, I look at it more as a spectrum, and Rust/C++ fall squarely on the "more manual" end of that.
- winstonewert 10y ago
  "I can't answer for Patrick, but I don't see the term "automatic memory management" as useful as distinction, I look at it more as a spectrum, and Rust/C++ fall squarely on the "more manual" end of that." I agree 100%. My objection was to the assertion that Rust and Swift were completely different because Swift was garbage collected and Rust was not. That's just not a helpful way of looking at it, because in many ways Swift's strategy is closer to Rust's then Java's.
  - Manishearth 10y ago
    Right, which is why in my other comment I explained why the memory management strategies make them different, and make that difference important :) type system wise they are pretty comparable otherwise; As a Rustacean who is used to nice type systems, Swift's type system is a pleasure to work with.
  - winstonewert 10y ago
    Sure there are significant differences between Rust and Swift. But characterizing that as Swift = GC, Rust = No GC, as I was originally objecting to is a pretty terrible way of describing it.
    - Manishearth 10y ago
      Right, but the significant difference does lie in the memory management thing. GC/No GC is (a) correct, according to the academic definition, and (b) a decent approximation to the difference.

Manishearth 10y ago

Rust is more similar to C++, not Swift, here. The distinction is in the programmer model involved. With Swift and GCd languages, you do not know about when the deallocations will happen, because this requires analysis of the whole program and the executions. You program with this in mind. Since GC/ARC is the only way to share, you end up using it often. The compiler can prevent some of this, but not the majority, because there isn't enough annotation helping it. (There is this difference between Go and Java, too. Go is more explicit about sharing than Java, and needs annotations when you share things (* and &). Java does not. So while Java 8 is getting escape analysis, it can never be as good as what Go does or potentially can do because the compiler just doesn't know enough. Go also generally avoids sharing unless necessary, whereas in Java you will see things shared willy-nilly because the distinction only lies in the optimizer. These annotations aren't as fine grained as Rust -- they're at the same level as Swift, approximately, but I'm trying to give an example of the same annotation-drives-optimization-and-design thing at a different level.) With Rust and C++, you know just by looking at a function what will be deallocated and where. C++ has API designers implement drop flags anyway (in the form of nulling the internal pointer, or something) for all types with a move constructor. The model of dealing with data changes; you explicitly think about where data comes from and how to share it. The additional annotation of zero-cost borrows (instead of just saying "Share this ... somehow", which is what Go and Swift do) means that zero-cost borrows will always be zero-cost, and not only if the optimizer decides it knows enough to be able to help. Note that ARC is much much costlier than than pointer-sharing. Not directly because of the increments; but because dynamically allocating for every instance of sharing, and then accessing that allocation whenever you wish to do a read/write or bump the reference count; is horrible for cache performance. This can be assuaged with a tuned allocator, but is less efficient than the usually-to-the-stack borrowed references of Rust. I will point out that Swift satisfies the academic definition of garbage collection and Rust/C++ do not, but I don't think terminology is as important as understanding what's actually going on. Rust is "automatic", in a sense, agreed, but automatic memory management is a vague term that can mean anything.

winstonewert 10y ago
"I will point out that Swift satisfies the academic definition of garbage collection and Rust/C++ do not" What is this academic definition of garbage collection? I'm familiar with how the different models work. But I'm having trouble with a definition of garbage collection that excludes Rust while containing Swift.
- pcwalton 10y ago
  "Down for the Count", for example, surveys the approaches to GC in its introduction: https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-... Note that reference counting has been considered a form of GC since the 1960s.
- winstonewert 10y ago
  The question isn't whether reference counting is garbage collection. In the academic definition: it is. The question is whether Rust's approach which looks a lot like reference counting where most of the time the compiler knows the reference count at compile time, also qualifies as garbage collection.
  - Manishearth 10y ago
    It isn't, because in other languages with linear/affine types it isn't called as such. Nor is C++s unique_ptr. Or Cyclone, which has region types. Rust isn't exactly revolutionary in its core memory management ideas, these have been around for a while and have been inside other languages. Cyclone, for example, is basically Rust (memory management wise) but as a safe dialect of C and a different stance on mutation and other things. It is not considered a GCd language. Rust just puts all these ideas together nicely. The compiler doesn't actually keep track of a reference count, btw. Refcounting and linear types/ownership/borrowing lead to very different programming styles. In Rust's model you actually have to think about ownership and design your program with this in mind that as much as possible you want to use single ownership. Given that they have very different impacts on programming style, they are pretty different practically speaking. On the other hand in swift you deal with memory management much like in Java, though with a few more choices you can make. Go might be a more apt comparison as far as memory management, though swift is more fine grained than Go as well.