5 ms·

A quick question from a Rust noob: if I knew Python, why should I try Rust? What is in there that would make my life better? At first glance I see a lot of unim

by bitL 11y ago

A quick question from a Rust noob: if I knew Python, why should I try Rust? What is in there that would make my life better? At first glance I see a lot of unimportant syntactic sugar or concepts I am not sure would make my life any easier (ownership tracking vs garbage collection).

okasaki 11y ago
Rust has much better performance.
untothebreach 11y ago
As a current python & rust user, I can say that I picked up rust because I liked the idea of a systems language that could give me c-like performance, without having to use C. Rust seems, to me, like a combination of the best parts of python (traits as pseudo-duck-typing), haskell (type inference, functional concepts), and C(++) (speed, no GC). As @mitsuhiko says in the article, it is very easy to export symbols from a Rust library so that they can be used via CFFI, so the possibility of "dropping down to Rust" instead of "dropping down to C" is very attractive to me.
- Cyph0n 11y ago
  I have my eyes on Rust, mainly for no GC and its ownership system, and Nim for its clean, Python-like syntax but with C performance. I also have Julia in my mind for my next scientific computing (image processing, DSP) project.
  - untothebreach 11y ago
    I keep on messing around with Julia, but I never stick with it. I have nothing in particular against the language, but I don't do a lot of scientific computing, so my motivations to use it are not that great.
    - juliangregorian 11y ago
      I think Julia gets unfairly pigeonholed. It's got a great concurrency story, for example. I know what you mean though, it always seems to be the language I'll write my "next" project in.
    - Lofkin 11y ago
      Why can't it be used for general computing?
      - Fede_V 11y ago
        It can. However, Julia made a very strong push to target the scientific computing niche (very strong array support, ease of writing tight loops in native code, etc) - and such it has a very quickly growing ecosystem of high quality scientific packages. In comparison, Julia has relatively few web frameworks, GUI toolkits, etc..
      - untothebreach 11y ago
        Sure it can. But why would I pick it up over, say, rust? Rust gives me the productivity of a dynamic language, and the speed of a systems language. Julia gives the same. So, given similar pros/cons, the choice comes down to aethsetics, and Julia just didn't give me a compelling enough reason to switch.
  - the_mitsuhiko 11y ago
    The main problem with nim is that you can't really pair it with Python whereas you can have Rust and Python call each other if you want.
    - Siecje 11y ago
      Can you expand on why that is?
      - untothebreach 11y ago
        Just a guess, but it is probably because they each have their own GCs, and that makes it harder* to ensure that objects created in language A, from language B, haven't been collected when language B needs them again. * harder, but not impossible
      - the_mitsuhiko 11y ago
        Nim requires a runtime to operate. Figuring out how to safely share the runtime between different Python extensions requires the cooperation of all of those extensions. You probably also need to move all nim code into a thread.
    - chrisheller 11y ago
      Have you played around with Nimborg? That allows embedding Python in Nim fairly easily. https://github.com/micklat/NimBorg https://github.com/micklat/NimBorg I've been able to call into the Nim side from Python by treating the Nim code as C functions to call. That works, but it would be interesting to come up with a more Pythonic way of doing that.
joliv 11y ago
I actually came for the robust type system. Not sure if that falls into your "unimportant concepts" category, though :)
olavk 11y ago
I don't think you would ever have a project were you could choose between Rust and Python. Their domains are quite distinct. Rust is for performance critical applications where you cant afford garbage collection. You would choose Rust as an alternative to C or C++. Using Rust will certainly not make your life easier compared to Python. But you could use Rust on some projects where Python is not possible.
apendleton 11y ago
So there probably aren't many circumstances where you would be choosing between one and the other, but one reason you might want to keep your eye on Rust is for extension-writing. The traditional approach to dealing with stuff that needs to be fast in Python is to get it working in pure Python first, optimize as best you can, and if it's still not fast enough, profile to identify your hot loops and rewrite those bits in C as an extension. This is somewhat less necessary in the era of PyPy, but still a common way to think about things. To me, at least, Rust provides a compelling alternative to C in the Python+C combination. Coming from Python, writing C is pretty unergonomic; it's super-easy to shoot yourself in the foot and have your program die with an inexplicable segfault, which feels pretty alien for someone used to nice pretty stack traces. Rust promises to make that a lot more pleasant by being memory-safe, while still making good performance promises.

