Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RustPython

rustpython.github.io

Post reply on HN
Print view View original

101–110 of 244 posts

Re: RustPython

#101

Post by aldanor »

amelius wrote: post #61
aldanor wrote: post #47

Earlier quoted context omitted.

Sometimes, Things just can't be Done with Python. E.g., you're parsing dozens terabytes of data, or need response time within a microsecond. So, you're left with a choice of C++, Rust (what else, C#, possibly Zig and a few other). Rust stops being a "puzzle" once you've written enough of it and you just know how to do things. It has one major disadvantage though - returning back to write in languages like C++/Python…

Turns out 99% of the time you don't need to parse terabytes or have μs-response times. Meaning you should be programming just about 99% of your time in Python. The Rust memory management puzzles are not really complicated. They just get in the way. > they don't have basic language tools like proper sum types or traits that get things done Sum types and traits are not getting things done.

> 99% of the time

99% of whose time? Where does this estimate come from?

Definitely not my case, and definitely not the case for lots of programmers I know and/or work with. Python has its own place (for example, in DS/ML) and while I use it myself on daily basis for what's it's best at, statements like "you should be programming just about 99% of your time in Python" make no sense at best.

And, note, it's not only about speed/performance; after writing lots of Rust (or even F#), it's hard to get back to Python because of missing expressiveness and basic language tooling.

Finally, speaking of Python (CPython in particular), part of why it's so attractive is all the fast binary extensions libraries written for it... in C++/Rust, not Python.

> Sum types and traits are not getting things done.

Disagreed, sum types are exactly what gets things done, regardless of language performance and other features. This kind of logic exists everywhere. That's why languages with proper (or even semi-proper) sum types like Rust, F# are a lot easier to express 'business logic' in. And e.g. that's exactly why serialization/deserialization can get so weird in Python where values can be of multiple types and you have to invent crutches to work around that, to simulate sum types in this way or another.

Re: RustPython

#103

Post by john-radio »

galangalalgol wrote: post #69
raverbashing wrote: post #63

Earlier quoted context omitted.

Absolutely It is really underrated. Maybe it's the extension issue, maybe it's something else or maybe it's the fact that it was born as an experimental platform more than anything But it should have been more popular

Python's use base is now dominated by ML and scientific in general isn't it? Both of those communities are relying on extensions completely. I am quite possibly biased as I haven't written any python that didn't use at least numpy.

If you do a job search for "Django", "flask" or "fastapi" you'll see that there are a lot of web dev jobs using it.

Re: RustPython

#104

Post by xpe »

_pdp_ wrote: post #98

RustyPython is more memorable and has a catchy flair; my $0.02

Rust y Python is what a Spanish speaker calls a project that uses both (:

Re: RustPython

#105

Post by DanielHB »

esrauch wrote: post #97
DanielHB wrote: post #89

> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard…

I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application. Large python codebases could take like a minute to start if loaded that way.

Once it does start then your arguments can make sense, but even so it would still make it impractical for most things.

Trust me, when the Javascript dev tells you something will be slow, it WILL be very slow

Re: RustPython

#106

Post by phkahler »

esrauch wrote: post #97
DanielHB wrote: post #89

> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard…

>> The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it.

Which means this whole thing is pointless from an end user point of view. The technology stack is getting very deep - Python, Rust interpreter, WASM, in a browser. I'd love to get back to running things on a toaster with no dependencies.

Re: RustPython

#107

Post by jug »

esrauch wrote: post #97
DanielHB wrote: post #89

> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard…

Sounds like a use case for simple Python rather than RustPython?

If you go full RustPython, surely looking to eek out performance must be a major reason to even go there rather than just script with CPython like it was 1999?

Re: RustPython

#108

Post by jsheard »

DanielHB wrote: post #105
esrauch wrote: post #97

Earlier quoted context omitted.

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard…

I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application. Large python codebases could take like a minute to start if loaded that way. Once it does start then your arguments can make sense, but even so it would still make it impractical for most things. Trust me, when the Javascript dev tells you something will be slo…

> I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application.

Indeed, the web demo takes about 5 seconds to cold-start on my beefy PC, between downloading the 22MB WASM blob and compiling it. It also grows the WASM heap to 160MB after running the simple Fibonacci example, and WASM heaps can't (yet) be shrunk, so the only way to reclaim any of that memory is to discard the whole instance and start over.

It's cool that it works, but not very practical.

Re: RustPython

#109

Post by antirez »

RantyDave wrote: post #28

Just putting my hand up to say that MicroPython is awesome (and runs on the RP2040). https://micropython.org

I agree. Incredible development environment for a huge number of MCUs. Super fast.

Re: RustPython

#110

Post by fluidcruft »

aldanor wrote: post #47
amelius wrote: post #21

Earlier quoted context omitted.

Python is a great language to Just Get Things Done™. Rust is great if you like puzzles and want to spend your precious time solving the same memory management riddle over and over again. You do get faster and often more robust code though, although in practice the difference is often not meaningful and the extra time invested doesn't pay off.

Sometimes, Things just can't be Done with Python. E.g., you're parsing dozens terabytes of data, or need response time within a microsecond. So, you're left with a choice of C++, Rust (what else, C#, possibly Zig and a few other). Rust stops being a "puzzle" once you've written enough of it and you just know how to do things. It has one major disadvantage though - returning back to write in languages like C++/Python…

I really, really get interested in rust sometimes and then I read comments like yours and remember the warnings about premature optimization and put it off again.
Post reply on HN