12 ms·

RustPython

• blurbleblurble 3y ago
  Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.
  • avgcorrection 3y ago
    Why does it make you wince?
    • mavamaarten 3y ago
      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 just never ends or it never clearly explains what to do. And all I want to do is run a relatively simple script. Or course I would use a docker image to run a more complex app. But it's frustratingly hard to manage for people who don't use it often. I'm from a java/Kotlin world where things aren't perfect either. But at least dependencies are clearly defined, and the only thing you need is Gradle that updates itself through a wrapper script if needed and pulls all dependencies. And a JVM/JDK which is also configured/installed quite clearly in a specific location.
      • diarrhea 3y ago
        Yeah, it's definitely painful. Over the years, I've probably spent in excess of 100 hours on understanding pip, venv, PYTHONPATH, poetry/pdm, pipfile, pyenv, ... still barely understand how it all works together. https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/ might make life much simpler for single-script applications.
      • FergusArgyll 3y ago
        for simple scripts, this is the easiest and works. python3 -m venv venv source venv/bin/activate pip install whatever echo "source path/to/venv/bin/activate && python3 path/to/app.py" > myscript mv myscript /usr/local/bin and just use myscript. I use this for a lot of little scripts
        • bomewish 3y ago
          Why not just Path/to/venv/bin/python path/to/app.py? Neat trick though, gonna adopt it!
        • ctippett 3y ago
          I haven't tried this myself, but you could probably save yourself the wrapper script and execute your script directly by adding a shebang pointing to the Python executable from your virtual environment. printf '%s\n%s\n' "#!path/to/venv/bin/python3" "$(cat path/to/app.py)" > /usr/local/bin/myscript
      • cultofmetatron 3y ago
        I feel you. python itself has its warts but its mostly minor. The dependancy hell though.. god damn it confuses me every time. I don't understand why they can't get it together with one consistent dependency system with good ergonomics. ruby does it with gem. elixir handles things reasonably well with mix. rust does it REALLY well with cargo. hell even ocaml has opam. but python? it between conda, pip, pip3, virtualenv and who knows what else. its hard to make something that I knwo will just work on everything.
        • odyssey7 3y ago
          To highlight another dynamically typed, interpreted language ecosystem, npm has been providing a remarkably smooth and uniformly adopted service for the JavaScript community.
      • VagabundoP 3y ago
        Rye[1] is an all in one manager for python projects. Including the python versions and virtualenv, pip etc etc... It separates tool deps from app deps. Its all configured through a pyproject.toml config file. Its still new but works well. I'm transitioning to it from an unholy mess of pyenv, pip installs and other manual hacks. If you're starting a new python project that is more than just a straightforward script I'd use Rye from the get go. [1]https://rye-up.com/ https://rye-up.com/
      • ptx 3y ago
        Part of the problem is that this used to require third-party tools, which gave rise to lots of different tools, but nowadays everything you need is included in Python itself. The simplest way (in the sense of having the fewest components required) is this, using only built-in tools: $ python3 -m venv --upgrade-deps my-virtual-environment $ my-virtual-environment/bin/pip install whatever-third-party-package $ my-virtual-environment/bin/python3 my-script.py This creates an isolated virtual environment in "my-virtual-environment". Use the pip and python3 binaries inside that directory to install packages and run scripts. Done. (The "activate" step suggested in other comments is just a convenience for setting your PATH to refer to the virtual environment implicitly, so that's completely optional.) Note that Debian's python3 package leaves out some parts of the standard Python distribution, but you can install the python3-full package for a complete installation.
        • pletnes 3y ago
          This is a fairly good answer but on windows, there’s no python3, so that’s your first command being broken.
          • ptx 3y ago
            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.
            • IshKebab 3y ago
              See this is the problem. You're already several "ah yes and you need to"s deep.
              • ptx 3y ago
                Not really. It's the same 3-step process in both cases.
      • weberer 3y ago
        Thankfully, most distros/OSs don't ship with Python 2 anymore, so `python` will just link to `python3`.
        • IshKebab 3y ago
          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.
      • klibertp 3y ago
        You seriously consider Gradle - a kitchen sink and a monstrosity scripted in obscure, extremely dynamic language - a better solution just because it has a... wrapper script?! With Gradle, where do you define dependencies? All with version numbers in the `dependencies` block? In a separate file, declaring a hash map of versions and then a hash map of dependencies, and then putting the latter into `ext`, which magically propagates to just about everywhere in the build silently? In a separate file using some plugin that tries to replicate the lockfile functionality baked into most other dependency systems? In a separate TOML file, using the Catalog? ...and that's just about dependencies, I could go on for days about other Gradle features... It's not any better than Python. You're just used to it. The same complexity is there in both Python and Kotlin, you just learned to cope with one better than the other. (Gradle with Kotlin DSL and good IDE support is a little better, mostly because Kotlin devs are not as afraid of touching the build as when it's done in Groovy. It's still 2 orders of magnitude more complex than whatever you use for Python - unless you use zc.buildout or something like that.)
    • postepowanieadm 3y ago
      Installing python software is hard. Golang is much easier for and end user.
      • vundercind 3y ago
        Go is what I reach for when I might otherwise write Python but need to actually, like, distribute my program.
    • lumb63 3y ago
      Personally, I wince at Python because, while I view it as a quick-and-dirty scripting language, some people write production code in Python. And here we are ten years later, stuck with code that reads a few metrics from the system, packages them into JSON, and sends them to an API for monitoring. The code takes 7 seconds at 100% CPU to resolve the imports, every time it runs.
      • wasmitnetzen 3y ago
        You can write bad code in any language, I fail to see how that's Python's problem.
  • berkes 3y ago
    I was recently looking for some ways to make a rust project dynamically configurable. Yaml/toml/etc are too static or are terrible to describe logic in (yet we do it all the time for CI, infra etc, ugh). WASM would be an option, but overengineered for my case. Ruby (through Artichoke), or Python (through RustPython); but they come with the downside of introducing Ruby or Python. I haven't decided yet, but would prefer Lua for it's simplicity. Or JavaScript (a subset) for how easy it can be limited in scope. Are there any (example) rust programs out there that have embedded scripting, or runtime plugins or addons in a scripting language?
    • ddorian43 3y ago
      why not lua?
      • berkes 3y ago
        No particular reason. edit: to be clear, I did mention "I would prefer lua for it's simplicity". I'm exploring all the existing work out there. Lua is certainly an option. From what I can see on the outside, is that lua embedding for rust is immature compared to some other solutions. But maybe that's because the lua-folks are just more honest :)
    • leoedin 3y ago
      There's Rhai - https://rhai.rs/ https://rhai.rs/
    • shzhdbi09gv8ioi 3y ago
      There's a bunch of scripting languages written in rust that targets "embed-in-rust", for example https://crates.io/crates/rhai https://crates.io/crates/rhai https://crates.io/crates/dyon https://crates.io/crates/dyon https://crates.io/crates/duckscript https://crates.io/crates/duckscript You can use the above links to browse crate "dependents", that is other crates using these dependencies if you are looking for example usage.
    • tveita 3y ago
      Your requirements are very close to Starklark - an embeddable programming language intended for configuration with an available Rust implementation. https://docs.rs/crate/starlark/latest https://docs.rs/crate/starlark/latest
  • repelsteeltje 3y ago
    Working on a significant C++ code base (shipped as deb, rpm and windows binaries) and wanting to allow some means to customize busyness logic we decided to integrate Python hooks, a couple of years ago. In hindsight, I'd call that decision a mixed blessing. The code level integration (pybind11) was nice and easy, the issues came later. We found operational problems (multithreading), performance (in particular initialization) and worst: memory leaks and crashes on python VM teardown. Another problem was that python has it's own particular ideas about package management than generally don't rhyme with packages from the OS vendor. I'm not sure what the angle is in this project, but I don't see a happy ending for projects that rely on both pip and cargo when it comes to maintenance and long-term support except for source-level integration. That is, unless there is some well designed and well thought out strategy to combine Rust and Python worlds that doesn't conflict with the RPM or apt view of doing things.
    • galangalalgol 3y ago
      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.
      • pipo234 3y ago
        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 is making is more about the dependencies Python ads to your C++ (or Rust). Ie.: build RustPython project to produce artifact that works on my machine, but relies on my python interpreter, my (which may have C dependencies) as well as a rust edition and cargo. How can I bundle this into a package for a different Linux? Preferably do it following the existing packages and lore of that distro, rather some python and some rustup version?
  • reedf1 3y ago
    I think it's very naive for a programming language to make you "wince", tools are tools.
    • wayvey 3y ago
      Agree, would like to know more context
      • spacecadet 3y ago
        Because you have all the power to change the tool or invent a new one.
    • blurbleblurble 3y ago
      Have you ever used pip?
    • amelius 3y ago
      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.
      • aldanor 3y ago
        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 makes you cringe because they don't have basic language tools like proper sum types or traits that get things done.
        • amelius 3y ago
          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.
  • deleted 3y ago
    [deleted]
  • saltwatercowboy 3y ago
    > That said, python makes me wince. O lord of the compiler, lend us thine wisdom.
