Live data from Hacker News

Writing Python like it's Rust

kobzol.github.io

361–369 of 369 posts

Re: Writing Python like it's Rust

#361
post #356
post #106

Earlier quoted context omitted.

In terms of usability, I feel that getting a Python codebase to a point where typing can actually be relied upon requires much, much, much more work than writing the same code in Rust or any other language with strong, static typing. And mypy is fragile enough that you can fairly easily sneak code that will break the guarantees without any warning, so even when I write "typing can actually be relied upon", I feel I'm…

You are completely disregarding the fact that python has a lot of modules. In rust you need an external dependency for anything. And of course external dependencies can be unmaintained, have vulnerabilities, change API every week…

Good point.

Anecdotally, though, I have the opposite experience. Python libraries changing API under my feet regularly (without support from the type system to help me find out how), core features that I depend on not being available in any maintained library and vulnerabilities.

It is entirely possible that my experience is biased, of course.

Out of curiosity, can you think of a module that is part of Python's standard distribution and is not available in Rust as a well-maintained crate?

Re: Writing Python like it's Rust

#362
post #353

Earlier quoted context omitted.

Do you work in an organization that does this? Because most organizations I've seen who don't pick the approach of "write it like it's Rust" rather have the following workflow. 1. Iterate on early prototype. 2. Show prototype to stakeholders. 3. Stakeholders want more features. At best, one dev has a little time to tighten a few bolts here and there while working on second prototype. 4. Show second prototype to stake…

> Do you work in an organization that does this? Yup! I'm at a company that used to be a startup and ended up becoming Big Tech (over many years, I'm a dinosaur here.) Our initial phase involved building lots of quick-and-dirty services as we were iterating very quickly. These services were bad and unreliable but were quick to write and throwaway. From there we had a "medium" phase where we built a lot of services in…

That's nice! Feels like your company has managed to get Python to work well for your case!

Most of the shops I've seen/heard of don't seem to reach that level of maturity. Although I'm trying very hard to get mine there :)

Re: Writing Python like it's Rust

#363
post #359

Earlier quoted context omitted.

(Sure, no compile time. But how much time do you think humanity collectively wastes waiting for CPython to import things? On. Every. Run.) "Did it work?" is a point-in-time observation. It is always situational. To find out, I have to construct esoteric objects with unobservable internal state and hope it is the state that I actually care about. "Should it work?" has an answer of infinite duration. I can recall what…

Yes but "Did it work?" can be discovered faster than "Should it work?". This means companies that ask "Did it work?" are more commerically competitive than companies that ask "Should it work?". The companies that ask "Should it work?" will eventually be eliminated by the market place.

[deleted]

Re: Writing Python like it's Rust

#364
post #361
post #356

Earlier quoted context omitted.

You are completely disregarding the fact that python has a lot of modules. In rust you need an external dependency for anything. And of course external dependencies can be unmaintained, have vulnerabilities, change API every week…

Good point. Anecdotally, though, I have the opposite experience. Python libraries changing API under my feet regularly (without support from the type system to help me find out how), core features that I depend on not being available in any maintained library and vulnerabilities. It is entirely possible that my experience is biased, of course. Out of curiosity, can you think of a module that is part of Python's stand…

[deleted]

Re: Writing Python like it's Rust

#366

Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. But that's missing the point that Python is still not meant to be the best at anything, but good at most things. And in this case, it's exactly what you get: optional typing, with decent safety if you need it. You can quick script or design seriously, you can explore in a shell or c…

Hei !

This comment inspired me because I was working on data-types at my company at the moment and I realized how static typing would have really benefited us.

So I made a library that does just that !

https://github.com/6r17/madtypes

I hope this will help some people !

Re: Writing Python like it's Rust

#367

Earlier quoted context omitted.

> These are not complicated tasks ... Just add the syntax to the language. Hahah, I've never designed a language, but I've been around long enough to know these 2 phrases are incredibly at odds.

I've never seen another language with generic syntax as poor as Python's. What's a better solution adding sensible syntax to the language or requiring every programmer to us an AI agent to handle the byzantine imports?

Oh I totally agree with you on that. It's just that "just add syntax" is incredibly difficult even as a greenfield effort, much less trying to fix an existing language, especially one as old and used as Python.

If the (studied) metric that "if over 20% to 25% of a thing needs to be redone, restart it from scratch" is true, then a new language altogether is probably the way and let Python just be Python.

Re: Writing Python like it's Rust

#368

Earlier quoted context omitted.

No, because to iterate in Python, you have run the program and get it into the right state. For many things in Rust, I can just use `cargo check`.

From that statement, I'm not convinced you know Python nor Rust. I'm going to suggest you read the following: https://docs.pytest.org/en/7.3.x/ https://doc.rust-lang.org/rust-by-example/testing/unit_testi...

Are you saying the only quick way to iterate is unit testing? My point is that there's a whole class of things that require unit testing in Python that are just automatically caught in Rust.

If you don't know Rust well, it's going to be slow going. If you've internalized the way it works, it can be very fast to iterate. Especially when you learn to start structuring types in such a way that bad states aren't even representable. You can often make it impossible to construct inputs that would require debugging in Python.

> From that statement, I'm not convinced you know Python nor Rust.

Thanks for the personal attack. I use both Rust and Python regularly at work, and write tests for both. Working on the Rust code base is pretty much always faster, because so many things are caught in advance. Yes, unit tests are still needed, but not for as many things. Learning to use the type system to your advantage, instead of treating it as an obstacle, can really speed things up.

Re: Writing Python like it's Rust

#369
post #231

Earlier quoted context omitted.

So, you realize Instagram, Pinterest, and a whole host of other unicorn software companies started out with python (often using django) right? And many, many current startups continue to do so.

They're websites, come on.

Instagram is a website with billions of people on it.
Post reply on HN