As with all of these posts, the big reason is never really written:
"I just wanted to learn a new language"
Now, the points they've made are valid, Go concurrency beats the pants off python, and with gofmt, there is less of a debate about style.
Te bit about finding a team is pure horse cock. As they point out there are a bunch of C++/C programmers about. There are even more python programmers too. Go is a tiny pond compared to the big three (c, java, python).
co-founder and CTO of Stream here. I did not write the article but I was very involved with the decision process.
Your assumption is wrong, we did not pick a different language just for fun or because we wanted to learn something new :)
Python was just not the language we needed for our APIs, we tried hard to make it work but eventually we looked at alternatives that would allow us to keep things simple and performant. End result was better latencies, a much simpler architecture (less async/MQ work) and processes that would eat a fraction of RAM and CPU compared to Python.
> Te bit about finding a team is pure horse cock. As they point out there are a bunch of C++/C programmers about. There are even more python programmers too. Go is a tiny pond compared to the big three (c, java, python).
If you can program in any language, you can program in Go. There's so much less to learn than even Python (perhaps especially Python when you consider all of the different packaging tools, testing frameworks, sync vs async, decorators, metaprogramming, etc).
> As with all of these posts, the big reason is never really written:
> "I just wanted to learn a new language"
Strong disagree. If the actual purpose was learning new things, they'd have chosen a language which does things a little differently than all of the mainstream. At least Haskell or some Lisp...
The fact they chose Go shows they care primarily about the practical side.
They didn't say they wanted to learn new things, they wanted to learn a new language. I can want to learn how to drive a race car in addition to my Toyota Corrola without wanting to lear how to operate a crane (though that would be pretty interesting honestly).
Are connected. More people out there would be willing to work in Go than Python, even if more people know python. First, a large portion of python writers aren't backend devs, whereas pretty much all Go users are. Second, Python has a very bad rap as a backend language, and for pretty good reason. Third, if someone doesn't know Go, then can still get up to speed and use the language extremely proficiently within a few months, unlike any of the other languages you listed.
> if someone doesn't know Go, then can still get up to speed and use the language extremely proficiently within a few months
Which combined with a new code base is very stressful. but this avoids the main point, which is
> Python has a very bad rap as a backend language,
its not a front end language really(discounting the transpiled JS web stuff). I know people dont like it, and that's fair enough, but its as good as virtually any other language for "backend stuff". Its perfectly possible to write low latency high scaling code in python, just as it is in go and rust.
Despite what people say, code is just a logic brush, how you hold it, and how toy paint with it determines how pretty the picture is.
Yes there are inherent defects that each language has, but once again part of being proficient is know how not to blow your feet off. If Goethe can make wonderful prose in german, you too can make good scalable backend code in python.
For those of us not deeply familiar with Python vs Go, can you share a bit about why gofmt is so much better than the Python status quo (IE what’s wrong with autopep8 mentioned in article?)?
Go has one, the same one used by the compiler, so there's no arguments, no multiple standards, etc. Python has a few options, and when a new language feature comes out the time to implementation may vary.
Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed?
Generally in the go community, contributions, patches, code, etc that's not formatted with gofmt is considered wrong/broken.
I don't think there is a status quo. There is choice between autopep8, yapf (which itself supports 4 different styles), black, and maybe some more I'm missing. With languages that have a built in formatter this isn't an issue.
I have experience with both (and a lot of other languages) and honestly - I wouldn't move from Python to Go. I'd move from Python to the very latest version of C#.
You get far better tooling, excellent performance, the ability to write extremely concise code (as long as you don't apply mainstream coding standards/style) and a better range of libraries for most situations than Go. More chance for re-use too (i.e. same library for mobile apps, websites via web assembly, backend and apps for all major PC platforms).
Also - the leaders of both Python and C# are coworkers - they both work at Microsoft.
To me the biggest advantage Python has is the debugging capabilities. Especially combined with PyCharm, ad-hoc interpreter to check things while the execution is at a breakpoint – this is just like cheating. It is too good. I am not an expert software developer and haven't developed anything that needs to be fast, but for my needs, Python is really awesome.
Go debugging is nearly the exact same experience as Python. GoLand (from JetBrains ... same folks that make Pycharm) or VSCode with delve debugger work flawlessly.
I don't think there is any difference between Go and Python when it comes to debugging. Support for both is widespread and high-quality.
This. I write in several languages (mutli-lingual project: C#, Python, JS/Node, JS/Front etc) and C# provides the best experience by far.
Everything you said above plus BIG community. C# is the top #4 language on StackOverflow, it's even more popular than PHP and HTML.
By comparison, Go is not even among the top #50. I'm not saying Go is a bad language, just bare numbers. Every problem you're going to bump into with C# - has been arleady discussed and resolved already.
P.S. latest .NET-core beats C++ in some benchmarks I love that
> extremely concise code (as long as you don't apply mainstream coding standards/style)
I'm interested in this aspect!
I discovered that I was able to write short scripts in PowerShell in a style I find readable, or I can add extra stuff (parameter annotations, mostly, IIRC) and it can stretch to look like the C# I see in Microsoft API documentation. I find that the idea just gets buried.
So I need to revisit C#, to find out how much can be effectively elided.
The language has evolved greatly in the last few years. With LINQ and generics it was already nice but add on all the recent syntax sugar and ideas stolen from F#.. and you can write very nice code.
Not all code will be though - we have a lot of Java-minded people in the community (who port Java libraries/frameworks) and they tend to be... ugly..
I've worked extensively in C# (for the first 15 years of my career, it was my primary language), and built a handful of projects in Go. They're mostly comparable in terms of dependencies. The average C# project I was on-- in the last few years I worked in it-- had roughly the same number of Nuget dependencies as the Go projects I've seen.
Both languages are great in this regard-- you can do a whole lot without 3rd parties.
It’s not much of an issue as long as you document your third party packages and versions.
It’s all going through an SA&A process that will check your c# framework as well as your random package downloaded from the interweb.
(based on the decent amount of audited government work done using tons of third party libraries. Just try doing anything in data science without third party packages)
I always wondered why Stream was using Python instead of Go. Glad to hear they are able to make the change now. There is no comparison between Go and my Python or Node.js services when it comes to data processing or pipelines.
> Revel, Iris, Echo, Macaron and Buffalo seem to be the leading contenders.
If you're talking about MVC-era frameworks these are fine. However a lot of companies are using Go for microservices so I would highly recommend looking at https://goa.design/ and https://gokit.io/
This article is dated "Wednesday, March 3 2021" but appears to be identical to https://getstream.io/blog/switched-python-go/ dated Oct 17, 2017 and updated either May 14th 2019 or Sep 15, 2020.
Both say "Early this year, we switched Stream’s primary programming language from Python to Go", and there was HN discussion about it on Oct 17, 2017 at https://news.ycombinator.com/item?id=15495562 (397 comments).
The Internet is awash with fake dates - old material 'up-dated' to make it appear current - but I wouldn't expect that sort of thing from SED which I have a decent amount of respect for.
Perhaps the author took something he had written before, and really did update it before republishing?
It looks like this blog is republishing the older article. It’s the authors only post on this site. His main blog seems to be medium maybe? The stream.io blog links I found didn’t work so maybe they were originally posted there and are disorganized since then?
Sure, but why do a cross-post years later without saying the information might be dated?
For example, you cannot now "Swap out True and False". That was changed in Python 3, and while many were still using Python 2 in 2019, it wasn't so true in 2021.
I also wonder how numba does with the "simple_gauss(time)*popularity" expression.
The post read like a sober description of some reasoning. The tech switch blogs we usually see are, by comparison, informal and feel somewhat half baked, where the author seems like their goal is to look like a cool leader of the valley. That’s what stuck out to me about this personally, it was refreshing
I read somewhere on HackerNews that Python is kinda like a default language and rest such as Go, C, C++, Java are just for Optimization, once you figure out your solution.
Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about. This is not a performance issue, and it’s the #1 issue that I choose to rewrite Python programs in other languages. Python type annotations help.
IMO modern languages like Go and Java are pretty easy to get into and you can use them for a first implementation without really sacrificing development time relative to Python, as long as you have invested the time to learn those languages and the associated tools. (C++ is not like that unless you have made a very serious investment in setting it all up.)
I’m not trying to say that any of these languages are better/worse, just that they are differently suited for particular situations (program size, team experience, etc)
> Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about.
In mye experience Python programs are not more difficult to reason about than equivalent Java programs. To the contrary an over-reliance on certain design patterns and ubiquitous, inescapable OOP complicates Java code bases, while the static typing is so weak it affords little safety compared to e.g. Python.
Worth keeping in mind a that a Python program will be about half the LOC of a Java program doing the same thing. (See the reference section here [1].) In other words you can get further with Python before passing the complexity threshold.
Bugs are also proportional to lines of code [2], which is another element that favours Python over more verbose languages like Java.
> Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about. This is not a performance issue, and it’s the #1 issue that I choose to rewrite Python programs in other languages. Python type annotations help.
I think you're spot on. Is some ways, it is a tooling problem, as type annotations require mypy (or some other type checker), and enforcement via e.g. CI.
Crucially, retrofitting them to a codebase is a difficult and tedious problem. On the other hand, it's relatively easy to do for new projects, but so is choosing a different language.
> Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about.
In my experience, this is because a lot of Python programmers are trying to write Java code in Python, carrying Java's awful and unreadable paradigms into a language that has no reason for them.
> Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about.
The other issue with Python is that it uses indentation for scoping. Combine that with the fact that it is super easy to mess up indentation when you are moving code around via copy/paste and it is super easy to change the meaning (ie accidentally move a statement out of an if block).
Using indentation for scoping is great for small projects and for beginners. However, once you get to medium or large projects, having the extra redundancy of curly braces is reassuring.
Python is a pretty terrible language to work with. Tooling sucks. Dependency conflicts are common. There's no test framework/runner worth a damn. Web frameworks are inferior to those in most other languages.
If you're doing data science things, it's hard to beat pandas/numpy. I get that those are popular in that community because the barrier to entry with Python is low. People who are just looking for a tool to solve immediate problems would do well to reach for Python.
The problems start when you try to write more complex things. Then you run into the weaknesses in tooling, testing, and performance. People would do well to skip Python and go right to another solution.
I say this having spent half of the last decade working on Python projects. If not for data science and academia keeping it alive, it'd be disappearing along with Perl.
> Web frameworks are inferior to those in most other languages.
That's quite a statement. Go on, for most of the other languages, show me a web framework that's better than Django.
Python absolutely has deployment challenges, but the performance is Good Enough™ and the speed of modelling and maintaining and accessing databases in Django's ORM is so much better than anything else I've found. Its Admin interface too is superb for same-day turnarounds on little CRUD projects. Nothing comes close.
And I've written quite complex systems around Django. Ones that are multi-headed websites, APIs to physical hardware IO, ANPR, card readers, ID printers. Python hasn't let us down.
These are the kind of comments that really made me feel insecure when I started out to program. Every programming environment/language has its advantages and drawbacks and python is obviously not a terrible language. People build amazing stuff with python.
> Python is a pretty terrible language to work with.
That's just like, your opinion, man.
> Tooling sucks.
Not in my experience. Lot of tools could be better, but I would not say there is a lack of un-sucky tooling at this point. Poetry and pytest in particular are largely excellent to work with.
> Dependency conflicts are common.
This has been a problem historically but it's leagues better today, especially with lockfiles.
> There's no test framework/runner worth a damn.
Um, what? Unittest (stdlib), Pytest, tox, nose, hypothesis, schemathesis, and a few other lesser known ones.
> Web frameworks are inferior to those in most other languages.
FastAPI is pretty amazing. Flask is well regarded as a good intro framework. Django I'm not a fan of personally, but many love it.
> If not for data science and academia keeping it alive, it'd be disappearing along with Perl.
And machine learning. And web dev. And sysadmin scripting.
For the little data sciences like statistics and mildly complex ML, R is really good. At least for data exploration. The REPL/emacs combo I use is much better than python/jupyter. By better I mean it's far more productive to test ideas, compute statistics, charts, etc. Unfortunately R programs I write are not as structured as python programs. I wouldn't like to maintain that kind of code for a long time, nor would I build big applications in R.
Sounds like inexperience or confusion, to be honest. None of those are problems particular to Python. Meanwhile you did not mention any of Python's significant issues, such as performance or deploying end-user apps. But it is best-in-class for what it was originally designed for.
The built-in unittest module is essentially a clone of JUnit, so it can't be much worse, and most of the remaining limitations are fixed by pytest which people seem pretty happy with. What test frameworks are you comparing them to?
The thing I want is a good monorepo solution for Python. There's at least 3 for JavaScript.
As much hate as JS gets, its package managers are also much better than Pip.
In order to manage complexity of Python as you do your big projects, you really need to do "enterprisey" patterns like DI. Even though it's rare for Python programmers to write like that.
Of things you mention I feel the testing part the most. I started python recently enough that I've only ever used pytest, but something about it just feels too...magical? I'm holding out hope for a new test framework that I'd feel more at home with, but I'm not aware of any such projects; do they exist?
> People would do well to skip Python and go right to another solution.
Okay, so what solution? What do you recommend? I'm guessing if you're qualified to make statements like your first paragraph, you can bring your wealth of skill and experience to the table and show us what we should be using.
Python is the Visual Basic of 2022. Easy to understand, easy to learn and very forgiving. Much nicer than the main alternative (Javascript).
Unskilled developers can be very productive very quickly. Skilled developers can write some really beautiful code with it.
Has issues with the ecosystem - it's a headache with M1 and far too many Python projects are just broken. The latter is because it's used by scientists / students so is more a function of the community than the language.
I use it as a scripting language, which it excels in as long as you don't have many dependencies.
Go: fast and cgo is really powerful. The language itself is a little verbose for my tastes though - it makes the simple verbose. The package management story is weird (import the source code from github). Better than having the dependency hell of npm or Python though.
I don't know who coined it but I love the term "second-best language for everything" when describing python. The ecosystem is so broad you can almost always find tools to do whatever you need, and it lets folks jump between domains simply by knowing the language.
> I read somewhere on HackerNews that Python is kinda like a default language and rest such as Go, C, C++, Java are just for Optimization, once you figure out your solution.
Python is extremely convenient when you are trying to be productive. It is a good general purpose tool, especially if you're doing anything web related. My project starts in seconds and requires no compilation. Stack traces and tooling for the language is far beyond most other popular languages IMO. The standard library is excellent, but also the quality of popular python libraries is unmatched by other languages in my experience.
Python is not super fast at doing some stuff. If you're doing that stuff all the time it may not be a good choice. But for most of what I do, python is really good enough. A user will not notice a few 10s of Ms for that web request, and usually that isn't even the scale anyway for this type of stuff.
Python is an excellent choice for that. What I tend to do is build with Python and, if (and that's a big if) the thing needs to be orders of magnitude faster, then we profile the app to find the hot spots and optimize those, either in Python, with some better approach, or in another language still being called from Python. A rewrite of a whole service from scratch is relatively rare in my experience (unless the original is really terrible and impossible to maintain).
I take a similar approach. Python allows me to rapidly prototype and ... gets the job done — fast (in terms of developer productivity). Once performance becomes a main criteria, it's not so difficult to fork/exec some Go/Rust/C/C++ executable.
There's an element of truth to that in some cases, but it's mostly just something Python fans say to excuse the fact that Python is so slow.
It's not true for two reasons:
1. In practice writing a prototype in one language, then completely scrapping it and rewriting it in another language almost never happens for fairly obvious reasons.
2. The "slow bits" of a Python program are rarely neatly concentrated in a few parts of the program that you can rewrite in a fast language. The whole program is slow, so there's no small part that you can rewrite to make it all faster.
3. There are other languages that are just as easy to use as Python (easier even!) but are also fast enough that you don't need to rewrite anything in most cases. Typescript is probably the best option at the moment but there's also Dart, Lua and probably others I've forgotten.
Python is popular because it's seen as very beginner friendly so there's a mountain of content out there teaching people Python. Also the REPL makes it good for beginners and for science.
The point is you're very productive up front, and have a number of choices with the rest of your time. Few rewrite from the ground up because they don't need to.
On first startup we used Tcl, and C code for performance, similar to what is fashionable with Python nowadays.
I had enough of the rewrite in C experience that since then, if the language doesn't come with a compiler on the box, either JIT or AOT, I only see it as scripting language for sysadmin work or learning purposes.
AOLServer had a lot of defaults that would magnify the performance issues of TCL. The documentation did not cover all of the necessary configuration options to get a system to scale and you had to dig into driver.c to understand how to tune the system. I think the two big undocumented bottlenecks were maxsok and backlog. I bet if you were writing the same applications today, using modern hardware and Naviserver you would not have to write C modules anymore.
Yes, it has from the beginning been a fantastic prototyping tool, with a growing number of exit strategies for when you outgrow it. Or make do when you don't.
It's had its deficiencies as well, exacerbated due to lack of investment, but that is changing. These are being knocked out one by one, every release.
I get frustrated with this nonsense that writing tons of boilerplate is somehow beneficial. As someone who actually reads a lot of code, no it isn't. I want to see the core logic, not an essay on how to iterate through an array. You can cut the bullshit code without resorting to cryptic Perl-like code.
Adding in more bullshit just gives me more code I have to read that I may not actually be interested in while also spreading out the code of interest.
In the horrific example code posted, all that should be there is the URL, that it is a GET, and parsing of JSON (maybe into struct). Or in other words, "fetch(url).then(resp => resp.json())" with some validation code elsewhere, though in this case it's just one field so validation of the whole response is probably unnecessary.
Nim is another option if you're wanting a language faster than Python, but with high productivity. The ecosystem is not quite there yet though. Nexus dev framework should help somewhat: https://nexusdev.tools
Readit News
"I just wanted to learn a new language"
Now, the points they've made are valid, Go concurrency beats the pants off python, and with gofmt, there is less of a debate about style.
Te bit about finding a team is pure horse cock. As they point out there are a bunch of C++/C programmers about. There are even more python programmers too. Go is a tiny pond compared to the big three (c, java, python).
Your assumption is wrong, we did not pick a different language just for fun or because we wanted to learn something new :)
Python was just not the language we needed for our APIs, we tried hard to make it work but eventually we looked at alternatives that would allow us to keep things simple and performant. End result was better latencies, a much simpler architecture (less async/MQ work) and processes that would eat a fraction of RAM and CPU compared to Python.
If you can program in any language, you can program in Go. There's so much less to learn than even Python (perhaps especially Python when you consider all of the different packaging tools, testing frameworks, sync vs async, decorators, metaprogramming, etc).
> "I just wanted to learn a new language"
Strong disagree. If the actual purpose was learning new things, they'd have chosen a language which does things a little differently than all of the mainstream. At least Haskell or some Lisp...
The fact they chose Go shows they care primarily about the practical side.
and
> finding a team
Are connected. More people out there would be willing to work in Go than Python, even if more people know python. First, a large portion of python writers aren't backend devs, whereas pretty much all Go users are. Second, Python has a very bad rap as a backend language, and for pretty good reason. Third, if someone doesn't know Go, then can still get up to speed and use the language extremely proficiently within a few months, unlike any of the other languages you listed.
Which combined with a new code base is very stressful. but this avoids the main point, which is
> Python has a very bad rap as a backend language,
its not a front end language really(discounting the transpiled JS web stuff). I know people dont like it, and that's fair enough, but its as good as virtually any other language for "backend stuff". Its perfectly possible to write low latency high scaling code in python, just as it is in go and rust.
Despite what people say, code is just a logic brush, how you hold it, and how toy paint with it determines how pretty the picture is.
Yes there are inherent defects that each language has, but once again part of being proficient is know how not to blow your feet off. If Goethe can make wonderful prose in german, you too can make good scalable backend code in python.
Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed?
Generally in the go community, contributions, patches, code, etc that's not formatted with gofmt is considered wrong/broken.
You get far better tooling, excellent performance, the ability to write extremely concise code (as long as you don't apply mainstream coding standards/style) and a better range of libraries for most situations than Go. More chance for re-use too (i.e. same library for mobile apps, websites via web assembly, backend and apps for all major PC platforms).
Also - the leaders of both Python and C# are coworkers - they both work at Microsoft.
That said, I want to learn Go properly.
I don't think there is any difference between Go and Python when it comes to debugging. Support for both is widespread and high-quality.
Everything you said above plus BIG community. C# is the top #4 language on StackOverflow, it's even more popular than PHP and HTML.
By comparison, Go is not even among the top #50. I'm not saying Go is a bad language, just bare numbers. Every problem you're going to bump into with C# - has been arleady discussed and resolved already.
P.S. latest .NET-core beats C++ in some benchmarks I love that
I'm interested in this aspect!
I discovered that I was able to write short scripts in PowerShell in a style I find readable, or I can add extra stuff (parameter annotations, mostly, IIRC) and it can stretch to look like the C# I see in Microsoft API documentation. I find that the idea just gets buried.
So I need to revisit C#, to find out how much can be effectively elided.
Not all code will be though - we have a lot of Java-minded people in the community (who port Java libraries/frameworks) and they tend to be... ugly..
Pulling third party packages would be instantly flagged and be put under high scrutiny.
Meanwhile with C# and .NET’s ungodly framework size you can just cruise along because it’s made by the creators of the language.
Both languages are great in this regard-- you can do a whole lot without 3rd parties.
It’s all going through an SA&A process that will check your c# framework as well as your random package downloaded from the interweb.
(based on the decent amount of audited government work done using tons of third party libraries. Just try doing anything in data science without third party packages)
> Revel, Iris, Echo, Macaron and Buffalo seem to be the leading contenders.
If you're talking about MVC-era frameworks these are fine. However a lot of companies are using Go for microservices so I would highly recommend looking at https://goa.design/ and https://gokit.io/
This was written 4 ½ years ago.
This article is dated "Wednesday, March 3 2021" but appears to be identical to https://getstream.io/blog/switched-python-go/ dated Oct 17, 2017 and updated either May 14th 2019 or Sep 15, 2020.
Both say "Early this year, we switched Stream’s primary programming language from Python to Go", and there was HN discussion about it on Oct 17, 2017 at https://news.ycombinator.com/item?id=15495562 (397 comments).
Perhaps the author took something he had written before, and really did update it before republishing?
For example, you cannot now "Swap out True and False". That was changed in Python 3, and while many were still using Python 2 in 2019, it wasn't so true in 2021.
I also wonder how numba does with the "simple_gauss(time)*popularity" expression.
IMO modern languages like Go and Java are pretty easy to get into and you can use them for a first implementation without really sacrificing development time relative to Python, as long as you have invested the time to learn those languages and the associated tools. (C++ is not like that unless you have made a very serious investment in setting it all up.)
I’m not trying to say that any of these languages are better/worse, just that they are differently suited for particular situations (program size, team experience, etc)
In mye experience Python programs are not more difficult to reason about than equivalent Java programs. To the contrary an over-reliance on certain design patterns and ubiquitous, inescapable OOP complicates Java code bases, while the static typing is so weak it affords little safety compared to e.g. Python.
Worth keeping in mind a that a Python program will be about half the LOC of a Java program doing the same thing. (See the reference section here [1].) In other words you can get further with Python before passing the complexity threshold.
Bugs are also proportional to lines of code [2], which is another element that favours Python over more verbose languages like Java.
1. https://svese.dev/comparing-java-and-python-is-java-10x-more...
2. https://amartester.blogspot.com/2007/04/bugs-per-lines-of-co...
I think you're spot on. Is some ways, it is a tooling problem, as type annotations require mypy (or some other type checker), and enforcement via e.g. CI.
Crucially, retrofitting them to a codebase is a difficult and tedious problem. On the other hand, it's relatively easy to do for new projects, but so is choosing a different language.
In my experience, this is because a lot of Python programmers are trying to write Java code in Python, carrying Java's awful and unreadable paradigms into a language that has no reason for them.
The other issue with Python is that it uses indentation for scoping. Combine that with the fact that it is super easy to mess up indentation when you are moving code around via copy/paste and it is super easy to change the meaning (ie accidentally move a statement out of an if block).
Using indentation for scoping is great for small projects and for beginners. However, once you get to medium or large projects, having the extra redundancy of curly braces is reassuring.
If you're doing data science things, it's hard to beat pandas/numpy. I get that those are popular in that community because the barrier to entry with Python is low. People who are just looking for a tool to solve immediate problems would do well to reach for Python.
The problems start when you try to write more complex things. Then you run into the weaknesses in tooling, testing, and performance. People would do well to skip Python and go right to another solution.
I say this having spent half of the last decade working on Python projects. If not for data science and academia keeping it alive, it'd be disappearing along with Perl.
That's quite a statement. Go on, for most of the other languages, show me a web framework that's better than Django.
Python absolutely has deployment challenges, but the performance is Good Enough™ and the speed of modelling and maintaining and accessing databases in Django's ORM is so much better than anything else I've found. Its Admin interface too is superb for same-day turnarounds on little CRUD projects. Nothing comes close.
And I've written quite complex systems around Django. Ones that are multi-headed websites, APIs to physical hardware IO, ANPR, card readers, ID printers. Python hasn't let us down.
That's just like, your opinion, man.
> Tooling sucks.
Not in my experience. Lot of tools could be better, but I would not say there is a lack of un-sucky tooling at this point. Poetry and pytest in particular are largely excellent to work with.
> Dependency conflicts are common.
This has been a problem historically but it's leagues better today, especially with lockfiles.
> There's no test framework/runner worth a damn.
Um, what? Unittest (stdlib), Pytest, tox, nose, hypothesis, schemathesis, and a few other lesser known ones.
> Web frameworks are inferior to those in most other languages.
FastAPI is pretty amazing. Flask is well regarded as a good intro framework. Django I'm not a fan of personally, but many love it.
> If not for data science and academia keeping it alive, it'd be disappearing along with Perl.
And machine learning. And web dev. And sysadmin scripting.
The built-in unittest module is essentially a clone of JUnit, so it can't be much worse, and most of the remaining limitations are fixed by pytest which people seem pretty happy with. What test frameworks are you comparing them to?
The thing I want is a good monorepo solution for Python. There's at least 3 for JavaScript.
As much hate as JS gets, its package managers are also much better than Pip.
In order to manage complexity of Python as you do your big projects, you really need to do "enterprisey" patterns like DI. Even though it's rare for Python programmers to write like that.
Re: test runner: pytest is pretty good
Okay, so what solution? What do you recommend? I'm guessing if you're qualified to make statements like your first paragraph, you can bring your wealth of skill and experience to the table and show us what we should be using.
Is it really?
Unskilled developers can be very productive very quickly. Skilled developers can write some really beautiful code with it.
Has issues with the ecosystem - it's a headache with M1 and far too many Python projects are just broken. The latter is because it's used by scientists / students so is more a function of the community than the language.
I use it as a scripting language, which it excels in as long as you don't have many dependencies.
Go: fast and cgo is really powerful. The language itself is a little verbose for my tastes though - it makes the simple verbose. The package management story is weird (import the source code from github). Better than having the dependency hell of npm or Python though.
Python is extremely convenient when you are trying to be productive. It is a good general purpose tool, especially if you're doing anything web related. My project starts in seconds and requires no compilation. Stack traces and tooling for the language is far beyond most other popular languages IMO. The standard library is excellent, but also the quality of popular python libraries is unmatched by other languages in my experience.
Python is not super fast at doing some stuff. If you're doing that stuff all the time it may not be a good choice. But for most of what I do, python is really good enough. A user will not notice a few 10s of Ms for that web request, and usually that isn't even the scale anyway for this type of stuff.
It's not true for two reasons:
1. In practice writing a prototype in one language, then completely scrapping it and rewriting it in another language almost never happens for fairly obvious reasons.
2. The "slow bits" of a Python program are rarely neatly concentrated in a few parts of the program that you can rewrite in a fast language. The whole program is slow, so there's no small part that you can rewrite to make it all faster.
3. There are other languages that are just as easy to use as Python (easier even!) but are also fast enough that you don't need to rewrite anything in most cases. Typescript is probably the best option at the moment but there's also Dart, Lua and probably others I've forgotten.
Python is popular because it's seen as very beginner friendly so there's a mountain of content out there teaching people Python. Also the REPL makes it good for beginners and for science.
The very words such as bottleneck/hotspot indicate that it is common to get the most benefit by optimizing small parts of the code.
I had enough of the rewrite in C experience that since then, if the language doesn't come with a compiler on the box, either JIT or AOT, I only see it as scripting language for sysadmin work or learning purposes.
Deleted Comment
It's had its deficiencies as well, exacerbated due to lack of investment, but that is changing. These are being knocked out one by one, every release.
Dead Comment
Adding in more bullshit just gives me more code I have to read that I may not actually be interested in while also spreading out the code of interest.
In the horrific example code posted, all that should be there is the URL, that it is a GET, and parsing of JSON (maybe into struct). Or in other words, "fetch(url).then(resp => resp.json())" with some validation code elsewhere, though in this case it's just one field so validation of the whole response is probably unnecessary.
I've actually written a lot of code and have used it for my own projects for some time, just need to get the release out now.