15 ms·

New Haskell Foundation to Foster Haskell Adoption, Raises 200k USD

160 points by antouank 6y ago

escape_goat 6y ago
The headline is a bit too generic. This organization is being founded with the support of Simon Peyton Jones and has corporate backing. It appears that the intent is to focus on pain points in the Haskell toolchain and libraries.
- Blikkentrekker 6y ago
  To me, the major major unsung pain point with Haskell and any non-strict language that makes it unsuitable for most applications is it's inability to use dynamic libraries as we're all used to. For an Haskell implementation to have any efficiency, it must re-order the order of execution inside of function calls as it sees fit, which it can do due to the non-strict semantics. This is fine in theory, but dynamic libraries aren't built on that assumption; they're, naturally, built upon the idea that they are a black box and that the consumer simply calls the function, obtains the result, and does not care nor has access to the insides. A Haskell implementation must have knowledge thereof, thus, the practical effect is that with Haskell it's impossible to, say, fix a security problem in a dynamic library and simply have all consumers seamlessly benefit from that fix — every consumer must be recompiled with the new library's source. And this problem is very seldom raised in discussions — dynamic libraries are fundamentally designed on the assumption of strict semantics.
  - simonfxr 6y ago
    I don't see how strict vs. lazy has anything to do with linkage. I guess you are talking about foreign functions defined in a dynamic library. Calling a foreign function (regardless of linkage) will just evaluate the arguments and pass them according to the calling convention of the foreign ABI. If you link to library dynamically and it gets updated (in an ABI compatible way) you don't have to recompile anything, it just works as you would expect.
    - Blikkentrekker 6y ago
      No, the issue does not apply to the f.f.i., because those are called with strict semantics, as C expects that. It's about dynamic libraries written in Haskell itself. Try compiling a Haskell program in GHC with the `-dynamic` flag, and then update any of the Haskell libraries it is linked against, after this, the program will fail to start with a linker error, and must be recompiled itself. https://www.reddit.com/r/archlinux/comments/7jtemw/which_package_do_you_hate_the_most/dra5q7v/ https://www.reddit.com/r/archlinux/comments/7jtemw/which_pac... See this discussion there which explains why, in essence, dynamic linking is not a feasible route with Haskell. Arch Linux currently does this, or at least at the time of writing there, which leads to all Arch Haskell packages being required to be recompiled and reinstalled, if but a simple library be updated that they all use.
      - tome 6y ago
        Yes, but this doesn't seem to have anything to do with lazy evaluation, rather it is because GHC is quite close to a whole-program optimizer.
        Blikkentrekker 6y ago
        Optimizing lazy evaluation requires this kind of hole-program optimizations. Non-strict semantics would be prohibitively slow without these optimizations. You won't find a Haskell compiler that doesn't do this.
      - simonfxr 6y ago
        Okay you are right, GHC does not produce a stable ABI with dynamic libraries. But it could do so in principal, no problem with laziness itself. It just would be a lot slower without all the cross module inlining and so GHC chooses not to. The archlinux haskell packagers could just ship programs as statically linked binaries and not recompile them on each minor dependency upgrade (except if there is a security upgrade). The binaries would not have any dependency on haskell packages themselves and you would not be forced to upgrade the whole package graph when some dependency is bumped, that would also save a lot of download bandwidth. I'm not sure that anyone really needs haskell packages (besides standalone programs) from the system package manager. No haskell dev I know builds their programs this way.
  - lalaithion 6y ago
    The trend in the last 10 years has been away from dynamic linking and toward static linking; Rust, Go, Nim and Zig all have static linking as the default.
    - a1369209993 6y ago
      > Rust, [...] have static linking as the default. Citation needed? Something like 20% of the reason I gave up on Rust was precisely that there was no documented way to force it to generate a static executable.
      - lalaithion 6y ago
        To clarify for Rust; Rust statically links other Rust code into your program by default. That's the relevant comparison in my post, because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code. Presumably that's what Blikkentrekker meant. If you want to have a 100% static executable, that's been possible for a while now: https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html https://doc.rust-lang.org/edition-guide/rust-2018/platform-a...
        a1369209993 6y ago
        > > no documented way to force [the reference implementation, with the standard libraries (in particular libc) that the default system semantics are dependent on] to generate a static executable. > https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html https://doc.rust-lang.org/edition-guide/rust-2018/platform-a... Yes, I'm aware of that; the fact that they continued using glibc as their default (aka canonical) OS/syscall interface after discovering that it was so impossible to statically link that people had to retarget code to a whole second libc was one of the final nails in the proverbial coffin for me. > because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code. Not particularly relevant, since my inquery was mainly about Rust, but on my system I get: $ echo 'main = pure ()' > foo.hs $ ghc foo.hs [1 of 1] Compiling Main ( foo.hs, /tmp/tmp.icUr2pqZXx/Main.o ) Linking foo ... $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped Admittedly, it's entirely possible that I fixed ghc and/or gcc at some point and forgot (I've fixed other bugs, but I don't recall fixing this one).
  - tome 6y ago
    I'm afraid I don't get the connection between non-strict semantics and dynamic linking at all. As far as I know they are completely orthogonal. I didn't follow your reasoning. Could you expand?
    - Blikkentrekker 6y ago
      They're very related. Due to Haskell's non-strict semantics, if a dynamic library, written in Haskell, that some Haskell program is linked to is recompiled, then the code that is linked to it must also be recompiled.
      - pklausler 6y ago
        Why is this a necessary consequence of lazy execution?
      - tome 6y ago
        I'm having trouble grasping that. Why would non-strict semantics imply that code must be recompiled if a dynamic library changes?
        Blikkentrekker 6y ago
        With non-strict semantics, function execution is re-ordered and turned inside out. For instance let us say we have pseudocode: let list = [1,2,3,4,5]; let new_list = do_something(list); lew newer_list = do_something_else(new_list); Both these functions consume and return lists. In a strict language, this process of iterating over the entire list internally in these two functions would happen twice; this would be wasteful. A non-strict language however is permitted to take the side-effect-less code apart, and restructure it in such a way that the list is only traversed once, essentially combining these two functions into one function and letting what each does run successively, for this purpose it is permitted to generate a new function that combines what both does, and doing so iterating the list only once, and optimizers are typically clever enough to be able to do so. Suppose that both of these functions be library function black boxes, provided by a dynamic library, then the implementation can no longer do this as it calls both from a library. The way Haskell is written is completely dependent on this; it would be awfully slow if the compiler weren't allowed to do this. The result in practice is that updating a dynamic library written in Haskell requires that all it's consumers be recompiled to compile against the new version. Or otherwise said: there is no concept of a stable a.b.i. in Haskell.
  - lallysingh 6y ago
    Do you mean no dynamic lib support for Haskell code, separately from C libraries that can be dynamically linked?
    - Blikkentrekker 6y ago
      There is support for it, but no support for a stable a.b.i., as such with every minor change to the library, nothing linked to it can run without a recompilation. This is due to the non-strict semantics. Consider that in a C library, or any other strict language, the function loaded in the dynamic library is called by first evaluating all of the arguments, and then calling the function by value with the evaluated arguments. This is not how Haskell operates, where the arguments are, in effect, placed inside the function body directly and may, or may not be evaluated, as such a function can't be a black box that can arbitrarily change it's internal workings, so long as the outside a.b.i. remain stable — a program compiled against a dynamic library is fundamentally compiled against the inner workings of functions, rather than simply against the stable interface they proffer to the outside world.
