[flagged]
Stroustrup licked every boot and inserted himself into every possible committee to promote his language until the network effect picked up. And later he post-rationalized about his language's popularity, attributing it to qualities the language never had.
And you proceeded to conclude based on the diatribe you repeated that nobody should want good things, because everyone has to be satisfied with popular things, because you chose to eat garbage and you will be too jealous to see others getting better treats?
----
Yes. Python is garbage, and programmers should be actively discouraged from using it. Python is today in the hands of people both incapable and unwilling to improve the language in the aspects that matter, and that's why programmers need to try to defeat the network effect created by it instead of encouraging more complacency. It is pretty much in the same situation as C++, so, unintentionally, you sort of guessed the direction. Both languages started small and rode the popularity wave w/o actually filling the gaps in original design with the worthwhile contents. Kind of like a TV show that keeps capitalizing on its pilot, while not creating anymore engaging experience.
Better products will lose, most of the time, unless they're significantly better as a product to a point were they can hurt and displace the incumbents. It's what people found out with Plan 9 vs UNIX.
> for certain kinds of problems
Even your denial makes it look like a poster boy for language nicheness.
1. In my experience (I both had to learn a language for a job and had to teach a language to the newcomers), for an experienced programmer, learning a new language enough to be productive takes couple months. In the kind of projects I work with, it's typical that a programmer won't be productive for several months anyways due to having to learn about the project's structure.
2. I would prefer to work with people willing to learn something new, or those who already expanded their horizons enough to have experience with better-than-average language. It's a natural filter against people I don't like to work with.
3. Infrastructure created around languages is a doubly-edged sword. On one hand you get free stuff in the form of community-provided libraries, on the other hand, the quality varies a lot and you often have to make uneasy compromises, being held hostage of the third-party bad programming practices. In particular, when it comes to Python, since I've been often responsible for auditing dependencies used in our projects, without a trace of remorse, I can confidently tell you: all Python packages are of poor quality. You are forced to choose the best of the worst, and it hurts a lot to take on another dependency. Erlang has less infrastructure, and in many cases you'll be the master of your own libraries. It takes longer to build, but it has the same effect as with living in your own house vs renting.
4. I don't like working in huge programming shops where it's important to take into account the dynamics of the job market. You may hope to have a company with five or ten good programmers. There's no hope of having a company with thousand of good programmers. In the later scenario, you want to rely on simplified processes and practices to produce something of quality. In the former case you have a chance of just being good. It's similar to SOF army units. You cannot have the entire army being SOF, but SOF will have very different arms, tactics etc.
----
Why not Go?
I'm not necessarily opposed to it. But, my point was to show that something existed for a long time. So, Go isn't a good example of that. Conceptually, Erlang is in some ways closer to Python (being based on a VM rather than compiling to different targets depending on platform). Today, Python drifts more and more towards becoming a Java, so, it also becomes more similar to Go, but in its origins it favored short and interactive development cycle, which is also how Erlang is.
So, I was just looking for an example where a programmer would be able to keep similar workflow, but get a net benefit of using a different environment.
> Erlang has less infrastructure, and in many cases you'll be the master of your own libraries
Which, funny enough, are also going to be of "poor quality" when judged by external observer.
At least with Python packages their pitfalls are known and documented. But I get it, NIH can be very enjoyable.
> In the kind of projects I work with, it's typical that a programmer won't be productive for several months anyways due to having to learn about the project's structure.
I can't help but notice that you're shifting the blame to the type of project to protect your precious tech stack.
Erlang may have different tradeoffs, the ecosystem may be smaller, less libraries available for important tasks, who knows.
The religion of the one true language has to die, it all depends on the circumstances which language is the best fit.
Python's multiprocessing doesn't hold a candle to Erlang's processes. It's a subprocess.Popen('python') with extra steps and lots of pitfalls. Erlang went through several iterations of process schedulers, several iterations of interfacing with foreign code from Erlang processes... Python developers don't even know yet they will have to solve these problems once multiprocessing becomes more mature (but it never will, so, who cares?)
Yet you know nothing about the specific particular context in which people would use Python Multiprocessing. And I bet that although not ideal from a purity standpoint PM is likely to be “good enough” for a lot of use-cases.
You seem so bitter and feel superior about those Python developers yet, here you are complaining like a bitter old person adding nothing of value to the discussion. I really feel sorry for you that you are like that.