Working with Haskell is not easy, finding Haskell developer is even worse. So we created the project
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.
You are not supposed to change software?
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).
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.
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.
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.
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.
You're talking about a massively different scale of thing here, especially in terms of lifecycle and long term support guarantee.
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.
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.
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.
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.
I am not making either of these assumptions at all -- I am only asserting that there is plenty to learn from a typed functional programming language, if it seems difficult at first. That doesn't mean it is good, nor that you want to learn it.
Wise men learn more from fools than fools learn from wise men. Some languages are bad but because they are significantly different from what I learned before, I learned a lot from them.
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.
Did you post on Functional Jobs, haskell-cafe, and r/haskell?
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.
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.