5 ms·

Working with Haskell is not easy, finding Haskell developer is even worse. So we created the project

ruslan_talpa 9y ago
PostgREST is an executable. You are not supposed to change it any more then you change something like PostgreSQL or Nginx. It does not matter what language it's written in.
- justinsaccount 9y ago
  > You are not supposed to change it You are not supposed to change software?
  - agentultra 9y ago
    Do you use Linux in your stack? Do you often extend the kernel? How about nginx or Apache Webserver? Tomcat? Node.js? If you want to contribute to and extend any of those projects you'll usually have to learn C, C++, or Java first if you don't already know them (or otherwise use the approved extension points if they have them, or link to them via some kind of FFI where available, etc, etc).
    - justinsaccount 9y ago
      > If you want to contribute to and extend any of those projects you'll usually have to learn Which is exactly why I don't use software written in java, haskell, nodejs and prefer things written in python or go. Given the choice between PostgREST or pREST I would chose pREST every time simply because if it breaks or ends up unmaintained I would have a chance in fixing it myself. I'm sure there are many people who have the exact opposite stance, and that's fine too. This shouldn't be surprising to anyone.
      - ruslan_talpa 9y ago
        How often did you change the python/go compiler, how about an apache module? :) edit: Point being every day you use a lot (i would say majority) of software which most probably it would be very hard for anyone to "change" and yet this seems to work. There's no point in making a decision to use some software by thinking "am i personally able to understand it's codebase". By this logic there is very little software one person should use, no one is able to know everything. Let the experts (in that particular software) work on it, while you contribute to the things where you are an expert, everybody wins. I remember an article here not long ago about the distinction between an expert and a smart person, interesting read.
      - unscaled 9y ago
        If PostgREST was a niche project with a single maintainer, I'd argue you're right - it's too risky to go with if you can't maintain it yourself. But once the project is large and popular enough (and PostgREST arguably is), you don't maintain it yourself anymore. Keep in mind than in any case you're probably using PostgreSQL and Linux: major pieces of complex C code that you probably can't and won't maintain yourself. To be clear, I do think being able to understand the source code for the system that you're running on and even submit patches or pull request is nice, but this is not what you pointed out as your reason, and it's also never going to be my #1 priority for a production system. For instance, PostgREST looks more mature than pREST and that's a pretty big consideration for a production system.
      - type0 9y ago
        > Which is exactly why I don't use software written in java, haskell, nodejs and prefer things written in python or go. I also prefer Python and Go but to say I would not use the software because of the language it's written in just sounds silly to me. Heck, I really dislike PHP but would still use PHP-software when it suits my need.
    - jwommack 9y ago
      > Do you use Linux in your stack? Do you often extend the kernel? How about nginx or Apache Webserver? Tomcat? You're talking about a massively different scale of thing here, especially in terms of lifecycle and long term support guarantee.
      - ruslan_talpa 9y ago
        You have a point there, but it was probably an exaggeration to give an example. But talking about small things, and long term support. Remember when someone removed a package from npm and the (Node) world stopped for a second? Where is the long time support there and guarantee. But still, this is how all of it works. Take any language, build anything nontrivial, i bet you'll end up using libraries far less supported and much younger then PostgREST.
    - zer00eyz 9y ago
      > Do you use Linux in your stack? Do you often extend the kernel? How about nginx or Apache Webserver? I have done all of these at one point or another in my career, as well as several others, and I have not been a contributor back to them. These were either know issues with separate fixes and consequences or very specific to the company I was working for at the time. Do I know C or C++. The answer is not really... However C and C++ (and to some extent java) are pervasive. Haskel doesn't fall into that camp. If your a Golang shop and you have a need for this, then it might be something you choose incase you need to support it, or tune it or mould it to your needs. Beyond that, projects like this are GREAT for go. You have a well defined problem space, an existing tool and a reimplementation like this is only going to grow the authors knowledge and expand the Golang universe.
      - solidsnack9000 9y ago
        There is a citizenship aspect of this that seems dubious, though. Expanding "the Golang universe" with a reimplementation isn't really expanding the computing capabilities available to all of us; or even to people doing Go. With regards to growing "the authors knowledge" -- contributing to PostgREST would have done a lot more for them there, since Haskell is quite different from Go.
        zer00eyz 9y ago
        > There is a citizenship aspect of this that seems dubious, though. Expanding "the Golang universe" with a reimplementation Maybe, but reimplementations can evolve differently... This is why we have forks and distros, and to some extent linux. > With regards to growing "the authors knowledge" -- contributing to PostgREST would have done a lot more for them there, since Haskell is quite different from Go. Your making the mighty assumption that one wants to learn a language, or that the language is good (NOT taking a pot shot at haskell here) or that it makes sense in their environment. I think you raise some important points however, that do need to be part of the decision to undertake reimplmentaion of something that already exists.
        solidsnack9000 9y ago
  - cel1ne 9y ago
    I have successfully made small patches to postgrest using haskell-knowledge from a single semester at university 11 years ago.
