3 ms·

Useful product, great marketing site. This is obviously a labor of love. Keep it up! Sadly I've moved on from Python world. Funny anecdote, using Pydantic eve

Useful product, great marketing site. This is obviously a labor of love. Keep it up! Sadly I've moved on from Python world. Funny anecdote, using Pydantic everywhere to improve maintainability made me realize I'm fighting an uphill battle with Python and I should move to a statically typed language, so I switched to C#. Thanks for your work.

sirsinsalot 2y ago
Honestly, after spending the last 10 years developing in Python, I'm considering doing something similar. I've lived the problems. They suck for engineering software with longevity.
necovek 2y ago
This is admittedly an unpopular opinion. I've actually really wondered why one wants static typing, especially with a language as expressive as Python, and where you can be so efficient with it? At a time, I was mesmerized with Zope (esp 3), but learned that nobody really learns to use it, but instead learns to work around it — for the uninitiated, Zope provided "interfaces", you'd have classes implementing those interfaces, and you could happily mix and match with "configuration" that lived in ZCML (an XML schema) files, way back in early 2000s. Static typing really kills off some of the biggest benefits of using Python (like "duck typing" to quickly emulate an identical API without having to construct a hierarchy of types before you can do that). How many bugs have you really hit in your Python code because of lack of static types? For ~20 years of doing Python, I honestly believe that it could have helped me at most once or twice. Generally, doing sufficient level of testing has covered most potential misuse of code, and you need to have tests anyway. The reason I'd want to move away from Python is mostly pure performance (loops should not be this slow) and library ecosystem (crappy code has risen to the top), but I find nothing is nearly as expressive, has a comparable standard library plus allows one to be so efficient.
- imiric 2y ago
  > How many bugs have you really hit in your Python code because of lack of static types? I don't work with Python much anymore (happily moved on to Go :), but was a heavy user for ~15 years. And honestly, typing issues were pretty common, if not the most common issue across all codebases I've worked on. The problem with dynamic typing is that, at the end of the day, you're still working with and thinking about types. You have to be implicitly aware of which type the function you're calling expects, which not only increases your mental burden, but makes refactoring much more unreliable. You have to rely on documentation or _very_ thorough tests, which most codebases don't have to the extent and quality they should. With static typing, all of this goes away. Types become explicit (remember "explicit is better than implicit"? Yeah...), you get immediate feedback from your IDE when passing the wrong type, and the code simply doesn't compile. Best of all, you don't learn about a TypeError exception from a Sentry alert after your users run into it. The amount of times this happens in the wild is shockingly high. > For ~20 years of doing Python, I honestly believe that it could have helped me at most once or twice. I honestly struggle to believe this, but good on you if true. > Generally, doing sufficient level of testing has covered most potential misuse of code, and you need to have tests anyway. But that's the thing: in order to catch basic typing issues, you would have to have dozens of tiny and mostly pointless tests for each function. Yes you need tests, but most tests, even at the unit level, shouldn't be concerned about types, but about the functionality. And you won't catch typing issues at the boundaries in integration, or higher level tests. Static typing simply helps you avoid all of this nuisance, and ultimately write more robust and maintainable code. If I was ever to work on a Python codebase again, I wouldn't consider it without a runtime type checker like Mypy, or whatever state of the art tooling is these days. All the supposed freedom of dynamic and duck typing just isn't worth it.
  - necovek 2y ago
    > I honestly struggle to believe this, but good on you if true. Having seen some of the codebases in the wild as I moved projects, I can understand why someone would feel that way — and to be honest, I was referring to the code I wrote, not necessarily code that someone else wrote, where I've seen many type errors, but which were really either irrelevant (exceptions that should have been "nicer" errors, as in, this was bad data getting passed in between systems), or missing functional tests (see below). Notably, once I moved to a Go codebase, I uncovered a weird bug that could have been caught by typing, but really wasn't due to induced type complexity by the developers to get things to work at all — mostly to demonstrate that complex type structure likely leads to bugs, rather than typing or lack of typing. > But that's the thing: in order to catch basic typing issues, you would have to have dozens of tiny and mostly pointless tests for each function. Yes, that's the thing: I am specifically not referring to the "typing" type of test like "this throws an error if an int is passed in instead of a str" or BaseFoo instead of BaseBar, but really, a test that confirms something fails when it needs to fail, and works when it needs to pass — iow, regular functional tests that you need either way. > Static typing simply helps you avoid all of this nuisance, and ultimately write more robust and maintainable code. I fully accept that may be true for some codebases, but I don't think it's true for everyone. My biggest gripe with Python is that idiomatic (or maybe "widely accepted way to write") Python leads to less robust and maintainable code, and non-stdlib packages are really, really, crappy. Django does like a gazillion of those anti-patterns, but even things like SQLAlchemy, Requests, Flask, FastAPI are problematic. I had the (mis?)fortune to land my first real job in a wonderful TDD shop way back in mid-2000s, and after I survived 6 months without getting fired (and it was close, I heard later :)), it was an excellent learning opportunity.
  - rewsiffer 2y ago
    You perfectly articulated how I feel about python and why I am trying to move my team’s projects to Go.
    - neonsunset 2y ago
      Hopefully Go being such a bare bones language with unsound features will tire you out soon enough to follow the sibling comment in moving to C# instead :)
