11 ms·

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

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 commit a public API into a file, you can start with untyped code and add some later. That makes it cumbersome sometimes, yes. mypy is slow, and the typing system + match / case have many rough edges. But it also keeps Python incredibly versatile. It's amazing what you can do with this (not so) little language, and the whole ecosystem is always getting better and better. Every time I try another language, I keep getting back into Python, because the fields I need tools for are vast, and it's the only one that I'm pretty sure will handle a problem decently in all it's various forms, especially the one I didn't consider when I started. There is immense value in this, because it keeps opportunities on the table no matter what you do. I often find my self during a project adding something I could only because Python let me do so easily. Python is quirky, yet it still damn practical.

timkofu 3y ago
> 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 ... I thought this is how most of us use Python? I find it repulsive to use without types. type_hints enable me to use it for Software Engineering, and I get to keep the Data Science stack, which is solid gold.
tialaramex 3y ago
> the fields I need tools for are vast, and it's the only one that I'm pretty sure will handle a problem decently in all it's various forms Whilst I agree with this stance to some extent, we should be clear that Python is not in fact the panacea you've made it out to be here. It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clumsy and must be rewritten in a better language. It is also very possible that a particular problem requires safety Python can't match, so that any Python solution will be too dangerous and must be rewritten in an appropriate safe language to avoid unacceptable losses.
- BiteCode_dev 3y ago
  > the panacea you've made it out to be here. This is misreading my comment, at best. > It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clumsy and must be rewritten in a better language. This has been discussed again and again on HN, and the answer to it still stands to this day. So now I'm not giving you the benefit of the doubt.
  - tialaramex 3y ago
    > This is misreading my comment, at best. If you don't like the characterization as a panacea, what would you prefer - jack of all trades maybe? All-purpose language ? > This has been discussed again and again on HN, and the answer to it still stands to this day. So now I'm not giving you the benefit of the doubt. I'd guess you're thinking you'll measure and just rewrite the hot code paths. The problem is in too many cases when industrialising software it's basically all hot, the heatmap just all glows red. Google people did talks about this maybe a decade ago, it's why Go ended up getting internal support, because if you write software the first time in a language with better performance you don't need to do the rewrite. I think Python's actual strength is as a language for people whose job isn't primarily to write software. Let me give an example of a choice Python made (admittedly not for years) that is exactly what you should do for that audience, and then the opposite: Ordered Dictionaries make dict have reasonable performance and yet also behave how naive users who have only a limited understanding of how the machine works would expect, which means they produce less buggy software in practice Multiple Inheritance is too complicated to teach to a class of say, Geographers, and yet it's not really crucial for the underpinnings of the language, so why go to such lengths to support this feature ?
  - deleted 3y ago
    [deleted]
golergka 3y ago
Everything you just said is true for Typescript, as you can set it up as strict or as forgiving as you like, and writing one off scripts for node is just as easy as for Python. But unlike Python, it has a great type system.
- chpatrick 3y ago
  TypeScript doesn't have the fantastic numpy/scipy/torch ecosystem though. I wish I could have TypeScript's block scope and type system but have access to Python's ecosystem. That would be a great combination.
- BiteCode_dev 3y ago
  Not really. First, the JS ecosystem is very web oriented, so if you want to dabble out of there, you often gonna fall short. Secondly, the JS packaging has very poor support for compiled extensions, which mean everything that needs a perf boosts is unlikely to get good quality treatments. Finally, the community makes it a constant moving target. After 20 years of writing both JS and Python, I can still install old django projects that use 2.7 (did it 2 months ago), but JS projects for even 5 years ago are a very hard to build. Bottom line, I use JS for the Web because I have to, given it has monopoly on the browser, and now good GUI, but if I want to keep my options open, I would rather go rust or go than JS.
  - devjab 3y ago
    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. We found the package support to be far superior in JavaScript. Even a lot of non-web things like working with solar inverters and various other green energy technologies (which at least here in Europe is very, very old school) we’re significantly easier with JavaScript than they were with Python. I guess FTP is web, but it’s the example I remember the best because I had to write my own Python library for it because the most used packages couldn’t handle a range of our needs. This may be because it’s FTP is not me shortening SFTP, no no, that’s just what solar plant engineers figured would be practical. Sure they recommend you don’t put the inverters directly on the internet in their manuals, but who reads those? Not solar plant installers at least. Anyway, I fully expected Python to be king for those things considering it’s what runs a lot of IoT, but JavaScript was just plain better at it. Which is generally the story of our migration of basically everything to typescript. Some or our C++ code ended up as Rust, and I really, really, love Rust, but most of our code base is now Typescript. It might all have been Rust if Rust was a frontend web language, but it would never be Python. The reason for this is the environment. Not just the package and module systems, but also how you can set up a very “functional programming” (in quotes because it’s not really FP but JSFP) to cut down on the usage of OOP unless absolutely advantageous, type safety, specific coding systems and how easy it is to actually enforce all of those things automatically. Is just a much better experience with Typescript compared to Python in our experience. I think you could very likely achieve some of the same with JSDoc and JS and not Typescript, but we couldn’t get that to work (as well) in our internal tooling. Somewhat ironically, the two areas JavaScript wasn’t better than Python were in what I’d consider web-related parts of your tech stack. There aren’t any good JS SQL ORMs, Prisma is ok and so is MikroOrm but none of them compare to what’s available in Python. The other is handling XML, which is soooo easy in Python. I mean theoretically it should always be easy to handle XML, but that would require the XML you need to handle to actually adhere to any form of standards, which I guess is utopia. But I guess you can have very different experiences.
