9 ms·

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

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.

nix23 6y ago
Ever heard of Pandoc? With your logic, python is the only reasonable language.
- detaro 6y ago
  I don't think "have you heard of this project with <5 main contributors" is a useful response to questioning if it scales to large groups.
infinityplus1 6y ago
Someone has to take the first step to solve the chicken and egg problem. If there are jobs requiring Haskell, it might get more users.
- st1x7 6y ago
  I don't think that it's wise to sabotage your own future and productivity as a company just so you can pave the way for some language to become more popular.
  - mjburgess 6y ago
    It isn't, of course. But the crowd of other people want you to do that. It's the role of applause (and in your case, downvotes). The crowd throws cheap adulation at individuals who act against their own interests.
    - oblio 6y ago
      The peanut gallery :-))
  - mightybyte 6y ago
    I don't think that it's wise to try to optimize for some kind of speculative long-term success at the expense of higher early-stage costs that reduce your odds of getting there. This is similar to companies that choose their initial technology with scalability in mind before they're even remotely close to needing to scale. I've actually done this only to discover that scalability has a very definite cost and when you're small it has an outsized impact on your burn rate. If you have success, you're going to figure out a way to make the changes you need. Case in point: Facebook. They successfully grew a PHP codebase into one of the most popular apps in the world. It definitely cost a lot more money for them to make PHP work, but when they got to that point they were a lot less cost-sensitive. 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.
  - whateveracct 6y ago
    I think at worst, Haskell is a a minor productivity cost for a company vs a mainstream language, and if it is, it's hard to pin it on the language. 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 :)
- 414owen 6y ago
  I write Haskell professionally, and I can confidently say that there are plenty of jobs. Some large tech companies (eg. Facebook, GitHub, Twitter), quite a few banks, a lot of consultancy companies, and plenty of random companies I'd never heard of. 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.
  - PietPtr 6y ago
    Working with Haskell professionally sounds like a very interesting career path. Could you point to some resources to get better at the production Haskell skills that these companies are looking for? Perhaps gaining experience with projects which use Haskell in a similar way to the companies you mention could help with finding that first Haskell job.
    - 414owen 6y ago
      Sure thing. 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 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 This reads as: `m` is a monad if, given an `m a`, and an `a -> m b`, you can construct an `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)) These are monad transformers from the mtl library. 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 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 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/ 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!
st1x7 6y ago
I feel like this isn't discussed enough. I can't comment on the technical merits of Haskell but growing an organization and replacing engineers is so much more difficult when you're using tools that aren't mainstream.
- detaro 6y ago
  The market works somewhat differently for small companies there. Yes, there are fewer people with relatively niche skills, on the other hand you have an easier time to attract the few you need. Not every company wants to become large.
  - st1x7 6y ago
    > on the other hand you have an easier time to attract the few you need How is it easier to find a Haskell developer vs finding a Java/Python/PHP developer?
    - detaro 6y ago
      I hear far more complaints about how difficult it is to find good people from companies hiring for mainstream languages than from those using more niche stuff, I would assume mostly due to larger competition among employers for the former (and in parts better community access for small shops in niche languages and self-selection of who learns the niche languages)
      - dragonwriter 6y ago
        > I hear far more complaints about how difficult it is to find good people from companies hiring for mainstream languages than from those using more niche stuff 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.)
cosmodisk 6y ago
They won't scale to 100+. From what it looks, it's a boutique dev shop that likes doing Haskell and they are going to stay that way +/- a few people here and there depending on how successful their projects are. 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...
fegu 6y ago
Using "boring" Haskell (less higher level magic) alleviates this to some extent - without being boring. The organzation should decide which features and code styles to use. I agree that the summer intern's multi-layer home-built monad transformer stack and custom operators can be a pain.
__0x01 6y ago
I've found that code readability decreases (for me) with the generous use of <$> and $. Edit: removed ` characters.
erik_seaberg 6y ago
Is is actually hard to hire for Haskell? You can’t just tell some random to learn it (because his head will explode), but my impression is that you’ll have candidates coming out of the woodwork who could never get away with using it before but always wanted to.
- egwor 6y ago
  Quite a few universities in the UK teach haskell as a way to start everyone on a level playing field and to introduce various concepts.
  - rednum 6y ago
    Similar situation in Poland. Also my anecdotal experience is that Haskell classes are not considered to be the most difficult, rather they are somewhere in the middle.
    - dagw 6y ago
      The University I went to in Sweden used Haskell for its intro classes. Intermediate classes where taught in Java.
