Live data from Hacker News

RustPython

rustpython.github.io

191–200 of 244 posts

Re: RustPython

#191

Earlier quoted context omitted.

Your project seems very cool, and good on you for it. 10 seconds is absurdly slow, though. That's like time to install Mathematica from a disk image level slow.

> 10 seconds is absurdly slow, though. I hate to say this, but have you used any $ModenWebApp with $HotJSFramework recently? I thank the gods when those pages load without a 5-10 second of fancy spinning animation. Really thought we would be in a better place by 2024 but nope.

I haven't used any such slow thing yet (am mostly a commandline world person).

Re: RustPython

#192

Earlier quoted context omitted.

Pretty much. Ecosystem brings most of the value than any programming language.

It's particular acute with Python. The language itself is poor - the value is in the massive ecosystem (particularly around ML). Compare this to say, Rust, where the safety guarantees are useful in their own right. There would be value in Rust even with zero packages, but I couldn't say the same for Python.

i'm incredibly suspicious of anyone who compares a language with a repl to one without.

as for your 3rd point about packages, just try this: `grep -l '#!.*python' /usr/bin/*` and then run that same command piped into `xargs grep import`. i.e. measure how many applications on your system are importing anything besides the builtins/standard libraries shipped in the base interpreter.

for extra fun, try porting the matches above to Rust and see how fun that is without `use clap`/`use structopt` and `use envlogger`. i think you've got the last point completely backward, not that i think it's a particularly important measure of a language anyway.

Re: RustPython

#193
post #97

> "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…

> essentially no performance requirements

In my experience this is very rarely actually true, even though people think it is.

Re: RustPython

#195
post #93

Earlier quoted context omitted.

there are JEP, JPype and PyJNIus these days...

Those are bridges to native CPython. There is also GraalPy ( https://github.com/oracle/graalpython ), which is a standalone implementation more similar to Jython. It seems already quite compatible with Python 3. I have tested the latest version graalpy-community-23.1.2 as a regular Python interpreter from the command line (i.e., not through a Java program). It was able to run my standard library-only Python scripts,…

wow oracle is really nervous about python and Microsoft's support for it, huh?

I just now learned about this project, thanks for pointing it out. I'll be curious how they go about shared data, especially shared str/String.

also I personally happen to depend on Windows support, I'll go popcorn on the future of this project...

Re: RustPython

#196

Earlier quoted context omitted.

> 10 seconds is absurdly slow, though. I hate to say this, but have you used any $ModenWebApp with $HotJSFramework recently? I thank the gods when those pages load without a 5-10 second of fancy spinning animation. Really thought we would be in a better place by 2024 but nope.

I haven't used any such slow thing yet (am mostly a commandline world person).

Don't work for a company where you need to turn in receipts or fill out info in crappy HR software? I mean, good for you and knowing the command line, but doing the less-fun, less-specialized parts of jobs usually involves regressing to the mean of what interfaces people know how to use.

Re: RustPython

#197
post #123

Earlier quoted context omitted.

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…

Pyodide (standard cPython in WebAssembly) loads surprisingly quickly. My https://lite.datasette.io application usually starts up in less than 10s - most of that is downloading about 10MB of WASM blobs, and 10MB isn't actually that big these days (many sites serve more than that in image headers). When I built Datasette Lite I did it as a research project, assuming it would be far too slow loading to be useful. I've s…

Curious - could these blobs be cached? I'm assuming they change only on upgrade?

Re: RustPython

#198
I’ve been going the other way, adding rust bindings for some performance-critical code, and calling it from Python. It’s worked wonders, speeding things up 20-30x in some places. This also has the benefit of compiling to WASM if I need to, so it’s a breeze to run my code in the browser.

Re: RustPython

#200

I think it's really cool that Python has a healthy third-party interpreter community. PyPy, IronPython, Jython, and now RustPython expand Python's accessibility. It's very cool to see how many people are working on this, and I wonder what kind of problems with CPython this has exposed also.

I wish IronPython ever gets over the Python 3.x hump. It's been "dead" for a while. Every now and then rumors that some developer has started up on it again, but never seems to get to a release state. To be fair, F# filled most of its niche after it "died" so it's not a need in any way, just a wish for nice things because there were a few years where IronPython was a very nice thing to have.

IronPython3 seems to be in pretty active development. Unfortunately, there are a lot of features that still need to be added.
Post reply on HN