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

281–290 of 369 posts

Re: Writing Python like it's Rust

#281

Post by lmm »

orthoxerox wrote: post #104
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

I left Python once I found Scala. There are a fair few ML-family languages (and I'd argue that the ML-family functionality is most of what people love about Rust) with garbage collection; OCaml is frequently mentioned.

Re: Writing Python like it's Rust

#282

Post by kgeist »

sidlls wrote: post #269
kgeist wrote: post #223

Earlier quoted context omitted.

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

We have a lot of Go services in production and errors have never been a performance issue. In the happy path, when there're no errors, errors are basically no-op. We don't use errors for control flow, though; only for exceptional situations, which aren't triggered often. If we want to branch based on an error, we use errors.Is. I don't remember ever having to inspect an error's string, that sounds like a hack. Usually, branching on an error's type is a rare scenario, even if it uses reflection, you usually just bubble up the error. In practice, at runtime, Go's error handling is just a bunch of TEST RAX, RAX instructions. Do you have benchmarks to show otherwise?

Re: Writing Python like it's Rust

#283

Post by fastasucan »

nrakx wrote: post #163
dragonsh wrote: post #158

Earlier quoted context omitted.

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

That applies to Python 2.7 and the code that Tim Peters writes. It does not apply to current Python and the coding styles that most people employ. Current coding styles are either: - Java-like ravioli, with class hierarchies that no one understands. - Academic functional and iterator spaghetti, written by academics who think Python offers the same guarantees as Haskell. Both styles result in severely broken code base…

Are you really saying that these are the two coding styles of Python? Any source for this claim?

Re: Writing Python like it's Rust

#284

Post by kgeist »

sidlls wrote: post #269
kgeist wrote: post #223

Earlier quoted context omitted.

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

>only true if the duplication: a) isn't also an abstraction (which, in go, it is in this case)

Can you give an example? I don't follow. I generally don't like abstractions for the sake of abstractions. I use Go's interfaces for a very specific reason: when I want dynamic dispatch, but with nice static typing guarantees. Interfaces in languages without structural typing force you to design a rigid, unflexible hierarchy/ontology well in advance, which only gets in your way when requirements change.

>is "contained" (i.e. not overly used)

Can you show why "containment" is necessary and why "overuse" is a bad thing?

Re: Writing Python like it's Rust

#285

Post by ojosilva »

Sosh101 wrote: post #128
movedx wrote: post #126

Earlier quoted context omitted.

Personally, I switched to Go.

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

I recommend you consider Rust if you can. I'm not going to lie: it's definitely harder to learn than Go, but the benefits are immense as Rust is serious about C-level performance and encompassing the ample capabilities of C++ while bringing some very commendable goals (ie safety) into the binary-compiled language arena.

And believe me: once you pass the first slope of learning (borrowing, lifecycles...), everything clicks just right and writing code becomes a very delightful experience, similar to what you do with [pick a trendy dynamic language of your choice].

And I think it's safe to say that Rust in 2023 can be considered mature and non-niche.

If you'd like sheer enthusiasm to help you make your mind, I recommend this guy's YT series on Rust:

https://www.youtube.com/watch?v=Q3AhzHq8ogs&list=PLZaoyhMXgB...

Re: Writing Python like it's Rust

#286

Post by peteradio »

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 you can't overload a function name.

Re: Writing Python like it's Rust

#287

Post by leetrout »

sidlls wrote: post #174
leetrout wrote: post #159

Earlier quoted context omitted.

> Go's handling of dependencies...leaves something to be desired Can you give specifics? I think publishing module versions as entire subtrees is very verbose and can be cumbersome but otherwise enjoy everything about Go modules. I find most peoples complaints are that its not like

That it's not like npm, pip, or maven is a plus in my view: I despise all three of them. I don't like the proxy system at all . It is not , in fact, easy to set up a private proxy that "just works." Also, it is quite trivial to have "sync" issues with the go.mod and go.sum files that manage/"lock" dependencies. `go mod tidy`, `clean -modcache`, etc., are required far too often. And it has the same problem with depend…

> And it has the same problem with dependencies-of-dependencies that python does. It leads to bloat and sometimes inconsistent behaviors in applications.

I haven't ran into that first hand. Is there a dependency management tool that prevents this? Cargo? (I don't have much experience with Rust yet FWIW)

Re: Writing Python like it's Rust

#288

Post by drekipus »

rami3l wrote: post #119
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

Indeed, that has been a real problem, so now you can probably write `private Dictionary > road = new();`.

This was my main complaint, as I nlk no one the dict part needs typing, but surely `new` could infer what I want.

If so, I'm very glad.

Re: Writing Python like it's Rust

#289

Post by mumblemumble »

Yoric wrote: post #264
mumblemumble wrote: post #243

Earlier quoted context omitted.

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?

I think it's the application of Scrum to work that doesn't primarily fall inside the (Cynefin) "simple" domain-type work that Scrum was designed for.

It's fine if the work is straightforward and easy to estimate. But, if it isn't, things get problematic. There are three variables that interact with each other when working on a project: time, scope, and quality. If you pin down both your acceptance criteria and the time you have to implement (which is basically what happens in a sprint planning meeting), then quality is the only remaining variable you have to manipulate when things aren't going according to plan.

Re: Writing Python like it's Rust

#290

Post by __MatrixMan__ »

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…

You're absolutely right that:

> Often the answer to this question unfortunately is not a technological merit, but knowledge of a team and willingness to learn.

And for the software engineer, this is also true:

> [it is] important ... to learn multiple programming languages

But I don't think the majority of python users are software engineers. They're data analysts, they're scientists, they're students. They'll never face a choice between Python and Rust, let's just be happy they chose Python over Matlab or Excel.

And with that in mind, writing Rust-shaped python so we can interoperate with our less-softwarey-brethren--while not the nirvana that we crave--is not a bad compromise.

Post reply on HN