- thallesr 9y ago
  really? isn't it the point in open source software.
  - ruslan_talpa 9y ago
    The choice of words might be unfortunate, but the point is that you don't have to change it any more the PostgreSQL/Nginx in order to use and develop apis with it.
    - bpicolo 9y ago
      Unless you have different requirements than the baseline, which is common
      - derefr 9y ago
        In my experience, most such people just solve this problem by either: 1. submitting an issue to the project's issue tracker, and waiting; 2. submitting an issue to the project's issue tracker, and becoming a project sponsor to expedite; 3. customizing the software using a scripting language it exposes; 4. using a third-party "plugin" for the project that someone else already developed to solve the problem; 5. developing such a plugin yourself, using the software's C FFI API to write your plugin library in your language of choice, rather than the language the software itself is written in; 6. wrapping the software in a single-purpose gateway that decorates or mutates its wire protocol/API with the new features. In practice, actually modifying the server software itself is very rare. Needlessly rare, even. Some great, clean codebases (Postgres itself; Nginx) get strategies #3-#6 applied so often that there exists a whole ecosystem of features "around" them that really should be in their cores, because everyone was too afraid to touch them even when they're written in common languages.
codygman 9y ago
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.
solidsnack9000 9y ago
This doesn't speak to the question that was asked, though. The original post -- "keep a haskell software in production is not easy job" -- implies PostgREST presents operational difficulties, which is quite different from what you are saying here. There is plenty of software that people use without direct competency in the underlying language -- for example, running Jenkins to do builds for a RoR shop does not require a Java programmer.

PostgREST is an executable. You are not supposed to change it any more then you change something like PostgreSQL or Nginx. It does not matter what language it's written in.

