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

261–270 of 369 posts

Re: Writing Python like it's Rust

#261

Post by throwaway894345 »

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…

I’ve been a Python developer for about 15 years and it isn’t good at most things. Performance is bad, package management is bad, typing is bad, async is bad, etc. Mostly it shines these days because of early mindshare in an exploding niche (AI/ML/numeric computing).

Re: Writing Python like it's Rust

#262

Post by grumpyprole »

hakanderyal wrote: post #259
grumpyprole wrote: post #153

Earlier quoted context omitted.

Even better would be to try F#, it will be able to use all the .NET libraries, has Python's succinctness, but with a strong type system (and inference).

I may switch to it eventually, but at this point in my career 16 years in, I try to avoid seemingly niche things when I just want to get stuff done. "Boring" is good. I know it's the same platform under the hood but I decided to spend my "innovation tokens"[0] on the stuff I'm buildin. [0]: https://mcfunley.com/choose-boring-technology

I call it "novelty budget" and I completely agree.

Re: Writing Python like it's Rust

#263

Post by Yoric »

duggan wrote: post #236
Yoric wrote: post #218

Earlier quoted context omitted.

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

Something that just about seems to work is something that has often met the threshold for "solves a real problem" while also meeting the other requirements that a product needs to be successful. It's easy to make something that works, is well designed, and either doesn't solve a problem someone has or nobody knows about it.

I realize that this is the common wisdom these days: write code that works just well enough that we have a chance to fix before it does too much damage whenever it breaks. I suspect that this approach is strongly fueled by the unlimited VC money available in tech, since it means that any company can employ an unlimited number of full-time developers (and PR) just to handle catastrophes.

We'll see how that wisdom holds if/when/as VC money dries up and/or moves to other sectors.

Re: Writing Python like it's Rust

#264

Post by Yoric »

mumblemumble wrote: post #243
Yoric wrote: post #218

Earlier quoted context omitted.

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

Wandering offtopic, perhaps, but I've noticed that this kind of behavior seems to strongly correlate with Scrum. The work starts getting rushed toward the end of the sprint. Every two weeks, people start furiously cutting corners to meet a completely artificial due date. And then there's basically zero chance that you'll be able to get the PO to agree to cleaning it up in the next sprint, because they can't see the p…

Oh, interesting observation. Would you say it is scrum itself or just the existence of arbitrary deadlines?

Re: Writing Python like it's Rust

#265

Post by Yoric »

goostavos wrote: post #220
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…

>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, de…

Yeah, types are a type of (usually) easy to write, automatically enforced, documentation which I find endlessly useful during experimentation, if sometimes constraining. I'm sure that there are other means to achieve similar results (some variant of TDD, maybe?) but I haven't experienced them yet.

Re: Writing Python like it's Rust

#266

Post by mumblemumble »

Yoric wrote: post #260
mumblemumble wrote: post #234

Earlier quoted context omitted.

That was what I originally thought, as someone who grew up on static typing and then migrated to Python. But what I've discovered in practice is that, during those early iterations, I don't really need the compiler to help me predict what will break, because it's already in my head. The more common problem is that static typing results in more breaks than there would be in the code that just uses heterogeneous maps a…

> But what I've discovered in practice is that, during those early iterations, I don't really need the compiler to help me predict what will break, because it's already in my head. Reading this, I have the feeling that you're talking mostly of single-person (or at least small team) projects. Am I wrong? > The more common problem is that static typing results in more breaks than there would be in the code that just us…

> I have the feeling that you're talking mostly of single-person (or at least small team) projects. Am I wrong?

Small teams. And ones that work collaboratively, not ones that than carve the code up into bailiwicks so that they can mostly work in mini-silos.

I frankly don't like to work any other way. Conway's Law all but mandates that large teams produce excess complexity, because they're basically unable to develop efficient internal communication patterns. (Geometric scaling is a heck of a thing.) And then additive bias means that we tend to deal with that problem by pulling even more complexity into our tooling and development methodologies.

I used to believe that was just how it was, but now I'm getting to old for that crap. Better to push the whole "expensive communication" mess up to a macro scale where it belongs so that the day-to-day work can be easier.

Re: Writing Python like it's Rust

#267

Post by throwmeout123 »

throwaway894345 wrote: post #261
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…

I’ve been a Python developer for about 15 years and it isn’t good at most things. Performance is bad, package management is bad, typing is bad, async is bad, etc. Mostly it shines these days because of early mindshare in an exploding niche (AI/ML/numeric computing).

This, after eight years with py I’m sick of it and of the stupid direction it’s taking

Re: Writing Python like it's Rust

#268

Post by capitainenemo »

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…

All this discussion is kind of interesting to me since in the beginning Python seemed to be focused on being the anti-Perl.

Rejecting "There's More Than One Way To Do It" in favour of "There should be one - and preferably only one - obvious way to do it" (IMO they did not find the right balance there in terms of python3 strings)

Ultra minimalism on syntax to the point of introducing invisible errors...

I suppose this greater leniency on approaches now is simply due to broad adoption.

Re: Writing Python like it's Rust

#269

Post by sidlls »

kgeist wrote: post #223
sidlls wrote: post #138

Earlier quoted context omitted.

Some pros: * Go is "simple" (the language has a "small surface area", if you will) * Go has a broad and deep standard library that is generally well-documented * Go comes with a reasonably good general-purpose build tool (it builds, formats code for you, runs tests, etc.) Some cons: * Go's structural subtyping is a pretty terrible approach to handling the problem it's meant to solve. It's not quite as bad as a runtim…

>it leads to what I consider an abusive over-reliance on ad-hoc interfaces that just get in the way of understanding the code I actually like it, from the architectural angle. Say, I have an entity (class, service etc.) which does only one thing X and it does it well. For a certain scenario, it wants also to do Y, and it wants to delegate it to a different entity, because it's not its responsibility. It doesn't reall…

"duplication is cheaper than the wrong abstraction" is only true if the duplication: a) isn't also an abstraction (which, in go, it is in this case) and b) is "contained" (i.e. not overly used), which it often is not in non-trivial go code.

Go's errors package is riddled with `reflect` and other inefficient code constructs. Printing an error (e.g. to stdout or the log) is fine. But if you want to actually do anything with the error in the code (e.g. to discriminate/branch based on the error), you have to resort to bloated types that implement a poor interface or else rely on string inspection. In either case, you are using the underlying errors package. In small scale applications it's fine, but when you're doing anything at even modest scale and your application encounters errors, it's going to introduce measurable performance degradation.

Re: Writing Python like it's Rust

#270

Post by sidlls »

DangitBobby wrote: post #203
sidlls wrote: post #138

Earlier quoted context omitted.

Some pros: * Go is "simple" (the language has a "small surface area", if you will) * Go has a broad and deep standard library that is generally well-documented * Go comes with a reasonably good general-purpose build tool (it builds, formats code for you, runs tests, etc.) Some cons: * Go's structural subtyping is a pretty terrible approach to handling the problem it's meant to solve. It's not quite as bad as a runtim…

More Pros: * Compiling to a single binary is awesome * Rich library ecosystem at this point * Backwards compatibility is a priority so you can be pretty sure code you wrote yesterday will work tomorrow More Cons: * Unused variables and imports are a compilation error which is INCREDIBLY annoying during development (number one frustration with the language) * If you work with a team or a legacy project, you will almos…

Unused variables are an indication that the author hasn't completed their thought, so to speak, in the best case. In the worst case, it's a mistake and indicates the code is likely implemented in a way that it does something other than what it intended. I think making it a compiler error is the right way to do it. Other languages should adopt it.
Post reply on HN