- egonschiele 6y ago
  That is great news. Haskell toolchain could use some help. I wonder if they'll work on the documentation and error messaging too. I think people are scared off when they realize that some of the libraries have no docs and you just have to read the type signatures.
  - sfvisser 6y ago
    Definitely agree with you that more documentation, especially with examples, would be great. However, reading just the types of a well written Haskell API probably gives me greater inside in its usage than most documentation I’ve read on npm packages. (To name an example I’m familiar with) There are so many very general patterns and idioms in Haskell being used all over the place that reading the signatures in the API docs can be extremely valuable.
    - tome 6y ago
      I program roughly equal amounts in Python and Haskell and every time I read Python documentation I wish it were as good as Haskell's. Having type signatures goes a long, long way to understanding an API. Python replaces that with rambling, unclear, prose. The same goes for Python's standard library and popular libraries like flask, pandas and matplotlib. (Haskell's direct links to source are also good, but there's no fundamental reason Python couldn't have those. I've never seen it though.)
- pbowyer 6y ago
  > It appears that the intent is to focus on pain points in the Haskell toolchain and libraries. Good. I set myself the challenge of compiling a Haskell program [1] during the Christmas holidays. It was meant to be a "one mince pie" challenge, but after an hour I discovered the VM I used didn't have enough RAM (during compilation we were approaching 4GB), then I ran out of disk space as stack approaches 5GB & I had other stuff installed. Once a few hours had gone by (this program isn't fast to compile) I had a working program. I now have to figure out if I can distribute just the resulting binary to other servers, or if it needs other software like GHC installing. Having finished the pack of mince pies, that can wait to another day. I know when I first started compiling C/C++ software there was a learning curve and it took hours the first time, but I found it easier to get started. With Haskell, the way one version of GHC is installed first and then Stack installs a completely isolated version is confusing; plus the inscrutable error messages (haven't got it to hand, but one means OOM but doesn't say that - it takes a Google to find the GitHub issue to work that out). And this is before I try and experiment/decide to learn some Haskell. Apart from the error messages they're not issues with Haskell per se, but they contribute to the experience of it. 1. https://github.com/facebook/duckling https://github.com/facebook/duckling
  - smadge 6y ago
    I upgraded my personal VPS from 1GB to 2GB RAM when I couldn't compile some Haskell standard library modules for a simple project.
  - mrkeen 6y ago
    When I started, I took the command I used for compiling c programs and substituted a letter. gcc -Wall -O3 -o ./main main.c ghc -Wall -O3 -o ./main main.hs I still compile that way every now and then.
    - pbowyer 6y ago
      Good to know, thanks. The README says to use stack, so I've stuck with that so far. I'll look for instructions for using ghc
