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

101–110 of 369 posts

Re: Writing Python like it's Rust

#101

Post by frodowtf »

golergka wrote: post #90
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…

Everything you just said is true for Typescript, as you can set it up as strict or as forgiving as you like, and writing one off scripts for node is just as easy as for Python. But unlike Python, it has a great type system.

With Typescript I have nothing comparable to Django.

Re: Writing Python like it's Rust

#102

Post by zelphirkalt »

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 benefits, but if your team does not want to learn Rust, you got a problem and cannot move on.

Here it becomes visible, how important it is to learn multiple programming languages. It makes teams flexible and allows choosing technologically better solutions, instead of having to shoehorn things into that one language the team knows. Programming languages matter. Each has its strong areas and flaws. Some languages allow you to change the language itself, to extend what you can do with them comfortably and safely.

All this is assuming of course, that you will have suitable replacements for any libraries you need. Such replacements can including writing some code oneself, using the language's facilities. For example, if the language is powerful enough or includes the right batteries for it, you can easily write a little parser for a file format yourself using a grammar that is available in some standard. But keep maintainance in mind. If the file format is still developing, you might not want to do this.

Something that in one language might be an external dependency, a library, can in another language be a concise self-written code, that one can look at and quickly understand.

Re: Writing Python like it's Rust

#103

Post by Yoric »

extr wrote: post #35

What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to…

I'm using pyright at the moment. It's ok. Feels better than mypy. If you're used to counting on the type system to guarantee your invariants, you'll be disappointed, but if you're just looking for fewer TypeError, it will help.

Re: Writing Python like it's Rust

#104

Post by orthoxerox »

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…

> 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?

Garbage collection

Re: Writing Python like it's Rust

#105

Post by Yoric »

drekipus wrote: post #94

I love python, and I understand the importance of typing, but is there a way to have less physical keyboard typing ? Consider the two examples: `private Dictionary > road = new Dictionary >();` `road : dict[RoadPlate, List[RoadPlate] = {}` Or even just `road = {}` I prefer python simply due to needing less writing and less reading. I can think more about the program when there's less stuff to read

Many years ago, I used to code in OCaml. I used to think exactly like you (OCaml has extreme levels of type-inference, so you write as little code as Python and you get type safety). However, as I worked on larger codebases, I realized that most of these type hints on which I was saving a few keystrokes were actually part of the documentation. When I returned to older code, it looked smart, too smart, but I had no clue about my invariants.

And in your particular example, if you write `road = {}`, chances are that it will end up being typed as a `Dict[str, Any]`, which is basically worthless, both to avoid TypeError, but also as a suggestion of what you should and shouldn't put in the dictionary.

These days, I write my types aggressively.

Re: Writing Python like it's Rust

#106

Post by Yoric »

SOLAR_FIELDS wrote: post #2

Tooling has come a long way in the past few years to help support better Python. Nowadays I can just throw on Pydantic V2 (still in Alpha, but stable to code against for basic use cases), ruff and mypy. Turn strict mode on in mypy and install the relevant vscode extensions and you get an experience that rivals a compiled language in both speed and usability.

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 overselling it.

YMMV

Re: Writing Python like it's Rust

#107

Post by BiteCode_dev »

Yoric wrote: post #100
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…

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…

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 less benefits for that phase than rust or haskel, but it's not impotent. Industrialization is just hard, no matter the language.

Because we are an industry where a lot of self-taught people get a career, we tend to forget this last point. Creating a serious computing system is engineering, and this includes the project management part, and being rigorous about a lot of thing.

Granted, the rigor needs to be higher with Python once your reach that scale, and at a certain point (which I wish everybody would reach), you may want to ditch it. It's a good problem to have though.

Yet we have to remember not all industrialization attempts are equal. Most are really tame. I'd argue you could replace half the website code base out there with a bunch of bash scripts on a VPS and they would still make money. So even in this context, Python can deliver a lot.

Re: Writing Python like it's Rust

#108

Post by Yoric »

ansgri wrote: post #86
tmarice wrote: post #78

This is a great way to to write very unaesthetic Python.

It's almost like with Python you have a spectrum of aesthetics and maintainability. The "most aesthetic" (concise and readable-as-plain-English) code involves a lot of magic (metaclasses, dynamic dispatch etc.), so it's better left to foundational libraries with extensive testing by thousands of developers. Except they probably have a ton of asserts and type hints under the hood, so only the interface is "aesthetic".…

You are right, that feels like a pretty good description of the tradeoffs when writing Python. While I'm not a big fan of Go, I kinda understand why Go doesn't allow writing "aesthetic" libraries, because the cost in terms of behind-the-scenes maintenance is enormous.

Re: Writing Python like it's Rust

#110

Post by devjab »

BiteCode_dev wrote: post #96
golergka wrote: post #90

Earlier quoted context omitted.

Everything you just said is true for Typescript, as you can set it up as strict or as forgiving as you like, and writing one off scripts for node is just as easy as for Python. But unlike Python, it has a great type system.

Not really. First, the JS ecosystem is very web oriented, so if you want to dabble out of there, you often gonna fall short. Secondly, the JS packaging has very poor support for compiled extensions, which mean everything that needs a perf boosts is unlikely to get good quality treatments. Finally, the community makes it a constant moving target. After 20 years of writing both JS and Python, I can still install old dj…

We gradually wanted to move our Java, C# and C++ into a more “generalised purpose” language because it would be easier to maintain and operate a small team with one language in what was becoming a non-tech enterprise. Python was our first go to, because well, it’s just a nice language that’s easy to learn, but we eventually ended up in Typescript and our story was basically the polar opposite to what you mention here.

We found the package support to be far superior in JavaScript. Even a lot of non-web things like working with solar inverters and various other green energy technologies (which at least here in Europe is very, very old school) we’re significantly easier with JavaScript than they were with Python. I guess FTP is web, but it’s the example I remember the best because I had to write my own Python library for it because the most used packages couldn’t handle a range of our needs. This may be because it’s FTP is not me shortening SFTP, no no, that’s just what solar plant engineers figured would be practical. Sure they recommend you don’t put the inverters directly on the internet in their manuals, but who reads those? Not solar plant installers at least. Anyway, I fully expected Python to be king for those things considering it’s what runs a lot of IoT, but JavaScript was just plain better at it.

Which is generally the story of our migration of basically everything to typescript. Some or our C++ code ended up as Rust, and I really, really, love Rust, but most of our code base is now Typescript. It might all have been Rust if Rust was a frontend web language, but it would never be Python. The reason for this is the environment. Not just the package and module systems, but also how you can set up a very “functional programming” (in quotes because it’s not really FP but JSFP) to cut down on the usage of OOP unless absolutely advantageous, type safety, specific coding systems and how easy it is to actually enforce all of those things automatically. Is just a much better experience with Typescript compared to Python in our experience. I think you could very likely achieve some of the same with JSDoc and JS and not Typescript, but we couldn’t get that to work (as well) in our internal tooling.

Somewhat ironically, the two areas JavaScript wasn’t better than Python were in what I’d consider web-related parts of your tech stack. There aren’t any good JS SQL ORMs, Prisma is ok and so is MikroOrm but none of them compare to what’s available in Python. The other is handling XML, which is soooo easy in Python. I mean theoretically it should always be easy to handle XML, but that would require the XML you need to handle to actually adhere to any form of standards, which I guess is utopia.

But I guess you can have very different experiences.

Post reply on HN