4 ms·

I personally would really hesitate before picking a language that will be hard to hire for to build a business around. Yes, you'll be more productive in the sho

I personally would really hesitate before picking a language that will be hard to hire for to build a business around. Yes, you'll be more productive in the short-term, but a business is more than just code and you will need to wear those hats too before you'll have enough understanding and resources to hire those out. At this point, I'm fairly certain your first hire should be someone to take the engineering load off of you. Engineering will be the only thing you really, truly understand about your business and so it will be the only thing you'll be able to effectively manage others doing.

theaustinseven 10y ago
> you'll be more productive in the short-term I'm not so sure. One of the advantages of these more mainstream languages is the combination of an incredibly large selection of libraries and many people having already made the mistake you will make. This means when you run into an issue, there are already several posts on stack overflow about it, and you move on without issue.
- jlouis 10y ago
  The really interesting problems have the property that there is no library written for them yet. Granted, you need some kind of interaction with the outside world, but this is easy to handle in another language layer. The "existing libraries" are only going to be efficient if your entrepreneurship is based around the idea of rehashing or recombining existing tooling, which is already there. But far from all projects has that property. Also, one of the really intriguing thing about splitting your service into smaller micro-service based architectures, is that you can mix and match different languages. Which gives you the ability to pick languages which suits a solution. A good example is the TensorFlow system by Google. Model building usually happens in Python, but you then load that model into a thin C++ layer which serves the requests on the network as a standalone application. The same approach can be taken with some of the more advanced languages. Even better, as a startup, the least of your worries straight away is horizontal scaling. Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling? This help the micro-service model even more, as there is less reason to worry about the communication overhead.
  - pdpi 10y ago
    > The really interesting problems have the property that there is no library written for them yet. But it's the reverse of that that's precisely the point though. If all the uninteresting problems already do have nicely packaged solutions, you get to focus on the interesting problem instead. The question then becomes: are you better off solving the interesting problems in better language at he cost of having to solve more of the uninteresting ones?
  - eva1984 10y ago
    > Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling. Because that node might die any second.
melling 10y ago
"I personally would really hesitate before picking a language that will be hard to hire for to build a business around" Unfortunately, this is HN so we know you're wrong: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- cle 10y ago
  Not everyone here accepts PG articles as infallible scripture, and many people have lots of experience to back up their disagreement. (I agree with PG on this issue.)
dsacco 10y ago
Jane Street Capital's Yaron Minsky once said that contrary to popular belief hiring for OCaml developers was easier because the signal to noise ratio in the OCaml community is so much better than other, more approachable languages. He would send a job post to the OCaml mailing list, get 15 responses, interview 10 people, bring five onsite and ultimately hire three new people. I don't have direct experience with this, but it makes sense in theory. PHP is an easy language to find developers for, but it's incredibly annoying to figure out how competent the developers you're interviewing in that ecosystem will be. But languages like Haskell and Scala have a (perceived or real) barrier to entry, so you typically have a higher median ability among developers in those languages.
- iheartmemcache 10y ago
  I've got managerial experience hiring (on both ends of the spectrum of talent) and engineering experience in computational finance at a prop firm similar to Jane Street. He has a fast-hire ability and high-signal to noise for sure but he works at a prop firm. His hiring practices are a market anomaly simply because he can pay effectively whatever a competent developer wants. Jane Street can basically throw money at the problem. What you have at a 'normal' company is a real difficult time finding someone who can tell me when to use a lens and when to use a zipper in Haskell who are actively looking for employment. Anecdotal but I casually attend Boston Haskell and I can't remember the last time someone was out of work other than 'funemployment' (e.g. a startup goes bust and they have accrued more than enough money to just sit around, stretch and work on pet projects). The second they 'need' a job, they'll casually mention it and I think ~3 out of the ~7 times this has happened, someone in the crowd went like "oh Bill, yeah come in to <his office> Monday and meet our CTO". No recruiters, no wait. The CTO trusts Joe has heard Todd ask enough insightful questions consistently enough that he's going to be a good hire. Tuesday 9AM HR, 10AM pull the repo down, setup stack, start poking around Haddock and start closing the easy tickets. Good talent (10 of the 15 applicants are quality) might respond to Minsky but those other 9 guys will be picked up almost invariably in well under two weeks
  - dsacco 10y ago
    Thanks for adding more color to this!

