> And, not to put too fine a point on it, but if you can code Python but not Go (or another decent programming language), you probably have no business writing software for a living. I know it sounds harsh and I apologize for that, but writing software is a profession and hence you should have the knowledge, skill, and experience to use professional tools.
Part of the profession of software engineering is maintaining software that's already written. Should the people who maintain python code, not be paid for their work?
Another part is choosing the right tool for the job. Python has its flaws, but it is better than Go in some ways. For example, it has a richer ecosystem of libraries.
Why hasn’t the go community, of professional software engineers built an even richer ecosystem of libraries?
Is it ennui, incompetence, or attitude?
As Go came from Google, is that the attitude was, “I am a professional I’ll just write my own code to solve X”, rather than considering building a library that others can use?
Are libraries harder to build in Go? Is adoption of libraries by the Go community different?
Is it a mindset, that libraries are uninteresting?
Compare the number of programmer-hours on Python to Go. Having a ~15 year head start helps a lot.
Plus, I've been programming in Go professionally for a while and it's been a while since I reached for a critical library and it was missing.
Go ends up needing fewer libraries anyhow; in Python you have the pure-Python version, no, wait, the Twisted version (which may not be current but are still all there, increasing the library count), no, wait, the async version, no, wait, the Python 2 version, no, wait, the one that binds to a C library.... and actually this isn't specific to Go, it's really more specific to Python. Library count gets bloated up over the decades by the fact that when, for example, Python went to async, all non-async libraries in which async was relevant suddenly needed a clone. Go has had effectively no language changes which create such parallel libraries (note changes, not additions; Go has had additions which create opportunities for more libraries but don't create lots of parallel libraries). I don't know that Python is uniquely changing, "best practices C++" is arguably up there, Javascript has had a lot of churn, but it's in the higher tier of such things. Languages that don't churn like that should be able to cover the same amount of "need" for libraries in fewer libraries by the numbers.
That is true, but where are the go libraries for machine learning, tensors, LLMs, equivalents to PyTorch that I see bandied about?
Others have stated that they don’t need such libraries in Go, or that Python just has a glut of libraries that are a sort of detritus obsolete or language version specific.
Why isn’t Go then, THE language of choice for machine learning, analytics, fast prototyping, data conversion, ETL, etc.
What I’ve heard of Rust in comparison is that the syntax of the language & the learning curve is counterintuitive for engagement by non-computer scientists or systems programmers.
Seems expected then that, non comp-sci folks will choose a language that is more accessible, with an ecosystem that lets them get things done in a short period of time.
I would wonder if it it that the experts & heavy users of Go or language architects moving Go forward see any need for a parallel course of engagement to bring Pythonists into the fold or to allow Go to become the language people choose over Python or TypeScript, et al, by providing a best of class approach to quickly prototyping and extending into well architected systems as an underlying function.
The computer industry has a bizarre reputation for moving fast and breaking things. In fact the industry is shockingly conservative. You will encounter many, many programmers who flat-out refuse to learn new things.
Most companies & universities aren’t exposed to cutting edge or even modern technology. They stay in their bubble.
Leaving Silicon Valley, I’ve found the engineering management culture can be averse to training and allowing active skill building via development projects.
Just code that shit in Java or C++, doesn’t matter if you haven’t been trained in SQL properly or are even aware of best practices.
That culture leads to some gruesome product implementations & upgrade scenarios.
Hell, our IT department blocks this very website from being accessed.
Part of the profession of software engineering is maintaining software that's already written. Should the people who maintain python code, not be paid for their work?
Another part is choosing the right tool for the job. Python has its flaws, but it is better than Go in some ways. For example, it has a richer ecosystem of libraries.