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

221–230 of 369 posts

Re: Writing Python like it's Rust

#221

Post by throwaway290 »

jstx1 wrote: post #40
throwaway290 wrote: post #22

The thing with type hints in Python is that it's not enforced unless you make and maintain checking it as part of your workflow. And it comes with a bunch of things, at least: make sure to configure mypy, make sure you run mypy after push (experienced pythonists will forget to run it before), make sure everyone's IDE has it integrated, make sure to be super clear on which version of mypy you run (so errors people see…

It's not that many steps. You already have CI - adding mypy is one extra line, you should already have a way to keep track of versions in your project - keeping track of the mypy version isn't any additional overhead. If your team uses VSCode, you can have a devcontainer for the project ( https://code.visualstudio.com/docs/devcontainers/containers ) to make sure that it's in everyone's IDE along with your other linte…

> You already have CI

Don't worry about me. I mean all projects that do not have people and resources for this stuff. People just want to write Python and be done with it.

Without type hints they wrote Python and if they run it and tests pass then it works. Now they write Python code that can be wrong but they don't find out unless they also run an extra tool.

The fact that it requires CI now is a good illustration of the problem;)

Re: Writing Python like it's Rust

#222

Post by throwaway290 »

asib wrote: post #65
throwaway290 wrote: post #22

The thing with type hints in Python is that it's not enforced unless you make and maintain checking it as part of your workflow. And it comes with a bunch of things, at least: make sure to configure mypy, make sure you run mypy after push (experienced pythonists will forget to run it before), make sure everyone's IDE has it integrated, make sure to be super clear on which version of mypy you run (so errors people see…

Don't all the exact same problems exist with e.g. what version of Python or what formatter/linter your team uses? I don't see how this is unique to mypy. There is undoubtedly setup with all these tools, but the benefit massively outweighs the cost to my mind.

Version of Python is a runtime thing that can be checked.

Formatting is not relevant to whether the code is correct, but types are.

The problem compared to static languages is that it does not need to compile, types are completely ignored at runtime and there is no built-in way of checking it (like python binary with a special flag) so everyone does things different.

Re: Writing Python like it's Rust

#223

Post by kgeist »

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…

>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 really care how it's done and who will do it, it wants to just delegate it. Why should it know or care if there's an existing interface in some package? That's an implementation detail. The consumer specifies what it wants by declaring an ad hoc interface close to its own definition, and as a result, there's no explicit dependency on a different package. Sure, there will be duplication if several entities in different packages want similar interfaces but, as they say, duplication is cheaper than the wrong abstraction.

>in Go errors are just strings with a gross, inefficient library and system for adding context

Not quite true: errors are interfaces, there's a common pattern to construct an error from a string (because most of the time, that's all you need), but no one stops you from using other ways to construct an error. What is inefficient about it? It's no different from constructing an exception in Java/C# etc.

>Go's handling of dependencies...leaves something to be desired

Can you elaborate?

Re: Writing Python like it's Rust

#224

Post by miiiiiike »

michaelcampbell wrote: post #148
miiiiiike wrote: post #133

Earlier quoted context omitted.

These are not complicated tasks that should require a plugin or an AI assistant to make bearable. Just add the syntax to the language.

> These are not complicated tasks ... Just add the syntax to the language. Hahah, I've never designed a language, but I've been around long enough to know these 2 phrases are incredibly at odds.

I've never seen another language with generic syntax as poor as Python's. What's a better solution adding sensible syntax to the language or requiring every programmer to us an AI agent to handle the byzantine imports?

Re: Writing Python like it's Rust

#225

Post by ReflectedImage »

wtetzner wrote: post #196
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.

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.

Re: Writing Python like it's Rust

#226

Post by kgeist »

DangitBobby wrote: post #203
sidlls wrote: post #138

Earlier quoted context omitted.

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

>Unused variables and imports are a compilation error which is INCREDIBLY annoying during development

It's easily solved with:

  _ = unused_variable

  _ "unused_import"
Sure, it's annoying, but not in an incredible way :) Before I knew about this trick, I used to temporarily delete or comment out all related code, which is indeed incredibly annoying.

Re: Writing Python like it's Rust

#229

Post by dehrmann »

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…

If you're scaling Python to the point where you need everything fully-typed, your next stop shouldn't be Rust, it should be something like Java or C#. You just don't need Rust's memory semantics, and the GC will be good enough.

Re: Writing Python like it's Rust

#230

Post by fnordpiglet »

I stopped writing anything like rust because rust its ecosystem is mostly complete enough , expressive, and rapid to prototype and use. To save my cognitive load I shelved my python, Bourne, JavaScript, etc, and just write rust now. It’s not a decision for everyone and I’m not here to convince anyone of anything. But my life is simpler, my scripts more general and faster, and I don’t particularly ever miss the interpreted languages. It took a while to build that level of facility in rust for simple tasks, and of getting over the mental wall of “python is for X and compiled is for Y.” But I’m generally glad I did. Except when it comes to coding interviews and none of the graders know rust and my Python is getting rusty (harhar) after a few years of leaving it aside.
Post reply on HN