theaustinseven 10y ago

> you'll be more productive in the short-term I'm not so sure. One of the advantages of these more mainstream languages is the combination of an incredibly large selection of libraries and many people having already made the mistake you will make. This means when you run into an issue, there are already several posts on stack overflow about it, and you move on without issue.

jlouis 10y ago
The really interesting problems have the property that there is no library written for them yet. Granted, you need some kind of interaction with the outside world, but this is easy to handle in another language layer. The "existing libraries" are only going to be efficient if your entrepreneurship is based around the idea of rehashing or recombining existing tooling, which is already there. But far from all projects has that property. Also, one of the really intriguing thing about splitting your service into smaller micro-service based architectures, is that you can mix and match different languages. Which gives you the ability to pick languages which suits a solution. A good example is the TensorFlow system by Google. Model building usually happens in Python, but you then load that model into a thin C++ layer which serves the requests on the network as a standalone application. The same approach can be taken with some of the more advanced languages. Even better, as a startup, the least of your worries straight away is horizontal scaling. Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling? This help the micro-service model even more, as there is less reason to worry about the communication overhead.
- pdpi 10y ago
  > The really interesting problems have the property that there is no library written for them yet. But it's the reverse of that that's precisely the point though. If all the uninteresting problems already do have nicely packaged solutions, you get to focus on the interesting problem instead. The question then becomes: are you better off solving the interesting problems in better language at he cost of having to solve more of the uninteresting ones?
- eva1984 10y ago
  > Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling. Because that node might die any second.

melling 10y ago

"I personally would really hesitate before picking a language that will be hard to hire for to build a business around" Unfortunately, this is HN so we know you're wrong: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

cle 10y ago
Not everyone here accepts PG articles as infallible scripture, and many people have lots of experience to back up their disagreement. (I agree with PG on this issue.)

dsacco 10y ago

Jane Street Capital's Yaron Minsky once said that contrary to popular belief hiring for OCaml developers was easier because the signal to noise ratio in the OCaml community is so much better than other, more approachable languages. He would send a job post to the OCaml mailing list, get 15 responses, interview 10 people, bring five onsite and ultimately hire three new people. I don't have direct experience with this, but it makes sense in theory. PHP is an easy language to find developers for, but it's incredibly annoying to figure out how competent the developers you're interviewing in that ecosystem will be. But languages like Haskell and Scala have a (perceived or real) barrier to entry, so you typically have a higher median ability among developers in those languages.

iheartmemcache 10y ago
I've got managerial experience hiring (on both ends of the spectrum of talent) and engineering experience in computational finance at a prop firm similar to Jane Street. He has a fast-hire ability and high-signal to noise for sure but he works at a prop firm. His hiring practices are a market anomaly simply because he can pay effectively whatever a competent developer wants. Jane Street can basically throw money at the problem. What you have at a 'normal' company is a real difficult time finding someone who can tell me when to use a lens and when to use a zipper in Haskell who are actively looking for employment. Anecdotal but I casually attend Boston Haskell and I can't remember the last time someone was out of work other than 'funemployment' (e.g. a startup goes bust and they have accrued more than enough money to just sit around, stretch and work on pet projects). The second they 'need' a job, they'll casually mention it and I think ~3 out of the ~7 times this has happened, someone in the crowd went like "oh Bill, yeah come in to <his office> Monday and meet our CTO". No recruiters, no wait. The CTO trusts Joe has heard Todd ask enough insightful questions consistently enough that he's going to be a good hire. Tuesday 9AM HR, 10AM pull the repo down, setup stack, start poking around Haddock and start closing the easy tickets. Good talent (10 of the 15 applicants are quality) might respond to Minsky but those other 9 guys will be picked up almost invariably in well under two weeks
- dsacco 10y ago
  Thanks for adding more color to this!