ivanbakel 6y ago
Previous discussion on the Foundation: https://news.ycombinator.com/item?id=24988454 https://news.ycombinator.com/item?id=24988454 Also relevant if you read through those comments, and the discussion they include on FP Complete's involvement, is Michael Snoyman's more recent statement: https://www.snoyman.com/blog/2020/12/haskell-foundation https://www.snoyman.com/blog/2020/12/haskell-foundation I think Snoyman makes a few good points - namely, it remains to be seen exactly what the Foundation can and will do, and what input the community is going to have in that process. While the criticism that was once made of Facebook/IOHK/FPC applies here (namely, that a large enough force will trump Haskellers who invest in the community), the Foundation has all the power to be much worse. The academic side of the language still carries the most weight.
- emilypi 6y ago
  If you're worried that the Foundation might not live up to your expectations or go awry, keep in mind that it can only function insofar as it has input from the community. Feel free to apply for the board at https://haskell.foundation/board-nominations/ https://haskell.foundation/board-nominations/, and if you think you can execute HF's technical agenda, try out for the Executive director position at https://haskell.foundation/ed-job-description/ https://haskell.foundation/ed-job-description/.
  - ivanbakel 6y ago
    I appreciate the openness of these invitations, but they are ultimately not valuable to large parts of the community. I (like most people) am not in a position to become a board member - certainly not an Executive Director. There are obstacles of both personal qualification and free time (since I don't see any evidence that the position is paid). Because of that, I'm much more interested in how the Board will determine how it can best serve the community, and gather community feedback. That question can only really be answered after the board members themselves have been chosen.
    - tome 6y ago
      > I don't see any evidence that the position is paid > Salary will be commensurate with the experience, qualities, and location of the individual, and will also reflect the Foundation’s status as a non-profit organisation funded by donations. https://haskell.foundation/ed-job-description/ https://haskell.foundation/ed-job-description/
noncoml 6y ago
I rage quit Haskell when I saw all the promises for application correctness fall like a house of cards by realizing I can write to a file after it has been closed when using lazyIO.
- dpc_pw 6y ago
  I'm not a Haskeler, but didn't they add affine/linear types recently that could help?
  - gizmo686 6y ago
    Linear types don't help here. The complaint is that with lazyIO, even if your code does the write before closing the file, the actual order the operations occur in could change, to put the close first. If you look at the lazyIO documentation, you will see: >Although this module calls unsafeInterleaveIO for you, it cannot take the responsibility from you. Using this module is still as unsafe as calling unsafeInterleaveIO manually. Thus we recommend to wrap the lazy I/O monad into a custom newtype with a restricted set of operations which is considered safe for interleaving I/O actions. https://hackage.haskell.org/package/lazyio-0.1.0.4/docs/System-IO-Lazy.html https://hackage.haskell.org/package/lazyio-0.1.0.4/docs/Syst... TLDR, don't use lazy IO.
    - taktoa 6y ago
      The lazyio package is not what people are talking about when they say "lazy IO".
      - dragonwriter 6y ago
        > The lazyio package is not what people are talking about when they say "lazy IO". I don't know which people you are talking about, but it clearly was in this specific subthread which started with a complaint about “LazyIO”, not “lazy IO”, and where the only use of “lazy IO” in a post before yours was in a post where all previous references were to “lazyIO” and it's specific package documentation, and contextually the “lazy IO” references was about the same thing, not something else.
emilypi 6y ago
This article is a little bit incorrect. We raised $400k+.
deleted 6y ago
[deleted]
davidw 6y ago
"I'm convinced that if only we could get a word in with management, and explain what a monad is, they'd consider using Haskell" Not an actual quote, but I liked the scene it brought to mind.
- javajosh 6y ago
  Haskell is the ultimate shibboleth. It's value for actual programming is secondary.
  - klodolph 6y ago
    I’d say that the value of Haskell is in all of the lessons we learn from the research that it enables. Language designers are constantly looking to languages like Haskell for well thought-out / sound features they can add to make programming easier in other languages. I’m not sure why, but Haskell is an amazing hotbed for experimentation with new language features. You don’t have to use Haskell directly to benefit from it. Saying that it’s a shibboleth—well, that’s kind of a crass way to dismiss an entire community. It’s rude and not insightful.
    - javajosh 6y ago
      If you want vengeance and to show me the error of my rude, crass ways, then write some great software in Haskell.
      - centimeter 6y ago
        Allowing for your (silly) premise, I use XMonad and Pandoc all the time and they are great. Of course, the quality of a language is at best weakly correlated, and at worst anticorrelated, with the amount of useful software that is written using it.
      - klodolph 6y ago
        I’m not trying to “get vengeance” or “show you the error of your ways”. Your comment was dismissive, and I’m pointing it out because if nobody responds to people making rude comments, other people will think it’s okay to make comments like yours.
eloff 6y ago
Honest question that's going to draw some ire. Why use Haskell when we have rust? I've poked at Haskell and it was not a good experience. I just don't think you can make an honest business case for it on a greenfield project. That's my opinion, is there a chance I'm wrong?
- tome 6y ago
  It would probably help if you said more about your experiences.
- gchamonlive 6y ago
  Maybe you could clarify what was not good in your experience poking at Haskell. Which source materials did you use? What is your background? How comfortable are you with higher level typing systems? I have very little hands-on experience, but with the little I messed with both languages, they serve different purposes and are not apples to apples comparison.
- gregwebs 6y ago
  Have you tried Haskell? It has garbage collection and immutability. This entirely removes the need for a borrow checker (while maintaining correctness). Overall development is at least twice as productive in my experience. Of course this comes with an associated slow-down in runtime performance.
  - eloff 6y ago
    If garbage collection is a plus and not a drawback on the project then I would prefer Go. In neither case would Haskell top the list of options for me.
- nimih 6y ago
  I'm not sure if an opinion of this sort can really be wrong, but here's an attempt at an honest case: - If you're working with complex domain objects, Haskell has somewhat better (edit: or at least more powerful) tools for forbidding invalid states during runtime and assisting refactors as your data model changes. - Haskell seems to have better libraries for writing parsers and compilers than Rust, if that's relevant to your project. - Some folks prefer ML syntax to Algol-like syntax. - The GC, immutable-by-default data, and reasonable concurrency model are pretty nice features of the GHC runtime. - The performance difference between Haskell and Rust probably doesn't matter for most projects. - Haskell might actually compile faster if you avoid crazy type-level programming shenanigans. - Haskell has a pretty decent REPL. Obviously, Rust has a different set of trade-offs, and the bigger cost to either is going to be that both are a bit off the beaten path and require some practice and experience to be productive and comfortable in.
javajosh 6y ago
Isn't the best course of action to rewrite popular components in Haskell, and show that its better? I'm thinking httpd/nginx/jetty, redis/memcached, postgres, and so on. You could even make a text editor. Or a kernel. Or anything, really. I really like functional programming, but Haskell turns me off and without at least one major example of a beautiful, popular solution written in Haskell (and I don't think pandoc counts), I'm not going to make the effort to push through that barrier. Other languages that occupy a similar space ("superior but tragically underused") have these examples. Erlang has...well a lot but Matrix and RabbitMQ come to mind. Clojure has...well it has datomic, but also Jepsen uses it, and heck I've used it and its fine. The real question is, who's fingers itch to write haskell, and can you please pay them $400k to rewrite nginx in it?
- dudul 6y ago
  So if erlang and clojure are superior but tragically underused in spite of having some big projects/tools to show, how is it helpful for haskell to try to have one as well?
  - javajosh 6y ago
    First, I've made no pretense about speaking for Haskell's interests, I am speaking strictly about my own wishes. While I think our interests are aligned, I'll let you be the judge. What would be good for me as a curious developer interested in the language, and who has had a years-long low-level FOMO about it, I would like to be able to wade in and do something with it, like I did with Clojure and Erlang, confident that I could, in the end, make it do stuff (since others had already made it do stuff, first). I do really honestly believe that Haskell needs a "paragon project" like Matrix or Jepsen that has proven itself useful to the world without respect to its Haskellness, and then show that this solution was much easier in Haskell. I keep getting down-voted on this thread, and I expect it to continue. Friends thought I was nuts to give up on Lost after season 1, or The Hobbit after movie 1, or the GoT books after book 3. After years of hearing much talk and seeing no walk, I'm giving up on Haskell. More than that, I'm going to call out anyone talking it up to give specifics because literally everyone I've every spoken to about it gives it a very high regard, but have never, ever written a line of it.
andi999 6y ago
I am confused. I thought Haskell was taking pride in not being used in production (and instead being a testbed for new language features/concepts)
- tome 6y ago
  No, not really, the number of Haskell-in-production shops is small but steadily growing.
- kccqzy 6y ago
  You might confused by the motto "avoid success at all costs" which is deliberately ambiguous.
  - chrisseaton 6y ago
    I think it's (avoid (success at all costs)) isn't it? But I agree - why do people seem to go out of their way to hamper themselves with pun mottos that are just begging to be misunderstood, either genuinely, or deliberately and used against them? Many people don't stick around for the 'ah it actually means...' bit where you unveil your witticism. They just go away with the face-value explanation and don't bother to learn more. Like 'free software'. 90% of people aren't sticking around to hear the pitch about 'free as in freedom'. You've already missed your opportunity to explain your point of view - you wasted it on making a pun instead of actually communicating! It's madness.
  - andi999 6y ago
    Yes, that's the line I remember (and read the explanation that Haskell is comfy with being niche). What other interpretation do you think is intended with this sentence? (to me it looks very un-ambiguous, more like deliberately un-ambitious) Edit: I think I read this explanation: https://news.ycombinator.com/item?id=12056169#:~:text=haskell-lang.org-,The%20Haskell%20motto%20is%20%22avoid%20success%20at%20all%20costs%22%2C,%2C%20restricting%20research%20possibilities%2C%20etc https://news.ycombinator.com/item?id=12056169#:~:text=haskel.... "Haskell would prefer to be powerful, safe, efficient, obscure and niche; rather than popular, industry-standard, widely-known, highly compatible, unsafe, insecure, inefficient and restricted"
zenknight 6y ago
I see a lot of comments on usability of HS in Prod. We @ juspay.in use it to power a bulk of UPI payment transactions. We also use PureScript to power our payment page SDKs. API (CRUD/Auth) code written in HS becomes a beauty once you start building experience with HS. I think the most advantage of FP comes from how it changes the way you model your solution for a problem. With a strict type system, it's easier to anticipate edge cases and with currying building abstractions becomes natural. Having said that, HS is not all sunshine. It took me an inordinate amount of time to setup an IDE like environment. If I recall correctly, HLS would take > 20GB of RAM in few hours with our code base. Eventually I had to remove that and extensively use only the editor features to jump around code.
- thdxr 6y ago
  Been exploring this more for my next project. Do you think using Purescript both on backend and frontend is viable?
micouay 6y ago
Chance to improve some user experience here: is it possible to use `stack` without installing Xcode on macOS (BigSur)? I get an error 'xcodebuild requires xcode' and 'C compiler cannot create executables' when running `stack setup`. I have the Xcode Command Line Tools installed. Anyone had similar experience?
- protomyth 6y ago
  If you are on Big Sur then it happens a lot. It happens with macports right so they have some information in tickets.

160 points by antouank 6y ago

The headline is a bit too generic. This organization is being founded with the support of Simon Peyton Jones and has corporate backing. It appears that the intent is to focus on pain points in the Haskell toolchain and libraries.

Blikkentrekker 6y ago
To me, the major major unsung pain point with Haskell and any non-strict language that makes it unsuitable for most applications is it's inability to use dynamic libraries as we're all used to. For an Haskell implementation to have any efficiency, it must re-order the order of execution inside of function calls as it sees fit, which it can do due to the non-strict semantics. This is fine in theory, but dynamic libraries aren't built on that assumption; they're, naturally, built upon the idea that they are a black box and that the consumer simply calls the function, obtains the result, and does not care nor has access to the insides. A Haskell implementation must have knowledge thereof, thus, the practical effect is that with Haskell it's impossible to, say, fix a security problem in a dynamic library and simply have all consumers seamlessly benefit from that fix — every consumer must be recompiled with the new library's source. And this problem is very seldom raised in discussions — dynamic libraries are fundamentally designed on the assumption of strict semantics.
- simonfxr 6y ago
  I don't see how strict vs. lazy has anything to do with linkage. I guess you are talking about foreign functions defined in a dynamic library. Calling a foreign function (regardless of linkage) will just evaluate the arguments and pass them according to the calling convention of the foreign ABI. If you link to library dynamically and it gets updated (in an ABI compatible way) you don't have to recompile anything, it just works as you would expect.
  - Blikkentrekker 6y ago
    No, the issue does not apply to the f.f.i., because those are called with strict semantics, as C expects that. It's about dynamic libraries written in Haskell itself. Try compiling a Haskell program in GHC with the `-dynamic` flag, and then update any of the Haskell libraries it is linked against, after this, the program will fail to start with a linker error, and must be recompiled itself. https://www.reddit.com/r/archlinux/comments/7jtemw/which_package_do_you_hate_the_most/dra5q7v/ https://www.reddit.com/r/archlinux/comments/7jtemw/which_pac... See this discussion there which explains why, in essence, dynamic linking is not a feasible route with Haskell. Arch Linux currently does this, or at least at the time of writing there, which leads to all Arch Haskell packages being required to be recompiled and reinstalled, if but a simple library be updated that they all use.
    - tome 6y ago
      Yes, but this doesn't seem to have anything to do with lazy evaluation, rather it is because GHC is quite close to a whole-program optimizer.
      - Blikkentrekker 6y ago
        Optimizing lazy evaluation requires this kind of hole-program optimizations. Non-strict semantics would be prohibitively slow without these optimizations. You won't find a Haskell compiler that doesn't do this.
    - simonfxr 6y ago
      Okay you are right, GHC does not produce a stable ABI with dynamic libraries. But it could do so in principal, no problem with laziness itself. It just would be a lot slower without all the cross module inlining and so GHC chooses not to. The archlinux haskell packagers could just ship programs as statically linked binaries and not recompile them on each minor dependency upgrade (except if there is a security upgrade). The binaries would not have any dependency on haskell packages themselves and you would not be forced to upgrade the whole package graph when some dependency is bumped, that would also save a lot of download bandwidth. I'm not sure that anyone really needs haskell packages (besides standalone programs) from the system package manager. No haskell dev I know builds their programs this way.
- lalaithion 6y ago
  The trend in the last 10 years has been away from dynamic linking and toward static linking; Rust, Go, Nim and Zig all have static linking as the default.
  - a1369209993 6y ago
    > Rust, [...] have static linking as the default. Citation needed? Something like 20% of the reason I gave up on Rust was precisely that there was no documented way to force it to generate a static executable.
    - lalaithion 6y ago
      To clarify for Rust; Rust statically links other Rust code into your program by default. That's the relevant comparison in my post, because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code. Presumably that's what Blikkentrekker meant. If you want to have a 100% static executable, that's been possible for a while now: https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html https://doc.rust-lang.org/edition-guide/rust-2018/platform-a...
      - a1369209993 6y ago
        > > no documented way to force [the reference implementation, with the standard libraries (in particular libc) that the default system semantics are dependent on] to generate a static executable. > https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html https://doc.rust-lang.org/edition-guide/rust-2018/platform-a... Yes, I'm aware of that; the fact that they continued using glibc as their default (aka canonical) OS/syscall interface after discovering that it was so impossible to statically link that people had to retarget code to a whole second libc was one of the final nails in the proverbial coffin for me. > because Haskell also links dynamically to glibc by default, but it statically links with other Haskell code. Not particularly relevant, since my inquery was mainly about Rust, but on my system I get: $ echo 'main = pure ()' > foo.hs $ ghc foo.hs [1 of 1] Compiling Main ( foo.hs, /tmp/tmp.icUr2pqZXx/Main.o ) Linking foo ... $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped Admittedly, it's entirely possible that I fixed ghc and/or gcc at some point and forgot (I've fixed other bugs, but I don't recall fixing this one).
- tome 6y ago
  I'm afraid I don't get the connection between non-strict semantics and dynamic linking at all. As far as I know they are completely orthogonal. I didn't follow your reasoning. Could you expand?
  - Blikkentrekker 6y ago
    They're very related. Due to Haskell's non-strict semantics, if a dynamic library, written in Haskell, that some Haskell program is linked to is recompiled, then the code that is linked to it must also be recompiled.
    - pklausler 6y ago
      Why is this a necessary consequence of lazy execution?
    - tome 6y ago
      I'm having trouble grasping that. Why would non-strict semantics imply that code must be recompiled if a dynamic library changes?
      - Blikkentrekker 6y ago
        With non-strict semantics, function execution is re-ordered and turned inside out. For instance let us say we have pseudocode: let list = [1,2,3,4,5]; let new_list = do_something(list); lew newer_list = do_something_else(new_list); Both these functions consume and return lists. In a strict language, this process of iterating over the entire list internally in these two functions would happen twice; this would be wasteful. A non-strict language however is permitted to take the side-effect-less code apart, and restructure it in such a way that the list is only traversed once, essentially combining these two functions into one function and letting what each does run successively, for this purpose it is permitted to generate a new function that combines what both does, and doing so iterating the list only once, and optimizers are typically clever enough to be able to do so. Suppose that both of these functions be library function black boxes, provided by a dynamic library, then the implementation can no longer do this as it calls both from a library. The way Haskell is written is completely dependent on this; it would be awfully slow if the compiler weren't allowed to do this. The result in practice is that updating a dynamic library written in Haskell requires that all it's consumers be recompiled to compile against the new version. Or otherwise said: there is no concept of a stable a.b.i. in Haskell.
- lallysingh 6y ago
  Do you mean no dynamic lib support for Haskell code, separately from C libraries that can be dynamically linked?
  - Blikkentrekker 6y ago
    There is support for it, but no support for a stable a.b.i., as such with every minor change to the library, nothing linked to it can run without a recompilation. This is due to the non-strict semantics. Consider that in a C library, or any other strict language, the function loaded in the dynamic library is called by first evaluating all of the arguments, and then calling the function by value with the evaluated arguments. This is not how Haskell operates, where the arguments are, in effect, placed inside the function body directly and may, or may not be evaluated, as such a function can't be a black box that can arbitrarily change it's internal workings, so long as the outside a.b.i. remain stable — a program compiled against a dynamic library is fundamentally compiled against the inner workings of functions, rather than simply against the stable interface they proffer to the outside world.
egonschiele 6y ago
That is great news. Haskell toolchain could use some help. I wonder if they'll work on the documentation and error messaging too. I think people are scared off when they realize that some of the libraries have no docs and you just have to read the type signatures.
- sfvisser 6y ago
  Definitely agree with you that more documentation, especially with examples, would be great. However, reading just the types of a well written Haskell API probably gives me greater inside in its usage than most documentation I’ve read on npm packages. (To name an example I’m familiar with) There are so many very general patterns and idioms in Haskell being used all over the place that reading the signatures in the API docs can be extremely valuable.
  - tome 6y ago
    I program roughly equal amounts in Python and Haskell and every time I read Python documentation I wish it were as good as Haskell's. Having type signatures goes a long, long way to understanding an API. Python replaces that with rambling, unclear, prose. The same goes for Python's standard library and popular libraries like flask, pandas and matplotlib. (Haskell's direct links to source are also good, but there's no fundamental reason Python couldn't have those. I've never seen it though.)
pbowyer 6y ago
> It appears that the intent is to focus on pain points in the Haskell toolchain and libraries. Good. I set myself the challenge of compiling a Haskell program [1] during the Christmas holidays. It was meant to be a "one mince pie" challenge, but after an hour I discovered the VM I used didn't have enough RAM (during compilation we were approaching 4GB), then I ran out of disk space as stack approaches 5GB & I had other stuff installed. Once a few hours had gone by (this program isn't fast to compile) I had a working program. I now have to figure out if I can distribute just the resulting binary to other servers, or if it needs other software like GHC installing. Having finished the pack of mince pies, that can wait to another day. I know when I first started compiling C/C++ software there was a learning curve and it took hours the first time, but I found it easier to get started. With Haskell, the way one version of GHC is installed first and then Stack installs a completely isolated version is confusing; plus the inscrutable error messages (haven't got it to hand, but one means OOM but doesn't say that - it takes a Google to find the GitHub issue to work that out). And this is before I try and experiment/decide to learn some Haskell. Apart from the error messages they're not issues with Haskell per se, but they contribute to the experience of it. 1. https://github.com/facebook/duckling https://github.com/facebook/duckling
- smadge 6y ago
  I upgraded my personal VPS from 1GB to 2GB RAM when I couldn't compile some Haskell standard library modules for a simple project.
- mrkeen 6y ago
  When I started, I took the command I used for compiling c programs and substituted a letter. gcc -Wall -O3 -o ./main main.c ghc -Wall -O3 -o ./main main.hs I still compile that way every now and then.
  - pbowyer 6y ago
    Good to know, thanks. The README says to use stack, so I've stuck with that so far. I'll look for instructions for using ghc

ivanbakel 6y ago

Previous discussion on the Foundation: https://news.ycombinator.com/item?id=24988454 https://news.ycombinator.com/item?id=24988454 Also relevant if you read through those comments, and the discussion they include on FP Complete's involvement, is Michael Snoyman's more recent statement: https://www.snoyman.com/blog/2020/12/haskell-foundation https://www.snoyman.com/blog/2020/12/haskell-foundation I think Snoyman makes a few good points - namely, it remains to be seen exactly what the Foundation can and will do, and what input the community is going to have in that process. While the criticism that was once made of Facebook/IOHK/FPC applies here (namely, that a large enough force will trump Haskellers who invest in the community), the Foundation has all the power to be much worse. The academic side of the language still carries the most weight.

emilypi 6y ago
If you're worried that the Foundation might not live up to your expectations or go awry, keep in mind that it can only function insofar as it has input from the community. Feel free to apply for the board at https://haskell.foundation/board-nominations/ https://haskell.foundation/board-nominations/, and if you think you can execute HF's technical agenda, try out for the Executive director position at https://haskell.foundation/ed-job-description/ https://haskell.foundation/ed-job-description/.
- ivanbakel 6y ago
  I appreciate the openness of these invitations, but they are ultimately not valuable to large parts of the community. I (like most people) am not in a position to become a board member - certainly not an Executive Director. There are obstacles of both personal qualification and free time (since I don't see any evidence that the position is paid). Because of that, I'm much more interested in how the Board will determine how it can best serve the community, and gather community feedback. That question can only really be answered after the board members themselves have been chosen.
  - tome 6y ago
    > I don't see any evidence that the position is paid > Salary will be commensurate with the experience, qualities, and location of the individual, and will also reflect the Foundation’s status as a non-profit organisation funded by donations. https://haskell.foundation/ed-job-description/ https://haskell.foundation/ed-job-description/

noncoml 6y ago

I rage quit Haskell when I saw all the promises for application correctness fall like a house of cards by realizing I can write to a file after it has been closed when using lazyIO.

dpc_pw 6y ago
I'm not a Haskeler, but didn't they add affine/linear types recently that could help?
- gizmo686 6y ago
  Linear types don't help here. The complaint is that with lazyIO, even if your code does the write before closing the file, the actual order the operations occur in could change, to put the close first. If you look at the lazyIO documentation, you will see: >Although this module calls unsafeInterleaveIO for you, it cannot take the responsibility from you. Using this module is still as unsafe as calling unsafeInterleaveIO manually. Thus we recommend to wrap the lazy I/O monad into a custom newtype with a restricted set of operations which is considered safe for interleaving I/O actions. https://hackage.haskell.org/package/lazyio-0.1.0.4/docs/System-IO-Lazy.html https://hackage.haskell.org/package/lazyio-0.1.0.4/docs/Syst... TLDR, don't use lazy IO.
  - taktoa 6y ago
    The lazyio package is not what people are talking about when they say "lazy IO".
    - dragonwriter 6y ago
      > The lazyio package is not what people are talking about when they say "lazy IO". I don't know which people you are talking about, but it clearly was in this specific subthread which started with a complaint about “LazyIO”, not “lazy IO”, and where the only use of “lazy IO” in a post before yours was in a post where all previous references were to “lazyIO” and it's specific package documentation, and contextually the “lazy IO” references was about the same thing, not something else.

emilypi 6y ago

This article is a little bit incorrect. We raised $400k+.

deleted 6y ago

[deleted]

davidw 6y ago

"I'm convinced that if only we could get a word in with management, and explain what a monad is, they'd consider using Haskell" Not an actual quote, but I liked the scene it brought to mind.

javajosh 6y ago
Haskell is the ultimate shibboleth. It's value for actual programming is secondary.
- klodolph 6y ago
  I’d say that the value of Haskell is in all of the lessons we learn from the research that it enables. Language designers are constantly looking to languages like Haskell for well thought-out / sound features they can add to make programming easier in other languages. I’m not sure why, but Haskell is an amazing hotbed for experimentation with new language features. You don’t have to use Haskell directly to benefit from it. Saying that it’s a shibboleth—well, that’s kind of a crass way to dismiss an entire community. It’s rude and not insightful.
  - javajosh 6y ago
    If you want vengeance and to show me the error of my rude, crass ways, then write some great software in Haskell.
    - centimeter 6y ago
      Allowing for your (silly) premise, I use XMonad and Pandoc all the time and they are great. Of course, the quality of a language is at best weakly correlated, and at worst anticorrelated, with the amount of useful software that is written using it.
    - klodolph 6y ago
      I’m not trying to “get vengeance” or “show you the error of your ways”. Your comment was dismissive, and I’m pointing it out because if nobody responds to people making rude comments, other people will think it’s okay to make comments like yours.

eloff 6y ago

Honest question that's going to draw some ire. Why use Haskell when we have rust? I've poked at Haskell and it was not a good experience. I just don't think you can make an honest business case for it on a greenfield project. That's my opinion, is there a chance I'm wrong?

tome 6y ago
It would probably help if you said more about your experiences.
gchamonlive 6y ago
Maybe you could clarify what was not good in your experience poking at Haskell. Which source materials did you use? What is your background? How comfortable are you with higher level typing systems? I have very little hands-on experience, but with the little I messed with both languages, they serve different purposes and are not apples to apples comparison.
gregwebs 6y ago
Have you tried Haskell? It has garbage collection and immutability. This entirely removes the need for a borrow checker (while maintaining correctness). Overall development is at least twice as productive in my experience. Of course this comes with an associated slow-down in runtime performance.
- eloff 6y ago
  If garbage collection is a plus and not a drawback on the project then I would prefer Go. In neither case would Haskell top the list of options for me.
nimih 6y ago
I'm not sure if an opinion of this sort can really be wrong, but here's an attempt at an honest case: - If you're working with complex domain objects, Haskell has somewhat better (edit: or at least more powerful) tools for forbidding invalid states during runtime and assisting refactors as your data model changes. - Haskell seems to have better libraries for writing parsers and compilers than Rust, if that's relevant to your project. - Some folks prefer ML syntax to Algol-like syntax. - The GC, immutable-by-default data, and reasonable concurrency model are pretty nice features of the GHC runtime. - The performance difference between Haskell and Rust probably doesn't matter for most projects. - Haskell might actually compile faster if you avoid crazy type-level programming shenanigans. - Haskell has a pretty decent REPL. Obviously, Rust has a different set of trade-offs, and the bigger cost to either is going to be that both are a bit off the beaten path and require some practice and experience to be productive and comfortable in.

javajosh 6y ago

Isn't the best course of action to rewrite popular components in Haskell, and show that its better? I'm thinking httpd/nginx/jetty, redis/memcached, postgres, and so on. You could even make a text editor. Or a kernel. Or anything, really. I really like functional programming, but Haskell turns me off and without at least one major example of a beautiful, popular solution written in Haskell (and I don't think pandoc counts), I'm not going to make the effort to push through that barrier. Other languages that occupy a similar space ("superior but tragically underused") have these examples. Erlang has...well a lot but Matrix and RabbitMQ come to mind. Clojure has...well it has datomic, but also Jepsen uses it, and heck I've used it and its fine. The real question is, who's fingers itch to write haskell, and can you please pay them $400k to rewrite nginx in it?

dudul 6y ago
So if erlang and clojure are superior but tragically underused in spite of having some big projects/tools to show, how is it helpful for haskell to try to have one as well?
- javajosh 6y ago
  First, I've made no pretense about speaking for Haskell's interests, I am speaking strictly about my own wishes. While I think our interests are aligned, I'll let you be the judge. What would be good for me as a curious developer interested in the language, and who has had a years-long low-level FOMO about it, I would like to be able to wade in and do something with it, like I did with Clojure and Erlang, confident that I could, in the end, make it do stuff (since others had already made it do stuff, first). I do really honestly believe that Haskell needs a "paragon project" like Matrix or Jepsen that has proven itself useful to the world without respect to its Haskellness, and then show that this solution was much easier in Haskell. I keep getting down-voted on this thread, and I expect it to continue. Friends thought I was nuts to give up on Lost after season 1, or The Hobbit after movie 1, or the GoT books after book 3. After years of hearing much talk and seeing no walk, I'm giving up on Haskell. More than that, I'm going to call out anyone talking it up to give specifics because literally everyone I've every spoken to about it gives it a very high regard, but have never, ever written a line of it.

andi999 6y ago

I am confused. I thought Haskell was taking pride in not being used in production (and instead being a testbed for new language features/concepts)

tome 6y ago
No, not really, the number of Haskell-in-production shops is small but steadily growing.
kccqzy 6y ago
You might confused by the motto "avoid success at all costs" which is deliberately ambiguous.
- chrisseaton 6y ago
  I think it's (avoid (success at all costs)) isn't it? But I agree - why do people seem to go out of their way to hamper themselves with pun mottos that are just begging to be misunderstood, either genuinely, or deliberately and used against them? Many people don't stick around for the 'ah it actually means...' bit where you unveil your witticism. They just go away with the face-value explanation and don't bother to learn more. Like 'free software'. 90% of people aren't sticking around to hear the pitch about 'free as in freedom'. You've already missed your opportunity to explain your point of view - you wasted it on making a pun instead of actually communicating! It's madness.
- andi999 6y ago
  Yes, that's the line I remember (and read the explanation that Haskell is comfy with being niche). What other interpretation do you think is intended with this sentence? (to me it looks very un-ambiguous, more like deliberately un-ambitious) Edit: I think I read this explanation: https://news.ycombinator.com/item?id=12056169#:~:text=haskell-lang.org-,The%20Haskell%20motto%20is%20%22avoid%20success%20at%20all%20costs%22%2C,%2C%20restricting%20research%20possibilities%2C%20etc https://news.ycombinator.com/item?id=12056169#:~:text=haskel.... "Haskell would prefer to be powerful, safe, efficient, obscure and niche; rather than popular, industry-standard, widely-known, highly compatible, unsafe, insecure, inefficient and restricted"

zenknight 6y ago

I see a lot of comments on usability of HS in Prod. We @ juspay.in use it to power a bulk of UPI payment transactions. We also use PureScript to power our payment page SDKs. API (CRUD/Auth) code written in HS becomes a beauty once you start building experience with HS. I think the most advantage of FP comes from how it changes the way you model your solution for a problem. With a strict type system, it's easier to anticipate edge cases and with currying building abstractions becomes natural. Having said that, HS is not all sunshine. It took me an inordinate amount of time to setup an IDE like environment. If I recall correctly, HLS would take > 20GB of RAM in few hours with our code base. Eventually I had to remove that and extensively use only the editor features to jump around code.

thdxr 6y ago
Been exploring this more for my next project. Do you think using Purescript both on backend and frontend is viable?

micouay 6y ago

Chance to improve some user experience here: is it possible to use `stack` without installing Xcode on macOS (BigSur)? I get an error 'xcodebuild requires xcode' and 'C compiler cannot create executables' when running `stack setup`. I have the Xcode Command Line Tools installed. Anyone had similar experience?

protomyth 6y ago
If you are on Big Sur then it happens a lot. It happens with macports right so they have some information in tickets.