Hacker News Reader

I think one of the most underrated aspects of Rust is its stellar documentation, tooling, community, high-level libraries and general accessibility. The language itself isn't easy per se, but 100% of the difficulty is intrinsic; none of it is incidental. In many ways it's "the practical Haskell", even though it's technically lower-level.

This is the most under appreciated feature of Python and Ruby. They got it right and other languages are still trying to catch up. Rust offers nothing better except memory safety at the expense of ease of use and with steep learning curve. Indeed same can be achieved by C, if one replace the complicated syntax and steep learning curve with better testing to check for memory safety. Zig language shows that it is possible to provide a simple way to write both memory safe or unsafe code.

Well begin is half done, and Python and Ruby made it so easy to program that without reading multiple of books and spending a year or two, programmers can write decent code. This is the reason why Go and Swift the other two system programming language is far ahead of Rust despite being GC language. Indeed even the latest OS Fuschia is written in C++ (zircon kernel), with Rust SDK to write high level programs same as the one written with Dart and flutter.

> Zig language shows that it is possible to provide a simple way to write both memory safe or unsafe code.

Zig is a kind of language that wouldn't have been written if its author discovered ATS[1] at a right time.

[1]: http://www.ats-lang.org

i was aware of ats before creating zig

This has been my experience as well. In fact, I often say that Rust is like a hyper-practical ML language, like Ocaml 2.0.

I learned Rust in 2016, and have kept up with it since. It was a painful first entry point, and then another rather painful experience when I first used it for a big hobby project, but now it is my go-to language because it's exactly as hard as it needs to be, has amazing community and documentation and libraries, and gives me the option to have really good performance while also using very nice ML-family linguistic constructs.

It's a bit of a chicken and egg problem and pretty much what the author of the article is talking about as well. You need people's time and energy to improve the status quo and getting people's attention takes ... people's time and energy. Haskell has always been grassroots and imho has enough hard-core believers that it will never go away but whether it'll ever be mainstream I don't know. I have great admiration for the small group of people who put their own time and energy into making the language and the ecosystem better. Re IDE support - loads happening there atm, ghcide is imho a true game changer and fast becoming an invaluable tool for working with Haskell.

It's a bit of a chicken and egg problem

It is. The way you usually resolve that problem if your language is going to become a big mainstream success is to have a particular focus, one key selling point where it is uniquely capable or at least so far ahead of the opposition that using it is a compelling advantage. JavaScript was the language for writing front-end code. C was the language for low-level programming. Java was the language for getting code monkey class programmers to be reasonably productive in enterprise environments. There are now other languages in each category, and there are now other uses for each of these languages, but the important point remains: those languages dominated those niches at the time they took off and that was why they took off.

Unfortunately for Haskell, a sophisticated type system and compiler capable of supporting experimental language design research is a niche that about 0.0001% of developers and people who pay developers care about. Haskell has indeed been very successful in that small niche, and it remains so. But I had a look into it the other day from the point of view of implementing the back-end for a new web project, and its support for writing web servers is still probably a decade behind the state of the art. I swallowed my pride and today that back end runs on Node. Would I prefer Haskell's safety and power over JS? Of course. But I'd prefer a language where any server I wrote can speak modern web protocols and support the functionality I need, and of those two languages, only one clears that bar.

Can you explain what Haskell fall behind in term of writing web servers? As someone who wrote Node and Haskell web apps in the past I don't think it's true. Let't take a look at one of premier Haskell web framework Yesod. It has support for authentication, http/2, https, middlewares, logging, etc. I don't think there is any "modern web protocols" that Haskell cannot support. It's only a language anyway. It popular and powerful enough for people to implement something novel with it.

I know Haskell had been used for testing-bed for programming language ideas because making abstractions in Haskell is freaking easy. But you can just ignore them and stick to boring, working and practical subset of the language. The language already been heavily used in industries so I know for a fact that it's fit for production use. I myself did deploy Haskell apps to production (Telegram bot for personal use) and never encounter any problem.

