4 ms·

I've noticed a trend that migrating from Python 2 to Python 3 includes adding mypy annotations and going async. At that point, why not Go? You're trying to cor

I've noticed a trend that migrating from Python 2 to Python 3 includes adding mypy annotations and going async. At that point, why not Go? You're trying to correct for a language that was designed for scripting, not application software. Go already has a type system, coroutines are a simpler model of concurrency than async (and Go can actually use multithreading), you don't have to choose between writing and async or nonasync library code, built in formatter (wheras Black is still experimental), and the code will run 10x faster.

ApolloFortyNine 8y ago
>You're trying to correct for a language that was designed for scripting, not application software. Well, that's not true. Are you basing this solely over a lack of a type system?
- eesmith 8y ago
  As an historical observation, Python 0.9p1's README said (emphasis mine): > This is Python, an extensible interpreted programming language that combines remarkable power with very clear syntax. > This is version 0.9 (the first beta release), patchlevel 1. > Python can be used instead of shell, Awk or Perl scripts, to write prototypes of real applications, or as an extension language of large systems, you name it. Note the emphasis on "prototypes of real applications." That would suggest that version 0.9 was not really designed for "real applications". However, by the 1.0 release this timid statement disappeared. For example, by the 1.0.3 release the README was telling "For a quick summary of what Python can mean for a UNIX/C programmer, read Misc/BLURB.LUTZ." That quotes an email dated Thu, 14 Oct 1993 17:10:37 GMT which said: > It's central goal is to provide the best of both worlds: the dynamic nature of scripting languages like Perl/TCL/REXX, but also support for general programming found in the more traditional languages like Icon, C, Modula,... > As such, it can function as a scripting/extension language, as a rapid prototyping language, and as a serious software development language. Python is suitable for fast development of large programs, but also does well at throw-away shell coding. Thus, in a very narrow and irrelevantly technical sense, ilovecaching is correct - the very earliest versions of Python were not described as being for full-blown application software. As it turns out, despite not being designed for 'real applications', it turned out to be useful for 'serious software development', and the evolution for the last 27 or so years has kept that goal in mind.
sammnaser 8y ago
I see your point, but I think when migrating over a million loc, it's a question of practicality. Incrementally migrating a project from Python 2 to 3, between which at least large-scale architectural patterns are more-or-less identical, is a completely different story from migrating to Golang, which uses drastically different paradigms to structure code and think about data flow. Reminds me of some of the points made here: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-....
- ilovecaching 8y ago
  Are most people migrating over a million loc? And if they are, is it one million loc Python service, or a bunch of small services that could all be rewritten independently? Chances are the worst case scenario is very rare. Golang really isn't that different from Python. They are both incredibly imperative languages with a one way mentality, and most people who learned CS in college will easily recognize both. The major difference is that Go has much less to learn, and very few patterns to speak of.
oconnor663 8y ago
The crucial lesson from the Python 2 -> 3 transition (which this article is also mainly about) is that incrementality is super valuable. In retrospect, a single codebase supporting 2 and 3 is the obvious best option, but that wasn't at all clear in the beginning. (For example, the u"" string syntax, which is crucial for compatibility, wasn't even legal until 3.3!) Moving to Python 3 incrementally is painful, but it's possible. Moving to a totally different programming language incrementally isn't possible, other than when you're starting brand new projects.

ApolloFortyNine 8y ago

>You're trying to correct for a language that was designed for scripting, not application software. Well, that's not true. Are you basing this solely over a lack of a type system?

eesmith 8y ago
As an historical observation, Python 0.9p1's README said (emphasis mine): > This is Python, an extensible interpreted programming language that combines remarkable power with very clear syntax. > This is version 0.9 (the first beta release), patchlevel 1. > Python can be used instead of shell, Awk or Perl scripts, to write prototypes of real applications, or as an extension language of large systems, you name it. Note the emphasis on "prototypes of real applications." That would suggest that version 0.9 was not really designed for "real applications". However, by the 1.0 release this timid statement disappeared. For example, by the 1.0.3 release the README was telling "For a quick summary of what Python can mean for a UNIX/C programmer, read Misc/BLURB.LUTZ." That quotes an email dated Thu, 14 Oct 1993 17:10:37 GMT which said: > It's central goal is to provide the best of both worlds: the dynamic nature of scripting languages like Perl/TCL/REXX, but also support for general programming found in the more traditional languages like Icon, C, Modula,... > As such, it can function as a scripting/extension language, as a rapid prototyping language, and as a serious software development language. Python is suitable for fast development of large programs, but also does well at throw-away shell coding. Thus, in a very narrow and irrelevantly technical sense, ilovecaching is correct - the very earliest versions of Python were not described as being for full-blown application software. As it turns out, despite not being designed for 'real applications', it turned out to be useful for 'serious software development', and the evolution for the last 27 or so years has kept that goal in mind.

sammnaser 8y ago

I see your point, but I think when migrating over a million loc, it's a question of practicality. Incrementally migrating a project from Python 2 to 3, between which at least large-scale architectural patterns are more-or-less identical, is a completely different story from migrating to Golang, which uses drastically different paradigms to structure code and think about data flow. Reminds me of some of the points made here: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-....

ilovecaching 8y ago
Are most people migrating over a million loc? And if they are, is it one million loc Python service, or a bunch of small services that could all be rewritten independently? Chances are the worst case scenario is very rare. Golang really isn't that different from Python. They are both incredibly imperative languages with a one way mentality, and most people who learned CS in college will easily recognize both. The major difference is that Go has much less to learn, and very few patterns to speak of.

oconnor663 8y ago

The crucial lesson from the Python 2 -> 3 transition (which this article is also mainly about) is that incrementality is super valuable. In retrospect, a single codebase supporting 2 and 3 is the obvious best option, but that wasn't at all clear in the beginning. (For example, the u"" string syntax, which is crucial for compatibility, wasn't even legal until 3.3!) Moving to Python 3 incrementally is painful, but it's possible. Moving to a totally different programming language incrementally isn't possible, other than when you're starting brand new projects.