Yoric 3y ago
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 together, with undocumented (and often inconsistent) invariants "because something will eventually throw a TypeError if I make a mistake", undocumented metaprogramming, and heroic levels of maintenance because this stuff works until it doesn't. 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. Option 2. feels like "experiments running out of control". That is the unfortunate price of this incredible versatility. I don't have a clear conclusion to this, except perhaps that Python is really good for the initial experimentation (when versatility actually gets you to initial results much faster), but really bad for... well, let's call it industralization.
- BiteCode_dev 3y ago
  To be fair, a division between hell and heaven will happen with any language. The question is: is this particular hell worth the result? There is no generic answer to that of course, it just happens is has been the case for me during those 20 years. First, you have to get to the industrialization phase. And of course, you have to get there, with the constraint of time, budgets, and talent. Second, Python does have less benefits for that phase than rust or haskel, but it's not impotent. Industrialization is just hard, no matter the language. Because we are an industry where a lot of self-taught people get a career, we tend to forget this last point. Creating a serious computing system is engineering, and this includes the project management part, and being rigorous about a lot of thing. Granted, the rigor needs to be higher with Python once your reach that scale, and at a certain point (which I wish everybody would reach), you may want to ditch it. It's a good problem to have though. Yet we have to remember not all industrialization attempts are equal. Most are really tame. I'd argue you could replace half the website code base out there with a bunch of bash scripts on a VPS and they would still make money. So even in this context, Python can deliver a lot.
  - 3y ago
Waterluvian 3y ago
I agree. In some cases I hate when I have to use Python for a task that really deserves full typings because Python’s type hints are so half baked. But all other times, I like just sprinkling them in where relevant. Python is great at being okay at everything. That’s a real power.
carapace 3y ago
The main drawback of Python is that it ruins you for other languages. Python is a scripting language, it's great for scripts and one-offs, etc. But once you get above, say, 100K LoC it starts to get out of its sweet spot and into more direct competition with languages like, e.g. OCaml.
dragonsh 3y ago
> 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. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! >>>
- nrakx 3y ago
  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 bases.
  - baq 3y ago
    and classes are most of the time not needed anyway, it's just Java programmers that aren't used to the idea that code can be perfectly correct and readable without a single class
  - fastasucan 3y ago
    Are you really saying that these are the two coding styles of Python? Any source for this claim?