Let't take a look at one of premier Haskell web framework Yesod.

OK, let's do that, since that's exactly one of the things I tried.

So, one thing I was interested in was indeed support for HTTP/2. You've just stated that Yesod supports it. Right now, with the aid of all of the main types of documentation linked from the Yesod site and a search engine, I am totally unable to verify that. I literally cannot find a single reference to it on the entire Web.

The same is true of identifying anything about the level of TLS support, configuring which cipher suites to accept, etc.

I was also interested in WebSocket support. Again, there's no obvious sign of this in the documentation, at least not that I found in a few minutes of browsing. Any of it. Seriously, projects wanting programmers to use them should have one authoritative source of reference documentation, and it should be up to date and easily searchable.

Still, on this one, at least a web search finds me yesod-websockets. That has the usual mix of package technicalities on its Hackage page, plus a documentation page with a long list of functions, type signatures and one-line descriptions in the Hackage documentation. Ironically, there is also a link from the package description to Stackage, which has another page of package technicalities linking to another similar page of documentation, which is roughly the same, but apparently the two versions I've found are different because one is 0.3.0.1 and one is 0.3.0.2. There's nothing to give you confidence in using a library in production like a four-part version number that starts with "0.". And no obvious description of the real level of maturity and stability that reflects, so I'm going to assume this is pre-release quality. And did I mention there should be one authoritative home for reference documentation? That goes for the package itself, too.

No matter how many times a Haskell fan says that this kind of thing is sufficient, it simply isn't. There is no introductory tutorial. There are no illustrative code snippets or HOWTOs or full working examples. There is no apparent organisation of any kind in what little reference documentation does exist except for a few headers that have little meaning if you don't already know what they mean. I have no idea how stable this package and its API are, but the version numbers (plural) suggest the default assumption should be "not very".

This isn't a serious proposition for production work. It just isn't. Maybe it's useful if you already know the Yesod library and the related libraries well, for example because you developed some of that ecosystem, or you've talked with someone who did, or maybe you've watched it evolve since it was simple enough to figure out from the limited documentation and kept up. But for someone with Haskell experience who hasn't used it to build a web server before, it's all but useless.

For the record, I had a working server, including proof of concept WebSockets code, up and running on both the client and server side using Node, in less time than it's taken me to re-check a few facts and then write this comment. And a web search for any of "node http2", "node tls" or "node websocket" immediately locates a wealth of relevant documentation, examples, etc.

> Right now, with the aid of all of the main types of documentation linked from the Yesod site and a search engine, I am totally unable to verify that. I literally cannot find a single reference to it on the entire Web.

> The same is true of identifying anything about the level of TLS support, configuring which cipher suites to accept, etc.

This is really weird, and I think that your comment doesn't represent the reality. Here's the official Yesod Book[1] mentioning WAI and Warp as a de-facto standard server implementation for a Haskell Web ecosystem. The Hackage page for Warp[2] contains "HTTP/2" and "TLS" at the very top of the package description section. Googling "haskell warp tls" produces the topmost link pointing to warp-tls package[3]. The package docs clearly show all supported ciphers[4]. And googling "haskell yesod http2" produces the second top link[5][6] that mentions HTTP/2 and TLS and it has been around since 2015.

[1]: https://www.yesodweb.com/book/web-application-interface#web-...

[2]: https://hackage.haskell.org/package/warp

[3]: https://hackage.haskell.org/package/warp-tls

[4]: https://hackage.haskell.org/package/warp-tls-3.2.12/docs/Net...

[5]: https://www.yesodweb.com/blog/2015/07/http2

[6]: https://pasteboard.co/JaRXKUR.png

Here's the official Yesod Book[1] mentioning WAI and Warp as a de-facto standard server implementation for a Haskell Web ecosystem.

So just to be clear:

