Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Python like it's Rust

kobzol.github.io

Post reply on HN
Print view View original

211–220 of 369 posts

Re: Writing Python like it's Rust

#211

Post by earthling8118 »

d0mine wrote: post #172
zelphirkalt wrote: post #102

At some point you gotta ask yourself: Why am I still writing Python then, if I want to write Rust? If I want Rust's safety, why not write Rust then, with battle proven tools and better type system from the start? Often the answer to this question unfortunately is not a technological merit, but knowledge of a team and willingness to learn. You might want to write actual Rust code and there can be any number of benefit…

Because Python enables faster iterations. By the time you manage to produce a Rust program that even compiles, you can do several edits with tests in Python.

`cargo new --bin cli`. There, it compiles.

I use Rust because I want to move fast. Python would slow down my iteration significantly. I have a lot of experience using it and I prefer not to whenever possible.

Re: Writing Python like it's Rust

#212

Post by jen20 »

dragonsh wrote: post #158
BiteCode_dev wrote: post #76

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…

> But that's missing the point that Python is still not meant to be the best at anything, but good at most things. The most important thing about Python is readability and its part of its syntax and is one of the best languages out there for readability. Zen of python: >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Compl…

I don’t know how people reconcile “python is beautiful and elegant” with “name your file __init__.py or __main__.py” while keeping a straight face.

Re: Writing Python like it's Rust

#213

Post by DangitBobby »

hakanderyal wrote: post #43

I went through a similar journey, without the Rust part. Started using type hints, data classes, pydantic to get the benefit of static typing after dealing with the pain of refactoring dynamically typed projects. It was better, but it _feels_ like lipstick on a pig. I love Python, but types are not what it's best at. It's missing features that makes typing easier. I've realized if was going to write typed Python, I m…

Django has kept me chained to Python. Just can't beat admin/migrations/ORM. Ive often wondered why a true django-like project has never been born out of the JavaScript/Typescript ecosystem.

Re: Writing Python like it's Rust

#214

Post by Yoric »

dagmx wrote: post #190
Yoric wrote: post #100

Earlier quoted context omitted.

On the one side, yes Python is incredibly versatile. On the other side, I have worked on many Python projects, some of them fairly high profile, and I have seen exactly two kinds of Python codebases: 1. a few were written by extreme professionals, plugging at every single hole, with ~100% coverage, plus considerable maintenance because every dependency upgrade tends to break something; 2. many that feel cobbled toget…

How are any of these points exclusive to Python among the commonly used languages? Everything you said applies equally to many C++ projects I work with as well

You are right, this is probably not specific to Python. It just happens that:

1. we're currently discussing Python;

2. anecdotally, the C++ projects on which I have worked were all case 1. ("code it like it's Rust") – I make no claim that this is representative, though.

Re: Writing Python like it's Rust

#215

Post by Yoric »

rowanG077 wrote: post #149
Yoric wrote: post #100

Earlier quoted context omitted.

On the one side, yes Python is incredibly versatile. On the other side, I have worked on many Python projects, some of them fairly high profile, and I have seen exactly two kinds of Python codebases: 1. a few were written by extreme professionals, plugging at every single hole, with ~100% coverage, plus considerable maintenance because every dependency upgrade tends to break something; 2. many that feel cobbled toget…

I would like to see a codebase of the first kind. All larger python projects I have seen are of kind 2...

The Firefox build system feels to me like kind 1. The Synapse Matrix server also feels pretty close (although I don't understand why it doesn't use Pydantic or something like Pydantic).

Re: Writing Python like it's Rust

#216

Post by Yoric »

kqr wrote: post #202
mumblemumble wrote: post #186

Earlier quoted context omitted.

This is roughly my experience, too. Static type safety has interesting YAGNI characteristics. For the bits of the code that must work, and where defects and regressions due to type errors may be subtle and difficult to detect, it's indispensable. But it can also be an impediment to iteration. Sometimes the code you're working on is still so experimental that you don't really know what the best structure and flow of d…

> Having to start with static types subtly anchors you to your first idea. And the first is typically the worst. Not just that, but dynamic typing conveniently allows you to try multiple ideas in parallel. In static languages, you tend to refactor The One Representation for a thing and try multiple ideas sequentially, which may or may not be better. Of course, none of this is really inherent to the type system -- ple…

That is a very good point.

However, the other side of the coin is that in many Python codebases I've seen, people keep using multiple antagonistic ideas/paradigms in the same code, way past the point where it should have become clear that these ideas are actually incompatible and no amount of heroic hackery will solve the issues.

