Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.
This may or may not be the right business strategy, however if everyone would be going with a notion of only using popular languages because it's easier to hire for them, by now we'd be using JS as a backend language.Oh,wait...
https://iohk.io/en/team/#team=development
Now if you needed to hire 1000 developers, then you'd have more of a problem, and perhaps Haskell wouldn't be the right approach. But in my experience, Haskell engineers get a multiplier effect over the average non-Haskell engineer because the code is more concise and the average engineer skill is higher. I don't know what the multiplier is, but it's definitely non-zero and positive. This not only pays the obvious direct benefits, but also reduces the communication overhead of your team and the number of managers you need to hire.
It's the role of applause (and in your case, downvotes). The crowd throws cheap adulation at individuals who act against their own interests.
Planning for that far down the road is the least of your worries. And any plans you make along those lines are not likely to be very accurate anyway. You're much better off optimizing for the near to mid term. Based on the hosting costs described by the OP they are already reaping a tangible value here.
So given the upside to paying people to using Haskell (they get to learn it for life, many join + grow the community, they enjoy working for your company more), I think it's worth that kind of harm to a corporation.
I'll keep trying to sap corporate resources into Haskell I take with me for life at least :)
It is quite difficult to get a first Haskell job though, because they mostly require production Haskell experience, so there's your chicken and egg problem.
I'm not sure what your current level is, but I can give some general advice for people that happen upon this:
---
Haskellers are generally expected to understand most of the typeclassopedia (https://wiki.haskell.org/Typeclassopedia), don't worry about learning it all in one go. I had to read this page many times before I grokked most of it.
---
Avoid tutorials that overuse analogies. A Monad only adds one operation to Applicative:
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
---
It's important to be really good at using Monads that support multiple effects, to create little DSLs. If I want a component of my program to support throwing errors, creating a log, and reading an environment, (all purely), I'd use something like this:
type MyDSL
= ReaderT Environment
(WriterT [String]
(Except ErrorType))
Where I work we use free monads instead of monad transformers, but that's just an implementation detail, it's used the same as a transformer stack.
---
Create a cool project, Haskell people like languages. When I was interviewing I showed off a tiny lisp-like language implemented in Haskell (https://github.com/414owen/phage). This was my first non-trivial Haskell project so don't judge it too harshly.
---
Read Haskell Weekly (https://haskellweekly.news/newsletter.html). It's a great source of ideas and knowledge.
---
A lot of Haskell shops use, or are migrating towards using, nix (https://nixos.org/).
---
Apply! The Haskell market seems to favor the interviewee. In the end, I had more than one offer, even for my first Haskell job.
Good luck!
How is it easier to find a Haskell developer vs finding a Java/Python/PHP developer?
I would assume that:
(1) Those using niche stuff are less likely to be hiring under the impression that the main measure of skill is years of experience with a language, and
(2) those using niche stuff are, on average, doing more interesting work that attracts more intellectually curious candidates.
As a result, the mainstream firms get worse candidates, and try to compensate by asking for even more years of experience, and asking for years of experience not just with language but specific libraries and other tools, hoping that will get them more skilled candidates, at least for their specific toolchains. But doubling down on that just gets them candidates that are less capable (because even to the extent years of experience are useful, there are diminishing returns, and people who have spent a huge amount of time with the same stack also are likely to be in the “1 year of experience, repeated N times” category, rather than N years of learning and compounding knowledge. (Also, because at a certain point you start making impossible demands, increasing the degree to which the hiring process filters for dishonesty.)
Of course, there is just more of them in the first place. The other effects that you describe might also be true but keep in mind what the base rates are.
With Haskell you just get 5 good ones. You probably don't start with Haskell as your first language but rather move into it after you are a senior in another language. If you are lousy in Java, you probably won't go and learn Haskell or some other niche language.
I also believe that to be the case as an employee. Ie, being a generalist is probably -EV for your career but it feels safer so it's kind of a contrarian position to say "be a specialist".
That's why you don't optimise for it in a vacuum. You weigh the potential benefits of switching to Haskell versus the additional cost of maintaining/growing a Haskell team.
Probably under 100, but not sure though.
I dont think this learning curve/hiring thing makes sense. Haskell can help attract smart dev, it makes refactoring so easy increased learning curve is off set.
I'd say it's harder to outsource, and there may not be as many libraries. Compare to Ruby/Rails for web, or Python for ML, and you have to write more by yourself in Haskell.
I didn't find the comment rude.
«Haskell does not scale to organizations of 100+ engineers. There is a trade-off between writing and reading code, which Haskell does not fare well in. Also, given the realities of the dev hiring market, steep learning curves would be very detrimental to the success of the company»
What would have been your reaction if I had replied "look up the word condescension in the dictionary" to you? It would lead to bad discussion, regardless of whether my point about condescension was right or not.
My experience with onboarding non-Haskellers has been pretty good, though I would certainly admit the argument that they were unusually talented individuals.
1. When your company uses esoteric language, your job offers usually have "we can teach you the language" instead of "we require x years experience in language and y, z libraries)". That is a really great filter for people you want to work with, as they have to accept they will be learning from the start.
2. There is a smaller number of engineers qualified, but the number of companies they can apply to is even more reduced. I think all in all you're winning in this equation as a hiring manager.
3. Your hiring process get cheaper, since it moves from having to filter candidates heavily to focus on matching the right person for the team. People who are interested in non-mainstream languages already fit some of the criteria you have to select for otherwise.
4. As the number of people to hire easily is smaller and onboarding even a talented person without experience in tech takes time, you get much better with selecting problems you want to tackle and grow in more reasonable pace. That has great benefits for your organisation.
I know for sure that if I am ever starting my own startup, I will use no mainstream technology. If I want JVM, I will use Clojure instead of Java, if I want web, I will use Elixir instead of Rails/Django, if I go low level, it's Rust, no C++ etc.
It's counterintuitive, but it works better. People think about size of the whole market, but they should think about percentage of candidates applying being fit for the job.
Edit: removed ` characters.