To discover what is actually possible in this area, someone new to Yesod is supposed to read the entire book through to an appendix, which itself could kindly be described as "not entirely clear".

Then they're supposed to recognise that they need to write their Haskell application using WAI and a Warp backend (whatever that means in this context, because the relationships between these tools are among the "not entirely clear" aspects of that appendix) instead of using the other tools that were already described earlier in the book, despite having no obvious motivation for doing so at this point (because terms like HTTP/2 and TLS do not appear anywhere in the Yesod book appendix you linked to).

Then on the off chance that these alternative tools mentioned in an appendix of an online book can do what the developer wants even though the appendix doesn't say anything about that at all, our intrepid developer is supposed to go and look up the Hackage pages for those tools, one of which does at least mention the term HTTP/2.

There's no further information on those documentation pages about how to actually use important features of HTTP/2, for example setting up server push, though. In fact, the only reference to server push I can find anywhere in the Warp documentation relates to the function setServerPushLogger.

So while I appreciate your taking the time to comment, I'm afraid my previous conclusion has not changed. Maybe these tools are useful if you already understand them in detail, but for someone familiar with Haskell but writing a web application with it for the first time, this experience isn't even on the same scale as a good, production-ready ecosystem.

Finally, just for the record, while choosing the perfect query to Google might have found you a useful link, several similar obvious searches I tried before did not, nor indeed does the exact term you mentioned ("haskell yesod http2") in some other search engines such as Duck Duck Go. And your Pasteboard link (I assume) intending to demonstrate the search you managed successfully is not working from here.

> Maybe these tools are useful if you already understand them in detail, but for someone familiar with Haskell but writing a web application with it for the first time, this experience isn't even on the same scale as a good, production-ready ecosystem.

But this is hardly an example of "not being able to find it with a search engine" as the original message seemed to claim. Surely it takes time to get acquainted with a new ecosystem, and curiosity is welcomed in the community.

> To discover what is actually possible in this area, someone new to Yesod is supposed to read the entire book through to an appendix

That's hardly true either, one just needs to google "haskell yesod http2" or "haskell yesod tls" - both results will be within topmost 5 links. The results will be full of potentially unfamiliar technical details, but they still allow getting the general idea of what is possible. And reading the book helps enormously to get everything internalized.

> There's no further information on those documentation pages about how to actually use important features of HTTP/2, for example setting up server push, though

the top link of googling "haskell warp http2 server push" produces a whole section on how server pushes are done - https://hackage.haskell.org/package/wai-3.0.4.0/docs/Network...

> in some other search engines such as Duck Duck Go

I use DDG by default, and I regularly add !g for the same reason

I tried too and there was nothing useful I could find in the first results of google for "haskell yesod http2". Google is heavily customizing search results per use so we probably have different results.

The only related thing I got at the end of search results is this page https://www.yesodweb.com/blog/2015/07/http2 that doesn't even mention yesod so good luck trying to understand what is it while all it talks about is haskell warp.

By the way this paragraph is scary. Haskell didn't support half of the modern cryptography required for TLS 1.2 (2008) so the author had to write them himself (and sent pull request to the tls haskell package).

"Unfortunately, many pieces were missing in the tls library. So, it was necessary for me to implement ALPN, ECDHE(Elliptic curve Diffie-Hellman, ephemeral) and AES GCM(Galois/Counter Mode). They are already merged into the tls and cryptonite library."

For what it's worth, it's extremely easy to write a fast WebSocket server in Haskell.

[0] puts examples front-and-center on the Hackage page.

[1] lets you easily integrate WebSockets with other things like Warp.

[2] shows that WebSocket servers in Haskell are actually quite performant.

[0] https://hackage.haskell.org/package/websockets

[1] https://hackage.haskell.org/package/wai-websockets

[2] https://github.com/hashrocket/websocket-shootout/blob/master...

For what it's worth, it's extremely easy to write a fast WebSocket server in Haskell.

