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

201–210 of 369 posts

Re: Writing Python like it's Rust

#201

Post by marcosdumay »

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…

Python can only be second-best at anything if you take advantage of its strengths and avoid its weaknesses. If you insist on taking advantage of its weaknesses, it will suck completely.

The typing system is a huge weakness. If you insist on focusing on it, it won't be a good language.

Re: Writing Python like it's Rust

#202

Post by kqr »

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…

> 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 -- plenty of Python folks try various shapes for their data sequentially, and you can have multiple representations of the same data in a static language too. But I feel like the languages encourage a particular kind of experimentation, and sometimes either is more helpful than the other.

Re: Writing Python like it's Rust

#203

Post by DangitBobby »

sidlls wrote: post #138
Sosh101 wrote: post #128

Earlier quoted context omitted.

I've been thinking about getting into go - do you mind giving some pros/cons?

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 almost certainly encounter panics from a nil dereference at some point (or in my experience basically all production bugs were the result of one)

* If you work with a legacy project, early lack of generics encouraged copy/paste spaghetti piles

* Due to early lack of real generics, many popular libraries (such as ent) used codegen to make generic behavior possible. Generated code balloons PRs (unless you take care to quarantine them to their own commit and share commit ranges for diffs), and gets in the way of understanding code you care about.

Re: Writing Python like it's Rust

#204

Post by x0x0 »

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…

Plus excellent testing support.

If you eg interact with remote apis a lot, you can write the natural code: some api calls for setup, then your business logic, then more api calls... and then test this. In one linear function that is straightforward to understand. With great mock support, no need for code generation for mocking, etc.

Ruby is one of the few languages sharing this excellent support. All the other common languages require some combination of dependency injection, code generation for mocking, spewing unnecessary interfaces all over your code and turning it into a tangled mess of logic smeared across many functions, etc.

Re: Writing Python like it's Rust

#205

Post by mrweasel »

bmacho wrote: post #120

Can't we write and read Rust like Python instead?

That would be better, I dislike much of the syntax in Rust, but I do love many of the concepts and the overall goals.

I don't know, typing in Python is something I do to get code completion to work in VSCode. Mostly I don't care for it, because I frequently find myself using duck typing to solve problems. Python is really good at doing what I mean and not bothering me with "technically you're wrong"... I don't care, the function does what's it's suppose to, I have tests.

Re: Writing Python like it's Rust

#206

Post by patrickkidger »

toxik wrote: post #191

I feel like the elephant in the room is that for most cases in this blog post, you either use NumPy arrays or something else like it. You can make ndarray subclasses and that helps but type hinting and NumPy feels so… poorly done.

Try using jaxtyping: https://github.com/google/jaxtyping.

It also supports numpy/pytorch/etc.

Re: Writing Python like it's Rust

#208

Post by [deleted] »

guggle wrote: post #156
switch007 wrote: post #141

Earlier quoted context omitted.

It’s mad how there isn’t a Django clone in the JS world. They just stitch together half finished, buggy ORMs, migration tools and web frameworks? After all this time? Something like Django requires focus and concerted effort over a period of many years, so I guess it makes sense. I get the impression JS devs would rather have a new framework with bugs and cool emojis in the commits than something more stable and less…

I'd like a Django in Go ! But so farI haven't found anything that productive. I guess the "traditional" web framework for multi-pages website is not trendy enough.

[deleted]

Re: Writing Python like it's Rust

#209

Post by earthling8118 »

jeremyjh wrote: post #177
zelphirkalt wrote: post #162

Earlier quoted context omitted.

To what end? I think avoiding manual memory management is great, but I never had issues in Rust either, since I don't manage memory manually there either. I think that is kind of a point of Rust, as it avoids that whole class of bugs common in C programs. But to what end do you want garbage collection (GC)? Just for having GC? Or a more specific purpose, that is difficult to attain with Rust's model? For example: I u…

GC is nice because you don’t have to constantly think about ownership and lifetimes.

The amount of time spent worrying about this is vastly overestimated. You don't really have to worry about lifetimes in your common day to day coding unless you're doing some seriously performant or low level stuff. At which point you probably don't want a GC anyway.

Re: Writing Python like it's Rust

#210

Post by Yoric »

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…

> 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 data will be yet, and it's easier to just bodge it together with maps and heterogeneous lists for the first few iterations so you can let the code tell you how it wants to be structured. Having to start with static types subtly anchors you to your first idea. And the first is typically the worst.

That's a very interesting observation.

Let me add a counterpoint, though. Indeed, you will refactor everything. But by having strong, static typing, you have a much clearer idea of what you're breaking along the way. Cue in hundreds of anecdotes by each of us, when we broke something during a refactoring because the dependency was not obvious and there were not enough tests to detect the breakage. I've seen two of these in Python code just this week.

Post reply on HN