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

341–350 of 369 posts

Re: Writing Python like it's Rust

#341

Post by adultSwim »

AdityaSanthosh wrote: post #4

So cool. I love rust and my day job is in Python. But I have a question. I'm a junior dev(gimme some leeway here). I don't really understand how important these design patterns are because in the programs I write, I usually write the classes and call them in runtime myself. I think usually we write the servers and client ourselves. Let's take the different client types example. You are making an assumption that users…

This is a great question. Often times its the new engineers trying to makes things complicated and the older ones pushing back. Most of the time contortions to make a language different than it was designed are terrible idea. In this case, my claim is that this is a real problem worthy of solving. However I've also worked on plenty of projects that used the simple style and it was fine. One differentiator is how big the program is and who all will be using it.

Re: Writing Python like it's Rust

#342

Post by tcfhgj »

ReflectedImage wrote: post #333
tcfhgj wrote: post #332

Earlier quoted context omitted.

Unit tests wouldn't help with that, because it doesn't cover the interaction of all the classes when they pass data on to each other; and they would probably take me months; I would need integration tests, for which I first need to understand how the code works together

"all the classes" Write simpler code, let go of the complex Java class hierarchies. No one can understand them, it's hard to reasonable them and they are mostly a mess. The point of Python duck typing is you do more by writing less code.

Data flows through functions as well... Or between classes that are injected , no hierarchies required; Anyways I can't make wishes about how the code was written

Re: Writing Python like it's Rust

#343

Post by mgaunard »

kobzol wrote: post #308
Shish2k wrote: post #255

Earlier quoted context omitted.

Last time I checked, that part was written in Python...

https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...

And the fact that they're spending so much time on it and were afraid to rewrite it tells you all you need to know.

Rewriting it in C++, leveraging the platform-specific APIs for disk I/O (sync_file_range on Linux, not even wrapped by a Python module) would yield not only much better performance, but also much higher reliability.

As it is this daemon is a recipe for page thrashing. Not that I would expect a Python dev to actually know how a kernel works.

Re: Writing Python like it's Rust

#344

Post by Yoric »

mumblemumble wrote: post #266
Yoric wrote: post #260

Earlier quoted context omitted.

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

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

Well, that may explain some of the difference between our points of view. Most of my experience is with medium ( 500 developers) applications. At some point, no matter how cooperative the team is, the amount of complexity that you can hold in your head is not sufficient to make sure that you're not breaking stuff during a simple-looking refactoring.

Re: Writing Python like it's Rust

#345

Post by Karrot_Kream »

Yoric wrote: post #344
mumblemumble wrote: post #266

Earlier quoted context omitted.

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

> 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. Well, that may explain some of the difference between our points of view. Most of my experience is with medium ( 500 developers) applications. At some point, no matter how cooperative the team is, the amount of complexity that you can hold in your head is not sufficient t…

Sure but at that point we're probably not on the first iteration of code anyway. Even at a big tech company, I find it most effective to make a POC first-iteration that you prove out in a development or staging environment that uses the map-of-heterogeneous-types style development. Once you get the PMs and Designers onboard, you'll iterate through it until the POC is in an okay state, and then you turn that into a final product that goes through a larger architecture review and gets carved up into deliverables that medium and large-scale teams work on. This latter work is done in a language with better type systems that can better handle the complexity of coordinating across 10s or 100s of developers and can generally handle the potential scale of Big Tech.

There's something to be said that the demand for type systems is being driven by organizational bloat but it's also true that large organizations delivering complex software has been a constant for decades now.

Re: Writing Python like it's Rust

#346

Post by eska »

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…

In my case I write Python like this because the colleagues who are using my software are hardcore engineers but only intermediate or beginner programmers. Well-designed APIs with IDE support and safe patterns protect them from a lot of potential mistakes they didn’t know they could make. I won’t be able to ask them to learn Rust out of time constraints.

Re: Writing Python like it's Rust

#347

Post by oblio »

mananaysiempre wrote: post #338
oblio wrote: post #337

Earlier quoted context omitted.

> Just about every sufficiently general system allows for arbitrary code in the latter, be they in debian/rules or PKGBUILD or the buildPhase argument to mkDerivation or—indeed—in setup.py. (Most systems also try to sandbox those sooner or later, although e.g. the Arch Linux maintainers gave up on cutting off Go and Rust builds from the Internet AFAIU.) Most other programming language package managers don't, see Mave…

> Most other programming language package managers don't, see Maven for Java. So it’s not able to express native extensions or even codegen then? I suppose that’s OK for something that’s not the only available solution, but I don’t think I’d love it, either. > But then again, NONE of the scripting languages ever wanted to learn stuff from Java, especially regarding packaging[.] Both Java and its docs are just extreme…

Well, they didn't need to read much about Java in this case, frankly. Just creating a simple Java project with Maven would have showed the groupId concept (namespaces preventing top level squatting), for example.

https://maven.apache.org/guides/getting-started/index.html#h...

Anyway, too late now, now Python & co. are finding their own, alternative, ways to retrofit stuff like this.

Re: Writing Python like it's Rust

#348

Post by Yoric »

ReflectedImage wrote: post #300
havercosine wrote: post #299

Earlier quoted context omitted.

Wholeheartedly agree. I'm a self taught programmer who programs to get things done rather than just doing programming for fun (I started in ML/data science field). That way, my code often resembles the caricature of these hacky codebases alluded above. And I'm well aware of it. I often have arguments about utility of Python with my more technically solid engineer friends who keep telling me "Python doesn't scale" etc…

Python scales fine as long as you know microservices. The issue is people assuming that they don't need to learn anything new to use Python. You got people stating that using static typing in a dynamically typed language like Python is a good or reasonable idea. It's not. But people don't want to put in the effort to learn things like dynamic typing and microservices.

How do microservices factor in this conversation? Do you find that they actually reduce complexity?

Re: Writing Python like it's Rust

#349

Post by timkofu »

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…

> 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

... I thought this is how most of us use Python? I find it repulsive to use without types. type_hints enable me to use it for Software Engineering, and I get to keep the Data Science stack, which is solid gold.

Re: Writing Python like it's Rust

#350

Post by davidatbu »

cb321 wrote: post #339
davidatbu wrote: post #331

Earlier quoted context omitted.

You know: this always tempts me, but I hold back because nim is not memory-safe (or has a clearly delineated memory-safe subset like Rust), and I would rather pick up an actually memory-safe (even if GCed) language even if some perf-cost (like F#, Ocaml, Swift, Vale ..etc).

There is a fairly clear subset of Nim which is memory safe. There are discussions once in a while to reduce that from a small set to one..two keywords, e.g.: https://forum.nim-lang.org/t/9280#61243 which has links to some others. The resolution is usually: Eh - it's already a very small set. There also may well be libs (that you feel unable to not rely upon) which use these language constructs, and trust sure is tric…

Definitely learnt from that link, thanks!

That still hasn't won me over from prioritizing definitely-memory-safe languages over "fairly-memory-safe" nim tho.

Post reply on HN