Again, that's all well and good if you already know how to do it. But to be useful for serious production work, it shouldn't take several hours of reading, including numerous side trips to dead ends, and a discussion on HN where multiple Haskell developers who apparently have a lot more experience in this area suggest a variety of different libraries that collectively might get the job done. Except that right now, we've got two libraries for dealing with the WebSockets aspect in play, not counting plumbing libraries to join them up with the other aspects, and it's not clear which would be preferable to use or why.

It's worth remarking that at this point, we still haven't reached the point where I'd know how to write the simple proof of concept that I wrote in probably 20-30 minutes with Node without needing to consult anyone else. Achieving that within the Haskell ecosystem would apparently take considerable further reading, not to mention writing considerably more code if the examples we've collectively come up with so far in this discussion are as good as it gets.

Just to be clear, that is a fair comparison. In both cases, I was already familiar with the language and its main tools but I had no previous experience of writing the server side of a web application using either.

I don't know how much clearer I can make my point here, and I think perhaps those commenting to defend Haskell are still missing it. Even if some combination of libraries exists to do something in Haskell, that is still of very limited practical use if someone who isn't already an expert in them can't find the relevant information about what they are and how to use them. The documentation and packaging we've been talking about in this part of the discussion appear to be far from ideal, and keep in mind that even in the discussions here, we've already started from the premise that the developer recognised Yesod as the way to go when several other similarly well-known libraries are available for writing web servers in Haskell with varying capabilities and limitations. This is the same fundamental criticism that numerous people have made of the Haskell ecosystem in many different contexts, including elsewhere in today's HN discussion.

I'm largely sympathetic to the point that you're making. Your original claims were a little more inflammatory. This has transitioned into a discussion about the quality of documentation and tutorials, which I largely agree with.

FWIW, my point was always intended to be about the big picture and not just what is technically possible for someone who is already an expert (as some of the replies seem to have interpreted it). I'm sorry if my original phrasing was insufficiently clear.

> But I had a look into it the other day from the point of view of implementing the back-end for a new web project, and its support for writing web servers is still probably a decade behind the state of the art.

This is an unsubstantiated claim. For years, Haskell has had the best in class backend web stack - https://www.aosabook.org/en/posa/warp.html

For years, Haskell has had the best in class backend web stack

Please define "best in class".

Best in class - when within a single language, the following is available either out of the box or as a simple extra library dependency:

