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

21–30 of 244 posts

Re: RustPython

#21

Post by amelius »

reedf1 wrote: post #11
blurbleblurble wrote: post #2

Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.

I think it's very naive for a programming language to make you "wince", tools are tools.

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.

Re: RustPython

#22

Post by tveita »

berkes wrote: post #8
blurbleblurble wrote: post #2

Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.

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

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

Re: RustPython

#23

Post by eptcyka »

gary_0 wrote: post #17

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...

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?

Re: RustPython

#24

Post by sanxiyn »

berkes wrote: post #8
blurbleblurble wrote: post #2

Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.

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

You are looking for Starlark. https://github.com/facebookexperimental/starlark-rust

Re: RustPython

#25

Post by IshKebab »

reedf1 wrote: post #11
blurbleblurble wrote: post #2

Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.

I think it's very naive for a programming language to make you "wince", tools are tools.

> Tools are tools

Are you trying to say that all tools are the same? There are no bad tools?

Why is it naive for a painful tool to make you wince?

Re: RustPython

#26

Post by networked »

brnt wrote: post #4
martijnarts wrote: post #3

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 wonder if anyone actually uses those third-party interpreters for anything serious. I've never come across anyone that did.

The release manager for PyPy posted "Ask HN: Is anyone using PyPy for real work?" last year and got many responses: https://news.ycombinator.com/item?id=36940871.

Re: RustPython

#27

Post by walthamstow »

reedf1 wrote: post #11
blurbleblurble wrote: post #2

Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.

I think it's very naive for a programming language to make you "wince", tools are tools.

I've used all kinds of hand tools and cooking utensils that were terrible and made me wince or experience other discomfort as I used them

Re: RustPython

#29

Post by reedf1 »

walthamstow wrote: post #27
reedf1 wrote: post #11

Earlier quoted context omitted.

I think it's very naive for a programming language to make you "wince", tools are tools.

I've used all kinds of hand tools and cooking utensils that were terrible and made me wince or experience other discomfort as I used them

It's completely fair enough to argue that a language/tools is a bad at what it is made to do, but this needs to be pared out from tool choice.

A baking spatula makes a bad cooking spatula. It's pliable and can easily scrape the curved surface of a bowl, but for flipping a fried egg it is hopeless - in a pinch it will work - but it would be nice to have something rigid.

Further, describing it as making you "wince" is a recipe for a flame war bordering on deliberate bating. Just describe your issues with the language in more than a single charged word. You don't have to write an essay, just "I don't like the package management environment". That way people can have a constructive discussion.

Re: RustPython

#30

Post by galangalalgol »

eptcyka wrote: post #23
gary_0 wrote: post #17

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...

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?

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
Post reply on HN