"[I]f a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job."
This could go round and round. The point is that there SEEMS to be a correlation with people who learn things for the sake of learning them and folks who do well at exercises that test for adjacent skills.
I didn't really express any thoughts or feelings about doing unusual things, real or perceived. Doing unusual things can be great! Telling yourself you are awesome can also be great! I do think, though, that the type of thought expressed in the "The Python Paradox" and related writings (say, the bit about blub language programmers) is pretty lousy. It was lousy then and has aged even more poorly.
Each step seemed like a good idea but when taken together you wonder what when wrong and when.
No, that's not it. It's that if you can only learn one programming language, Go is not a very good choice, so those who learn Go are almost always multilingual ("lingual" as in programming languages, not natural languages). Python and JavaScript are Swiss Army knives with outstanding ecosystems that make them excellent choices if you can only afford one tool. There are plenty of reasons to learn Go but, as a more specialized tool, it makes a better component of a nice toolset than a solitary multitool.
My anecdotal experience says that 1) most programmers are monolingual, 2) almost all Go programmers are multilingual, and 3) the average multilingual programmer is a better programmer than the average monolingual programmer for various reasons, so the average Go programmer is better than the average programmer. And, by that logic, the average Rust, Haskell, Erlang, Lisp, etc., programmer would be, too.
This surprises me as I've never worked on a nontrivial system that's also a monolingual system.
There's nearly always another language to use to get the job done, whether for configuration, scripting/automation, or because backends and UIs are written in different languages, especially for internet-based software.
Sure, but in most cases programmers spend most of their time only in one 'part' of the system and only really have to know the language that part of written. In general it doesn't matter if the back end server is written in Lisp, Java or APL, as long as it talks to my part of the system in the way it's supposed to.
Perhaps that's a reflection of the structure of the organizations they work in.
Anyways, the other cause of multilingualism is switching jobs, projects, or problem spaces. All three of those often involve a language switch.
Anecdotally, I've seen it replace Java in quite a few small and medium sized established companies.
Go feels similar but younger. I love languages with big standard libraries. Just need their package management story to settle down for a while.
There's something wonderful about a language being so popular and around for so long that there's plenty of resources and answers on just about anything. I think that's a core part of what I'm missing from Go.
There are ways to deal with it, but it requires rigorous discipline, and resisting Python's dynamic siren call earlier on in the process.
Golang naturally guides you into a style of programming which scales. You're not fighting the language (or your own inclinations) to avoid getting entangled later on.
Everything has exceptions†, you can shoot yourself in the foot with anything, yes. But, reasonably, it's about the relative struggle to end up in a similar place. Which is higher for Golang initially, but higher for Python later on.
Not trying to turn this into a Python vs Go thread; they both have their place. But Python can definitely go wrong, in an area significant to many people.
† Except Go... T_T
I will say that asyncio is amazing and really solves concurrency for me. But Go looks like you also get parallelism without a lot of work.
Its beauty is that there is so little to it. You don’t need StackOverflow to discover/debug a clever way of expressing something because there is no clever way. It feels limiting until you learn the idioms.
Package management has indeed been extremely painful, particularly in the Glide era, but Dep and VGO are both solid.
At the company I used to work at it took nearly a 1000 lines to replace an 80 line bash script. So I can't help but laugh at this statement.
More LOC means more opportunities for error, and more resources needed to review that code and more time required for a new developer to get familiar with the code base.
That said if you have 85 LOC vs 1000 it usually means that the 85 LOC “app” used a metric ton of external dependencies which are on their own a good source for problems.
When comparing apples to apples (as in both apps use dependencies equally) I don’t see how such delta can be caused by using a different language, even using assembly would likely not cause this much inflation.
Because even less people use D than they use Go. :)
Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake.
It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interest to spend time learning something unnecessary.