4 ms·

Name some OSS: - Written in Haskell - Not a tool for manipulating Haskell - With a substantial user base - Other than Pandoc, xmonad, or shellcheck Partial

Name some OSS: - Written in Haskell - Not a tool for manipulating Haskell - With a substantial user base - Other than Pandoc, xmonad, or shellcheck Partial credit if you can name closed source software instead. For Go, off the top of my head, Docker/K8s would qualify, but if we want to eliminate that, Hugo, Caddy, Gogs, etcd, fzf… https://github.com/search?q=stars%3A%3E1000+language%3AGo&type=Repositories&ref=advsearch&l=Go&l= https://github.com/search?q=stars%3A%3E1000+language%3AGo&ty... https://github.com/search?l=&o=desc&q=stars%3A%3E1000+language%3AHaskell&s=stars&type=Repositories https://github.com/search?l=&o=desc&q=stars%3A%3E1000+langua...

thayne 6y ago
Git-annex, darcs, postgREST. I might have cheated and used google, but those are all projects I've heard of before. And it's not really fair to exclude big projects for haskell, but not for go.
- earthboundkid 6y ago
  I explicitly excluded the big Go projects of Docker/K8s. I think I've heard the name darcs, but have no idea what it is or does. I may have heard of postgrest but I think the whole category of a thin layer over the DB is dumb, so I refuse to learn about it. :-) (If you want to talk to your DB, use the native SQL drivers. Don't just invent the same thing but as REST or GraphQL for no reason. Backend system should connect SQL to SQL. If you want a browser to be able to talk to your DB, then you will need auth and want bundling of calls and object translation and suddenly the thin translation layer isn't thin anymore.) Anyway, the point is that Haskell has been around for a long time and is very popular with HN/Reddit users, but unlike Go and Rust, it has produced a very small amount of OSS.
  - eru 6y ago
    Darcs is a distributed version control system. It predates git. I tried using darcs for a bit. But the designers were a bit too ambitious: they had an elegant concept to solve all rebases automatically at least in principle. Alas, the early implementations sometimes ran into corner cases that had exponential runtime. Which in practice meant that it hang forever for all a user could tell. As far as I can recall, that behaviour is fixed now. But they missed their window of opportunity, when other dvcs became really popular. Like git. Interestingly, git had the opposite philosophy: they explicitly only resolve simple conflicts in a simple way, and bubble up anything slightly more complicated to the user. About SQL: Haskell users wouldn't want to use SQL directly. They want their compiler to yell at them when they get their database interactions wrong. So they don't want some much to have a layer on top of SQL that hides things, but they'd rather want some support to forbid nonsensical SQL queries. Interestingly, at one of my previous jobs we had 'relational object mappers' in our Haskell code. What that means is that we used relations as data structures inside our Haskell code, but had to interact with a mostly object oriented world on the outside. Relations make fabulous data structures for expressing business logic. Take the leap in expressivity coming from eg dumb C to Python's ad-hoc dicts and tuples, and then imagine making a similar step again, and you arrive at relations. Especially the various kinds of joins are good at expressing many business concerns. But projections and maps etc as well. Basically, everything that makes SQL useful, but embedded in a better language and just as a datastructure. Codd's paper on relational algebra (https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf) is just as relevant to in-memory programming as it is to data bases. > Anyway, the point is that Haskell has been around for a long time and is very popular with HN/Reddit users, but unlike Go and Rust, it has produced a very small amount of OSS. The ML family of languages that Haskell is a part of has been around for even longer, and many of the beloved features of Haskell stem from that older legacy. I don't have high hopes of the ML family becoming more mainstream. But I am really glad to see many advances born in the land of functional programming, and ML or Haskell in particular, making it out into the wider world. The poster child is garbage collection. Which was invented for Lisp in the first place. (You can do functional programming without garbage collection, but it requires much more finesse and understanding than they had when Lisp was young. And even then, garbage collection is probably still the right trade-off when you programme is not resource constrained.) Garbage collection is pretty much the default for new languages these days. People expect a good rationale for any deviation. More recently we have seen first class functions, closures and lambdas make it out into the wider world. Even Java and C++ have picked up some of those. First class functions belong relate to a wider theme of 'first class' elements of your programming language. I remember that eg in Perl you had to jump through extra hoops to make an array of arrays. That's because arrays were not by default treated the same as any other value. I think Python did a lot for the mainstream here: Python is pretty good at letting you assign many of its constructs (like classes or functions or ints or tuples etc) to variables and pass them around just like any other value. In the understanding of the Python community, they see that just as good OOP, of course. Combinators like map and filter have become popular in mainstream languages. Algebraic data types have made it to a few languages. With that comes structural pattern matching, and the compiler complaining when you miss a case. Tuples are pretty much expected in any new language these days. The very article we are commenting on talks about generics. Immutable data types are something every new language is supposed to have thought about. Even C++ has const and Java has final. Go's designers were asked to justify their very limited support for immutability. Many people go so far as suggesting immutability should be the default in new languages. (And you could very well imagine a dialect of C++ where 'const' is implied, and you need 'mutable' everywhere, if you want to override that.) There's quite a few more examples. Of course, correlation is not causation, and so not everything that showed up in functional programming languages before it showed up in the mainstream means that the mainstream actually got it from FP. --- In summary, you are right that Haskell has not been used in OSS or commercial products as much as eg Go, but I am just happy that the rest of the world is moving in the Right Direction.
    - earthboundkid 6y ago
      I’ll agree with that: while Haskell/FP has had a ton of OSS, it has had a huge, positive impact on other languages. Eg Rust would never exist without Haskell being around first.
      - earthboundkid 6y ago
        * "has not had"