by bitL 11y ago

okasaki 11y ago

Rust has much better performance.

untothebreach 11y ago

As a current python & rust user, I can say that I picked up rust because I liked the idea of a systems language that could give me c-like performance, without having to use C. Rust seems, to me, like a combination of the best parts of python (traits as pseudo-duck-typing), haskell (type inference, functional concepts), and C(++) (speed, no GC). As @mitsuhiko says in the article, it is very easy to export symbols from a Rust library so that they can be used via CFFI, so the possibility of "dropping down to Rust" instead of "dropping down to C" is very attractive to me.

Cyph0n 11y ago
I have my eyes on Rust, mainly for no GC and its ownership system, and Nim for its clean, Python-like syntax but with C performance. I also have Julia in my mind for my next scientific computing (image processing, DSP) project.
- untothebreach 11y ago
  I keep on messing around with Julia, but I never stick with it. I have nothing in particular against the language, but I don't do a lot of scientific computing, so my motivations to use it are not that great.
  - juliangregorian 11y ago
    I think Julia gets unfairly pigeonholed. It's got a great concurrency story, for example. I know what you mean though, it always seems to be the language I'll write my "next" project in.
  - Lofkin 11y ago
    Why can't it be used for general computing?
    - Fede_V 11y ago
      It can. However, Julia made a very strong push to target the scientific computing niche (very strong array support, ease of writing tight loops in native code, etc) - and such it has a very quickly growing ecosystem of high quality scientific packages. In comparison, Julia has relatively few web frameworks, GUI toolkits, etc..
    - untothebreach 11y ago
      Sure it can. But why would I pick it up over, say, rust? Rust gives me the productivity of a dynamic language, and the speed of a systems language. Julia gives the same. So, given similar pros/cons, the choice comes down to aethsetics, and Julia just didn't give me a compelling enough reason to switch.
- the_mitsuhiko 11y ago
  The main problem with nim is that you can't really pair it with Python whereas you can have Rust and Python call each other if you want.
  - Siecje 11y ago
    Can you expand on why that is?
    - untothebreach 11y ago
      Just a guess, but it is probably because they each have their own GCs, and that makes it harder* to ensure that objects created in language A, from language B, haven't been collected when language B needs them again. * harder, but not impossible
    - the_mitsuhiko 11y ago
      Nim requires a runtime to operate. Figuring out how to safely share the runtime between different Python extensions requires the cooperation of all of those extensions. You probably also need to move all nim code into a thread.
  - chrisheller 11y ago
    Have you played around with Nimborg? That allows embedding Python in Nim fairly easily. https://github.com/micklat/NimBorg https://github.com/micklat/NimBorg I've been able to call into the Nim side from Python by treating the Nim code as C functions to call. That works, but it would be interesting to come up with a more Pythonic way of doing that.

joliv 11y ago

I actually came for the robust type system. Not sure if that falls into your "unimportant concepts" category, though :)

olavk 11y ago

I don't think you would ever have a project were you could choose between Rust and Python. Their domains are quite distinct. Rust is for performance critical applications where you cant afford garbage collection. You would choose Rust as an alternative to C or C++. Using Rust will certainly not make your life easier compared to Python. But you could use Rust on some projects where Python is not possible.

apendleton 11y ago

So there probably aren't many circumstances where you would be choosing between one and the other, but one reason you might want to keep your eye on Rust is for extension-writing. The traditional approach to dealing with stuff that needs to be fast in Python is to get it working in pure Python first, optimize as best you can, and if it's still not fast enough, profile to identify your hot loops and rewrite those bits in C as an extension. This is somewhat less necessary in the era of PyPy, but still a common way to think about things. To me, at least, Rust provides a compelling alternative to C in the Python+C combination. Coming from Python, writing C is pretty unergonomic; it's super-easy to shoot yourself in the foot and have your program die with an inexplicable segfault, which feels pretty alien for someone used to nice pretty stack traces. Rust promises to make that a lot more pleasant by being memory-safe, while still making good performance promises.