• martijnarts 3y ago
  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.
  • brnt 3y ago
    I wonder if anyone actually uses those third-party interpreters for anything serious. I've never come across anyone that did.
    • copx 3y ago
      The infamous MMO game EVE uses Stackless Python.. and the players certainly seem to take it very seriously.
      • dagurp 3y ago
        why infamous?
        • jaymzcampbell 3y ago
          I think it might be in reference to the semi-frequent heists that happen, that have real monetary value behind them. EVE players seem to be a special breed. Some of the stories are pretty incredible. - https://www.pcgamer.com/inside-the-biggest-heist-in-eve-online-history/ https://www.pcgamer.com/inside-the-biggest-heist-in-eve-onli... - https://www.mmorpg.com/news/an-eve-online-player-has-pulled-off-a-major-heist-in-one-of-mmos-most-powerful-alliances-2000129491 https://www.mmorpg.com/news/an-eve-online-player-has-pulled-... - https://www.escapistmagazine.com/the-infamous-eve-online-bank-heist-the-stuff-of-legends/ https://www.escapistmagazine.com/the-infamous-eve-online-ban...
    • gkbrk 3y ago
      At least PyPy sees real production use.
    • 3y ago
• curt15 3y ago
  How do extensions work with interpreters written other languages? Does the interpreter still expose a C API?
  • ptspts 3y ago
    PyPy exposes a subset of the CPython C API, which is good enough for many C extensions, and some others can be ported with little effort. Most other Python implementations don't provide any way to use CPython C extensions. There is also the HPy API and ABI, which some C extensions target and multiple Python implementations can compile or load.
    • galangalalgol 3y ago
      There is a merge request up to add autogen rust bindings to hpy https://github.com/hpyproject/hpy/pull/457 https://github.com/hpyproject/hpy/pull/457
  • wokwokwok 3y ago
    No. …and this one is no exception -> https://github.com/RustPython/RustPython/issues/1940 https://github.com/RustPython/RustPython/issues/1940 Packages that rely on c dependencies like numpy, etc. only work if you write a custom implementation by hand; the “normal” package flat out doesn’t (and cannot) work. So basically you get no packages that use native extensions, unless the project explicitly implements support for them. Pypy is the only implementation I’m aware of that has implemented a c api that is mostly compatible (see https://doc.pypy.org/en/latest/faq.html#do-c-extension-modules-work-with-pypy https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...) For eg. Python running in a .net host or a Java host… I think this kind of compatibility would just be flat out impossible. For rust… hm… probably possible. For wasm? Definitely not.
    • nickpsecurity 3y ago
      Would there be a way to write a bridge between the Rust interpreters and C API where calls to existing extension API could work to/from the Rust interpreter?