Re: Writing Python like it's Rust

#217

Post by pharmakom »

orthoxerox wrote: post #192
anthomtb wrote: post #180

Earlier quoted context omitted.

Might I ask what scripting-like language does have good support for compiled extensions? Such that you can easily develop on Mac and deploy on Linux? Because it seems to me that once you compile something you are in the awkward world of ABI and CPU differences. And binary portability has been a paint point of programmers since before I was born (and I'm not that young). So if there is a programming language that neat…

C# does. It's not exactly a scripting language and authoring a native dependency NuGet package isn't exactly an obvious task, but when you learn how, it's a straighforward solution: - a NuGet package with native deps (win, linux, osx) cross join (x86, arm) - a P/Invoke package that depends on the native one - actual software that uses the dependency When you publish the actual software, it pulls the deps and includes…

F# by extension has this. It’s a pretty good scripting language although not perfect.

Re: Writing Python like it's Rust

#218

Post by Yoric »

giantrobot wrote: post #199
mumblemumble wrote: post #186

Earlier quoted context omitted.

This is roughly my experience, too. Static type safety has interesting YAGNI characteristics. For the bits of the code that must work, and where defects and regressions due to type errors may be subtle and difficult to detect, it's indispensable. But it can also be an impediment to iteration. Sometimes the code you're working on is still so experimental that you don't really know what the best structure and flow of d…

> Something I really like about Python for this sort of thing is that I have a lot more ability to delay this industrialization stuff to the last responsible moment This is one of my favorite aspects of Python. I can start with every module in prototype form and industrialize each module as its design firms up. I can spend my early development getting an idea fleshed out with minimal overhead.

> I can start with every module in prototype form and industrialize each module as its design firms up.

That is definitely the theory. And this flexibility is indeed very precious for some types of work.

However... does it actually happen as you describe? I can count on half of the fingers of one hand the number of Python codebases that I've seen that actually feel like they've properly been reworked into something of industrial quality. All the other codebases I've seen are of the "I guess it works, maybe?" persuasion, quite possibly because there is always something higher priority than quality.

Re: Writing Python like it's Rust

#219

Post by ReflectedImage »

8589934591 wrote: post #195
ReflectedImage wrote: post #185

Earlier quoted context omitted.

Using static typing in Python will generally speaking significantly increase the number of bugs in the codebase.

Could you elaborate your statement? How? My experience says otherwise. I am interested to know your viewpoint and experience.

Of course, statically typed code is usually around 3 times the number of lines of code as it's dynamically typed equivalent.

This is due to lots of boilerplate, complex types, usage of abstract base classes, adding code for testing purposes into the production codebase due to disregarding language features such as mocking, etc...

The development time and bugs in a program are directly proportional to the total number of lines written.

You write 3x the number of lines of code using a verbouse code style then you have 3x the number of bugs. Static type checking only catches around 5% of bugs. It's not a significant debugging tool.

If instead of writing static types and all the involed boilerplate required to make it work, you instead invested that type in unit tests and proper qa, you will always come out ahead.

Re: Writing Python like it's Rust

#220

Post by goostavos »

mumblemumble wrote: post #186
BiteCode_dev wrote: post #107

Earlier quoted context omitted.

To be fair, a division between hell and heaven will happen with any language. The question is: is this particular hell worth the result? There is no generic answer to that of course, it just happens is has been the case for me during those 20 years. First, you have to get to the industrialization phase. And of course, you have to get there, with the constraint of time, budgets, and talent. Second, Python does have le…

This is roughly my experience, too. Static type safety has interesting YAGNI characteristics. For the bits of the code that must work, and where defects and regressions due to type errors may be subtle and difficult to detect, it's indispensable. But it can also be an impediment to iteration. Sometimes the code you're working on is still so experimental that you don't really know what the best structure and flow of d…

>impediment to iteration

The "aha!" moment that converted me from a Clojure guy to a Haskell guy was realizing that types aren't an impediment to iteration, they are an enabler of rapid design iterating. Once written, code has a way of not wanting to be changed. Types let me work "above the code" during that squishy beginning period when I'm not sure 'what the best structure and flow of data will be'. Emotionally, deleting types is a lot easier for me than deleting code.

This is in no way saying that types are the One True Way™ ^_^ Just that I've found them, given the way my brain is wired, to be a great tool for iteration.

Post reply on HN