Earlier quoted context omitted.
Well, with cython, either you write python compiled to C, and you won't match rust perf nor types, or you write c/c++ and bind it to python, and you won't match rust safetiness.
why would rust have better performance than cython? cython is as fast as C
Speed up your Python using Rust
11–20 of 102 posts
Re: Speed up your Python using Rust
#12Learn a language that compiles to native binaries and be better off for it.
For example: Go, Swift, D.
Re: Speed up your Python using Rust
#13> Having Rust installed (recommended way is https://www.rustup.rs/).
This essentially recommends unconditionally using the "curl | sh" anti-pattern.
Shouldn't they recommend instead e.g. "apt-get install rustc" for Debian users?
Since this doesn't make use of too recent Rust features, using Rust 1.14 of Debian/Stable should be fine, shouldn't it? Same of Fedora, etc.
Re: Speed up your Python using Rust
#14Speed up your python by not using python at all. Learn a language that compiles to native binaries and be better off for it. For example: Go, Swift, D.
Oh, and Python is perfectly fine for most things. If you like it, sticking with it and just speeding up the rare thing that needs that performance makes much more sense than switching language, especially if you already are well into a project.
Re: Speed up your Python using Rust
#15Re: Speed up your Python using Rust
#16Earlier quoted context omitted.
you should also quote "easier" ;) it's certainly easier once you sacrifice a goat to the compiler to stop insulting you and your mother. disclaimer: i love rust
Well it's better than your client insulting you and your mother because your software killed their goat by mistake.
Re: Speed up your Python using Rust
#17I like the article, but the following advice confused me, especially since this comes from RedHat i.e. Linux people: > Having Rust installed (recommended way is https://www.rustup.rs/ ). This essentially recommends unconditionally using the "curl | sh" anti-pattern. Shouldn't they recommend instead e.g. "apt-get install rustc" for Debian users? Since this doesn't make use of too recent Rust features, using Rust 1.14…
Re: Speed up your Python using Rust
#18Earlier quoted context omitted.
Cython is unsafe.
It's much easier to learn Cython once you know Python. That's the biggest selling point.
Re: Speed up your Python using Rust
#19I like the article, but the following advice confused me, especially since this comes from RedHat i.e. Linux people: > Having Rust installed (recommended way is https://www.rustup.rs/ ). This essentially recommends unconditionally using the "curl | sh" anti-pattern. Shouldn't they recommend instead e.g. "apt-get install rustc" for Debian users? Since this doesn't make use of too recent Rust features, using Rust 1.14…
The advantage of this method is that it will work on any linux distro (and even BSD, Darwin and mingw) and you'll get the latest stable version. I don't see the advantage of using potentially outdated OS packages for installing a compiler, it's not like it's a dependency for other packages.
It also makes it easy to manage the various components of the toolchain, for instance if you later want to crosscompile for an other target, use the nightly version etc...
Re: Speed up your Python using Rust
#20I like the article, but the following advice confused me, especially since this comes from RedHat i.e. Linux people: > Having Rust installed (recommended way is https://www.rustup.rs/ ). This essentially recommends unconditionally using the "curl | sh" anti-pattern. Shouldn't they recommend instead e.g. "apt-get install rustc" for Debian users? Since this doesn't make use of too recent Rust features, using Rust 1.14…
It's no harder than apt-get install, and sets the best practice early on so that someone doesn't get confused and have to switch later.
"curl | sh" is only an anti-pattern in the sense that you have to trust the source (and therefore "curl | sh" without https is bad). It gives exactly the same ability to execute arbitrary code on your machine as downloading an RPM/DEB does, or adding a vendor specific repo (e.g. Docker). Distro package repos probably have broader scrutiny of the contents of packages, but there are a lot of packages so how sure can you be?