- jen20 3y ago
zokier 3y ago
> the whole ecosystem is always getting better and better. That is debatable. In many ways the ecosystem is getting more enterprisy, more ceremonious, overall "heavier". I feel Python ecosystem is rapidly losing its winning characteristic lightness that was so defining for it 10ish years ago. I don't think "modern" Python code like in the article would inspire comics like this https://xkcd.com/353/ https://xkcd.com/353/
loeg 3y ago
You are allowed to include more than once sentence in a paragraph here. It would substantially improve your comment.
agumonkey 3y ago
who's using hypothesis these days ? or any advanced testing paradigm even.
nonethewiser 3y ago
It could have a better type system and be just as versatile.
marcosdumay 3y ago
Python can only be second-best at anything if you take advantage of its strengths and avoid its weaknesses. If you insist on taking advantage of its weaknesses, it will suck completely. The typing system is a huge weakness. If you insist on focusing on it, it won't be a good language.
x0x0 3y ago
Plus excellent testing support. If you eg interact with remote apis a lot, you can write the natural code: some api calls for setup, then your business logic, then more api calls... and then test this. In one linear function that is straightforward to understand. With great mock support, no need for code generation for mocking, etc. Ruby is one of the few languages sharing this excellent support. All the other common languages require some combination of dependency injection, code generation for mocking, spewing unnecessary interfaces all over your code and turning it into a tangled mess of logic smeared across many functions, etc.
throwaway894345 3y ago
I’ve been a Python developer for about 15 years and it isn’t good at most things. Performance is bad, package management is bad, typing is bad, async is bad, etc. Mostly it shines these days because of early mindshare in an exploding niche (AI/ML/numeric computing).
- throwmeout123 3y ago
  This, after eight years with py I’m sick of it and of the stupid direction it’s taking
- kobzol 3y ago
  Hey now. Async in Python ain't that bad :)
  - throwaway894345 3y ago
    I’ve seen a lot of outages in production which were very hard to debug because someone blocked the event loop with a sync call or some CPU-intensive thing. The failures weren’t in the route that was blocking the event loop, but all over the place, including health checks, which would cause instances to be bounced until the whole service fell over. Go doesn’t have problems like this—you could theoretically block the event loop with something sufficiently CPU-intensive, but Go schedules work across all cores (and moreover, Go gets hundreds or thousands of times more work done per core than Python, so it’s far less likely to run into these problems) so this becomes highly unlikely.
6r17 3y ago
Hei ! This comment inspired me because I was working on data-types at my company at the moment and I realized how static typing would have really benefited us. So I made a library that does just that ! https://github.com/6r17/madtypes https://github.com/6r17/madtypes I hope this will help some people !
fastasucan 3y ago
>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.
- berkes 3y ago
  > very few Python users have type safety as their most important factor This is a text-book example of selection-bias though.
peteradio 3y ago
But you can't overload a function name.
mananaysiempre 3y ago
> Python is[] not meant to be the best at anything, but good at most things. I haven’t yet had the time to look at dataclasses and pattern matching in recent versions, so serious question: do we finally have a standard solution for doing algebraic-datatype-style stuff? I do have a generic visitor implementation lying around somewhere, but that doesn’t change the fact that every time I see any writeup of the type “Let’s do <a thing involving syntax> in Python!”, I spend most of my reading time wishing they had used SML or OCaml—and I don’t even know OCaml.

timkofu 3y ago

> 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 ... I thought this is how most of us use Python? I find it repulsive to use without types. type_hints enable me to use it for Software Engineering, and I get to keep the Data Science stack, which is solid gold.

tialaramex 3y ago

> the fields I need tools for are vast, and it's the only one that I'm pretty sure will handle a problem decently in all it's various forms Whilst I agree with this stance to some extent, we should be clear that Python is not in fact the panacea you've made it out to be here. It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clumsy and must be rewritten in a better language. It is also very possible that a particular problem requires safety Python can't match, so that any Python solution will be too dangerous and must be rewritten in an appropriate safe language to avoid unacceptable losses.

BiteCode_dev 3y ago
> the panacea you've made it out to be here. This is misreading my comment, at best. > It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clumsy and must be rewritten in a better language. This has been discussed again and again on HN, and the answer to it still stands to this day. So now I'm not giving you the benefit of the doubt.
- tialaramex 3y ago
  > This is misreading my comment, at best. If you don't like the characterization as a panacea, what would you prefer - jack of all trades maybe? All-purpose language ? > This has been discussed again and again on HN, and the answer to it still stands to this day. So now I'm not giving you the benefit of the doubt. I'd guess you're thinking you'll measure and just rewrite the hot code paths. The problem is in too many cases when industrialising software it's basically all hot, the heatmap just all glows red. Google people did talks about this maybe a decade ago, it's why Go ended up getting internal support, because if you write software the first time in a language with better performance you don't need to do the rewrite. I think Python's actual strength is as a language for people whose job isn't primarily to write software. Let me give an example of a choice Python made (admittedly not for years) that is exactly what you should do for that audience, and then the opposite: Ordered Dictionaries make dict have reasonable performance and yet also behave how naive users who have only a limited understanding of how the machine works would expect, which means they produce less buggy software in practice Multiple Inheritance is too complicated to teach to a class of say, Geographers, and yet it's not really crucial for the underpinnings of the language, so why go to such lengths to support this feature ?
