9 ms·

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

by talson 9y ago

walkingolof 9y ago
This may be a good start: http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/ http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/
michaelchisari 9y ago
Performance is quite a bit higher for rust. And it's a much safer language by design (and forces the programmer to be as such). That said, development time in Python is much faster. Honestly, it depends on what you're building.
- Etzos 9y ago
  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?
  - michaelchisari 9y ago
    That's a big one.
  - smaddox 9y ago
    Rust also enforces deep immutability by default, which makes resource sharing bugs much less common.
  - lmm 9y ago
    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)
    - FullyFunctional 9y ago
      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).
      - lmm 9y ago
        > 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. Umm yeah, they've been a part of every ML-family language since the '70s, OCaml, Haskell and Rust included.
        tome 9y ago
        (FullyFunctional seems to understand this, as far as I can tell)
        FullyFunctional 9y ago
        I do, but I wasn't aware that Rust was considered in the ML family (ML as Meta Language, like SML/NJ). I'm somewhat skeptical of that. 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.
    - saghm 9y ago
      > 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.
  - estebank 9y ago
    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
  - currymj 9y ago
    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.
  - grayrest 9y ago
    > 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. [1] https://github.com/glium/glium#why-should-i-use-glium-instead-of-raw-opengl-calls 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-only-garbage-collector/ 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 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/ 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.
- andrewflnr 9y ago
  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.
  - vvanders 9y ago
    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.
  - roblabla 9y ago
    > you can write memory bugs in Rust, by design 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.
aidenn0 9y ago
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.
- pas 9y ago
  Python is great, and getting better. 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!
smt88 9y ago
What do you use Python for?
IshKebab 9y ago
They really very different but... + 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.
- MrBuddyCasino 9y ago
  > Compiles to a relatively standalone binary (not as good as Go though) Whats the difference?
  - steveklabnik 9y ago
    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.
    - burntsushi 9y ago
      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: $ 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) 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.)
dorfsmay 9y ago
Python: 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
kzrdude 9y ago
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.
- Rotareti 9y ago
  > 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: https://stackoverflow.com/a/45426493/1612318 https://stackoverflow.com/a/45426493/1612318
  - sidlls 9y ago
    Those artifacts in Python don't really compare with what the parent laments. Rust's sum types are one of my top reasons for preferring the language.
  - whyever 9y ago
    There are not sum types though.
- akmittal 9y ago
  Go is good middle ground between simplicity and being fast/dynamic.
  - kod 9y ago
    Walk middle, sooner or later get the squish just like grape.
pvg 9y ago
That's a bit like asking someone to sell you on using a plasma cutter over a dremel tool. It can be done but it's not particularly useful or sensible.
- ZenoArrow 9y ago
  Everything you can write in Python you can write in Rust, and everything you can write in Rust you can write in Python. The main differences are found in tooling, library ecosystems, development speed and runtime overhead.
  - laxd 9y ago
    Python does'nt give you the low level control needed for.. low level stuff. And even if it can be implemented does'nt mean it will be fast enough.
    - ZenoArrow 9y ago
      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": https://micropython.org/ https://micropython.org/ http://www.myhdl.org/ http://www.myhdl.org/
      - sp0ck 9y ago
        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.
seanmcdirmid 9y ago
Python and Rust exist in very application domains, so I don’t think they are very interchangeable with each other. Now if you are writing C++ code...
shpongled 9y ago
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.
- carlmr 9y ago
  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).
fafhrd91 9y ago
you can always try rust in parallel with python code with libraries like pyo3
oconnor663 9y ago
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.
- chrismorgan 9y ago
  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).
todd_wanna_code 9y ago
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.
narimiran 9y ago
> Can someone sell me on using rust over python? 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. [0] https://nim-lang.org/ https://nim-lang.org/ [1] https://github.com/narimiran/AdventOfCode2017 https://github.com/narimiran/AdventOfCode2017
dingo_bat 9y ago
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.
- dthul 9y ago
  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.
- e12e 9y ago
  Hopefully the need for c/c++ will fade, and one will be able to use python and rust. https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html https://blog.sentry.io/2016/10/19/fixing-python-performance-... https://github.com/getsentry/milksnake/blob/master/README.md https://github.com/getsentry/milksnake/blob/master/README.md https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463 https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463
carlmr 9y ago
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.
- pjmlp 9y ago
  My Rust dream IDE would visually display lifetimes and how they relate to each other. :)
  - carlmr 9y ago
    That would be a really cool feature.
