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.
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 is a kind of language that wouldn't have been written if its author discovered ATS[1] at a right time.
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.
Language server support is a recent trend, and it’s being worked on for Haskell just like it is for everything else.
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...
Brutalist Software engineering.
If you want chickens to hatch reliably, you need a coop too.
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.
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.
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.
> 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...
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.
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
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."
[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...
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.
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
Please define "best in class".
* 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)
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?
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.
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.
So for example, just use http-client instead of req. Use postgres-simple or persistent instead of beam, etc...
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...
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?
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.
There's at least https://plugins.jetbrains.com/plugin/8258-intellij-haskell that is as simple for newcomers to setup as it can be.
Maybe my needs are limited but I rarely need something more than the GET and POST json examples there.
My biggest complaints are 1) the lack of good libraries, and 2) the apalling state of documentation for the few that exist. Too many Haskell projects read like "I figured out this neat family of types for thinking about X - at last URL parsing is provably safe - now you figure out the rest".
Let's take a practical example: HTTP requests. If I'm a budding JavaScript developer, or Kotlin developer, or Python developer, I can read through copious search results and tutorials on Axios / OkHttp / Requests / delete as appropriate. These tutorials not only walk me through the common use cases but also show me their APIs in the context of the new and alien syntax of the language I'm grappling with. They give me enough template code that I can use an incomplete understanding of whatever language it is I'm learning to figure out the rest without recourse to a textbook.
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.
And that's my assessment of Haskell as a whole - not the language individually, which is expressive and powerful and inspired - but the whole ecosystem around Haskell that feels like a set of beta projects and hobby repositories generally developed by interested individuals rather than commercial endeavours.
Or look at the paltry state of IDE support. It's 2020 and the best option we have is VSCode with HIE, which rapidly spirals out of control allocating memory, randomly crashes and on Windows just refuses to even start half the time. Without this tooling a lot of the theoretical benefit of the type system is being lost. This is low hanging fruit but there's been no incentive to pick it.
And so I've made the difficult decision to leave Haskell behind. If you need typed functional programming, your options are OCaml, Scala, F# or even subsets of Rust and TypeScript. Haskell is a great learning experience but totally unproductive right now.