5 ms·

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

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.

ardfard 6y ago
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.
- Silhouette 6y ago
  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.
ghostwriter 6y ago
> 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 https://www.aosabook.org/en/posa/warp.html
- Silhouette 6y ago
  For years, Haskell has had the best in class backend web stack Please define "best in class".
  - ghostwriter 6y ago
    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/2009/09/multicore-ghc.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... , https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/using-concurrent.html#using-smp-parallelism 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/2016/02/parallel_haskell2.pdf 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-memory.html http://book.realworldhaskell.org/read/software-transactional...) * type-safe native TLS (https://hackage.haskell.org/package/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 https://hackage.haskell.org/package/blaze-html , http://fvisser.nl/clay/ http://fvisser.nl/clay/) * type-safe embeddable binary content at build-time (https://hackage.haskell.org/package/file-embed-0.0.12.0/docs/Data-FileEmbed.html https://hackage.haskell.org/package/file-embed-0.0.12.0/docs... , https://hackage.haskell.org/package/servant-static-th-0.2.2.1/docs/Servant-Static-TH.html 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 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://reflex-frp.org , https://haskell-miso.org https://haskell-miso.org)

ardfard 6y ago

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.

Silhouette 6y ago
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.

ghostwriter 6y ago

> 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 https://www.aosabook.org/en/posa/warp.html

Silhouette 6y ago
For years, Haskell has had the best in class backend web stack Please define "best in class".
- ghostwriter 6y ago
  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/2009/09/multicore-ghc.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... , https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/using-concurrent.html#using-smp-parallelism 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/2016/02/parallel_haskell2.pdf 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-memory.html http://book.realworldhaskell.org/read/software-transactional...) * type-safe native TLS (https://hackage.haskell.org/package/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 https://hackage.haskell.org/package/blaze-html , http://fvisser.nl/clay/ http://fvisser.nl/clay/) * type-safe embeddable binary content at build-time (https://hackage.haskell.org/package/file-embed-0.0.12.0/docs/Data-FileEmbed.html https://hackage.haskell.org/package/file-embed-0.0.12.0/docs... , https://hackage.haskell.org/package/servant-static-th-0.2.2.1/docs/Servant-Static-TH.html 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 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://reflex-frp.org , https://haskell-miso.org https://haskell-miso.org)