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

231–240 of 244 posts

Re: RustPython

#231

Post by 0x457 »

kaanyalova wrote: post #202
estebank wrote: post #199

Earlier quoted context omitted.

Just wait until we get IronRust through a clr rustc backend :)

You don't need to wait https://github.com/FractalFir/rustc_codegen_clr

This is different. This is a backend for rustc that emits CLR instead of LLVM IR.

Iron* were full .NET implementation of those runtimes. It had things like using .Net (C#) types to implement Iron* types (e.g. implement ruby's Hash with C#'s Dictionary).

This is actually why none of these Iron* things took off: they were often slower than official implementations.

Re: RustPython

#232

Post by v3ss0n »

youknowone wrote: post #175
v3ss0n wrote: post #18

Earlier quoted context omitted.

PyPy is one of the most underrated python implementation. It just makes your pure python code 20x faster without needing to change anything ( if you don't have c++. Extension depends) We had used PyPy in production , especially on Real-time/ asynchronous web apis that doesn't need machine learning stack

If Python community and CPython developers were more open to PyPy, many things could be changed. A group of people talks about how good having a third-party interpreter in Python community while the whole Python eco-system is heavily relying on the old (maybe good-enough) Python C API. Whenever I meet a C API issue on RustPython project (yes, I contribute to RustPython), I think about PyPy, and check what's going on…

Core contributors still contributing regularly. Problem of PyPy was making decisions that's really bad for exposure - like having non GitHub repo because they love mercurial. I love mercurial too but to contribute to opensource have to use GitHub. Which they finally moved now. I hope PyPy will become popular again.

Re: RustPython

#233

Post by v3ss0n »

diath wrote: post #150
v3ss0n wrote: post #18

Earlier quoted context omitted.

PyPy is one of the most underrated python implementation. It just makes your pure python code 20x faster without needing to change anything ( if you don't have c++. Extension depends) We had used PyPy in production , especially on Real-time/ asynchronous web apis that doesn't need machine learning stack

When I wrote asset processing script for a video game in Python, the initial run time was 14 minutes, I was not happy with it because it made the CI times long as hell, so my next step was to rewrite it in C++ and try to sprinkle it with some SIMD magic to speed it up, but out of curiosity, I ran it through PyPy - that brought down the run time from 14 minutes to just 18 seconds (!), needless to say, I was happy enou…

News like this needs to promote. They asked user's to post that on their blog. Can you help posting it?

Re: RustPython

#234

Post by v3ss0n »

raverbashing wrote: post #63
v3ss0n wrote: post #18

Earlier quoted context omitted.

PyPy is one of the most underrated python implementation. It just makes your pure python code 20x faster without needing to change anything ( if you don't have c++. Extension depends) We had used PyPy in production , especially on Real-time/ asynchronous web apis that doesn't need machine learning stack

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

Well, PyPy was not really accepted by Guido and the PSF people. When we ask questions about PyPy to PSF people, they give unfavorable answers but some of those shows they didn't try much at all. So I don't know what kind of drama they have.

Re: RustPython

#235

Post by pletnes »

galangalalgol wrote: post #222
pletnes wrote: post #162

Earlier quoted context omitted.

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.

Ah, I was thinking about compatibility. Didn’t realize the performance was that bad? Thanks for the warning.

Re: RustPython

#236

Post by esrauch »

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 just opened Facebook.com and it took more then 10 seconds time to first content paint, and it isn't because of slow internet. I've worked on more than one FAANG external user facing site fixing stuff to get median initial page latency to be below 5 seconds, so I think your "this will take _seconds_" emphasis is kind of funny.

Internal business crud apps often take multiple seconds on every click. Even a minute for an employee to start an app that is then snappy would be acceptable for practically any internal business usecase if they can just leave the tab open, and there's no technology reason why python wasm interpreters would need to be that slow.

Re: RustPython

#238

Post by IshKebab »

ptx wrote: post #228
IshKebab wrote: post #227

Earlier quoted context omitted.

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.

You literally gave a different process on Windows to Linux.

Re: RustPython

#239

Post by IshKebab »

weberer wrote: post #133
mavamaarten wrote: post #36

Earlier quoted context omitted.

From a non-python dev perspective: I always struggle with dependencies and versions. I have a script in front of me that I want to run, and am often just frustratingly brute-forcing commands to make it work. Do I: python? python3? pip install? pip3 install? python pip install? python pip3 install? python3 pip install? python3 pip3 install? And then everyone mentions "oh just use venv" or "conda" or docker or... It ju…

Thankfully, most distros/OSs don't ship with Python 2 anymore, so `python` will just link to `python3`.

Nope. Debian doesn't ship a `python` at all, which I think is the sensible option.

You should universally use `python3`. Except on Windows the official distribution is bonkers and has no `python3.exe`. Probably the easiest solution is to install it from the Microsoft store instead which does.

Re: RustPython

#240

Post by ptx »

IshKebab wrote: post #238
ptx wrote: post #228

Earlier quoted context omitted.

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

You literally gave a different process on Windows to Linux.

It's the same process described with different syntax for different operating systems. It contains no "ah yes and you need to" and is not "deep". Here's a templated version of the same process, if you prefer, which works on both Windows and Linux:

1. [PATH TO YOUR PYTHON COMMAND IN WHATEVER PYTHON DISTRIBUTION YOU YOURSELF INSTALLED ON YOUR OS OF CHOICE] -m venv --upgrade-deps my-virtual-environment

2. [PATH TO PIP COMMAND INSIDE THE DIRECTORY CREATED BY THE FIRST COMMAND IN THE SYNTAX OF YOUR OS OF CHOICE] install whatever-third-party-package

3. [PATH TO PYTHON COMMAND INSIDE THE DIRECTORY CREATED BY THE FIRST COMMAND IN THE SYNTAX OF YOUR OS OF CHOICE] my-script.py

Post reply on HN