eru 6y ago
Huh? What does Haskell's (lack of) adoption have to do with any merits of Go? PHP, Visual Basic (perhaps?) and Javascript have even better adoption than Go, if you want to go down that route. If anything, you should have asked about the prospects of OCaml, shouldn't you? (Spoiler alert: they are grimmer than Haskell's.) Mostly, Go is full of wasted opportunities. It would have perhaps been a worthwhile language had they come up with Go instead of C in the 1970s. https://github.com/ksimka/go-is-not-good https://github.com/ksimka/go-is-not-good is a good summary. I would suggest having a look at D as an example of what an evolution of C could look. An evolution with fewer wasted opportunities.
- aldanor 6y ago
  OCaml is used, for instance, as a main language in Jane Street which is a top prop trading firm. They also are the main sponsors of the language and contribute a lot to the compiler, but that doesn't invalidate the point.
  - eru 6y ago
    Yes. We also used OCaml at Bloomberg quite a bit. (And they are still using it, but I'm not there anymore.) But there's not that much more in the commercial OCaml world. Haskell has actually a bit of a broader adoption. The open source library situation is also better. (For the record, I like both OCaml and Haskell. And Janestreet are doing a great job. And commercial and open source adoption are important. But they are not the end to every discussion.)
- still_grokking 6y ago
  Funny that I also always claim D being "the better Go". It has a very similar compilation and runtime model. But D is a much more powerful language, it's not "dumbed down to the max". For people that like Go's runtime model but don't see "simplified at all costs" as an advantage D could be just right.
stevefan1999 6y ago
[Hasura GraphQL Engine](https://hasura.io/ https://hasura.io/)

thayne 6y ago

Git-annex, darcs, postgREST. I might have cheated and used google, but those are all projects I've heard of before. And it's not really fair to exclude big projects for haskell, but not for go.

earthboundkid 6y ago
I explicitly excluded the big Go projects of Docker/K8s. I think I've heard the name darcs, but have no idea what it is or does. I may have heard of postgrest but I think the whole category of a thin layer over the DB is dumb, so I refuse to learn about it. :-) (If you want to talk to your DB, use the native SQL drivers. Don't just invent the same thing but as REST or GraphQL for no reason. Backend system should connect SQL to SQL. If you want a browser to be able to talk to your DB, then you will need auth and want bundling of calls and object translation and suddenly the thin translation layer isn't thin anymore.) Anyway, the point is that Haskell has been around for a long time and is very popular with HN/Reddit users, but unlike Go and Rust, it has produced a very small amount of OSS.
- eru 6y ago
  Darcs is a distributed version control system. It predates git. I tried using darcs for a bit. But the designers were a bit too ambitious: they had an elegant concept to solve all rebases automatically at least in principle. Alas, the early implementations sometimes ran into corner cases that had exponential runtime. Which in practice meant that it hang forever for all a user could tell. As far as I can recall, that behaviour is fixed now. But they missed their window of opportunity, when other dvcs became really popular. Like git. Interestingly, git had the opposite philosophy: they explicitly only resolve simple conflicts in a simple way, and bubble up anything slightly more complicated to the user. About SQL: Haskell users wouldn't want to use SQL directly. They want their compiler to yell at them when they get their database interactions wrong. So they don't want some much to have a layer on top of SQL that hides things, but they'd rather want some support to forbid nonsensical SQL queries. Interestingly, at one of my previous jobs we had 'relational object mappers' in our Haskell code. What that means is that we used relations as data structures inside our Haskell code, but had to interact with a mostly object oriented world on the outside. Relations make fabulous data structures for expressing business logic. Take the leap in expressivity coming from eg dumb C to Python's ad-hoc dicts and tuples, and then imagine making a similar step again, and you arrive at relations. Especially the various kinds of joins are good at expressing many business concerns. But projections and maps etc as well. Basically, everything that makes SQL useful, but embedded in a better language and just as a datastructure. Codd's paper on relational algebra (https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf) is just as relevant to in-memory programming as it is to data bases. > Anyway, the point is that Haskell has been around for a long time and is very popular with HN/Reddit users, but unlike Go and Rust, it has produced a very small amount of OSS. The ML family of languages that Haskell is a part of has been around for even longer, and many of the beloved features of Haskell stem from that older legacy. I don't have high hopes of the ML family becoming more mainstream. But I am really glad to see many advances born in the land of functional programming, and ML or Haskell in particular, making it out into the wider world. The poster child is garbage collection. Which was invented for Lisp in the first place. (You can do functional programming without garbage collection, but it requires much more finesse and understanding than they had when Lisp was young. And even then, garbage collection is probably still the right trade-off when you programme is not resource constrained.) Garbage collection is pretty much the default for new languages these days. People expect a good rationale for any deviation. More recently we have seen first class functions, closures and lambdas make it out into the wider world. Even Java and C++ have picked up some of those. First class functions belong relate to a wider theme of 'first class' elements of your programming language. I remember that eg in Perl you had to jump through extra hoops to make an array of arrays. That's because arrays were not by default treated the same as any other value. I think Python did a lot for the mainstream here: Python is pretty good at letting you assign many of its constructs (like classes or functions or ints or tuples etc) to variables and pass them around just like any other value. In the understanding of the Python community, they see that just as good OOP, of course. Combinators like map and filter have become popular in mainstream languages. Algebraic data types have made it to a few languages. With that comes structural pattern matching, and the compiler complaining when you miss a case. Tuples are pretty much expected in any new language these days. The very article we are commenting on talks about generics. Immutable data types are something every new language is supposed to have thought about. Even C++ has const and Java has final. Go's designers were asked to justify their very limited support for immutability. Many people go so far as suggesting immutability should be the default in new languages. (And you could very well imagine a dialect of C++ where 'const' is implied, and you need 'mutable' everywhere, if you want to override that.) There's quite a few more examples. Of course, correlation is not causation, and so not everything that showed up in functional programming languages before it showed up in the mainstream means that the mainstream actually got it from FP. --- In summary, you are right that Haskell has not been used in OSS or commercial products as much as eg Go, but I am just happy that the rest of the world is moving in the Right Direction.
  - earthboundkid 6y ago
    I’ll agree with that: while Haskell/FP has had a ton of OSS, it has had a huge, positive impact on other languages. Eg Rust would never exist without Haskell being around first.
    - earthboundkid 6y ago
      * "has not had"

eru 6y ago

Huh? What does Haskell's (lack of) adoption have to do with any merits of Go? PHP, Visual Basic (perhaps?) and Javascript have even better adoption than Go, if you want to go down that route. If anything, you should have asked about the prospects of OCaml, shouldn't you? (Spoiler alert: they are grimmer than Haskell's.) Mostly, Go is full of wasted opportunities. It would have perhaps been a worthwhile language had they come up with Go instead of C in the 1970s. https://github.com/ksimka/go-is-not-good https://github.com/ksimka/go-is-not-good is a good summary. I would suggest having a look at D as an example of what an evolution of C could look. An evolution with fewer wasted opportunities.

aldanor 6y ago
OCaml is used, for instance, as a main language in Jane Street which is a top prop trading firm. They also are the main sponsors of the language and contribute a lot to the compiler, but that doesn't invalidate the point.
- eru 6y ago
  Yes. We also used OCaml at Bloomberg quite a bit. (And they are still using it, but I'm not there anymore.) But there's not that much more in the commercial OCaml world. Haskell has actually a bit of a broader adoption. The open source library situation is also better. (For the record, I like both OCaml and Haskell. And Janestreet are doing a great job. And commercial and open source adoption are important. But they are not the end to every discussion.)
still_grokking 6y ago
Funny that I also always claim D being "the better Go". It has a very similar compilation and runtime model. But D is a much more powerful language, it's not "dumbed down to the max". For people that like Go's runtime model but don't see "simplified at all costs" as an advantage D could be just right.

stevefan1999 6y ago

[Hasura GraphQL Engine](https://hasura.io/ https://hasura.io/)