- pwm 6y ago
  Single datapoint: The last time I posted a job ad (I was the hiring manager) I got ~40 good applicants within a week. I expected much less and got pretty overwhelmed.
- dllthomas 6y ago
  In my experience, it's easy to hire the next Haskell programmer and hard to hire the next ten. My experience with onboarding non-Haskellers has been pretty good, though I would certainly admit the argument that they were unusually talented individuals.
bachmeier 6y ago
Thanks for sharing, but honestly, what does your comment add to a discussion of the post, which is about what works for them? You're making a rude comment that assumes they don't already know these things. Have you considered the possibility that the tiny slice of the world you've experienced is just that?
- secondcoming 6y ago
  Because what works for one company may not work for another. It's useful to point to any potential cons of a particular approach. I didn't find the comment rude.
  - bvaldivielso 6y ago
    Their point is valid, though the comment reads condescending to me. Maybe it reads condescending to me because I don't agree with it, but I believe it could have been phrased in a less adversarial way: «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.
cies 6y ago
Not sure, but how big are the pools of Haskell-devs over at Galois, FPComplete, HKIO, Facebook, Tsuru Capital, Type Safe, ...? 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.
mightybyte 6y ago
You're off by probably an order of magnitude. You can absolutely scale this organization to 100+ engineers. I've worked at a company with ~30 Haskell developers and I was involved in hiring most of them without lowering our hiring bar. If we really needed more it would have been quite easy to lower the bar a little and increase the numbers significantly. Here's another example of a company that has a large Haskell team: https://iohk.io/en/team/#team=development 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.
d3ckard 6y ago
That's just untrue and Paul Graham wrote a great essay on that(Python paradox, mentioned in another comment in this tree). I have been working with Elixir for last 5 years, so I guess I can give some first hand opinion. 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.

nix23 6y ago

Ever heard of Pandoc? With your logic, python is the only reasonable language.

detaro 6y ago
I don't think "have you heard of this project with <5 main contributors" is a useful response to questioning if it scales to large groups.

infinityplus1 6y ago

Someone has to take the first step to solve the chicken and egg problem. If there are jobs requiring Haskell, it might get more users.

st1x7 6y ago
I don't think that it's wise to sabotage your own future and productivity as a company just so you can pave the way for some language to become more popular.
- mjburgess 6y ago
  It isn't, of course. But the crowd of other people want you to do that. It's the role of applause (and in your case, downvotes). The crowd throws cheap adulation at individuals who act against their own interests.
  - oblio 6y ago
    The peanut gallery :-))
- mightybyte 6y ago
  I don't think that it's wise to try to optimize for some kind of speculative long-term success at the expense of higher early-stage costs that reduce your odds of getting there. This is similar to companies that choose their initial technology with scalability in mind before they're even remotely close to needing to scale. I've actually done this only to discover that scalability has a very definite cost and when you're small it has an outsized impact on your burn rate. If you have success, you're going to figure out a way to make the changes you need. Case in point: Facebook. They successfully grew a PHP codebase into one of the most popular apps in the world. It definitely cost a lot more money for them to make PHP work, but when they got to that point they were a lot less cost-sensitive. 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.
- whateveracct 6y ago
  I think at worst, Haskell is a a minor productivity cost for a company vs a mainstream language, and if it is, it's hard to pin it on the language. 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 :)
