5 ms·

I can’t get over how clunky Python 3 is getting. Does anyone like working with type hinting in Python? All of my code is typed but compared to basically every o

I can’t get over how clunky Python 3 is getting. Does anyone like working with type hinting in Python? All of my code is typed but compared to basically every other type system the process was far more painful than it should have been. Even years later I still keep printouts of the typing documentation next to me so I can save time when I invariably need to look up the multiple ways you can define ‘T’ when it would just be ‘class Foo<T>’ in almost any other language. I never have this problem C++/C#/TypeScript. I’d love to see type hinted Python look more like TypeScript. I use Python every day and I like it less and less as it gets more of the features I want/need to use. I want types, I want generics, I want abstract classes, I want enums, I want interfaces. But I don’t want to have to import all of those features from modules when they should be built into the language itself.. When they’re built into the syntax of practically every other language that supports them. When was the last time you saw a `Protocol` in the wild? Just add interfaces. Teaching Python to a new developer is a ridiculous experience. There are just too many, usually half-baked, ways of doing things. Even this article, which does a great job going over some of Python’s newer/more advanced features, doesn’t use the latest version of the syntax or the generic versions of most types. If I didn’t have such a massive investment in Python I would have moved to Rust by now. And don’t me wrong, I love Python, I want to use it. I just wish it would stop eating its tail. Let’s just do a Python 4. Even if it means another decade long 2/3 adoption foot dragging.

movedx 3y ago
Personally, I switched to Go.
- Sosh101 3y ago
  I've been thinking about getting into go - do you mind giving some pros/cons?
  - sidlls 3y ago
    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 runtime failure when a 'type' doesn't implement a method (since that would be caught at compile time in Go), but it leads to what I consider an abusive over-reliance on ad-hoc interfaces that just get in the way of understanding the code (runtime or test code) * Go's error handling method is inefficient and generally awful. I'm not talking about the verbosity (it's a relatively small issue, in my opinion), I'm talking about that in Go errors are just strings with a gross, inefficient library and system for adding context * Go's generics implementation is, to put it mildly, inadequate; doing anything mildly interesting with it will be a cumbersome chore * Go's handling of dependencies...leaves something to be desired
    - leetrout 3y ago
      > 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 <npm|pip|maven>
      - sidlls 3y ago
        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 dependencies-of-dependencies that python does. It leads to bloat and sometimes inconsistent behaviors in applications.
        leetrout 3y ago
        > 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)
      - DangitBobby 3y ago
        I don't have a ton of go experience but it seems like there isn't a way to declare tool/binary dependencies that aren't imported anywhere. We ran into this problem for codegen libraries.
    - DangitBobby 3y ago
      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 almost certainly encounter panics from a nil dereference at some point (or in my experience basically all production bugs were the result of one) * If you work with a legacy project, early lack of generics encouraged copy/paste spaghetti piles * Due to early lack of real generics, many popular libraries (such as ent) used codegen to make generic behavior possible. Generated code balloons PRs (unless you take care to quarantine them to their own commit and share commit ranges for diffs), and gets in the way of understanding code you care about.
  - ojosilva 3y ago
    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=PLZaoyhMXgBzoM9bfb5pyUOT3zjnaDdSEP https://www.youtube.com/watch?v=Q3AhzHq8ogs&list=PLZaoyhMXgB...
- deleted 3y ago
  [deleted]
- willmeyers 3y ago
  I've started this transition as well. I love Python, but loathe it's typing and anything to do with asyncio.
- FireInsight 3y ago
  Personally, I switched to Go and soon after to Nim. https://nim-lang.org/ https://nim-lang.org/ It's great!
  - lucidrains 3y ago
    Same, I love it! Having done ruby, javascript, python, I'm allowed one niche language (although I really hope it grows in popularity!)
nwatson 3y ago
A good IDE like PyCharm makes it pretty simple, will offer to write all the import statements for you when you reference something that's new to the file you're working on. I'm taking a pretty decent course on Udemy right now, but the instructor said they didn't see the value in PyCharm and they're writing all this extra boilerplate by hand in VSCode. I started using copilot recently and that's accelerated the process even more.
- miiiiiike 3y ago
  These are not complicated tasks that should require a plugin or an AI assistant to make bearable. Just add the syntax to the language.
  - michaelcampbell 3y ago
    > 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.
    - miiiiiike 3y ago
      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?
      - michaelcampbell 3y ago
        Oh I totally agree with you on that. It's just that "just add syntax" is incredibly difficult even as a greenfield effort, much less trying to fix an existing language, especially one as old and used as Python. If the (studied) metric that "if over 20% to 25% of a thing needs to be redone, restart it from scratch" is true, then a new language altogether is probably the way and let Python just be Python.
