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

271–280 of 369 posts

Re: Writing Python like it's Rust

#271

Post by devjab »

oblio wrote: post #240
devjab wrote: post #110

Earlier quoted context omitted.

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…

I would have just kept Java and updated the language version and style. Everything Java 11+, modern libraries (no Spring, no Hibernate). The Java ecosystem is so deep that you can avoid the top 2 libraries/frameworks in any major domain and #3-#5 would be highlights in other ecosystems.

Java was never really an option because of how hard it is to hire for in my region of Denmark (and maybe the field of green energy). Java certainly has some presence at some of the larger tech focused enterprise orgs, but most developers we come in contact with aren’t interested in working with it. Not sure why considering C# is quite popular among them, but it is what it is.

Re: Writing Python like it's Rust

#272

Post by winrid »

mgaunard wrote: post #46
hmry wrote: post #33

Earlier quoted context omitted.

Lots of production software is written in Python, for better or for worse. In fact, production software gets written in every language eventually, no matter the intent of its designers. Maybe you only write your production software in C and C++, in which case good for you.

I do write Python code used in production, but does that doesn't make it serious production software. It takes a lot of effort to make a Python program not break on some inputs, so it's not really fire and forget like it is with C++. It's possible but it requires many more iterations.

Fire and forget? I am not gonna even bother to list all the "modern" software in C++ with serious bugs or security defects...

Re: Writing Python like it's Rust

#273

Post by winrid »

earthling8118 wrote: post #211
d0mine wrote: post #172

Earlier quoted context omitted.

Because Python enables faster iterations. By the time you manage to produce a Rust program that even compiles, you can do several edits with tests in Python.

`cargo new --bin cli`. There, it compiles. I use Rust because I want to move fast. Python would slow down my iteration significantly. I have a lot of experience using it and I prefer not to whenever possible.

There are no high productivity web frameworks for Rust. That's what Python is used for (Django). Plz don't bother to list actix or axum, or askama. That's a joke compared to Django.

Re: Writing Python like it's Rust

#274

Post by mejutoco »

smnrchrds wrote: post #244
mejutoco wrote: post #140

Earlier quoted context omitted.

You need to use mypy or similar to not check it at runtime: els: List[int] To test it at runtime you can use typeguard s @typechecked annotation. For convenience you can also use Pydantic.

I didn't know about typeguard. Thank you for the recommendation! How do you do this in Pydantic though?

For this example pydantic would be overkill, but you can use with it class definitions that follow standard python class hints, with additional utilities like YourClass.parse_obj(d) that parse a dict and throw a validation error if it does not match, with mostly standard type annotations.

It can also be used to generate openapi swagger files from the types and things like that.

Re: Writing Python like it's Rust

#275

Post by duggan »

Yoric wrote: post #263
duggan wrote: post #236

Earlier quoted context omitted.

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

> I suspect that this approach is strongly fueled by the unlimited VC money available in tech,

Well, I suppose we could trade anecdotes and counter-examples, but my position largely comes from my own experience rather than received wisdom (though there's plenty of that).

Instead I'll just say that I disagree, largely because because a business is a complex and shifting arrangement of various factors competing for limited time and resources. Even in a software business, software is only one of those.

Re: Writing Python like it's Rust

#276

Post by fastasucan »

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.

Its weird that so many conflate "this would be nice to have" with "this is the most important factor when deciding on a programming language". I think, obviously, very few Python users have type safety as their most important factor when deciding on a programming language.

Re: Writing Python like it's Rust

#277

Post by fastasucan »

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…

>Option 1. feels like "writing Python like it's Rust", but of course without any of the benefits of Rust either on performance or on safety.

...but with the benefits of Python. You might not see them/need them but they are there :)

Re: Writing Python like it's Rust

#278

Post by jeremyjh »

earthling8118 wrote: post #209
jeremyjh wrote: post #177

Earlier quoted context omitted.

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.

I’ve written a fair bit of Rust but it was ~5 years ago. I understand some ergonomics have improved but I think this somewhat depends on the type of application you are developing.

Re: Writing Python like it's Rust

#279

Post by tcfhgj »

ReflectedImage wrote: post #225
wtetzner wrote: post #196

Earlier quoted context omitted.

That's only until you've grokked Rust. I find iterating in Rust to be faster than Python.

Iterating in Python is always faster than iterating in Rust. If you do indeed find what you are saying then you simply speaking aren't able to write Python code.

I thought this too before my current python project.

It doesn't even use type hints and has no tests.

When I look at something I don't know what it is, what it does, and have to debug there (mentally or actually) to even know what's happening. If I change something, a few runtime errors pop up right at the start. Others take 30 minutes.

Re: Writing Python like it's Rust

#280

Post by JodieBenitez »

bmacho wrote: post #120

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

Rust is not pretty, but it's not that bad:

    use actix_web::{get, web, App, HttpServer, Responder};

    #[get("/hello/{name}")]
    async fn greet(name: web::Path) -> impl Responder {
        format!("Hello {name}!")
    }

    #[actix_web::main]
    async fn main() -> std::io::Result {
        HttpServer::new(|| {
            App::new().service(greet)
        })
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
    }
Of course, anything with brackets can be improved ! ;-)

    from sanic import Sanic
    from sanic.request import Request
    from sanic.response import text, HTTPResponse

    app = Sanic("MyHelloWorldApp")

    @app.get("/hello/")
    async def hello_world(request: Request, name: str) -> HTTPResponse:
        return text(f"Hello, {name}")
Post reply on HN