* Semi-explicit deterministic parallelism out of the box (https://www.microsoft.com/en-us/research/wp-content/uploads/... , https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_gui...)

* implicit Async IO runtime out of the box (https://www.microsoft.com/en-us/research/wp-content/uploads/...)

* thread-safe global mutable state and atomic transactions (http://book.realworldhaskell.org/read/software-transactional...)

* type-safe native TLS (https://hackage.haskell.org/package/tls)

* multicore async streaming web server (Warp) with a unified application API (WAI)

* type-safe embeddable DSLs for rendering web content (https://hackage.haskell.org/package/blaze-html , http://fvisser.nl/clay/)

* type-safe embeddable binary content at build-time (https://hackage.haskell.org/package/file-embed-0.0.12.0/docs... , https://hackage.haskell.org/package/servant-static-th-0.2.2....)

* type-safe HTTP specs and automatic schema derivation (https://docs.servant.dev/en/stable/cookbook/index.html)

* the whole stack (multicore asyncio runtime, Network, HTTP/1.1/2, WebSockets, TLS, HTTP Server + Schema Specs, Markup rendering) is compiled into a single static binary of ~3 megabytes, universally across Linux, MacOS, Windows.

* fullstack story with a help of GHCJS and a selection of frameworks (https://reflex-frp.org , https://haskell-miso.org)

So Haskell is best in class if you define that to mean web servers written in Haskell?

If we surveyed a representative sample of 1000 professional web developers, how many of them do you think would give a list broadly in line with your definition for the properties of their ideal server implementation language?

Since most web developers have no real clue about any of that stuff, why would their list in comparison matter here?

I think if you are going to claim a tool is "best in class" then it should be demonstrably better at meeting the actual needs of people doing what it's used for.

The list above was a list of features, not a list of benefits. Those features might bring practical benefits to the working web developer -- after all, people who program in Haskell do so for a reason, which is probably that they believe this kind of language is helpful in some way -- but that has yet to be established here.

Meanwhile, an experienced back end web developer will probably be asking questions about managing large numbers of routes or guarding against common attack vectors or integrating with databases or calling external APIs or having a template system that supports translation to multiple (human) languages or understanding performance characteristics and how the servers will react to higher loads. These are practical matters that many web server frameworks attempt to address. It is revealing but not entirely surprising that the Haskell response to my question was instead to talk about strong typing and STM and so on.

> So Haskell is best in class if you define that to mean web servers written in Haskell?

I was answering your comment about Haskell's web ecosystem. I didn't claim that Haskell is the best in class for everything just because it's the best for implementing web backends.

> It is revealing but not entirely surprising that the Haskell response to my question was instead to talk about strong typing and STM and so on.

I put them into my response because they are the features that you highly likely are not going to find alltogether on any other platform. The regular things like I18N, L10N, and so on that you mentioned are not worth the discussion, because Haskell ecosystem has them, in various shapes and forms, and apart from boring implementation details they are no different from similar libraries on other platforms.

I no longer think it's a chicken and egg problem with Haskell, and more of a goals & culture problem. Libraries like lens and parseq have a huge amount of effort put into them, probably more than what it would take to create a good HTTP client library. The problem is that creating industry friendly libraries is apparently not a goal that the Haskell community has.

> The problem is that creating industry friendly libraries is apparently not a goal that the Haskell community has.

I don't think that's a fair take. Haskell started as a research language, and it's only in the 2010s really that it started taking off and becoming more and more practical. That's because people invested lots of effort in libraries like lens (and many others). Haskell didn't even have a strong build system until Stack popped up in the mid-2010s. Frankly these were bigger priorities. These things had to be solved first in order to transition Haskell from a research experiment in lazy evaluation into a real-world tool.

In 2020, outside of maybe dependent types, the community is probably more concerned with practicality and pragmatism than ever before. There's a huge focus right now on improved IDE support, for instance.

10 years should be enough time to get a working IDE and a good starting set of libraries, and my personal experience is that Haskell has neither.

Maybe you ran into an issue where there still isn’t a decent starter library, but there are actually tons of great ones out there that we’ve used to build production services. So I can’t say I really know what you’re talking about in general.

Language server support is a recent trend, and it’s being worked on for Haskell just like it is for everything else.

People put energy into what's most useful for them and I don't think they should be blamed for this. I'm sure I'm biased but Lens and Parseq (and its successors) are both amazing libraries solving real problems in a powerful way. You probably don't agree and that's perfectly fine by me. I'd also go as far as saying that the 2 libs you've picked actually have pretty comprehensive documentations as well which is not always the case with Haskell libs (a real problem I 100% agree with btw).

I’m not blaming them, mostly, but I am pointing out that what they’ve put their effort is not consistent with industry usage. Parsec is neat, but parsing is a relatively niche industrial need, and lens sits somewhere between PL research and “solving problems that only Haskell has”.

They’re fine libraries, they’re just not what I want to see if you’re trying to convince me to replace Java with Haskell at work. If I was looking to write a compiler however...

I think when framing it as a chicken and the egg problem, haskell communities take on it is that you don't need a nest for the chicken to hatch in.

Brutalist Software engineering.

Usage based data implies that you actually do need a nest for an chicken to hatch in.

If you want chickens to hatch reliably, you need a coop too.

In haskell it's best to stick to libraries with more users than those that try to experiment with a fancy api.

So for example, just use http-client instead of req. Use postgres-simple or persistent instead of beam, etc...

> What does Haskell have? It has Req (and a bunch of other also rans), and the docs for Req are atrocious, spanning a staggering 1 (one) example and then a meandering essay on the deficiency of other Haskell HTTP clients. It's not good enough.

For HTTP request library, most would recommend Wreq. Being most popular, the documentation is really good I might say with most used API have their own example [1]. You can also easily find great tutorial on the net, like http://www.serpentine.com/wreq/tutorial.html for example. Honestly I never use Req myself and looking at the documentation myself, even though I don't it's lacking, I think it's not really geared toward Haskell beginners so maybe you have a point there.

As a novice Haskell programer who only use it for side projects, I don't think the documentation is that bad and it's only getting better. Most popular libraries like database clients and web frameworks have intensive documentation and tutorial nowadays.

I agree with you for the state of IDE support, it leaves something to be desired. But people are still working on it[2]. For now I mostly use vim with help of linter and formatter. The great thing about good type system is, you can still do much even without great IDE support. Haskell already have working and great REPL support that make development a breeze so it helped. I'll still take Haskell over OCaml or Scala anyday. Rust is great and I love it so much that it's my go to language for something system programming or networking related, but I don't think it's a good match if you want to learn functional programming.

[1] https://hackage.haskell.org/package/wreq-0.5.3.2/docs/Networ...

[2] https://github.com/haskell/haskell-language-server

From your complaints, which are all valid, at least the IDE problem is progressing very rapidly right now. Ghcide used to be a better solution over hie until now but now these two projects have been merged and we're finally getting something that works well out of the box.

The problem is that every time Haskell achieves some major milestone in the state of the art developer experience, the world has moved on to something new and Haskell is 5 years behind again.

Could you be more specific on this point? From my perspective, it’s always all the mainstream languages that are copying things from Haskell.

Haskell's language is very sophisticated, but the tooling and bindings to external systems is primitive.

Again, I’m going to ask for specifics. I run a Haskell company so I’m not unfamiliar with the language.

Eclipse then Visual Studio Code, Tensorflow, web services. I'm sure Haskell is great for you in your niche, but someone with arbitrary interest X, who knows Java or JavaScript or Python (or all 3 together, which is easier than knowing Haskell), X likely works out of the box with those languages, but not Haskell.

I’m sorry, but I still don’t understand what you mean. Haskell has mature libraries for writing web services. That’s what I use the language for, and it’s hardly a niche.

Plenty of people (including some of my colleagues) write Haskell in Visual Studio Code.

I don’t know anything about Tensorflow (though machine learning seems a bit more “niche” than building websites tbqh), and I haven’t known anyone to use Eclipse for writing code in the past decade or so.

Genuinely, I haven’t a clue what you are talking about. How would three general purpose languages “work out of the box” with X, but a fourth would not? Eclipse is a text editor and you can write Haskell with it. There are Haskell bindings to Tensorflow available.

Your point now doesn’t even seem to be consistent with your original point. How is Eclipse state-of-the-art? How is Haskell behind?

My experience recently has been great steps forward in features, and massive steps backwards in reliability.

>If you need typed functional programming, your options are OCaml, Scala, F# or even subsets of Rust and TypeScript.

And don't forget D. It's surprisingly well-suited for FP as its effects system has explicit support for pure functions and specifying a function is guaranteed not to throw, in addition to support for true (transitive) immutability. Not to mention full first-class function support, with lexical closures.

> Or look at the paltry state of IDE support. It's 2020 and the best option we have is VSCode with HIE

There's at least https://plugins.jetbrains.com/plugin/8258-intellij-haskell that is as simple for newcomers to setup as it can be.

You might like https://hackage.haskell.org/package/http-client/docs/Network...

Maybe my needs are limited but I rarely need something more than the GET and POST json examples there.

99.9 percent of folks should just be sticking to http-client instead of using dodgy libraries with fancy api that are not well maintained.