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.
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:
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.
Just religiously use mypy. (Gradual typing!)
And profiling, and when something is reallly slow, bring out the Cython.
And when something is still not fast enough, well ...
Release the Rustacean!
+ Static typing (extra safety, robust refactoring, code completion etc.)
+ Much much faster and less memory use
+ 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.
Instead you have the stable/nightly nonsense to deal with, like Clippy and Rocket only working on nightly for example.
Whats the difference?
$ cat main.go
package main
import "fmt"
func main() {
fmt.Println("Hello, world!")
}
$ go build
$ ldd scratch
not a dynamic executable
$ cat main.go
package main
import (
"log"
"net/http"
)
func main() {
// Simple static webserver:
log.Fatal(http.ListenAndServe(":8080", http.FileServer(http.Dir("/usr/share/doc"))))
}
$ go build
$ ldd scratch
linux-vdso.so.1 (0x00007fff161f0000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f796b0e8000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f796ad31000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f796b306000)
(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.)
It's a bit sad that this is still unsolved, probably due to the GNU people's hatred for closed-source distribution.
1. Refuse to do something properly because it will make it too easy... or something.
2. Wait until someone else gets fed up enough and makes a better version.
3. Fade into irrelevance.
See: GCC/Clang, glibc/musl, Bash/??? (someone please make something sane)
Think about your domain problem, don't worry about CS and perf
Use the REPL to "touch data with your own hands"
Rustlang:
Fast, fast, fast
Everything bundled inside a single binary that you can just ship - no dependency hell for your users
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.
Error detection, at least in VSCode is only displayed after compiling, that might be the plugin though.
That said, development time in Python is much faster.
Honestly, it depends on what you're building.
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.
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?
type Point(u32);
fn foo(p: Point) {...}
foo(0u32);
^^^^ expected Point, found u32(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.
Umm yeah, they've been a part of every ML-family language since the '70s, OCaml, Haskell and Rust included.
What I see from Rust is a lot of the really great things from functional languages (esp. strong typing) and beyond, but applying them to a language aiming as low as C. That's certainly interesting.
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.
[1] https://github.com/glium/glium#why-should-i-use-glium-instea...
The Servo project uses the type system to tie rust code into the spidermonkey garbage collector so it can't be misused[2].
[2] https://research.mozilla.org/2014/08/26/javascript-servos-on...
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.
[3] https://github.com/fitzgen/state_machine_future#example
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.
[4] https://rocket.rs/overview/
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.
This especially shines through if you have to use code someone else wrote.
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 differences are found in tooling, library ecosystems, development speed and runtime overhead.
That really isn't true in any practically meaningful sense. '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.
The moment you trot that out, you lose your 'but your analogy is terrible' privileges by default, however terrible my analogy is.
If you understand what it means, then you'd know that it means that all programming languages are comparable, from assembly to Haskell, in the sense they can all be used to do the same job. Therefore, requesting a comparison of the strengths and weaknesses of two programming languages is not a foolish request. The point of such a request is to find out where it makes sense to use a particular language. To give another example, let's say someone asks if it's a good idea to write a web server in assembly or in Go. It's certainly possible in either, but in order to explore what the best choice is then further discussion is required. Comparing a Dremel to a plasma cutter is an attempt to shut down this discussion, which doesn't help in furthering the knowledge of the participants.
I think this is where we strongly diverge and I resent, a bit, your implication that because I don't buy into this I somehow 'don't understand what it means'. I understand what it means. I just think it's plainly ridiculous.
You compared a Dremel to a plasma cutter as a way to explain the differences between Python and Rust, how is that any less ridiculous?
You're getting hung up on a minor detail. My main point was not about Turing completeness. My main point was that requesting a comparison of programming languages is a legitimate request. Turing completeness is just one angle by which to see this. As you seem to object to that suggestion, there are plenty of other ways to explain it.
For example, one way to compare languages is to look at the key libraries and frameworks that have been built up around them. So for example, Rocket vs Django, Diesel vs SQLAlchemy, etc... If we're comparing languages, we should compare what the languages makes it easy for us to do, and libraries are a big part of that.
Another way to look at this suggestion is that "writing performant code" is something that's easier in some languages than others, and the libraries built using those languages are likely to reflect that. However, performance is just one metric by which to compare languages/libraries/frameworks, which is another reason why these comparisons can help in building an understanding in when a language is likely to be the best one for the job.
Lastly, to make this as clear as possible, I'm not advocating for Python or for Rust, I am only advocating for language comparison as a helpful approach when building familiarity with programming language strengths and weaknesses. Both Python and Rust have niches they excel in, but there's also a large amount of overlap. As an example, game frameworks exist for both Python and Rust, and discussion can help others find what's best for them.
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.
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.
Actually you seem to suggest that not even performance is of any hindrance to python. In which case I'm lost for words. You win.
I didn't think I'd have to spell things out so excessively, but... let's extend the description then... Any Turing complete language where you can write files to storage. To give an example of why the storage is relevant, let's look at Java. Java's sandboxed in the JVM right? However, if you think about it more broadly, as long as you can freely write files to disk you can write machine code to disk. In other words, as you can write a compiler in Java, you can break out of the sandbox.
As for Minecraft, I don't know enough about it, but if it's possible to write a compiler in Minecraft then that would have the same escape hatch too. It might not be a tool you choose to code a BIOS, but we're not looking at whether something is optimal, we're looking at whether something is possible.
> "I see you keep refering to Turing completeness in other replies"
> "Actually you seem to suggest that not even performance is of any hindrance to python. In which case I'm lost for words. You win."
Perhaps you overlooked the following quote as it didn't fit with what you decided you wanted to say...
"I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option."
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.
https://blog.sentry.io/2016/10/19/fixing-python-performance-...
https://github.com/getsentry/milksnake/blob/master/README.md