414owen 6y ago
I write Haskell professionally, and I can confidently say that there are plenty of jobs. Some large tech companies (eg. Facebook, GitHub, Twitter), quite a few banks, a lot of consultancy companies, and plenty of random companies I'd never heard of. 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.
- PietPtr 6y ago
  Working with Haskell professionally sounds like a very interesting career path. Could you point to some resources to get better at the production Haskell skills that these companies are looking for? Perhaps gaining experience with projects which use Haskell in a similar way to the companies you mention could help with finding that first Haskell job.
  - 414owen 6y ago
    Sure thing. 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 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 This reads as: `m` is a monad if, given an `m a`, and an `a -> m b`, you can construct an `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)) These are monad transformers from the mtl library. 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 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 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/ 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!

st1x7 6y ago

I feel like this isn't discussed enough. I can't comment on the technical merits of Haskell but growing an organization and replacing engineers is so much more difficult when you're using tools that aren't mainstream.

detaro 6y ago
The market works somewhat differently for small companies there. Yes, there are fewer people with relatively niche skills, on the other hand you have an easier time to attract the few you need. Not every company wants to become large.
- st1x7 6y ago
  > on the other hand you have an easier time to attract the few you need How is it easier to find a Haskell developer vs finding a Java/Python/PHP developer?
  - detaro 6y ago
    I hear far more complaints about how difficult it is to find good people from companies hiring for mainstream languages than from those using more niche stuff, I would assume mostly due to larger competition among employers for the former (and in parts better community access for small shops in niche languages and self-selection of who learns the niche languages)
    - dragonwriter 6y ago
      > I hear far more complaints about how difficult it is to find good people from companies hiring for mainstream languages than from those using more niche stuff 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.)

cosmodisk 6y ago

They won't scale to 100+. From what it looks, it's a boutique dev shop that likes doing Haskell and they are going to stay that way +/- a few people here and there depending on how successful their projects are. 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...

fegu 6y ago

Using "boring" Haskell (less higher level magic) alleviates this to some extent - without being boring. The organzation should decide which features and code styles to use. I agree that the summer intern's multi-layer home-built monad transformer stack and custom operators can be a pain.

__0x01 6y ago

I've found that code readability decreases (for me) with the generous use of <$> and $. Edit: removed ` characters.

erik_seaberg 6y ago

Is is actually hard to hire for Haskell? You can’t just tell some random to learn it (because his head will explode), but my impression is that you’ll have candidates coming out of the woodwork who could never get away with using it before but always wanted to.

egwor 6y ago
Quite a few universities in the UK teach haskell as a way to start everyone on a level playing field and to introduce various concepts.
- rednum 6y ago
  Similar situation in Poland. Also my anecdotal experience is that Haskell classes are not considered to be the most difficult, rather they are somewhere in the middle.
  - dagw 6y ago
    The University I went to in Sweden used Haskell for its intro classes. Intermediate classes where taught in Java.
pwm 6y ago
Single datapoint: The last time I posted a job ad (I was the hiring manager) I got ~40 good applicants within a week. I expected much less and got pretty overwhelmed.
dllthomas 6y ago
In my experience, it's easy to hire the next Haskell programmer and hard to hire the next ten. My experience with onboarding non-Haskellers has been pretty good, though I would certainly admit the argument that they were unusually talented individuals.

bachmeier 6y ago

Thanks for sharing, but honestly, what does your comment add to a discussion of the post, which is about what works for them? You're making a rude comment that assumes they don't already know these things. Have you considered the possibility that the tiny slice of the world you've experienced is just that?

secondcoming 6y ago
Because what works for one company may not work for another. It's useful to point to any potential cons of a particular approach. I didn't find the comment rude.
- bvaldivielso 6y ago
  Their point is valid, though the comment reads condescending to me. Maybe it reads condescending to me because I don't agree with it, but I believe it could have been phrased in a less adversarial way: «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.

cies 6y ago

Not sure, but how big are the pools of Haskell-devs over at Galois, FPComplete, HKIO, Facebook, Tsuru Capital, Type Safe, ...? 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.

mightybyte 6y ago

You're off by probably an order of magnitude. You can absolutely scale this organization to 100+ engineers. I've worked at a company with ~30 Haskell developers and I was involved in hiring most of them without lowering our hiring bar. If we really needed more it would have been quite easy to lower the bar a little and increase the numbers significantly. Here's another example of a company that has a large Haskell team: https://iohk.io/en/team/#team=development 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.

d3ckard 6y ago

That's just untrue and Paul Graham wrote a great essay on that(Python paradox, mentioned in another comment in this tree). I have been working with Elixir for last 5 years, so I guess I can give some first hand opinion. 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.