9 ms·
I was a Haskell developer in my last gig. I entered that job determined to make a success of it, because I was excited about the language and felt I wanted to "
by jbreckmckye 6y ago
I was a Haskell developer in my last gig. I entered that job determined to make a success of it, because I was excited about the language and felt I wanted to "prove" that it had value in a "boring" domain like financial services. But I was stymied at every opportunity by Haskell itself.
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.
- pwm 6y agoIt'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.
- Silhouette 6y agoIt'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 agoCan 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.
- hopia 6y agoFrom 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.
- gowld 6y agoThe 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.
- yakshaving_jgt 6y agoCould you be more specific on this point? From my perspective, it’s always all the mainstream languages that are copying things from Haskell.
- sukilot 6y agoHaskell's language is very sophisticated, but the tooling and bindings to external systems is primitive.
- yakshaving_jgt 6y agoAgain, I’m going to ask for specifics. I run a Haskell company so I’m not unfamiliar with the language.
- gowld 6y agoEclipse 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.
- mrkeen 6y agoYou might like https://hackage.haskell.org/package/http-client/docs/Network-HTTP-Client.html 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.
- platz 6y ago99.9 percent of folks should just be sticking to http-client instead of using dodgy libraries with fancy api that are not well maintained.
- _bxg1 6y agoI 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.
- dragonsh 6y agoThis 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.
- ghostwriter 6y ago> 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 http://www.ats-lang.org
- AndyKelley 6y agoi was aware of ats before creating zig
- logicprog 6y agoThis 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.
- platz 6y agoIn 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...
- deleted 6y ago[deleted]
- ardfard 6y ago> 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 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/Network-Wreq.html https://hackage.haskell.org/package/wreq-0.5.3.2/docs/Networ... [2] https://github.com/haskell/haskell-language-server https://github.com/haskell/haskell-language-server
- ghostwriter 6y ago> 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 https://plugins.jetbrains.com/plugin/8258-intellij-haskell that is as simple for newcomers to setup as it can be.
- EvenThisAcronym 6y ago>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.