• iAkashPaul 3y ago
  Wonder how difficult it would be to write something akin to PyO3 but with python syntax for writing rust programs, just like a subset
• gary_0 3y ago
  Does it allow sandboxing, or is Lua still the only good option for that? There are so many cases where you'd rather not give extension scripts unlimited access to the OS and file system, you'd think this option would be more common...
  • eptcyka 3y ago
    Depending on if it supports the various CPython APIs, it'd be non-trivial to sandbox it. On the other hand, if it doesn't expose a CPython API, is it really python?
    • galangalalgol 3y ago
      The CPython API is the main source of overhead in FFI. It is why using numpy to multiply lots of small matricies is so much slower than one large one. This has prompted people to support the simpler and faster HPy API. https://docs.hpyproject.org/en/latest/overview.html https://docs.hpyproject.org/en/latest/overview.html
  • SkiFire13 3y ago
    Note that Lua is not sandboxed by default. You need to thinker a bit with it or use Luau to actually make it sandboxed.
• RantyDave 3y ago
  Just putting my hand up to say that MicroPython is awesome (and runs on the RP2040). https://micropython.org https://micropython.org
  • antirez 3y ago
    I agree. Incredible development environment for a huge number of MCUs. Super fast.
    • imhoguy 3y ago
      Being able to run REPL session directly on MCUs and interact with the hardware live with short development loop is such a great idea.
    • rch 3y ago
      Your examples in particular have been excellent lately.
      • antirez 3y ago
        Appreciated.
        • thegabriele 3y ago
          A quali esempi si riferisce?
  • westbywest 3y ago
    At a previous job I was checking out MicroPython due to its support on LEON4 RAD-hardened CPUs like GR740. It was appealing as a possible design path from proof-of-concept implementations with desktop python/numpy (etc) to space-certified platforms, ideally reducing the quantity of code to reimplement in C. https://essr.esa.int/project/micropython-for-leon-pre-qualified-version https://essr.esa.int/project/micropython-for-leon-pre-qualif...
