Skip Navigation
Programming @programming.dev
Bluetreefrog @lemmy.world

What to learn next, Swift or Rust

I’ve been programming for decades, though usually for myself, not as a profession. My current go-to language is Python, but I’m thinking of learning either Swift (I’m currently on the Apple ecosystem), or Rust. Which one do you think will be the best in terms of machine learning support in a couple of years and how easy is it to build MacOS/ iOS apps on Rust?

54 comments

  • I think Python is still unmatched when it comes to ML, and nothing can beat Swift in terms of Apple ecosystem support. Why not learn both, though? I find Swift a bit harder to reason with than rust, but both have merit (and both have interesting use cases). Just see what uses you will find for them as you progress.

    • I was working on the assumption that it would make it harder to learn two at once. Maybe you are right though.

      • Honestly - now that you know one language learning any new language is a pretty simple task. For example - here's a hello world in the three languages:

         
            
# Python
print("Hello, World!")

// Swift
print("Hello, World!")

// Rust
fn main() {
    println!("Hello, World!");
}

        As you can see, the differences between Swift and Python are pretty minimal* and while rust adds a whole bunch of extra busywork (you need a function, you need an explanation point, you need a semicolon...) it's generally the same thing.

        (*) While that comparison of Python/Swift only differs in the comments, Swift is generally a much more complex language than Python, so you will need to learn a bunch of new concepts. For example if you needed to manually specify the output string encoding you'd write the Swift hello world like this:

         
            
let string = "Hello, World!"
if let data = string.data(using: .utf16) {
    print(data)
}

        There are some common Swift language patterns there that are rare in other languages:

        • if let will gracefully handle any errors that occur in the encoding step (there can't be any errors when you're using utf16 encoding, but if another encoding format was specified it might fail if, for example, you gave it an emoji.
        • Swift allows you to interleave part of your function names in between the function arguments. That's not a data() function, the function name is data(using:) and there are other function names that start with data() but accept totally different arguments, for example you might give it a URL and it would download the contents of the URL as the contents of the data.
        • the .utf16 syntax is also something I haven't seen elsewhere. The using parameter only accepts String.Encoding.something and you can shortcut that by only writing the .something part.

        For completeness, in python and rust you would do:

         
            
# python
string = "Hello, World!"
utf16_data = string.encode("utf-16")
print(utf16_data)

# rust
fn main() {
    let string = "Hello, World!";
    let utf16_data: Vec< u16 > = string.encode_utf16().collect();
    println!("{:?}", utf16_data);
}

        That's actually pretty good comparison of the three languages and an example of why I like Swift.

        The syntax in Rust is absurdly complicated for such a simple task. And while the Python code is very simple, it doesn't handle potential encoding errors as gracefully as Swift, and it also uses a string to specify the encoding, which opens up potential mistakes if you make a simple typo an also you'll have to do a Google search to check - is it "utf-16" or "utf16"? With Swift the correct encoding string will auto-complete and it will fail to compile if you make a mistake.

      • The tricky part isn’t the syntax, it's the domain knowledge. Well, actually it's syntax, too. Swift has a whole lot of things that aren’t like anything else with sprinkles of Objective-C. Rust turns the common patterns upside down because they make borrow checker sad. But, in the end, what makes you a good engineer is knowing how to apply the tool to solve the problem and that goes well beyond syntax.

        Programming languages are like different kinds of saws: all of them are made to cut things, but there are nuances. Some are replaceable, others can be used for one specific thing. Knowing how to operate a hacksaw gives you some idea how a chainsaw would work even though they are fundamentally different. But tinkle it this way: what are you trying to do? Answering that will tell you which saw you need to use.

  • @Bluetreefrog
    I, like you, code for myself not others and not professionally. Take a dive into Xcode and Swift if you're in the Apple world. It is just stupid easy to throw together an app or tool in no time at all.

  • Something to consider as well is learning both. Swift is certainly the best choice for making macOS/iOS GUIs. Other languages are probably better than Swift for your ML needs (could be rust, Python, etc.). However it’s totally possible to have an app using multiple languages. You could have the UI portion be in Swift, but the ML portions be in another language.

    At my company we have a Mac app with the GUI written in Swift, shared logic with our Windows app written in C++, and some libraries written in Rust. So it’s certainly possible.

    One caveat is that some languages don’t work with each other very well. Swift and Python do work well together iirc, so doing UI code in Swift and ML code in Python may not be a bad idea.

    If you want to just stick to Swift, Apple does have some ML frameworks for Swift that you can use. I don’t do any work with ML, so I have no idea if these frameworks are any good, or have good resources for learning.

    If you want to just stick with whatever language you use for ML, there are GUI libraries in nearly every language. These certainly won’t be as robust or as nice to work with as the native frameworks in Swift, but they could probably get the job done. I do know that a major issue with GUIs in Python is the difficulty in multi threading, which is a must for any app that performs long tasks without the UI freezing.

54 comments