- deleted 3y ago
  [deleted]

golergka 3y ago

Everything you just said is true for Typescript, as you can set it up as strict or as forgiving as you like, and writing one off scripts for node is just as easy as for Python. But unlike Python, it has a great type system.

chpatrick 3y ago
TypeScript doesn't have the fantastic numpy/scipy/torch ecosystem though. I wish I could have TypeScript's block scope and type system but have access to Python's ecosystem. That would be a great combination.
BiteCode_dev 3y ago
Not really. First, the JS ecosystem is very web oriented, so if you want to dabble out of there, you often gonna fall short. Secondly, the JS packaging has very poor support for compiled extensions, which mean everything that needs a perf boosts is unlikely to get good quality treatments. Finally, the community makes it a constant moving target. After 20 years of writing both JS and Python, I can still install old django projects that use 2.7 (did it 2 months ago), but JS projects for even 5 years ago are a very hard to build. Bottom line, I use JS for the Web because I have to, given it has monopoly on the browser, and now good GUI, but if I want to keep my options open, I would rather go rust or go than JS.
- devjab 3y ago
  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. We found the package support to be far superior in JavaScript. Even a lot of non-web things like working with solar inverters and various other green energy technologies (which at least here in Europe is very, very old school) we’re significantly easier with JavaScript than they were with Python. I guess FTP is web, but it’s the example I remember the best because I had to write my own Python library for it because the most used packages couldn’t handle a range of our needs. This may be because it’s FTP is not me shortening SFTP, no no, that’s just what solar plant engineers figured would be practical. Sure they recommend you don’t put the inverters directly on the internet in their manuals, but who reads those? Not solar plant installers at least. Anyway, I fully expected Python to be king for those things considering it’s what runs a lot of IoT, but JavaScript was just plain better at it. Which is generally the story of our migration of basically everything to typescript. Some or our C++ code ended up as Rust, and I really, really, love Rust, but most of our code base is now Typescript. It might all have been Rust if Rust was a frontend web language, but it would never be Python. The reason for this is the environment. Not just the package and module systems, but also how you can set up a very “functional programming” (in quotes because it’s not really FP but JSFP) to cut down on the usage of OOP unless absolutely advantageous, type safety, specific coding systems and how easy it is to actually enforce all of those things automatically. Is just a much better experience with Typescript compared to Python in our experience. I think you could very likely achieve some of the same with JSDoc and JS and not Typescript, but we couldn’t get that to work (as well) in our internal tooling. Somewhat ironically, the two areas JavaScript wasn’t better than Python were in what I’d consider web-related parts of your tech stack. There aren’t any good JS SQL ORMs, Prisma is ok and so is MikroOrm but none of them compare to what’s available in Python. The other is handling XML, which is soooo easy in Python. I mean theoretically it should always be easy to handle XML, but that would require the XML you need to handle to actually adhere to any form of standards, which I guess is utopia. But I guess you can have very different experiences.

Yoric 3y ago

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 together, with undocumented (and often inconsistent) invariants "because something will eventually throw a TypeError if I make a mistake", undocumented metaprogramming, and heroic levels of maintenance because this stuff works until it doesn't. 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. Option 2. feels like "experiments running out of control". That is the unfortunate price of this incredible versatility. I don't have a clear conclusion to this, except perhaps that Python is really good for the initial experimentation (when versatility actually gets you to initial results much faster), but really bad for... well, let's call it industralization.

BiteCode_dev 3y ago
To be fair, a division between hell and heaven will happen with any language. The question is: is this particular hell worth the result? There is no generic answer to that of course, it just happens is has been the case for me during those 20 years. First, you have to get to the industrialization phase. And of course, you have to get there, with the constraint of time, budgets, and talent. Second, Python does have less benefits for that phase than rust or haskel, but it's not impotent. Industrialization is just hard, no matter the language. Because we are an industry where a lot of self-taught people get a career, we tend to forget this last point. Creating a serious computing system is engineering, and this includes the project management part, and being rigorous about a lot of thing. Granted, the rigor needs to be higher with Python once your reach that scale, and at a certain point (which I wish everybody would reach), you may want to ditch it. It's a good problem to have though. Yet we have to remember not all industrialization attempts are equal. Most are really tame. I'd argue you could replace half the website code base out there with a bunch of bash scripts on a VPS and they would still make money. So even in this context, Python can deliver a lot.
- 3y ago

