This post seems even less valid than in 2018. > Hiring is Harder [...] When it comes to hiring people, it’s true that programmers versed with functional progra

This post seems even less valid than in 2018. > Hiring is Harder [...] When it comes to hiring people, it’s true that programmers versed with functional programming would be, on average, better than those who aren’t. However, the hiring pool itself would shrink massively. [...] The company has to lower the criterion and train engineers in functional programming instead. Many mainstream languages now support functional constructs, so there should be plenty of developers that could readily pick up an actual functional language that uses those now familiar constructions. > Less Resources > [...] If an open source solution already has solved a problem that you’ve, you don’t have spend hours doing the same thing. And this is not just about libraries. [...] everything is better for a mature language. We now have choices like Clojure with the Java ecosystem behind it, or F# with .NET ecosystem behind it. The choice is not either-or. > Familiarity of a Language Isn’t a Great Criterion > Preferred language/framework is a personal choice. I prefer to choose a stack that has worked for me for all the years, while somebody may believe that newFooLang benefits in the longer run. I don’t think it’s wise to sideline all programmers who are perfectly happy with their choice of technology. So it comes down to the stated preference of the author vs the preference of PG or others. Good luck convincing Jane Street to use Python instead of OCaml. > [...] Facebook was pretty successful [...] PHP. > Good engineers must be concerned with solving problems that users have, not the tooling used in the solution. Paul Graham’s idea promotes a wrong order of priorities. If you want to hire a very talented small team to do some very complex work, you don't want good engineers, you want great ones. Great engineers won't choose to use PHP because they have the choice to work at practically any company. They could also learn a new language without much fuss. The important factor here is that by having a small team there are much less 'communication losses' that occur by having more bodies. If the company you're building is well served by a React front-end on a CRUD api, by all means choose whatever tech you can get good and average developers for. I know I wouldn't work for Facebook using PHP.