clawlor 3y ago
> [...] when it would just be ‘class Foo<T>’ in almost any other language. Good news on that front at least. PEP-895 [1] removes the need for `T = TypeVar(...)` boilerplate in Python 3.12. [1] - https://peps.python.org/pep-0695/ https://peps.python.org/pep-0695/
- roflyear 3y ago
  Yes. Incremental change is good imo. They may actually be moving too fast.
  - mumblemumble 3y ago
    Incremental change is good as long as the increments can themselves be changed. When you're promising indefinite backward compatibility, it's important to be VERY confident of each change before committing to it. It seems like the price of all these small incremental changes in Python is that the language as a whole keeps falling further and further away from the 13th item in PEP20: "There should be one - and preferably only one - obvious way to do it." Also, for that matter, "Never is often better than *right* now."
    - roflyear 3y ago
      I think you're right, but maybe times that those mantras change.
roflyear 3y ago
I do. It works well.

movedx 3y ago

Personally, I switched to Go.

Sosh101 3y ago
I've been thinking about getting into go - do you mind giving some pros/cons?
- sidlls 3y ago
  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 runtime failure when a 'type' doesn't implement a method (since that would be caught at compile time in Go), but it leads to what I consider an abusive over-reliance on ad-hoc interfaces that just get in the way of understanding the code (runtime or test code) * Go's error handling method is inefficient and generally awful. I'm not talking about the verbosity (it's a relatively small issue, in my opinion), I'm talking about that in Go errors are just strings with a gross, inefficient library and system for adding context * Go's generics implementation is, to put it mildly, inadequate; doing anything mildly interesting with it will be a cumbersome chore * Go's handling of dependencies...leaves something to be desired
  - leetrout 3y ago
    > 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 <npm|pip|maven>
    - sidlls 3y ago
      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 dependencies-of-dependencies that python does. It leads to bloat and sometimes inconsistent behaviors in applications.
      - leetrout 3y ago
        > 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)
    - DangitBobby 3y ago
      I don't have a ton of go experience but it seems like there isn't a way to declare tool/binary dependencies that aren't imported anywhere. We ran into this problem for codegen libraries.
  - DangitBobby 3y ago
    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 almost certainly encounter panics from a nil dereference at some point (or in my experience basically all production bugs were the result of one) * If you work with a legacy project, early lack of generics encouraged copy/paste spaghetti piles * Due to early lack of real generics, many popular libraries (such as ent) used codegen to make generic behavior possible. Generated code balloons PRs (unless you take care to quarantine them to their own commit and share commit ranges for diffs), and gets in the way of understanding code you care about.
- ojosilva 3y ago
  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=PLZaoyhMXgBzoM9bfb5pyUOT3zjnaDdSEP https://www.youtube.com/watch?v=Q3AhzHq8ogs&list=PLZaoyhMXgB...
deleted 3y ago
[deleted]
willmeyers 3y ago
I've started this transition as well. I love Python, but loathe it's typing and anything to do with asyncio.
FireInsight 3y ago
Personally, I switched to Go and soon after to Nim. https://nim-lang.org/ https://nim-lang.org/ It's great!
- lucidrains 3y ago
  Same, I love it! Having done ruby, javascript, python, I'm allowed one niche language (although I really hope it grows in popularity!)

nwatson 3y ago

A good IDE like PyCharm makes it pretty simple, will offer to write all the import statements for you when you reference something that's new to the file you're working on. I'm taking a pretty decent course on Udemy right now, but the instructor said they didn't see the value in PyCharm and they're writing all this extra boilerplate by hand in VSCode. I started using copilot recently and that's accelerated the process even more.

miiiiiike 3y ago
These are not complicated tasks that should require a plugin or an AI assistant to make bearable. Just add the syntax to the language.
- michaelcampbell 3y ago
  > 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.
  - miiiiiike 3y ago
    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?
    - michaelcampbell 3y ago
      Oh I totally agree with you on that. It's just that "just add syntax" is incredibly difficult even as a greenfield effort, much less trying to fix an existing language, especially one as old and used as Python. If the (studied) metric that "if over 20% to 25% of a thing needs to be redone, restart it from scratch" is true, then a new language altogether is probably the way and let Python just be Python.

clawlor 3y ago

> [...] when it would just be ‘class Foo<T>’ in almost any other language. Good news on that front at least. PEP-895 [1] removes the need for `T = TypeVar(...)` boilerplate in Python 3.12. [1] - https://peps.python.org/pep-0695/ https://peps.python.org/pep-0695/

roflyear 3y ago
Yes. Incremental change is good imo. They may actually be moving too fast.
- mumblemumble 3y ago
  Incremental change is good as long as the increments can themselves be changed. When you're promising indefinite backward compatibility, it's important to be VERY confident of each change before committing to it. It seems like the price of all these small incremental changes in Python is that the language as a whole keeps falling further and further away from the 13th item in PEP20: "There should be one - and preferably only one - obvious way to do it." Also, for that matter, "Never is often better than *right* now."
  - roflyear 3y ago
    I think you're right, but maybe times that those mantras change.

roflyear 3y ago

I do. It works well.