81–90 of 102 posts
Earlier quoted context omitted.
Cython is unsafe.
It's much easier to learn Cython once you know Python. That's the biggest selling point.
Earlier quoted context omitted.
It's much easier to learn Cython once you know Python. That's the biggest selling point.
But the tooling is terrible in comparison. I find rust sigificantly easier as a python developer than cython. There is so much more rust ecosystem to take advantage of.
> Rust is a language that, because it has no runtime, can be used to integrate with any runtime; you can write a native extension in Rust that is called by a program node.js, or by a python program, or by a program in ruby, lua etc. and, however, you can script a program in Rust using these languages. — “Elias Gabriel Amaral da Silva” Can someone explain why is "having a runtime" problematic for writing extensions an…
Rust has a big standard library that is linked by default. Using it with no runtime is pretty rough going and is usually done only by people targeting bare metal microcontrollers or OS kernels, because it loses a lot of the power normally available in the language.
I never got around to talking about it, but as part of my "month of Rust", I ported permission-based authorization logic from Python to Rust and then ran performance benchmarks of the Rust implementation and a pypy-compiled version. The pypy-compiled python ran slightly faster. I've been told not to expect similar results in other implementations. These findings cannot be used to draw any conclusions about pypy. My r…
I don't understand all the implications, but I often hear from JIT language people that their language could be as fast as a AOT language if it was used correctly. What are the use-cases that lend itself to be faster in Rust, than JS/Ruby/Phython?
>Python: interactive glue language between high performance C libraries.
Appreciate this walkthrough for Rust!
Earlier quoted context omitted.
Cython is unsafe.
Rust is disgusting language with too much commercial exploitation
Shouldn't Python, et al have more "native" ways to achieve these sorts of performance improvements?
https://news.ycombinator.com/item?id=14588333 (beautifulsoup/lxml upgrade) > Python: interactive glue language between high performance C libraries. Appreciate this walkthrough for Rust!
https://news.ycombinator.com/item?id=14588333 (beautifulsoup/lxml upgrade) > Python: interactive glue language between high performance C libraries. Appreciate this walkthrough for Rust!
How does it compare with https://github.com/servo/html5ever (someone with free time do run some benchmarks)
I think the primary claim to fame for this C-based https://github.com/kovidgoyal/html5-parser is serving as a drop-in performance boost for lxml (at the API level; it parses invalid HTML differently/more consistently).
I too would be interested in a performance comparison to help decide which project makes more sense for new projects. The existing Python layer in html5-parser might give it a leg up if the language of choice is Python - is there a similar project for the Rust-based html5ever?
Earlier quoted context omitted.
Debian packages integrate better with the system, are authenticated by gpg, and have at least one more critical pair of eyes on them. If you're willing to stick with an older version of cargo and rustc, why not?
Because the ecosystem is not. A lot of what’s on crates.io needs the latest and greatest version.
Thankfully, crates.io lists the dates next to crates so that users can select a version that is released before or during the release cycle of their compiler, thus guaranteeing compatibility.