- hakanderyal 2y ago
  Main selling point for me is productivity. Performance benefits are just icing on the cake. Being explicit about types allows the IDE and platform to help you write & refactor code, allowing your brain to work on the actual problem instead. This may sound surprising but modern C#/.NET is almost as expressive as Python. You don`t need unnecessary boilerplate or AbstractBaseFactorySingletonProxyDecoratorAdapterWrapper style types. LINQ alone is a game changer. I`m still writing code with almost same style as Python in C#, but now with the power of IDE behind me. I`m much more productive. Interfaces are duck typing in an explicit form. Being explicit about it may sound more work, but you also need that work in Python if you want your solution to become maintainable, in the form of tests. I`ve been using Python for ~10 years (with years of PHP/Ruby before) and written probably hundreds of thousands of lines of code. One thing I don`t like while programming is doing unnecessary work myself if the computer can do it. So I do a lot of meta programming and build abstractions when it becomes annoying to repeat myself. There had been a lot of moments where I return to a highly dynamic part of code that I`ve written months before to fix a bug and spend a lot of time trying to figure out how everything is connected. Same code in C# is both quicker to write (once you grok how reflection works and how everything is tied together), and infinitely more maintainable for less work. Give C#/.NET a serious try. You may become surprised. I was.
  - necovek 2y ago
    > LINQ alone is a game changer. I`m still writing code with almost same style as Python in C#,... That's very curious: do you have any quick examples that you could point me to? I was generally intrigued by C# and .NET way back when it was introduced and especially when Mono started shipping the runtime for Linux, but I hated the boilerplate and couldn't move away from Python for that reason.
    - necovek 2y ago
      FWIW, I've read up on LINQ and it strikes me as having exactly the same issues as any ORM generally does: you lose on the expressiveness needed to get most optimal querying capabilities for the tool in use (eg. Postgres specifics or SQLite specifics or...). This is not to say that one should use string concatenation to construct queries, but that you want smart tools that do just enough. I.e. I like Storm expression language or sqlalchemy-core to express SQL as Python, but getting into deeper ORM level stuff generally harms what you can achieve once you need more complex stuff.
- LtWorf 2y ago
  You want correct data.
joshsyn 2y ago
[dead]
BurningFrog 2y ago
When I get tired of Python, I think of working in Ruby instead. Maybe it's the Python disease of trying to be everything at once, which can end up as the worst of all worlds. Ruby is a proudly untyped language, and that's all it is.
- neonsunset 2y ago
  It does not offer better productivity, sometimes worse due to brittleness, at the cost of 0.1x performance of .NET. It is this easy to make a back-end application with ASP.NET Core: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis/overview?view=aspnetcore-8.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...

sirsinsalot 2y ago

Honestly, after spending the last 10 years developing in Python, I'm considering doing something similar. I've lived the problems. They suck for engineering software with longevity.

necovek 2y ago

This is admittedly an unpopular opinion. I've actually really wondered why one wants static typing, especially with a language as expressive as Python, and where you can be so efficient with it? At a time, I was mesmerized with Zope (esp 3), but learned that nobody really learns to use it, but instead learns to work around it — for the uninitiated, Zope provided "interfaces", you'd have classes implementing those interfaces, and you could happily mix and match with "configuration" that lived in ZCML (an XML schema) files, way back in early 2000s. Static typing really kills off some of the biggest benefits of using Python (like "duck typing" to quickly emulate an identical API without having to construct a hierarchy of types before you can do that). How many bugs have you really hit in your Python code because of lack of static types? For ~20 years of doing Python, I honestly believe that it could have helped me at most once or twice. Generally, doing sufficient level of testing has covered most potential misuse of code, and you need to have tests anyway. The reason I'd want to move away from Python is mostly pure performance (loops should not be this slow) and library ecosystem (crappy code has risen to the top), but I find nothing is nearly as expressive, has a comparable standard library plus allows one to be so efficient.

imiric 2y ago
> How many bugs have you really hit in your Python code because of lack of static types? I don't work with Python much anymore (happily moved on to Go :), but was a heavy user for ~15 years. And honestly, typing issues were pretty common, if not the most common issue across all codebases I've worked on. The problem with dynamic typing is that, at the end of the day, you're still working with and thinking about types. You have to be implicitly aware of which type the function you're calling expects, which not only increases your mental burden, but makes refactoring much more unreliable. You have to rely on documentation or _very_ thorough tests, which most codebases don't have to the extent and quality they should. With static typing, all of this goes away. Types become explicit (remember "explicit is better than implicit"? Yeah...), you get immediate feedback from your IDE when passing the wrong type, and the code simply doesn't compile. Best of all, you don't learn about a TypeError exception from a Sentry alert after your users run into it. The amount of times this happens in the wild is shockingly high. > For ~20 years of doing Python, I honestly believe that it could have helped me at most once or twice. I honestly struggle to believe this, but good on you if true. > Generally, doing sufficient level of testing has covered most potential misuse of code, and you need to have tests anyway. But that's the thing: in order to catch basic typing issues, you would have to have dozens of tiny and mostly pointless tests for each function. Yes you need tests, but most tests, even at the unit level, shouldn't be concerned about types, but about the functionality. And you won't catch typing issues at the boundaries in integration, or higher level tests. Static typing simply helps you avoid all of this nuisance, and ultimately write more robust and maintainable code. If I was ever to work on a Python codebase again, I wouldn't consider it without a runtime type checker like Mypy, or whatever state of the art tooling is these days. All the supposed freedom of dynamic and duck typing just isn't worth it.
- necovek 2y ago
  > I honestly struggle to believe this, but good on you if true. Having seen some of the codebases in the wild as I moved projects, I can understand why someone would feel that way — and to be honest, I was referring to the code I wrote, not necessarily code that someone else wrote, where I've seen many type errors, but which were really either irrelevant (exceptions that should have been "nicer" errors, as in, this was bad data getting passed in between systems), or missing functional tests (see below). Notably, once I moved to a Go codebase, I uncovered a weird bug that could have been caught by typing, but really wasn't due to induced type complexity by the developers to get things to work at all — mostly to demonstrate that complex type structure likely leads to bugs, rather than typing or lack of typing. > But that's the thing: in order to catch basic typing issues, you would have to have dozens of tiny and mostly pointless tests for each function. Yes, that's the thing: I am specifically not referring to the "typing" type of test like "this throws an error if an int is passed in instead of a str" or BaseFoo instead of BaseBar, but really, a test that confirms something fails when it needs to fail, and works when it needs to pass — iow, regular functional tests that you need either way. > Static typing simply helps you avoid all of this nuisance, and ultimately write more robust and maintainable code. I fully accept that may be true for some codebases, but I don't think it's true for everyone. My biggest gripe with Python is that idiomatic (or maybe "widely accepted way to write") Python leads to less robust and maintainable code, and non-stdlib packages are really, really, crappy. Django does like a gazillion of those anti-patterns, but even things like SQLAlchemy, Requests, Flask, FastAPI are problematic. I had the (mis?)fortune to land my first real job in a wonderful TDD shop way back in mid-2000s, and after I survived 6 months without getting fired (and it was close, I heard later :)), it was an excellent learning opportunity.
- rewsiffer 2y ago
  You perfectly articulated how I feel about python and why I am trying to move my team’s projects to Go.
  - neonsunset 2y ago
    Hopefully Go being such a bare bones language with unsound features will tire you out soon enough to follow the sibling comment in moving to C# instead :)
hakanderyal 2y ago
Main selling point for me is productivity. Performance benefits are just icing on the cake. Being explicit about types allows the IDE and platform to help you write & refactor code, allowing your brain to work on the actual problem instead. This may sound surprising but modern C#/.NET is almost as expressive as Python. You don`t need unnecessary boilerplate or AbstractBaseFactorySingletonProxyDecoratorAdapterWrapper style types. LINQ alone is a game changer. I`m still writing code with almost same style as Python in C#, but now with the power of IDE behind me. I`m much more productive. Interfaces are duck typing in an explicit form. Being explicit about it may sound more work, but you also need that work in Python if you want your solution to become maintainable, in the form of tests. I`ve been using Python for ~10 years (with years of PHP/Ruby before) and written probably hundreds of thousands of lines of code. One thing I don`t like while programming is doing unnecessary work myself if the computer can do it. So I do a lot of meta programming and build abstractions when it becomes annoying to repeat myself. There had been a lot of moments where I return to a highly dynamic part of code that I`ve written months before to fix a bug and spend a lot of time trying to figure out how everything is connected. Same code in C# is both quicker to write (once you grok how reflection works and how everything is tied together), and infinitely more maintainable for less work. Give C#/.NET a serious try. You may become surprised. I was.
- necovek 2y ago
  > LINQ alone is a game changer. I`m still writing code with almost same style as Python in C#,... That's very curious: do you have any quick examples that you could point me to? I was generally intrigued by C# and .NET way back when it was introduced and especially when Mono started shipping the runtime for Linux, but I hated the boilerplate and couldn't move away from Python for that reason.
  - necovek 2y ago
    FWIW, I've read up on LINQ and it strikes me as having exactly the same issues as any ORM generally does: you lose on the expressiveness needed to get most optimal querying capabilities for the tool in use (eg. Postgres specifics or SQLite specifics or...). This is not to say that one should use string concatenation to construct queries, but that you want smart tools that do just enough. I.e. I like Storm expression language or sqlalchemy-core to express SQL as Python, but getting into deeper ORM level stuff generally harms what you can achieve once you need more complex stuff.
LtWorf 2y ago
You want correct data.

joshsyn 2y ago

[dead]

BurningFrog 2y ago

When I get tired of Python, I think of working in Ruby instead. Maybe it's the Python disease of trying to be everything at once, which can end up as the worst of all worlds. Ruby is a proudly untyped language, and that's all it is.

neonsunset 2y ago
It does not offer better productivity, sometimes worse due to brittleness, at the cost of 0.1x performance of .NET. It is this easy to make a back-end application with ASP.NET Core: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis/overview?view=aspnetcore-8.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...