I lost so many weeks trying to decode the fk of the code written in scala with so much "magic" in it.
And I'm working with a colleague to "unmagic" it in our source base.
If I have to inherit code, I'd take (JavaScript|Rails|PHP|Python)+(MySQL|PostgreSQL) over (Scala|Haskell|F#|Lisp)+(MongoDB|Cassandra|Kafka) any day.
I understand that all of these tools have their uses, but the most important thing is ease of finding decent developers. Lots of people can do JavaScript well, but few can do Scala, so you're going to have a smaller pool of talent. More popular languages are also going to have more developed patterns, more native libraries, and better tooling options.
If you need Scala, please just write Java. You'll always be able to hire a Java dev. Everyone hates writing Java, but everyone can write Java.
And related, if you're using any kind of NoSQL for your business data, you're wrong. I understand NoSQL for caching and document storage, but not everything is a document. Most things are actually best in SQL tables. Especially if you're a startup.
Isn't that a side benefit? It keeps out the riffraff.
What actually causes trouble in an enterprise setting is not any particular paradigm itself, but "magic." All that flexibility of Scala or Lisp is great in the small, but it doesn't scale easily. You are effectively building new DSLs in them, and then everyone that comes to the project has to first learn the specific variation that you ended up with.
The problem is that people usually neither acknowledge they are building a language, nor think about design of that language to make it easy to learn and use, including documentation. So new people come and are completely lost. If they are experienced in the given base language, it is only easier for them to find the starting point to reverse engineer what was done, but that work still has to be done.
This actually happens in Java and other less "magic" languages as well, but then nobody blames the language: they blame frameworks and development practices in a particular shop.
Additionally, the whole mindset of "easier to hire a Java dev" only makes sense for juniors, if at all. Developers are meant to be problem solvers, and any particular language or framework is but a small part of the overall toolset they should have. Sure, if they are experienced in a particular language that you are using, they will have easier time starting up, but that is only a short term benefit.
I can easily find someone with 5+ years of full time Java development (or JS, Python, and Ruby), and that means they're going to come fully equipped to dive into a problem, using familiar patterns and libraries. I don't want to hire people to make them learn Scala as quickly as possible and hope that they're able to figure it out very quickly.
> the average one chooses a major language and framework and hacks things together with stack overflow
Call me average, but I spend most of the day googling and reading results on SO. I think most developers do the same. Even if I already know how to do something, I usually google it to see if there's a better way to write it. If you're working with Scala (or some other less popular language), you're going to have less results doing these things, because less people are going to have hit your special problem. There is no amount of amazing language features that make this trade-off worth it.
And it's not just true for languages, it's true for frameworks too. Using common stuff (language choice, framework choice, library choice, compiler choice, etc) makes it so much easier to solve the problems you'll inevitably run into.
I have to agree that in most cases few days are not realistic, but I'm convinced you could apply Pareto principle and state that you can get most things done with knowing just enough of the language.
A year or two to understand nuances sounds like not making a deliberate effort to learn about them and instead just waiting until you get that through osmosis by just working with the language. It works, but it's slower than deliberate effort to identify differences from what you know already and learning specifically about them.
At any rate, arguments like that neglect that most languages are very similar, and after learning a few quite different ones the differences with most others become largely superficial.
> I can easily find someone with 5+ years of full time Java development (or JS, Python, and Ruby), and that means they're going to come fully equipped to dive into a problem, using familiar patterns and libraries.
Yes, and no. You assume that all people using the same language use similar patterns and libraries. Assuming recent experience with Python or Ruby that might be close enough to true in those languages, but I heard that in case of JS the ecosystem is incredibly diverse.
Setting aside any particular language, any sufficiently large codebase will have its own idiosyncrasies that add to the entry barrier.
> I don't want to hire people to make them learn Scala as quickly as possible and hope that they're able to figure it out very quickly.
You seem to be optimising for "very" short time horizon. It strikes me as short-sighted. You also seem to underestimate how much knowing the JVM as the runtime environment gives you.
> If you're working with Scala (or some other less popular language), you're going to have less results doing these things, because less people are going to have hit your special problem.
There will of course be fewer results, but you seem to assume that has to mean you will regularly run into trouble. Numerically, most Google results are bogus or even misguided anyway. You might try to argue that having more people using given technology increases the odds of finding a good solution, but that requires relatively stable signal to noise ratio across different technologies. I don't think that is necessarily the case.
Additionally, Scala might be poor example for this one, as it is actually used quite a lot in industry. It is nowhere near as esoteric as Haskell, for example.
> There is no amount of amazing language features that make this trade-off worth it.
This is a very dogmatic statement that I strongly disagree with. It is ironic to read it on Hacker News, given the emphasis from Paul Graham on how much velocity he gained by starting his career (were those e-shops?) in Lisp and being able to iterate much more quickly because of that. It is especially ironic given your focus on short term earlier in the post.
> And it's not just true for languages, it's true for frameworks too. Using common stuff (language choice, framework choice, library choice, compiler choice, etc) makes it so much easier to solve the problems you'll inevitably run into.
Straying from the common path should be weighed carefully for sure. But never forget that if you are far enough from the lowest common denominator for which it has to optimise, you might actually get way more mileage by using something else. Right tool for the job and all that.
I can almost guarantee you they cannot.
Or you can define a sane coding standard and subset that your team agrees is readable, and stick with it, and enforce it through code review.