Live data from Hacker News

RustPython

rustpython.github.io

221–230 of 244 posts

Re: RustPython

#221

Earlier quoted context omitted.

Rust bindings into the OS packages aren't nearly as common as in C++, so that could be a saving point. With MUSL builds there can easily be no shared dependencies at all, and with glibc builds it would just be glibc and a couple friends.

Yes, C++ definitely tends to rely more on binary dependencies, shared objects. Rust will probably have to as well, once frameworks and libraries get to size and maturity that you want your OS vendor to take over responsibility (and compile time!). And note that even MUSL doesn't help create a package that works seamlessly on any Linux OS/release — maybe WASM will (or more accurately: WASI). But I think, the point GP…

Sorry I just saw this. Rust python is a python interpreter and you build it and all its dependencies when you build your application that embeds it. And a musl package is indeed a single binary. The only issue you could have is a breaking kernel api change or instruction set mismatch (avx on an old machine for instance). I've done from scratch docker containers that only have a single rust binary that work anywhere I've tried.

Re: RustPython

#222

Earlier quoted context omitted.

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.

Pypy supports numpy just fine.

Not really? It is hideously slow. They say that will get fixed when numpy finishes getting ported to the HPy interface, but for now my stuff runs faster in cpython. I could try using numpypy but they have deprecated it.

Re: RustPython

#223
post #134

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

I can't speak for rustpython, but you can partially evaluate dynamic languages in wasm with something like wizer https://github.com/bytecodealliance/wizer . So you can let the runtime do all the parsing and compiling ahead of time. We do this with javascript (quickjs). It does have a few downsides regarding memory size but it is pretty fast.

Yeah this is really interesting, could make this kind of approach viable.

Re: RustPython

#224
post #169

Earlier quoted context omitted.

This is a fairly good answer but on windows, there’s no python3, so that’s your first command being broken.

Right, on Windows the recipe needs a few alterations but is essentially the same. This should work: > py -3 -m venv --upgrade-deps my-virtual-environment > my-virtual-environment\Scripts\pip install whatever-third-party-package > my-virtual-environment\Scripts\python my-script.py This assumes that the Python launcher (py.exe) was installed when installing Python, which it is by default.

Py is not installed when you get it from windows store. Another gotcha to worry about.

The story about python on windows is a nightmare for new people for these reasons. And installing packages - while not as bad anymore - is a mixed bag due to fewer precompiled C extensions than on linux.

Paradoxically, microsoft have spent some effort on improving things. This has led to multiple incompatible choices which, effectively, has made the experience worse.

Re: RustPython

#225

I was curious about how slow (or fast) it is compared to cpython. On fibonacci.py rustpython about 11x slower than cpython. def fib(n): if n == 0 or n == 1: return 1 return fib(n-1) + fib(n-2) print(fib(35)) time python3 ~/code/fibs.py 14930352 ________________________________________________________ Executed in 1.18 secs fish external usr time 1.14 secs 180.00 micros 1.14 secs sys time 0.01 secs 616.00 micros 0.01 s…

Using the .__jit__() method in your rustpython version might get you a speedup (I assume they intend for this to be automatic eventually, and it's only explicit right now while the feature is under construction).

I tried jit as well but looks like recursive functions cannot be jitted yet :(

Re: RustPython

#226
post #169

Earlier quoted context omitted.

Right, on Windows the recipe needs a few alterations but is essentially the same. This should work: > py -3 -m venv --upgrade-deps my-virtual-environment > my-virtual-environment\Scripts\pip install whatever-third-party-package > my-virtual-environment\Scripts\python my-script.py This assumes that the Python launcher (py.exe) was installed when installing Python, which it is by default.

Py is not installed when you get it from windows store. Another gotcha to worry about. The story about python on windows is a nightmare for new people for these reasons. And installing packages - while not as bad anymore - is a mixed bag due to fewer precompiled C extensions than on linux. Paradoxically, microsoft have spent some effort on improving things. This has led to multiple incompatible choices which, effecti…

Sure. Add "Get the actual official Python from python.org, not whatever mess Microsoft has cooked up" as step 0.

If you do use Microsoft's Python distribution though, are you saying that it provides neither "python3" nor "py"? How do you use it then?

According to the docs[0] the Microsoft Store package should provide "python" and "python3" commands (effectively unsolving the problem solved by the Python launcher, I guess?) so either my original suggestion of "python3" or my subsequent suggestion of "py -3" should work, depending on which distribution was installed.

[0] https://docs.python.org/3.11/using/windows.html#the-microsof...

Re: RustPython

#227
post #169

Earlier quoted context omitted.

This is a fairly good answer but on windows, there’s no python3, so that’s your first command being broken.

Right, on Windows the recipe needs a few alterations but is essentially the same. This should work: > py -3 -m venv --upgrade-deps my-virtual-environment > my-virtual-environment\Scripts\pip install whatever-third-party-package > my-virtual-environment\Scripts\python my-script.py This assumes that the Python launcher (py.exe) was installed when installing Python, which it is by default.

See this is the problem. You're already several "ah yes and you need to"s deep.

Re: RustPython

#228
post #169

Earlier quoted context omitted.

Right, on Windows the recipe needs a few alterations but is essentially the same. This should work: > py -3 -m venv --upgrade-deps my-virtual-environment > my-virtual-environment\Scripts\pip install whatever-third-party-package > my-virtual-environment\Scripts\python my-script.py This assumes that the Python launcher (py.exe) was installed when installing Python, which it is by default.

See this is the problem. You're already several "ah yes and you need to"s deep.

Not really. It's the same 3-step process in both cases.

Re: RustPython

#230
post #152

Earlier quoted context omitted.

> > "it can be compiled to WebAssembly in order to run [..] in the browser." > and NodeJS Wait... what? Why?

So you can run NodeJS code in the browser, even though both are JS-based, NodeJS has a bunch of APIs that deal with things like file systems that the browser doesn't have. For example, imagine you have a lib that converts markdown to html, but the lib happens to write the files directly to the disk, hence it can't be used in the browser. If you compile the nodejs runtime to wasm with a WASI that maps the file system…

nah, this is about running wasm version of this inside nodejs.
Post reply on HN