4 ms·

Can you briefly talk about the issues you experienced working with Haskell and the even worse issues you experienced trying to find Haskell developers? Did you

Can you briefly talk about the issues you experienced working with Haskell and the even worse issues you experienced trying to find Haskell developers? Did you post on Functional Jobs, haskell-cafe, and r/haskell?

kornish 9y ago
To play devil's advocate (as a huge FP fan myself), it's undeniably harder to find a Haskell-literate programmer compared to a Go one. If an organization is going to be changing and maintaining software, too, it can also be unwarranted debt and risk to introduce a new language and ecosystem into their software stack. Seems like NuevoHQ is a Go shop. I was just confused by whether or not this project was inspired because it's difficult to extend PostgREST or because of operation issues with PostgREST itself. Seems like the former...though I'm not sure what this does that PostgREST doesn't.
- ruslan_talpa 9y ago
  It's technically correct what you are saying but it's a "businessy" way of looking at the landscape. Developers (and orgs even more) should try and always expand their area of competence, not limit themselves to one area (not saying they should be experts in all). A good piece of tech should make you want to learn a language more (RabbitMQ/Erlang, PostgREST/Haskell, Pandoc/Haskell/).
  - kornish 9y ago
    > It's technically correct what you are saying but it's a "businessy" way of looking at the landscape. For sure. Hence my business-oriented qualification "If an organization is going to be changing and maintaining software...". > Developers (and orgs even more) should try and always expand their area of competence, not limit themselves to one area. About developers: absolutely. Constant growth is a must. About large and mature orgs: agree. That's what R&D budgets are for. About startups: disagree. Invest only in what you need to ship product and gain differentiated competitive advantage. When there's an infinite queue of features to build and bugs to fix, not taking on unwarranted technical debt is key - and it's easiest to take on accidental technical debt when you don't have experience in a tool, language, or ecosystem. I think a point expressed elsewhere in this thread is worth reiterating: language agnostic APIs (e.g. a HTTP API) mean that I don't have to care what language something is implemented in to use it. That's a Good Thing. Learn Erlang to hack on RabbitMQ? Sure, for fun. But if I'm putting it in prod for customers, I care more about how my application code - in a language I'm strong with - interfaces with it than the internals.

kornish 9y ago

To play devil's advocate (as a huge FP fan myself), it's undeniably harder to find a Haskell-literate programmer compared to a Go one. If an organization is going to be changing and maintaining software, too, it can also be unwarranted debt and risk to introduce a new language and ecosystem into their software stack. Seems like NuevoHQ is a Go shop. I was just confused by whether or not this project was inspired because it's difficult to extend PostgREST or because of operation issues with PostgREST itself. Seems like the former...though I'm not sure what this does that PostgREST doesn't.

ruslan_talpa 9y ago
It's technically correct what you are saying but it's a "businessy" way of looking at the landscape. Developers (and orgs even more) should try and always expand their area of competence, not limit themselves to one area (not saying they should be experts in all). A good piece of tech should make you want to learn a language more (RabbitMQ/Erlang, PostgREST/Haskell, Pandoc/Haskell/).
- kornish 9y ago
  > It's technically correct what you are saying but it's a "businessy" way of looking at the landscape. For sure. Hence my business-oriented qualification "If an organization is going to be changing and maintaining software...". > Developers (and orgs even more) should try and always expand their area of competence, not limit themselves to one area. About developers: absolutely. Constant growth is a must. About large and mature orgs: agree. That's what R&D budgets are for. About startups: disagree. Invest only in what you need to ship product and gain differentiated competitive advantage. When there's an infinite queue of features to build and bugs to fix, not taking on unwarranted technical debt is key - and it's easiest to take on accidental technical debt when you don't have experience in a tool, language, or ecosystem. I think a point expressed elsewhere in this thread is worth reiterating: language agnostic APIs (e.g. a HTTP API) mean that I don't have to care what language something is implemented in to use it. That's a Good Thing. Learn Erlang to hack on RabbitMQ? Sure, for fun. But if I'm putting it in prod for customers, I care more about how my application code - in a language I'm strong with - interfaces with it than the internals.