When I use Python I miss Rust's enums, the pattern matching of those enums, and the static types that help refactoring (the compiler spots where one change has knock-on effects in the rest of the project..).
Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me.
I don't think Rust is better than Python for every task. Python is a lot simpler if you can get something done with its built in types (dicts, sets and lists). Python's dynamic types are also a great benefit for some tasks, where Rust's dynamic dispatch support is very limiting.
Crazily, handling dependencies and building a project is way easier in pure-Rust than pure-Python since it's standardized.
> Avoiding both these extremes, the Tathagata (the Perfect One) has realized the Middle Path; it gives vision, gives knowledge, and leads to calm, to insight, to enlightenment and to Nibbana.
> Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me.
In recent versions Python got some nice improvements in this area, with the new way of creating NamedTuples, Data Classes and the typing module. I wrote a stackoverflow answer recently that sums it up, if anyone is interested:
While there is overlap between problems that might be sanely solved using python and problems that might be sanely solved using rust, the languages target very different problems.
You could write parts of a network server or parts of an OS kernel in python. You could write nearly the entirety of it in rust.
I would say that you need not use rust if python works well for you, but rust is probably better than C for implementing libraries that might be called from python.
+ Compiles to a relatively standalone binary (not as good as Go though)
+ No Python 2/3 nonsense to deal with
- Much more complicated. You have to deal with lifetimes and borrowing and so on. It's really very difficult and we still don't know how to write some types of programs nicely (e.g. GUIs)
- Slow compilation times
- Can get pretty verbose and full of type boilerplate
Honestly if I was coming from Python I think I would switch to Go first. It is still way faster than Python, has a very nice "batteries included" standard library, static typing, very fast compilation and makes nice static binaries. The downside compared to Python is that it isn't very expressive at all - you'll find yourself writing out loops where you might have used a one-line list comprehension or something in Python.
We use glibc by default, so while Rust statically links all Rust code by default, that's still dynamically linked. You can use MUSL to remove that, where appropriate, but it's not the deafult.
To add an additional clarification here for others (I know Steve knows this :P), by default, at least on Linux, whether Go produces a dynamic executable or not depends on which things you import. For example, a simple hello world program will produce a static executable:
$ cat main.go
package main
import "fmt"
func main() {
fmt.Println("Hello, world!")
}
$ go build
$ ldd scratch
not a dynamic executable
But anything using the network, like a simple HTTP server, will cause the Go tool to build a dynamic executable:
Now of course, you can set flags to force Go to always produce a static executable, but the difference here isn't too much different with Rust. With Rust, you do need to install MUSL, add the target and then rebuild with an extra flag, but it's all very simple.
(To be clear, I am not criticizing Go here! There are good reasons why they link to libc by default when network stuff comes into the picture.)
The problem is that you have to think about it at all. If you compile on a machine with a new libc, and then try to run it on a machine with an old libc, it won't work. So you end up doing what most people do, even outside of Rust, which is take the oldest CentOS box you can stand and do builds on that.
The Autopackage project had a solution for this problem years ago called apbuild. It would search for the versions of glibc symbols and use the oldest possible ones, which resulted in portable binaries. With some quick googling I found the code here: https://github.com/DeaDBeeF-Player/deadbeef-plugin-builder/t... Probably doesn't work anymore though :/
It's a bit sad that this is still unsolved, probably due to the GNU people's hatred for closed-source distribution.
Rust can give you speed and safety in one package. But you sacrifice ease of coding, especially as the IDE ecosystem is not there yet in terms of ease of use.
I've taken a few apps from Python to C#/F# and seen speed increases around 50x. With Rust I could increase the speed from C#/F# by around a factor of 10x for string heavy applications processing large files. So the speed difference might be 500x between a Python and Rust application (depends HEAVILY on the problem you're solving though, a lot of the problems that can be vectorized easily work pretty fast in Python).
I'd say I'm faster at writing F# than at Python, because the type system helps me build more easily maintainable code, and the functional style is better for the way I think (I grew up with structural, learned OO in uni and thought most of it is bananas and more obfuscation than helping, and I'm happy the world is now slowly getting to something sensible again). It takes me a bit longer to write Rust programs though.
Cargo is the best build system of the 3 languages though, you can easily add crates (imports) and the build system handles everything, even unit testing. I gotta say on the project setup front Rust with Cargo is much better than any other language I know.
And I think once we get good IDEs with robust code completion and error detection, I can become quite fast at Rust as well.
RLS works just fine on my Linux box, error detection and completion and formatting. Debugging is so so, not very good.
But on my Mac box, it's always crashing.
For me it's a) crashing quite often on Windows and Linux and b) doesn't really autocomplete anything beyond really simple cases where I don't need it like "Vec::<String>::" will give me new. But on most things it's just really awful.
Error detection, at least in VSCode is only displayed after compiling, that might be the plugin though.
Just my favorite single reason: I love ownership. I love knowing what a function is going to do with the HashMap/dictionary I pass into it. I love knowing when I'm the only piece of code that can touch something. Sure, there are benefits in terms of not needing a GC too, but I just love how clear it makes everything.
Yeah, I vacillate between judging algebraic data types and ownership as the thing I like most about Rust over other languages (formerly Python, but I do much more JavaScript now), but I think ownership wins most of the time. Strong ownership protects from vast swathes of really annoying bugs that are unpleasantly easy to unknowingly inject and particularly hard to track down. Certainly I believe that Rust’s strong ownership model is the defining feature of the language—most of the language’s features come about as a consequence of it (though this dominance has slowly been diminishing since 1.0).
Rust is not safer than Python in Rust's own terminology. It takes more work than in C, but you can write memory bugs in Rust, by design. Python will catch those damn near every time, and if it doesn't you file a bug. Sure, there's less serious classes of bugs that Rust is likely to catch, but that's not really safety except in a definition loosened to near uselessness.
Unless you're talking about unsafe rust, that's wrong. And if you ARE talking about unsafe rust, well you can do the same in Python.
I do agree that python and rust are both "memory-safe" languages. I'm not sure about the other kind of safety rust provides though: thread-safety. That's really where Rust shines: you can write concurrent program and be statically guaranteed to have no data-races. I'm not sure how this transposes in python.
You can describe "safe" along different axes and python is not completely immune to memory issues. I guarantee that if you start using ctypes you'll manage it at some point.
I'm curious what parts of Rust you think are safer than Python.
Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
Immutability by default, exhaustiveness checks (make sure that you match over all variants of an enum or cover all valid values in an integer), return flow validation (did you forget a return somewhere? Is it the right type?), and, as you mentioned, type checking being mandatory, all libraries define their accepted types. Not only that, being types "cheap", it is customary to wrap base types in explicit types that won't be compiled:
type Point(u32);
fn foo(p: Point) {...}
foo(0u32);
^^^^ expected Point, found u32
When you work with the type system it checks a lot more than you check in Python. In Python you pass around untyped tuples and maps because defining classes won't gain you anything (and is surprisingly cumbersome and unpythonic), whereas in an ML-family language like Rust you use lightweight, fine-grained types to check that every function call is correct and you can refactor fearlessly.
(I'd recommend using a language with garbage collection unless you really need to not though; OCaml is quite Rust-like but means you won't have to worry about the borrow checker)
> I'd recommend using a language with garbage collection unless you really need to not though; OCaml is quite Rust-like but means you won't have to worry about the borrow checker
OTOH, Rust arguably has a better story for tooling (build system, dependency management, etc.), a more full-featured standard library, and better concurrency support. Depending on your priorities, some or all of these might be worth having to learn the borrow checker.
Well, O'Caml and Haskell predates Rust by decades. I was delighted to see Sum-Product types in Rust when I played with it. They go a long way to cleanly model the problem domain. Obviously you can simulate them, but it's much easier to get wrong or "cheat" (say having a bunch of fields, only some of which are valid depending on a tag).
the type-checking catches lots of memory errors (irrelevant in a GC language like Python, but wouldn't be caught by the compiler in C or C++), but it also catches data races when writing concurrent code, which is definitely something that could happen in Python.
> The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
It's this but designs in statically typed languages with more expressive type systems tend to push a lot of the logic into the type system so you can't use APIs incorrectly. This isn't exclusive to Rust but I do have a few examples:
The Glium OpenGL wrapper puts a lot of effort into moving errors to compile time. The overview[1] explains a bunch of them.
More abstractly, one of the more unique features of Rust's type system (linear types) is the ability to be sure a reference is destroyed. This makes Rust particularly good at describing state machines that are compile-time checked. Using standard OOP terms, each state is a class and its methods are the valid transitions. You can't take an invalid transition because the method is missing. You can do this in any language, though it tends to be only done in statically typed languages and it's awkward in Python. What makes Rust unique is that calling the method will consume the instance so you can't accidentally make a transition twice. Trying to call the method again is a compile error. A concrete example of this is state_machine_future[3], which generates an asynchronous state machine using macros.
In a slightly different use of the type system, the Rocket framework has a concept called Request Guards that allow you to map from something in the Request to a parameter in the request handler function. The overview[4] has a simple example on the "Dynamic Params" tab that maps url pieces to a string and an int. This mapping, however, is extensible and you can map to anything. If your handler needs an AdminUser, you can have the request guard pull the user id off the request, connect to the db, retrieve the user, verify the user as an admin, and only enter the handler if all that is successful. This means you can move all the logic and error handling around this into a single place that can be reused just by putting an AdminUser parameter on a handler. I've seen this done with middleware in other frameworks but in Rocket it's on-demand per-handler. As a result, the handlers only have to implement the happy path, which keeps them more compact than I've seen in dynamic language frameworks.
So the general idea is to use the type system to help you use stuff right. As with anything, it's possible to overdo it and get crazy boilerplate heavy code where you have to convert/cast all over the place and unanticipated use cases can't be done but it tends to be helpful, particularly with autocomplete.
I pretty much can't stand to write python after learning and using Rust. The static type system in Rust is just so great, and easy to use once you get the hang of it.
This especially shines through if you have to use code someone else wrote.
I'm happy there are others seeing the benefits of strong static type systems (strong is important, the C type system which is rather weak in many instances is not as helpful).
I can't. But I can try to sell you Nim [0] as a compiled/faster addition to your Python, from my own experience of using it in last few months and coming from Python.
It uses significant whitespace and the syntax will surely look familiar to any Pythonista, and the entry barrier is much lower (i.e. learning curve is much shallower) than Rust.
Speed improvements I experienced are in the range of 10-100x, while the code doesn't look that much different than Python. I have solved Advent of Code in both Nim and Python in parallel [1] so you can compare the solutions/syntax yourself.
> "'The main difference is everything is different' is not a very strong counter-argument."
That wasn't my counter argument, and I can't work out what you misinterpreted about what I said to get that impression.
My point was, unlike a Dremel and a plasma cutter, Rust and Python can be used for the same tasks. As they're both Turing-complete, anything you write in one can be written in another. The differences I suggested were to highlight the relative strengths, or in other words how much work you'd need to put in to get the desired result.
To be clear, if you hadn't tried to dismiss the GP who requested information about how Python and Rust compared to each other, I wouldn't have replied.
If that's your impression, then I'd suggest Python is used for more than you're currently aware of. Here are two examples of Python being used for "low level stuff":
Nothing against Python (I'm using it) , but those solutions have huge performance impact comparing C/Rust on bare-metal. Interrupt handling, GPIO operations are orders of magnitude slower in python. Take such simple board and run basic bit-banged gpio PWM. You need "beefy" Cortex-M family to get similar performance that you can get with 8/16-uC with C. Nice for hacking stuff but I would't trust my AC conditioner firmware running months without power cycle on interpreted language :) C/Rust gives you static analysis of memory usage so you can predict sw memory usage. With Python VM single bug in it can shutdown your code or eat all heap. Maybe now maybe after six months running your code. Nice hacking tools thou.
> "those solutions have huge performance impact comparing C/Rust on bare-metal"
I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option.
> "You need "beefy" Cortex-M family to get similar performance that you can get with 8/16-uC with C."
In the case of MicroPython, people find it usable on platforms like the ESP8266, which is less powerful than a "beefy" Cortex-M. As before, I don't deny that there is a performance overhead compared to C, but it clearly has some traction in the embedded space.
If you understood what MyHDL is doing, you'd know that doesn't matter.
Furthermore, most Python implementations are built using C, including the canonical one (CPython). It is possible to have performant Python implementations without using C, if that's what you're getting at.
I would say types. I think types have been really a lot of help to me, coming from mostly dynamic languages. It forces you to think about your problem more than just throwing some code together. Another thing I enjoyed is easier concurrency. But apart from that, I feel like its a matter of choosing the right tool for the right task.
Instead of learning weird new stuff like rust or go, I find that c/c++ and python cover the entire range of problems you will ever need to solve. It takes a lot of time to start being productive in rust/go, and the benefits are vague. Instead I'd rather learn to use C++ and python better.
Learning weird new stuff can have a positive impact even though you don't end up using it as your workhorse though.
After coding in Rust for several weeks I went back to C++ for my day-to-day work since I'm still more productive with it and the code I produce has no safety/security implications. The knowledge gained in those few weeks of Rust readily translated into C++ skill improvements, even though I already considered myself a solid C++ programmer before. Being forced to think about ownership, borrowing, move semantics, etc. constantly gets you into a mindset that is very helpful also outside of Rust.
Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me.
I don't think Rust is better than Python for every task. Python is a lot simpler if you can get something done with its built in types (dicts, sets and lists). Python's dynamic types are also a great benefit for some tasks, where Rust's dynamic dispatch support is very limiting.
Crazily, handling dependencies and building a project is way easier in pure-Rust than pure-Python since it's standardized.