• tracker1 3y ago
  I'm curious how large the WASM target is. One of the things that turned me off of C#'s Blazor WASM was the payload size. I've found some of Rust's offerings like yew and leptos more interesting.
  • c0balt 3y ago
    It's okay-ish in size, ~10 MB, I made a small playground with an older version a while back: https://playground.cobalt.rocks/interactive https://playground.cobalt.rocks/interactive
• coldtea 3y ago
  Last blog entry being from "Dec 1, 2021" doesn't make it sound like there's much action.
  • ergonaught 3y ago
    The GitHub repo is more relevant for “action”, no?
  • wraptile 3y ago
    Last release (0.3.0) was on 2023-09 and last commit was 2 weeks ago
  • nicce 3y ago
    Contribution graph seems pretty good https://github.com/RustPython/RustPython/graphs/contributors https://github.com/RustPython/RustPython/graphs/contributors
    • leadingthenet 3y ago
      Does seem to have died down since June of last year.
  • youknowone 3y ago
    Our team tends to drilling on code more than writing. I know it is not a strategic good way though. Any idea what do you expect to see on the blog?
    • swyx 3y ago
      talk about fun technical challenges and "things you wish you had known". endless appetite for that stuff
• Twixes 3y ago
  That's cool, but now for REAL bare-metal performance someone should rewrite Python in an even lower-level language. That's right, Python written in C is gonna be hella fast! Oh, wait…
  • nicce 3y ago
    Rust can be even faster that C on some cases, so not self-explanatory. Rust compiler can sometimes make better performance optimizations because there are more guarantees that code works as it is supposed to. You can bypass these with C of course, but you need more manual (and less secure) operations.
    • tialaramex 3y ago
      Also as with C++ having a more expressive language means that while you could have done it in C in practice you won't because it sucks to do all this extra labour, whereas in Rust it's fine because the machine did all the hard work. Monomorphization is an example where that happens, in C if we're sorting and de-duplicating Geese, Customers and BugReports, we're either writing three separate functions dedup_geese, dedup_customers and dedup_bug_reports, or we're using function pointers and we incur the function call overhead when our functions get called. Ouch. In Rust (or C++) the monomorphization step is going to turn sort & dedup for Geese, Customers and BugReports into separate functions†, and yet we only wrote the code once. To some extent you can try to mimic this in C via the "X macro" strategy, but now you're not even just writing C any more, you're writing the macros and maybe running them through pre-processing and trying to understand if the result does what you meant, it's a pretty horrible way to work, so again you're discouraged from doing it. † However the compiler may spot that actually the machine code implementation for say, BugReport and Goose is identical and so it only emits one in the eventual binary with the other just aliased - which may confuse a debugger and thus a human trying to debug it.
  • galangalalgol 3y ago
    Yeah, how crazy is it that a python interpreter written in python is so much faster than the one written in C? My guess is that it is constrained by not breaking the api, where pypy did break it, and that is probably why pypy hasn't gotten more use. That makes me think any python interpreter that fully supports the cpython api will be slow.
• deleted 3y ago
  [deleted]
• Sovann102 3y ago
  [flagged]