justinsaccount 9y ago
> You are not supposed to change it You are not supposed to change software?
- agentultra 9y ago
  Do you use Linux in your stack? Do you often extend the kernel? How about nginx or Apache Webserver? Tomcat? Node.js? If you want to contribute to and extend any of those projects you'll usually have to learn C, C++, or Java first if you don't already know them (or otherwise use the approved extension points if they have them, or link to them via some kind of FFI where available, etc, etc).
  - justinsaccount 9y ago
    > If you want to contribute to and extend any of those projects you'll usually have to learn Which is exactly why I don't use software written in java, haskell, nodejs and prefer things written in python or go. Given the choice between PostgREST or pREST I would chose pREST every time simply because if it breaks or ends up unmaintained I would have a chance in fixing it myself. I'm sure there are many people who have the exact opposite stance, and that's fine too. This shouldn't be surprising to anyone.
    - ruslan_talpa 9y ago
      How often did you change the python/go compiler, how about an apache module? :) edit: Point being every day you use a lot (i would say majority) of software which most probably it would be very hard for anyone to "change" and yet this seems to work. There's no point in making a decision to use some software by thinking "am i personally able to understand it's codebase". By this logic there is very little software one person should use, no one is able to know everything. Let the experts (in that particular software) work on it, while you contribute to the things where you are an expert, everybody wins. I remember an article here not long ago about the distinction between an expert and a smart person, interesting read.
    - unscaled 9y ago
      If PostgREST was a niche project with a single maintainer, I'd argue you're right - it's too risky to go with if you can't maintain it yourself. But once the project is large and popular enough (and PostgREST arguably is), you don't maintain it yourself anymore. Keep in mind than in any case you're probably using PostgreSQL and Linux: major pieces of complex C code that you probably can't and won't maintain yourself. To be clear, I do think being able to understand the source code for the system that you're running on and even submit patches or pull request is nice, but this is not what you pointed out as your reason, and it's also never going to be my #1 priority for a production system. For instance, PostgREST looks more mature than pREST and that's a pretty big consideration for a production system.
    - type0 9y ago
      > Which is exactly why I don't use software written in java, haskell, nodejs and prefer things written in python or go. I also prefer Python and Go but to say I would not use the software because of the language it's written in just sounds silly to me. Heck, I really dislike PHP but would still use PHP-software when it suits my need.
  - jwommack 9y ago
    > Do you use Linux in your stack? Do you often extend the kernel? How about nginx or Apache Webserver? Tomcat? You're talking about a massively different scale of thing here, especially in terms of lifecycle and long term support guarantee.
    - ruslan_talpa 9y ago
      You have a point there, but it was probably an exaggeration to give an example. But talking about small things, and long term support. Remember when someone removed a package from npm and the (Node) world stopped for a second? Where is the long time support there and guarantee. But still, this is how all of it works. Take any language, build anything nontrivial, i bet you'll end up using libraries far less supported and much younger then PostgREST.
  - zer00eyz 9y ago
    > Do you use Linux in your stack? Do you often extend the kernel? How about nginx or Apache Webserver? I have done all of these at one point or another in my career, as well as several others, and I have not been a contributor back to them. These were either know issues with separate fixes and consequences or very specific to the company I was working for at the time. Do I know C or C++. The answer is not really... However C and C++ (and to some extent java) are pervasive. Haskel doesn't fall into that camp. If your a Golang shop and you have a need for this, then it might be something you choose incase you need to support it, or tune it or mould it to your needs. Beyond that, projects like this are GREAT for go. You have a well defined problem space, an existing tool and a reimplementation like this is only going to grow the authors knowledge and expand the Golang universe.
    - solidsnack9000 9y ago
      There is a citizenship aspect of this that seems dubious, though. Expanding "the Golang universe" with a reimplementation isn't really expanding the computing capabilities available to all of us; or even to people doing Go. With regards to growing "the authors knowledge" -- contributing to PostgREST would have done a lot more for them there, since Haskell is quite different from Go.
      - zer00eyz 9y ago
        > There is a citizenship aspect of this that seems dubious, though. Expanding "the Golang universe" with a reimplementation Maybe, but reimplementations can evolve differently... This is why we have forks and distros, and to some extent linux. > With regards to growing "the authors knowledge" -- contributing to PostgREST would have done a lot more for them there, since Haskell is quite different from Go. Your making the mighty assumption that one wants to learn a language, or that the language is good (NOT taking a pot shot at haskell here) or that it makes sense in their environment. I think you raise some important points however, that do need to be part of the decision to undertake reimplmentaion of something that already exists.
        solidsnack9000 9y ago
- cel1ne 9y ago
  I have successfully made small patches to postgrest using haskell-knowledge from a single semester at university 11 years ago.
thallesr 9y ago
really? isn't it the point in open source software.
- ruslan_talpa 9y ago
  The choice of words might be unfortunate, but the point is that you don't have to change it any more the PostgreSQL/Nginx in order to use and develop apis with it.
  - bpicolo 9y ago
    Unless you have different requirements than the baseline, which is common
    - derefr 9y ago
      In my experience, most such people just solve this problem by either: 1. submitting an issue to the project's issue tracker, and waiting; 2. submitting an issue to the project's issue tracker, and becoming a project sponsor to expedite; 3. customizing the software using a scripting language it exposes; 4. using a third-party "plugin" for the project that someone else already developed to solve the problem; 5. developing such a plugin yourself, using the software's C FFI API to write your plugin library in your language of choice, rather than the language the software itself is written in; 6. wrapping the software in a single-purpose gateway that decorates or mutates its wire protocol/API with the new features. In practice, actually modifying the server software itself is very rare. Needlessly rare, even. Some great, clean codebases (Postgres itself; Nginx) get strategies #3-#6 applied so often that there exists a whole ecosystem of features "around" them that really should be in their cores, because everyone was too afraid to touch them even when they're written in common languages.

codygman 9y ago

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.

solidsnack9000 9y ago

This doesn't speak to the question that was asked, though. The original post -- "keep a haskell software in production is not easy job" -- implies PostgREST presents operational difficulties, which is quite different from what you are saying here. There is plenty of software that people use without direct competency in the underlying language -- for example, running Jenkins to do builds for a RoR shop does not require a Java programmer.