- qarioz 9y ago
  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.
  - carlmr 9y ago
    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.

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

by talson 9y ago

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

walkingolof 9y ago

This may be a good start: http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/ http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/

michaelchisari 9y ago

Performance is quite a bit higher for rust. And it's a much safer language by design (and forces the programmer to be as such). That said, development time in Python is much faster. Honestly, it depends on what you're building.

Etzos 9y ago
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?
- michaelchisari 9y ago
  That's a big one.
- smaddox 9y ago
  Rust also enforces deep immutability by default, which makes resource sharing bugs much less common.
- lmm 9y ago
  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)
  - FullyFunctional 9y ago
    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).
    - lmm 9y ago
      > 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. Umm yeah, they've been a part of every ML-family language since the '70s, OCaml, Haskell and Rust included.
      - tome 9y ago
        (FullyFunctional seems to understand this, as far as I can tell)
        FullyFunctional 9y ago
        I do, but I wasn't aware that Rust was considered in the ML family (ML as Meta Language, like SML/NJ). I'm somewhat skeptical of that. 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.
  - saghm 9y ago
    > 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.
- estebank 9y ago
  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
- currymj 9y ago
  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.
- grayrest 9y ago
  > 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. [1] https://github.com/glium/glium#why-should-i-use-glium-instead-of-raw-opengl-calls 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-only-garbage-collector/ 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 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/ 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.
andrewflnr 9y ago
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.
- vvanders 9y ago
  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.
- roblabla 9y ago
  > you can write memory bugs in Rust, by design 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.

aidenn0 9y ago

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.

pas 9y ago
Python is great, and getting better. 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!

smt88 9y ago

What do you use Python for?

IshKebab 9y ago

They really very different but... + 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.

MrBuddyCasino 9y ago
> Compiles to a relatively standalone binary (not as good as Go though) Whats the difference?
- steveklabnik 9y ago
  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.
  - burntsushi 9y ago
    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: $ 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) 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.)

dorfsmay 9y ago

Python: 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

kzrdude 9y ago

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.

Rotareti 9y ago
> 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: https://stackoverflow.com/a/45426493/1612318 https://stackoverflow.com/a/45426493/1612318
- sidlls 9y ago
  Those artifacts in Python don't really compare with what the parent laments. Rust's sum types are one of my top reasons for preferring the language.
- whyever 9y ago
  There are not sum types though.
akmittal 9y ago
Go is good middle ground between simplicity and being fast/dynamic.
- kod 9y ago
  Walk middle, sooner or later get the squish just like grape.

pvg 9y ago

That's a bit like asking someone to sell you on using a plasma cutter over a dremel tool. It can be done but it's not particularly useful or sensible.

ZenoArrow 9y ago
Everything you can write in Python you can write in Rust, and everything you can write in Rust you can write in Python. The main differences are found in tooling, library ecosystems, development speed and runtime overhead.
- laxd 9y ago
  Python does'nt give you the low level control needed for.. low level stuff. And even if it can be implemented does'nt mean it will be fast enough.
  - ZenoArrow 9y ago
    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": https://micropython.org/ https://micropython.org/ http://www.myhdl.org/ http://www.myhdl.org/
    - sp0ck 9y ago
      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.

seanmcdirmid 9y ago

Python and Rust exist in very application domains, so I don’t think they are very interchangeable with each other. Now if you are writing C++ code...

shpongled 9y ago

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.

carlmr 9y ago
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).

fafhrd91 9y ago

you can always try rust in parallel with python code with libraries like pyo3

oconnor663 9y ago

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.

chrismorgan 9y ago
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).

todd_wanna_code 9y ago

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.

narimiran 9y ago

> Can someone sell me on using rust over python? 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. [0] https://nim-lang.org/ https://nim-lang.org/ [1] https://github.com/narimiran/AdventOfCode2017 https://github.com/narimiran/AdventOfCode2017

dingo_bat 9y ago

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.

dthul 9y ago
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.
e12e 9y ago
Hopefully the need for c/c++ will fade, and one will be able to use python and rust. https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html https://blog.sentry.io/2016/10/19/fixing-python-performance-... https://github.com/getsentry/milksnake/blob/master/README.md https://github.com/getsentry/milksnake/blob/master/README.md https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463 https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463

carlmr 9y ago

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.

pjmlp 9y ago
My Rust dream IDE would visually display lifetimes and how they relate to each other. :)
- carlmr 9y ago
  That would be a really cool feature.
qarioz 9y ago
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.
- carlmr 9y ago
  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.