4 ms·

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

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.

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.