• syrusakbary 3y ago
  Happy to see RustPython making awesome progress! Note: I just realized that they mention wapm in their homepage. We phased out the WAPM CLI in favor of Wasmer (https://wasmer.io https://wasmer.io), so you can simply run in your shell: wasmer run rustpython Or, if you want to try it using the Wasmer JS SDK: import { Wasmer } from "@wasmer/sdk"; let rustpython = Wasmer.fromRegistry("rustpython"); let instance = await rustpython.entrypoint.run({ args: "-c \"print(1)\"" }); let output = await instance.wait(); Will send a PR soon it can be updated!
  • deleted 3y ago
    [deleted]
  • jedahan 3y ago
    Probably worth a mention this is the creator of wasmer, for anyone interested. (I was curious who 'We' was to see what companies have experience with multiple wasm runtimes and their learnings)
• rrr_oh_man 3y ago
  For a dum dum like me who only dabbles in programming: What would be a use case for this?
  • benrutter 3y ago
    A big use case is Rust's web assembly support. There are lots of people who'd probably want to run python in the browser, but doing that at the moment is a little shaky. RustPython is maybe a good route for doing this (they give this in "reasons to use" but I can't say I've tried it)
• Kayodedcreative 3y ago
  [flagged]
• sylware 3y ago
  python is already written in plain and simple C, it is sad to make it depends on such complex language which is rust (no less worse than c++). Actually, I would not mind a python interpreter in rv64 assembly (near 0 SDK) instead.
• jjtheblunt 3y ago
  > RustPython is in a development phase and should not be used in production or a fault intolerant setting. Our current build supports only about half of the Python standard library.
• Hamuko 3y ago
  >RustPython can be embedded into Rust programs to use Python as a scripting language for your application How big are my binaries going to be if I embed a whole Python interpreter in it?
  • jffry 3y ago
    Hello world in pure Rust: 400832 bytes Hello world w/ rustpython interpreting Python[1]: 15459264 bytes (Rust 1.75.0; rustpython 0.3.0; MacOS / Apple Silicon) [1] https://github.com/RustPython/RustPython/blob/main/examples/hello_embed.rs https://github.com/RustPython/RustPython/blob/main/examples/...
    • Hamuko 3y ago
      Huh, that seems extremely reasonable even if it's not a finished product yet.
• DanielHB 3y ago
  > "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 happening (once by the wasm runtime to compile the rust-python wasm and again by the rust-python code compiling your python code). And this is on top of normal performance degradation from using a dynamically typed language compared to a statically typed language To make dynamic languages (even JS) viable to run in a wasm runtime, the language must be compiled directly to wasm. Project still looks pretty cool and useful though, there is plenty of python code that could be useful to use in the browser no matter how badly it runs. Just don't try to build a web framework on top of this kind of approach. Edit: Let me reframe this a bit, this is what I think, I haven't really benchmarked anything and rust python might be doing some tricks I am not aware of.
  • esrauch 3y ago
    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 way special cases" byzantine business code to something that can run on a web server and be accessed by the companies employees rather than passing around scripts for them to run, with a lot of benefits including instant upgrades for everyone for bug fixes. That said, this specific impl claims to only support half of the standard library so I kinda doubt its ready for any 'serious' business usecases yet anyway.
    • DanielHB 3y ago
      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
• _pdp_ 3y ago
  RustyPython is more memorable and has a catchy flair; my $0.02
  • xpe 3y ago
    Rust y Python is what a Spanish speaker calls a project that uses both (:
  • greenie_beans 3y ago
    RustyPy
• amelius 3y ago
  Cool. Can I use NumPy, SciPy, PyTorch, Shapely, ...?
• sakesun 3y ago
  I thought RustPython is what Ironpython become after being abandoned for a while.
  • Induane 3y ago
    I feel smart because I got your very funny joke. Silliness aside, I actually had almost the same thought when I was reading the post lol. Great minds think for themselves so I guess maybe we're only really good minds then. Ahh well....
  • paulddraper 3y ago
    Ha ha. For those interested, Iron* is .NET. IronPython IronRuby IronJS
    • estebank 3y ago
      Just wait until we get IronRust through a clr rustc backend :)
      • kaanyalova 3y ago
        You don't need to wait https://github.com/FractalFir/rustc_codegen_clr https://github.com/FractalFir/rustc_codegen_clr
        • 0x457 3y ago
          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.
  • antod 3y ago
    I thought it was renamed after Oxide picked up the sponsorship.
  • 3y ago
• sbt567 3y ago
  I've been using RustPython for my side project (scripting purpose) and its been amazing ride so far! (albeit with minimal docs which is understandable at this stage). AFAIK, the parser also been used in the awesome ruff project
• KingLancelot 3y ago
  [dead]
• sebastianconcpt 3y ago
  How is it about safety then? All the Rust program parts scripted using python are unsafe?
• thurn 3y ago
  How does their garbage collection work? Especially in Rust it would be cool to see a concurrent collector.
• posix_monad 3y ago
  I'm not convinced that projects like this can really have broad application. The value of Python is interfacing to native libraries, but as soon as you use something like PyPy, you lose access to all of that. It's the same story with the performance orientated forks of cPython.
  • ixaxaar 3y ago
    Pretty much. Ecosystem brings most of the value than any programming language.
    • posix_monad 3y ago
      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.
      • globular-toast 3y ago
        > The language itself is poor The language is a joy and one of the main reasons it became popular. How do you think it got its ecosystem?
        • Falell 3y ago
          "worse is better", the fact that a great ecosystem has grown does not necessarily mean the language and its tools are great. Personally, I find the lack of static types makes maintenance a nightmare, and think the build and deployment situation is miserable.
        • ildjarn 3y ago
          It become popular in the era of Java, Perl and object orientated C++
      • colinsane 3y ago
• AlbatrossAA 3y ago
  [dead]
• stratigos 3y ago
  please, just stop with Python already
  • ReflectedImage 3y ago
    We can't do that as Python is the programming language that meets business needs the best and they pay the bills.
• qwerty456127 3y ago
  > Each of these implementations offer some benefits: Jython, for example, compiles Python 2 source code to Java byte code... IronPython is well-integrated with .NET, which means IronPython can use the .NET framework and Python 2 libraries or vice versa. Python 2 is dead and that's why Jython and IronPython, who have failed to catch up with Python 3, are dead as well and are not worth mentioning, are they?
• lastmjs 3y ago
  We've been using RustPython as the Python interpreter for our project Kybra, which is a Python environment for the Internet Computer Protocol (decentralized cloud, where all programs are automatically replicated across 13-40 nodes). Wasm is the runtime environment on ICP. It's been working quite well, though lack of C extensions is a problem. We're hoping to move to CPython once the wasi and C extension support is there. But the project works, compiles to wasm32-wasi, and can execute on the live ICP network: https://github.com/demergent-labs/kybra https://github.com/demergent-labs/kybra
  • willquack 3y ago
    What has your experience been with Pyodide? Why did you opt for RustPython instead?
  • youknowone 3y ago
    Thank you for working with RustPython. I believe kybra made RustPython wasi support a lot more stable.
• dang 3y ago
  Related: RustPython – A Python-3 (CPython >= 3.11.0) Interpreter written in Rust - https://news.ycombinator.com/item?id=35056586 https://news.ycombinator.com/item?id=35056586 - March 2023 (136 comments) A full Python interpreter written in Rust - https://news.ycombinator.com/item?id=31086317 https://news.ycombinator.com/item?id=31086317 - April 2022 (7 comments) Python interpreter written in rust reaches 10000 commits - https://news.ycombinator.com/item?id=29094323 https://news.ycombinator.com/item?id=29094323 - Nov 2021 (93 comments) RustPython: A Python interpreter written in Rust - https://news.ycombinator.com/item?id=28280790 https://news.ycombinator.com/item?id=28280790 - Aug 2021 (49 comments) RustPython – Python Written in Rust - https://news.ycombinator.com/item?id=27060802 https://news.ycombinator.com/item?id=27060802 - May 2021 (2 comments) A Python interpreter rewritten in Rust, that can run pip - https://news.ycombinator.com/item?id=26030269 https://news.ycombinator.com/item?id=26030269 - Feb 2021 (48 comments) A Python Interpreter Written in Rust - https://news.ycombinator.com/item?id=19064069 https://news.ycombinator.com/item?id=19064069 - Feb 2019 (194 comments)
• janalsncm 3y ago
  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.
  • dathinab 3y ago
    not sure if you use pyo3 but it works wonders (except for some minor parts as well as the python in rust cross compilation case (last I tried ~1y ago), the rust in python cross compilation is fine tho)
    • janalsncm 3y ago
      Yeah pyo3. It also plays nicely with rust’s numpy so for a lot of deep learning applications you can load a file in rust and build your data, then pass it to python ML libraries. Only issue I’ve had so far are some weird issues with conda versions and maturin. But those were basically my fault.
• ashish01 3y ago
  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 secs time ./target/release/rustpython ~/code/fibs.py 14930352 ________________________________________________________ Executed in 13.44 secs fish external usr time 13.32 secs 175.00 micros 13.32 secs sys time 0.02 secs 776.00 micros 0.02 secs
  • soerxpso 3y ago
    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).
    • ashish01 3y ago
      I tried jit as well but looks like recursive functions cannot be jitted yet :(