Waterluvian 3y ago

I agree. In some cases I hate when I have to use Python for a task that really deserves full typings because Python’s type hints are so half baked. But all other times, I like just sprinkling them in where relevant. Python is great at being okay at everything. That’s a real power.

carapace 3y ago

The main drawback of Python is that it ruins you for other languages. Python is a scripting language, it's great for scripts and one-offs, etc. But once you get above, say, 100K LoC it starts to get out of its sweet spot and into more direct competition with languages like, e.g. OCaml.

dragonsh 3y ago

> 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. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! >>>

nrakx 3y ago
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 bases.
- baq 3y ago
  and classes are most of the time not needed anyway, it's just Java programmers that aren't used to the idea that code can be perfectly correct and readable without a single class
- fastasucan 3y ago
  Are you really saying that these are the two coding styles of Python? Any source for this claim?
jen20 3y ago

zokier 3y ago

> the whole ecosystem is always getting better and better. That is debatable. In many ways the ecosystem is getting more enterprisy, more ceremonious, overall "heavier". I feel Python ecosystem is rapidly losing its winning characteristic lightness that was so defining for it 10ish years ago. I don't think "modern" Python code like in the article would inspire comics like this https://xkcd.com/353/ https://xkcd.com/353/

loeg 3y ago

You are allowed to include more than once sentence in a paragraph here. It would substantially improve your comment.

agumonkey 3y ago

who's using hypothesis these days ? or any advanced testing paradigm even.

nonethewiser 3y ago

It could have a better type system and be just as versatile.

marcosdumay 3y ago

Python can only be second-best at anything if you take advantage of its strengths and avoid its weaknesses. If you insist on taking advantage of its weaknesses, it will suck completely. The typing system is a huge weakness. If you insist on focusing on it, it won't be a good language.

x0x0 3y ago

Plus excellent testing support. If you eg interact with remote apis a lot, you can write the natural code: some api calls for setup, then your business logic, then more api calls... and then test this. In one linear function that is straightforward to understand. With great mock support, no need for code generation for mocking, etc. Ruby is one of the few languages sharing this excellent support. All the other common languages require some combination of dependency injection, code generation for mocking, spewing unnecessary interfaces all over your code and turning it into a tangled mess of logic smeared across many functions, etc.

throwaway894345 3y ago

I’ve been a Python developer for about 15 years and it isn’t good at most things. Performance is bad, package management is bad, typing is bad, async is bad, etc. Mostly it shines these days because of early mindshare in an exploding niche (AI/ML/numeric computing).

throwmeout123 3y ago
This, after eight years with py I’m sick of it and of the stupid direction it’s taking
kobzol 3y ago
Hey now. Async in Python ain't that bad :)
- throwaway894345 3y ago
  I’ve seen a lot of outages in production which were very hard to debug because someone blocked the event loop with a sync call or some CPU-intensive thing. The failures weren’t in the route that was blocking the event loop, but all over the place, including health checks, which would cause instances to be bounced until the whole service fell over. Go doesn’t have problems like this—you could theoretically block the event loop with something sufficiently CPU-intensive, but Go schedules work across all cores (and moreover, Go gets hundreds or thousands of times more work done per core than Python, so it’s far less likely to run into these problems) so this becomes highly unlikely.

6r17 3y ago

Hei ! This comment inspired me because I was working on data-types at my company at the moment and I realized how static typing would have really benefited us. So I made a library that does just that ! https://github.com/6r17/madtypes https://github.com/6r17/madtypes I hope this will help some people !

fastasucan 3y ago

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

berkes 3y ago
> very few Python users have type safety as their most important factor This is a text-book example of selection-bias though.

peteradio 3y ago

But you can't overload a function name.

mananaysiempre 3y ago

> Python is[] not meant to be the best at anything, but good at most things. I haven’t yet had the time to look at dataclasses and pattern matching in recent versions, so serious question: do we finally have a standard solution for doing algebraic-datatype-style stuff? I do have a generic visitor implementation lying around somewhere, but that doesn’t change the fact that every time I see any writeup of the type “Let’s do <a thing involving syntax> in Python!”, I spend most of my reading time wishing they had used SML or OCaml—and I don’t even know OCaml.