16 ms·

Haskell: The Bad Parts, part 2 (2020)

258 points by anuragsoni 6y ago

cies 6y ago
I'm enjoying the read. Having written a fair deal of Haskell, I'm really grateful for what leaning Haskell told me about programming at large. Snoyman has written amazing libs and acute articles, and I appreciate this series a lot. My interest though are: what's next? Can Haskell evolve? Can we move to a better standard lib? Here Snoyman has put forward a great effort by releasing his classy-prelude, but iirc he also stopped using it. So what can be done? Could we come up with a new Haskell-spec version that fixes some of these, flips some pragmas to be on-by-default? I can imagine that laziness is not going out, it too much at the heart of the language: or am I just assuming that? But besides laziness there is a lot to fix by just setting a new standard. It will help newcomers, an eventually even old codebases may make the jump. Some part of this article talks about partial functions. To what extend can we do without? Can we build a checker [1] for that and simply disallow it? 1: https://stackoverflow.com/questions/42151927/what-is-haskell-missing-for-totality-checking https://stackoverflow.com/questions/42151927/what-is-haskell...
- ivanbakel 6y ago
  >Some part of this article talks about partial functions. To what extend can we do without? Can we build a checker [1] for that and simply disallow it? You don't need an advanced checker for partial functions - the link you use is discussing proving termination, but total vs partial functions just requires checking whether the function is defined for all arguments, which is easy and something that GHC can already do. And to be honest, I'm not sure we can do without. Partial functions and `error` (or `undefined`) are necessary escape hatches for the programmer who knows something the compiler doesn't. Partial functions should probably not end up in any APIs (and definitely not in the Prelude), but they are still an important part of the language. Only the introduction of dependent typing has the possibility of really eliminating partial functions for good.
  - Ericson2314 6y ago
    The issue is not "undefined" and "error" but accidental partiality. `head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! The fact that https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop returns Option<T> really says it all. We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I wrote https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 to address just these sorts of issues, and not the harder ones people confuse them with.
    - ivanbakel 6y ago
      > The issue is not "undefined" and "error" but accidental partiality. I don't understand what you mean by this. >`head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! But the user can use `head` when they know that the list they are handling is non-empty (but then they can also opt for `Data.List.NonEmpty`). I never said the partial function itself carried any knowledge - only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. >We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I'm not opposed to that - and I don't see why you would think that I am. I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. That doesn't mean I believe they belong everywhere, and certainly not in most APIs.
      - cies 6y ago
        > I don't understand what you mean by this. I think that GP tries to say the escape hatches are not the problem. "error" and "undefined" are fine (we can check for undefined not being in production code, and errors, well, could be implemented as a "die" or "halt"). But head though... It should return a Maybe wrapped value! And as you say the other option is nonempty lists a.k.a. "(a, [a])". > only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. Well the docs do not present head as an escape hatch out of Haskell iron type system! It's documented rather innocently [1] (search for head). Unlike unsafePerformIO[2] and the likes, which have whole epistols detailing their danger. > I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. Please consider escape hatches differently from basic stuff like head and you see we argue for the same end result. Head is plain bad, should be removed or annotated as the smelly thing it is. maybeHead and non-empty-collections are the way fwd there, would you agree? 1: http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude.html http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude... 2: https://hackage.haskell.org/package/base-4.14.0.0/docs/System-IO-Unsafe.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Syste...
- gizmo686 6y ago
  GHC already supports strict-by-default https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/stri... Obviously making it the default would be backwards incompatible. But, as long as lazyness remains supported and simple to use on a per-case basis, it doesn't actually seem like that big of a change to me. Also, the fact that GHC supports so many extensions actually gives a good path to updating the language. Since extension are enabled on a per-file basis, in most cases old libraries would just work with new-Haskell as long as the build system knows to build them in old-Haskell mode.
  - nightski 6y ago
    I worked with Haskell for a few years and have a book on immutable data structures (Okasaki) in my book shelf here. From what I remember, with immutable data structures strict by default is actually a pretty bad default (please correct me if I remember wrong). I can only imagine this is one of the reasons Haskell is lazy by default (seriously, it's more than just that they wanted to try this crazy thing). Just enabling strictness everywhere in Haskell isn't just inherently better. Laziness is actually quite good (and the OP even says this to an extent). It's more nuanced than it seems.
    - gizmo686 6y ago
      For small amounts of data, strictness is better then laziness. There is a simmilar lesson even in non-pure languages: copying small amounts of data is almost always faster than fancy scheme you want to do to avoid copying. For large amounts of data in an immutable structure, laziness is pretty much essential. The theory behind strict-by-default is that most of the time, you are not dealing with large amounts of data; even if you have pointers to large data, or pointers to pointers of large data. Even though laziness is vital to a pure language, you only need to use it in a relatively small number of places.
      - dwohnitmok 6y ago
        Wait why is laziness vital to large data structures? Even with strict functions on strict, but persistent functions, you almost never copy the entire data structure. For example a strict function on a strict persistent list that swaps the head of the list doesn't have to copy the entire tail of the list. The thing that laziness enables is short-circuiting, so e.g. a fold over the list can bail out early if necessary. But this is actually a minority of use cases for large data, since we often bound the size of data structures with something like a `take n` function for some integer n, which only processes n elements in a strict language.
- massysett 6y ago
  Laziness - or more precisely, non-strictness - is the essence of Haskell. Haskell was created because there were a bunch of non-strict languages out there, and folks saw a need for one non-strict language to rule them all. Often a defining feature of Haskell is thought to be its purity. Purity arose from non-strictness. Monadic IO arose from non-strictness (other solutions to IO were also tried.) This is best discussed in a paper: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... I guess you could make Haskell strict by default...but why? It wouldn't be Haskell anymore. Non-strictness is the defining element of the language. In my view a strict-by-default Haskell is...something else. Maybe it's better for certain things. Maybe it takes things to the next level. But it isn't Haskell. Don't call it that.
  - rtpg 6y ago
    I think what’s being proposed around “strict data fields by default” (or, an alternative or “some new concept that evokes strictness where it makes sense”) could let us continue to use Haskell and its laziness. This isn’t really obvious to me but I think you could build a mixed reality without splitting a community up.
  - mst 6y ago
    "strict-by-default" isn't really the proposal here. Only "some things' laziness is more a footgun than a feature, maybe we should consider fixing those". The foldl/sum/product example in part one is maybe clearer about that.
  - cies 6y ago
    I understand the historic context of laziness, and what it "brought" or "taught" us. But is it really that important now, or moving forward? I side with Snoyman in the "strict by default would probably be better". Sure it's no longer Haskell then. But could there not be a language like Haskell leveraging strict by default? Possibly even on the GHC?
    - cycloptic 6y ago
      Isn't that basically every other ML variant?
- 3np 6y ago
  Do you think there's any hope of Haskell community moving to Idris? It's years since I did either but I think Idris is just a Better Haskell without several of the issues brought up.
  - lupire 6y ago
    For small programs, but not in general. Haskell has too many more language features and libraries.
- mumblemumble 6y ago
  > Can Haskell evolve? Should it? Haskell has already shown an impressive ability to evolve. Evolution is how it got where it is today. Language design analogues of the blood vessels being on the wrong side of the retina and all. If the goal remains to have an effective research language with a more-or-less unsurpassed capacity for evolution and pushing the state of the art in interesting directions, I'd say Haskell is still great just as it is. If, on the other hand, the goal is to have a productive industrial programming language that encompasses all of Haskell's great ideas, but without quite so many troublesome language warts, evolutionary vestiges, or {-# LANGUAGE EverythingInterestingThatsHappenedOverThePastThirtyYears #-}, it might be better to make a clean break.
  - agentultra 6y ago
    GHC is a production-ready compiler (for Haskell) suited for industry use. I work on a growing, healthy team and we ship an application written in Haskell several times a day. It has decent tooling, which is improving, and the language itself is what makes it possible to tolerate the pace of those developments. Haskell isn't a pure "research-only" language. I realize people like to point out that it's original goal was research... however the nature of that research has changed over time. Take Galois' Crucible project where they used advanced dependent-types in order to write their security analysis tool [0]. They could have used research-grade dependently-typed languages that are much more expressive and easier to use... but they chose Haskell because they needed an industrial-grade compiler capable of producing fast code to run in a production setting. The kind of research being done in GHC and Haskell these days is bringing innovation and advancement in functional programming into industrial applications. Every compiler is going to have warts. Especially with people using it and depending on it for industrial use. That's a good thing. You could be like Lean 4 which will make no promises of backwards compatibility or consideration for industrial users in the name of staying purely for research. Although I agree that Haskell is impressive in its ability to evolve and grow! Linear types just landed in GHC 9.0.1 and many fine folks are improving the compiler to make way for dependent types. It's good stuff! And to see languages like Java, C#, C++, and others pick up on the low-hanging fruit of FP languages is a sign that the paradigm is gaining popularity and adoption: ADTs, lamdbas, type inference, pattern matching... Maybe in 20-30 years will see these languages adopting higher-kinded types, rank-n types, GADTs, and more? [0] https://www.researchgate.net/publication/334751646_Dependently_typed_Haskell_in_industry_experience_report https://www.researchgate.net/publication/334751646_Dependent...
- willtim 6y ago
  IMHO Haskell is missing three features that would really improve programming in the large: 1) better structural types. For example, polymorphic extensible records and variants. These could even be the basis for all algebraic data types. Current encodings have poor syntax and poor type inference (due to non-injective type families). The need to make all records nominal types really gets in the way when dealing with structured data. Python is the main competitor here; and so we could also just use strings and maps, but we can do better. 2) a better module system. Even Miranda had a better module system than Haskell. OOP has first-class modules. 3) a better commitment to backwards compatibility. There have been controversial and breaking changes to Haskell's standard libraries that have done more harm than good. This has likely damaged industrial adoption of Haskell. For example, my employer, a prominent Haskell sponsor, is stuck on a 7-year old version. Unfortunately the above problems are difficult to retrofit for and so I think a new language may ultimately be needed.
  - Ericson2314 6y ago
    You realize 3 would make 1 and 2 harder or less valuable? And 3 would have also prevented a gazillion 1s and 2s from being still with us? I think breaking changes are highly underratted and people only shy away from them because the tooling expectations in all languages are so rock bottom.
    - willtim 6y ago
      > You realize 3 would make 1 and 2 harder or less valuable? Yes that is why I think (1) and (2) need a new language. > And 3 would have also prevented a gazillion 1s and 2s from being still with us? I disagree. Most new features have been implemented as extensions that must be enabled with language pragmas. This is not the same thing as large breaking changes in the standard libraries.
      - IngoBlechschmid 6y ago
        Isn't constructing a new language the ultimate breaking change :-)
- SkyMarshal 6y ago
  Keep Haskell as a research language imho, but perhaps create an industrial-oriented subset of the language, similar to Ada’s SPARK [1]. Make it strict if necessary, flip whatever pragmas support an industrial use case, etc., and create a separate brand but which still references Haskell. [1]:https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language)
- js8 6y ago
  > Can we move to a better standard lib? Here Snoyman has put forward a great effort by releasing his classy-prelude, but iirc he also stopped using it. He mentioned https://github.com/commercialhaskell/rio https://github.com/commercialhaskell/rio in the 1st article, it's interesting, I wasn't aware of it. (I am using classy-prelude but I might try it out.)
- jrochkind1 6y ago
  The OP addresses your question, saying he is not advocating for removing laziness, but does have some specific suggestions. > I'm not advocating for removing laziness in Haskell. In fact I'm not really advocating for much of anything in this series. I'm just complaining, because I like complaining. > But if I was to advocate some changes: * Deprecate partial functions * Introduce a naming scheme for partial functions to be more obvious * Introduce a compiler warning to note partial function use (with a pragma to turn off specific usages) * Warn by default on partial pattern matches * Advocate strict data fields by default
  - colonwqbang 6y ago
    Change all partial functions from returning a to returning Maybe a. Then we rename the fromJust function into the $%&!# operator (name intended to suggest the exclamation made by the programmer when function fails).
  - _ezkx 6y ago
    If StrictData were simply made the new default (with exceptions for lists and some other things in the standard lib), I bet very little code would break. It certainly wouldn't change the flavor of the language. I think it's a good idea.
- tikhonj 6y ago
  Haskell needs its own Elixir: a language different enough to fix fundamental problems but similar enough to inhabit the same world. I'm imagining a language with its own frontend and some of its own features that could still reuse GHC (maybe from Core down) and share libraries freely in both directions, while also able to address some fundamental issues without being constrained by backwards compatibility. I personally love Haskell: I think it's in a great place as a language (even if it isn't wildly popular) and on a positive trajectory. But I definitely feel the same pain points Snoyman brings up, and maybe some others. (Template Haskell >.<) I don't see any way of fixing many of the biggest issues if we care about backwards-compatibility at all, and a language with 30 years of existing code can never get away from that. I also don't think te community could weather a Python 2 → 3 transformation (much less Perl 5 → 6). So the only path I see towards simultaneously keeping what's great about Haskell and improving all that isn't would be another language that can coexist simultaneously, just like Elixir and Erlang.
  - Kototama 6y ago
    PureScript would almost fit :-). It would just need a modern Haskell backend but having a strict language built on a lazy-one is probably not the best idea :-).
    - YawningAngel 6y ago
      You can avoid lazy behaviour entirely in Haskell if you want to, so your purescript to haskell compiler can just only generate contrived haskell code that doesn't exhibit laziness
    - cies 6y ago
      Idris maybe? If Idris has easy interop with the Rust ecosystem, we'd have a great backend (and with wasmer possibly also fontend) option.
      - Kototama 6y ago
        I was also thinking as Rust as a backend for a FP language in the last day. I found some Ocaml binding for Rust. It would be interesting to see how it fits.
- cptwunderlich 6y ago
  FYI there was a proposal for a "Haskell 2021 Language" Extensions (similar to Haskell 98 and 2010), which was approved. This enables a bunch of extensions (and I guess will become default): https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/p... That being said, while there are alternative preludes, I'm not sure how or when (or ever) the current prelude will be changed or replaced. In terms of language evolution, the community seems to focus on further extensions of the Type System (linear types, quicklook impredicativity, dependent types), where I think there is a bigger need in better tooling. Of course, there too, lots of things are happening, like haskell-language-server, ghc-debug etc. etc. But still lots of work to do. Would be great if more people worked on modern tooling and improving GHC. And even better if more companies would fund that =)
IggleSniggle 6y ago
I’ve been meaning to learn Haskell. I appreciate this post for being honest that there are warts and that there’s a body of “community” knowledge about “the right” and “the wrong” way to do Haskell that might not be immediately evident. Anyway, a good read, even for an outsider to the ecosystem.
- dgellow 6y ago
  In case you're looking for a resource to learn more about Haskell, I would highly recommend http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/. I started recently to learn the language and tooling and found this guide randomly on Twitter, and it's by far the best codex of knowledge on the language I've seen so far. No bullshit, straight to the point, everything in one page (so easy to Ctrl-F around).
  - als0 6y ago
    Amazing find, thanks for sharing.
  - almostdeadguy 6y ago
    Easily the best reference to this I've found. I wish every language had one of these.
  - Koshkin 6y ago
    This is worth a separate submission.
- kitd 6y ago
  This is probably just personal taste, but I found the Haskell Wikibook [1] the single most useful resource when first coming to the language from a typical OO background. It keeps things simple and practical, how to solve typical problems, etc, without getting overrun by theory. Eg, it talks about 2 types of code, normal declarative and the imperative-like 'do' style, when to use them and how you can make them interact. Just accepting and working with that without having to understand monads etc reduces the cognitive load a lot. Once you're comfortable with it, it then goes through the underlying theory. I appreciated that. YMMV [1] https://en.wikibooks.org/wiki/Haskell https://en.wikibooks.org/wiki/Haskell
swagonomixxx 6y ago
I'm not sure I understand the relationship between partial function and exception handling. Aren't partial functions just curried? One or more arguments are bound, but not all? At least in Python, if you partial-ify a function that raises an exception, it still raises. I don't understand if the author likes that behavior or doesn't. Maybe this is some Haskell implementation detail that I'm not aware of. Last time I wrote any non-trivial Haskell was in 2014, so a long time ago, but I found that my biggest problem with it at the time was the really huge variety of Haskell in the wild. If you're doing simple stuff, you probably stick to the prelude and you'll be happy. But if you're doing anything that's a bit complex, you'll end up seeing hundreds of mini-dialects of Haskell in the wild, so much so that I found it really difficult as a newcomer to understand code on the net. In many cases it's almost like a different language completely, what with the user-defined infix functions, tons of currying everywhere, laziness, and the like, made it very difficult to follow code paths.
- UncleMeat 6y ago
  "Partial function" is an overloaded term. In this context it means "a function which does not map its entire domain to an output". This means that there are some inputs which return "Bottom", which happily gets propagated through the system until it is needed as input to some function and then your application explodes. The downside here is that rather than blowing up your application immediately upon a bug it blows up your application somewhere else depending on your logic. This can be a useful thing. You can write powerful and elegant algorithms that avoid error management because the bottom values never actually get used. But most people aren't doing that and instead these are time bombs.
  - codesnik 6y ago
    when bottom is actually reached that point of evaluation, does haskell provide any indication on where it came from? stacktrace or something?
  - cies 6y ago
    > This can be a useful thing. You can write powerful and elegant algorithms that avoid error management because the bottom values never actually get used. Agreed. This would be with some escape hatch function, maybe even from Unsafe. But having head in Prelude, without huge warning in the docs, without deprecation warnings, it just, well, not very Haskelly, I'd say.
Ericson2314 6y ago
I have a https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 in the works for the stupid partiality issue. As for the library ones: 1. Rust's std is better now, but will eventually sink to the level of base as ideoms improve because neither language has a good process for making breaking changes to the standard library 2. Rust has the core---std split, which Haskell desperately needs. Vector absolutely should be a separate package, but just the way alloc and hashbrown are separate packages in Rust land. Trying to work on that too. Now that Michael Snoyman thinks that exceptions in pure code are bad, and likes Rust, I wish he would think that exceptions in IO code are also bad, and we should use more EitherT like Rust.
- ragnese 6y ago
  Yeah. Rust's standard library already has cruft (e.g., std::error::Error deprecations), and some potential sore spots (no custom allocators, Pin/Promise unsoundness: https://internals.rust-lang.org/t/unsoundness-in-pin/11311 https://internals.rust-lang.org/t/unsoundness-in-pin/11311). I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude.
  - nynx 6y ago
    Custom allocators are coming soon.
    - ragnese 6y ago
      Right, but there was some frustration expressed in the discussions (IIRC) because you can't break backwards compat. So you can't just pass in an allocator to functions that might allocate. I don't have any skin in the game and don't really care how custom allocators will work (I'm glad the feature will exist, though).
  - Ar-Curunir 6y ago
    > I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude. Maybe in the future one could introduce pub(< ed2018) to indicate that an item is available only before edition 2018
dgellow 6y ago
This series of article should be turned into a linter. I'm only half joking!
Decabytes 6y ago
I'm curious about the tweet that says > True mastery of Haskell comes down to knowing which things in core libraries should be avoided like the plague. and one of the examples is foldl. foldl is used in Racket and other lisps, is Haskells implementation poor? Or are there better alternatives? I admit it's tricky to grok at first Nevermind I read further down the page and my question was answered. Should have actually read the article!
- almostdeadguy 6y ago
  Typically, you want to use the strict form of foldl, foldl'. The lazy version is susceptible to collecting a large number of thunks. See here: https://wiki.haskell.org/Foldr_Foldl_Foldl%27 https://wiki.haskell.org/Foldr_Foldl_Foldl%27
madmax96 6y ago
I’m a relative newcomer to Haskell. I still haven’t used it for anything serious, but I’d like to. I had experienced all of these problems. Initially, I was attracted to Haskell for the promise of “if it compiles then it’s probably correct.” I quickly discovered that isn’t true, for the reasons discussed in the article. But I also had issues with Cabal. I couldn’t get Snap to install. I tried installing it in a container, still didn’t work. I finally figured out something that would let me build with Snap, but for some reason LSP in Emacs couldn’t find the snap libraries, so it couldn’t provide me correct feedback. And then the build times. Wow. I gave up on writing that program in Haskell and wrote it in Go instead. I think Haskell has a lot to offer. I’d be open to trying it again. Hopefully these shortcomings improve.
- marcosdumay 6y ago
  Haskell has a real tooling problem. At this point, I do not allow any Haskell IDE engine to manage project data. Things work much smoother if you call cabal directly. But that's actually a low ball. I don't let any Java or Javasript, or Python (except Conda) IDE manage it either. And, of course, I've long gave up on anything integrated for C, C++ or Perl.
steelheadfly 6y ago
The Good Parts book by Crockford had its' focus on the language features (as opposed to prevailing conventions or the failures in the standard library). Not sure if this lived up to the spirit 100%. But outside of that, great stuff! (:
munk-a 6y ago
So if I'm a PHP developer that actively uses lazy evaluation patterns in his day to day that means I'm... best of both worlds? (Hint: I am!) Lazy values are a very powerful tool in the context of responding to requests as an intermediary between a client and a database due to how neatly you can reduce your peak memory usage - a lot of web-stuff follows the basic pattern of 1) Accept request 2) Figure out query to send to DB 3) Sent results to the user Since results aren't actively scanned by the server in many cases the goal of being able to pass-through data without directly exposing any of your internal guts to the client is a noble one to pursue.
- steelheadfly 6y ago
  Yeah the critique about laziness here lives in a different context. Lazy eval is great, don't worry about it. :)
mcguire 6y ago
Wow. It's almost like Rust has 20 years of programming language development experience on Haskell. (Note: Haskell and Rust are different languages, for different uses. Haskell has many advantages over Rust (some of which the author (and I) have probably complained about at some point). But many of the things that Rust does right and Haskell does wrong, Rust gets right because Haskell did them wrong.)
jamwt 6y ago
> And if I write a "Rust: The Bad Parts", believe me, I'll be mentioning panicking. This is why `panic=abort` should be the default, and the whole unwind-and-try-to-keep-the-world-sound path should be opt-in. Then panic is truly like `assert` and I'm guessing most of his objections would be gone. My guess about default-panic behavior being unwind is rust's origins in the servo project. When you're part of a very large monolith that should try very hard not to crash (a browser), you will put some work in to try to make this unwinding okay. Yes, tests still want panic to unwind, but you could opt in to this to, or change the default in a `[test]` context, or a bunch of other things I'm sure smarter folks could argue in an RFC. But getting correctness right in prod should be goal #1 IMO, so it should bias toward abort. For most places rust is probably actually used today (server-side), crashing is the safer and simpler behavior, and things like lock poisioning are not things you need to reason though. I know the article is about Haskell, so not trying to derail it, but I have a really similar Haskell -> Rust path in my background, so a lot of the rest of Michael's reactions here are just +1 for me. For example, yes, exactly this about partial functions. And, IMO, laziness, which he hints at in this section. The default should be the other way. Nothing worse than an `error` that's fired in some unexpected place/time due to lazy evaluation, and some thunk landed somewhere technically correct, but infuriating. Trying to figure out what the heck is going on can be really challenging/frustrating (as of my prod experience in Haskell 8-11 years ago, not sure what's gotten better/worse since then in ghc-land.) I learned a ton from Haskell, and am so glad I used it in depth for awhile (ditto ML). But these days, to actually build something I want to build with long-term value in mind, either individually or as part of a team, I just use Rust. I get most of what I loved about Haskell without the annoyances.
- kevincox 6y ago
  > the whole unwind-and-try-to-keep-the-world-sound path should be opt-in The unfortunate thing is that if this was the default even less code would be ready for it. The only way to make catching panics have any hope of working is to have it default-enabled.
- steveklabnik 6y ago
  I think it has more to do with the early language design than Servo per se; it took a lot of inspiration from Erlang. Green threads and “let it fail” were the error handing strategy.
brokencode 6y ago
Speaking as an outsider to Haskell, I have to say that while its core purely functional ideas are a little hard to wrap my head around, what daunts me the most is the incredible number of different ways there are to do everything, some recommended, some relics. You have to ask so many questions when you start learning Haskell: Should I use an alternate prelude? What string type should I use? Should I use lens? What package manager and build system should I use? What IDE plug-in works the best? What language extensions should I use? Should I make use of laziness, or try to avoid it? Are linear types a thing yet and should I use them? And on and on the questions go.. these aren’t questions that move forward the product, but just an endless list of boring details to figure out. I’d love a new version of Haskell with all the incredible power of GHC but without the standard library cruft. With all the best extensions picked out and on by default. With a wonderfully thought out stack and set of recommendations, along with a clear guide describing all of this, similar to what the Rust ecosystem has. In short, Haskell to me seems like a playground of interesting ideas rather than a coherent ecosystem for building software. Which I think is true since it’s a research language, but that’s what stops me from using it.
thesz 6y ago
As a long time Haskell user (from 1998 - my career started at 1989) and professional Haskell programmer, I should say that Snoyman is quite responsible for what I do not like in Haskell infrastructure. At 1998, Haskell was a joy to play. At 2008, it was still a joy to play - I really played through ghci (interpreter) implementing MIPS core. And, later, implementing a eDSL that can compile Haskell description of MIPS interpreter into VHDL. I also ghci'd through VHDL compiler prototype. At about 2009 or so there comes a cabal, a tool that "helps building large application", which took all the fun away. I had to manually download and put into local version control all packages I needed for a project. I also mandated, being the team lead, that we do not use cabal packages, we use stable sources of packages downloaded into our version control for easy inspection and problem fixing. That was my last attempt to bring fun (not "fun" as in "functional", but "fun" as "joy to play with") into my programming duties. Then there was a stack by Snoyman. It was purported to bring easiness back into cabal-based Haskell world of building applications. The problem is that easiness does not equal joy. You can use Roomba with easiness yet Roomba mopping floor would give you any resemblance of joy first one or two times it works on your command. That stack thing did not brought back the joy of use of Haskell. It did not provided you with ALL sources (only interface package authors intended) for you to consume, play and learn. It was all that boring cabal all over again. He was able to fix that - he had the power. He just does not care about learning from other's code, I guess. Me, on contrary, I do not have power there. But I have my goals set to bring the joy back into Haskell programming. And now let me somewhat relate that with the article. The "partiallness" of functions he referred there quite often, can be learned, through REPL interpreter and often quite useful. I used partiality quite fruitfully in development of the MIPS core I mentioned above - and yes, I was in full REPL control of all of my code. For that fruitfullness, one need not only compiled and installed package(s), but sources. To see, to learn, to modify. This is where stack by Snoyman fails as miserably as cabal it wanted to replace. One would see that article as a critique of Haskell. I see a failure to see and acknowledge one's shortcomings.
cjstadler 6y ago
What does it mean for a type class to be "law-abiding"? I'm coming from Rust so I'm curious what the "issue" is with FromIterator.
- joppy 6y ago
  I don’t know if there is an “issue” with fromIterator, the comment is just that it is ad-hoc: there is no law for it to satisfy. Law-abiding means that some equation holds, for example a monoid instance should be associative, so ((a <> b) <> c) should always produce the same result as (a <> (b <> c)). There is nothing checking that my implementation of <> abides by this law, but other programmers (and optimisers or compilers, maybe?) can make use of it, and might write incorrect code if my instance does not abide by the law. Another example would be functors: it should be the case that (fmap f) . (fmap g) is the same as fmap (f . g), for all functions f and g that make sense in the equation (output type of g must match input type of f).
jari_mustonen 6y ago
Not written in same spirit but his reminds me of the evergreen classic C++ FQA Lite. FQA of course stands for "frequently questioned answers". https://yosefk.com/c++fqa/ https://yosefk.com/c++fqa/

258 points by anuragsoni 6y ago

cies 6y ago

I'm enjoying the read. Having written a fair deal of Haskell, I'm really grateful for what leaning Haskell told me about programming at large. Snoyman has written amazing libs and acute articles, and I appreciate this series a lot. My interest though are: what's next? Can Haskell evolve? Can we move to a better standard lib? Here Snoyman has put forward a great effort by releasing his classy-prelude, but iirc he also stopped using it. So what can be done? Could we come up with a new Haskell-spec version that fixes some of these, flips some pragmas to be on-by-default? I can imagine that laziness is not going out, it too much at the heart of the language: or am I just assuming that? But besides laziness there is a lot to fix by just setting a new standard. It will help newcomers, an eventually even old codebases may make the jump. Some part of this article talks about partial functions. To what extend can we do without? Can we build a checker [1] for that and simply disallow it? 1: https://stackoverflow.com/questions/42151927/what-is-haskell-missing-for-totality-checking https://stackoverflow.com/questions/42151927/what-is-haskell...

ivanbakel 6y ago
>Some part of this article talks about partial functions. To what extend can we do without? Can we build a checker [1] for that and simply disallow it? You don't need an advanced checker for partial functions - the link you use is discussing proving termination, but total vs partial functions just requires checking whether the function is defined for all arguments, which is easy and something that GHC can already do. And to be honest, I'm not sure we can do without. Partial functions and `error` (or `undefined`) are necessary escape hatches for the programmer who knows something the compiler doesn't. Partial functions should probably not end up in any APIs (and definitely not in the Prelude), but they are still an important part of the language. Only the introduction of dependent typing has the possibility of really eliminating partial functions for good.
- Ericson2314 6y ago
  The issue is not "undefined" and "error" but accidental partiality. `head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! The fact that https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop returns Option<T> really says it all. We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I wrote https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 to address just these sorts of issues, and not the harder ones people confuse them with.
  - ivanbakel 6y ago
    > The issue is not "undefined" and "error" but accidental partiality. I don't understand what you mean by this. >`head` absolutely doesn't know something the compiler doesn't, because there is no guarantee the user is using it correctly! But the user can use `head` when they know that the list they are handling is non-empty (but then they can also opt for `Data.List.NonEmpty`). I never said the partial function itself carried any knowledge - only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. >We're not trying to be perfect, we're just trying to be no worse than Rust, which shouldn't be a high bar at all. I'm not opposed to that - and I don't see why you would think that I am. I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. That doesn't mean I believe they belong everywhere, and certainly not in most APIs.
    - cies 6y ago
      > I don't understand what you mean by this. I think that GP tries to say the escape hatches are not the problem. "error" and "undefined" are fine (we can check for undefined not being in production code, and errors, well, could be implemented as a "die" or "halt"). But head though... It should return a Maybe wrapped value! And as you say the other option is nonempty lists a.k.a. "(a, [a])". > only that it was a necessary escape hatch for cases where the programmer has the knowledge to use it correctly. Well the docs do not present head as an escape hatch out of Haskell iron type system! It's documented rather innocently [1] (search for head). Unlike unsafePerformIO[2] and the likes, which have whole epistols detailing their danger. > I'm just arguing that, in response to the question made by the other commenter, we can't "do without" partial functions entirely. Please consider escape hatches differently from basic stuff like head and you see we argue for the same end result. Head is plain bad, should be removed or annotated as the smelly thing it is. maybeHead and non-empty-collections are the way fwd there, would you agree? 1: http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude.html http://hackage.haskell.org/package/base-4.3.1.0/docs/Prelude... 2: https://hackage.haskell.org/package/base-4.14.0.0/docs/System-IO-Unsafe.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Syste...
gizmo686 6y ago
GHC already supports strict-by-default https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/stri... Obviously making it the default would be backwards incompatible. But, as long as lazyness remains supported and simple to use on a per-case basis, it doesn't actually seem like that big of a change to me. Also, the fact that GHC supports so many extensions actually gives a good path to updating the language. Since extension are enabled on a per-file basis, in most cases old libraries would just work with new-Haskell as long as the build system knows to build them in old-Haskell mode.
- nightski 6y ago
  I worked with Haskell for a few years and have a book on immutable data structures (Okasaki) in my book shelf here. From what I remember, with immutable data structures strict by default is actually a pretty bad default (please correct me if I remember wrong). I can only imagine this is one of the reasons Haskell is lazy by default (seriously, it's more than just that they wanted to try this crazy thing). Just enabling strictness everywhere in Haskell isn't just inherently better. Laziness is actually quite good (and the OP even says this to an extent). It's more nuanced than it seems.
  - gizmo686 6y ago
    For small amounts of data, strictness is better then laziness. There is a simmilar lesson even in non-pure languages: copying small amounts of data is almost always faster than fancy scheme you want to do to avoid copying. For large amounts of data in an immutable structure, laziness is pretty much essential. The theory behind strict-by-default is that most of the time, you are not dealing with large amounts of data; even if you have pointers to large data, or pointers to pointers of large data. Even though laziness is vital to a pure language, you only need to use it in a relatively small number of places.
    - dwohnitmok 6y ago
      Wait why is laziness vital to large data structures? Even with strict functions on strict, but persistent functions, you almost never copy the entire data structure. For example a strict function on a strict persistent list that swaps the head of the list doesn't have to copy the entire tail of the list. The thing that laziness enables is short-circuiting, so e.g. a fold over the list can bail out early if necessary. But this is actually a minority of use cases for large data, since we often bound the size of data structures with something like a `take n` function for some integer n, which only processes n elements in a strict language.
massysett 6y ago
Laziness - or more precisely, non-strictness - is the essence of Haskell. Haskell was created because there were a bunch of non-strict languages out there, and folks saw a need for one non-strict language to rule them all. Often a defining feature of Haskell is thought to be its purity. Purity arose from non-strictness. Monadic IO arose from non-strictness (other solutions to IO were also tried.) This is best discussed in a paper: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... I guess you could make Haskell strict by default...but why? It wouldn't be Haskell anymore. Non-strictness is the defining element of the language. In my view a strict-by-default Haskell is...something else. Maybe it's better for certain things. Maybe it takes things to the next level. But it isn't Haskell. Don't call it that.
- rtpg 6y ago
  I think what’s being proposed around “strict data fields by default” (or, an alternative or “some new concept that evokes strictness where it makes sense”) could let us continue to use Haskell and its laziness. This isn’t really obvious to me but I think you could build a mixed reality without splitting a community up.
- mst 6y ago
  "strict-by-default" isn't really the proposal here. Only "some things' laziness is more a footgun than a feature, maybe we should consider fixing those". The foldl/sum/product example in part one is maybe clearer about that.
- cies 6y ago
  I understand the historic context of laziness, and what it "brought" or "taught" us. But is it really that important now, or moving forward? I side with Snoyman in the "strict by default would probably be better". Sure it's no longer Haskell then. But could there not be a language like Haskell leveraging strict by default? Possibly even on the GHC?
  - cycloptic 6y ago
    Isn't that basically every other ML variant?
3np 6y ago
Do you think there's any hope of Haskell community moving to Idris? It's years since I did either but I think Idris is just a Better Haskell without several of the issues brought up.
- lupire 6y ago
  For small programs, but not in general. Haskell has too many more language features and libraries.
mumblemumble 6y ago
> Can Haskell evolve? Should it? Haskell has already shown an impressive ability to evolve. Evolution is how it got where it is today. Language design analogues of the blood vessels being on the wrong side of the retina and all. If the goal remains to have an effective research language with a more-or-less unsurpassed capacity for evolution and pushing the state of the art in interesting directions, I'd say Haskell is still great just as it is. If, on the other hand, the goal is to have a productive industrial programming language that encompasses all of Haskell's great ideas, but without quite so many troublesome language warts, evolutionary vestiges, or {-# LANGUAGE EverythingInterestingThatsHappenedOverThePastThirtyYears #-}, it might be better to make a clean break.
- agentultra 6y ago
  GHC is a production-ready compiler (for Haskell) suited for industry use. I work on a growing, healthy team and we ship an application written in Haskell several times a day. It has decent tooling, which is improving, and the language itself is what makes it possible to tolerate the pace of those developments. Haskell isn't a pure "research-only" language. I realize people like to point out that it's original goal was research... however the nature of that research has changed over time. Take Galois' Crucible project where they used advanced dependent-types in order to write their security analysis tool [0]. They could have used research-grade dependently-typed languages that are much more expressive and easier to use... but they chose Haskell because they needed an industrial-grade compiler capable of producing fast code to run in a production setting. The kind of research being done in GHC and Haskell these days is bringing innovation and advancement in functional programming into industrial applications. Every compiler is going to have warts. Especially with people using it and depending on it for industrial use. That's a good thing. You could be like Lean 4 which will make no promises of backwards compatibility or consideration for industrial users in the name of staying purely for research. Although I agree that Haskell is impressive in its ability to evolve and grow! Linear types just landed in GHC 9.0.1 and many fine folks are improving the compiler to make way for dependent types. It's good stuff! And to see languages like Java, C#, C++, and others pick up on the low-hanging fruit of FP languages is a sign that the paradigm is gaining popularity and adoption: ADTs, lamdbas, type inference, pattern matching... Maybe in 20-30 years will see these languages adopting higher-kinded types, rank-n types, GADTs, and more? [0] https://www.researchgate.net/publication/334751646_Dependently_typed_Haskell_in_industry_experience_report https://www.researchgate.net/publication/334751646_Dependent...
willtim 6y ago
IMHO Haskell is missing three features that would really improve programming in the large: 1) better structural types. For example, polymorphic extensible records and variants. These could even be the basis for all algebraic data types. Current encodings have poor syntax and poor type inference (due to non-injective type families). The need to make all records nominal types really gets in the way when dealing with structured data. Python is the main competitor here; and so we could also just use strings and maps, but we can do better. 2) a better module system. Even Miranda had a better module system than Haskell. OOP has first-class modules. 3) a better commitment to backwards compatibility. There have been controversial and breaking changes to Haskell's standard libraries that have done more harm than good. This has likely damaged industrial adoption of Haskell. For example, my employer, a prominent Haskell sponsor, is stuck on a 7-year old version. Unfortunately the above problems are difficult to retrofit for and so I think a new language may ultimately be needed.
- Ericson2314 6y ago
  You realize 3 would make 1 and 2 harder or less valuable? And 3 would have also prevented a gazillion 1s and 2s from being still with us? I think breaking changes are highly underratted and people only shy away from them because the tooling expectations in all languages are so rock bottom.
  - willtim 6y ago
    > You realize 3 would make 1 and 2 harder or less valuable? Yes that is why I think (1) and (2) need a new language. > And 3 would have also prevented a gazillion 1s and 2s from being still with us? I disagree. Most new features have been implemented as extensions that must be enabled with language pragmas. This is not the same thing as large breaking changes in the standard libraries.
    - IngoBlechschmid 6y ago
      Isn't constructing a new language the ultimate breaking change :-)
SkyMarshal 6y ago
Keep Haskell as a research language imho, but perhaps create an industrial-oriented subset of the language, similar to Ada’s SPARK [1]. Make it strict if necessary, flip whatever pragmas support an industrial use case, etc., and create a separate brand but which still references Haskell. [1]:https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language)
js8 6y ago
> Can we move to a better standard lib? Here Snoyman has put forward a great effort by releasing his classy-prelude, but iirc he also stopped using it. He mentioned https://github.com/commercialhaskell/rio https://github.com/commercialhaskell/rio in the 1st article, it's interesting, I wasn't aware of it. (I am using classy-prelude but I might try it out.)
jrochkind1 6y ago
The OP addresses your question, saying he is not advocating for removing laziness, but does have some specific suggestions. > I'm not advocating for removing laziness in Haskell. In fact I'm not really advocating for much of anything in this series. I'm just complaining, because I like complaining. > But if I was to advocate some changes: * Deprecate partial functions * Introduce a naming scheme for partial functions to be more obvious * Introduce a compiler warning to note partial function use (with a pragma to turn off specific usages) * Warn by default on partial pattern matches * Advocate strict data fields by default
- colonwqbang 6y ago
  Change all partial functions from returning a to returning Maybe a. Then we rename the fromJust function into the $%&!# operator (name intended to suggest the exclamation made by the programmer when function fails).
- _ezkx 6y ago
  If StrictData were simply made the new default (with exceptions for lists and some other things in the standard lib), I bet very little code would break. It certainly wouldn't change the flavor of the language. I think it's a good idea.
tikhonj 6y ago
Haskell needs its own Elixir: a language different enough to fix fundamental problems but similar enough to inhabit the same world. I'm imagining a language with its own frontend and some of its own features that could still reuse GHC (maybe from Core down) and share libraries freely in both directions, while also able to address some fundamental issues without being constrained by backwards compatibility. I personally love Haskell: I think it's in a great place as a language (even if it isn't wildly popular) and on a positive trajectory. But I definitely feel the same pain points Snoyman brings up, and maybe some others. (Template Haskell >.<) I don't see any way of fixing many of the biggest issues if we care about backwards-compatibility at all, and a language with 30 years of existing code can never get away from that. I also don't think te community could weather a Python 2 → 3 transformation (much less Perl 5 → 6). So the only path I see towards simultaneously keeping what's great about Haskell and improving all that isn't would be another language that can coexist simultaneously, just like Elixir and Erlang.
- Kototama 6y ago
  PureScript would almost fit :-). It would just need a modern Haskell backend but having a strict language built on a lazy-one is probably not the best idea :-).
  - YawningAngel 6y ago
    You can avoid lazy behaviour entirely in Haskell if you want to, so your purescript to haskell compiler can just only generate contrived haskell code that doesn't exhibit laziness
  - cies 6y ago
    Idris maybe? If Idris has easy interop with the Rust ecosystem, we'd have a great backend (and with wasmer possibly also fontend) option.
    - Kototama 6y ago
      I was also thinking as Rust as a backend for a FP language in the last day. I found some Ocaml binding for Rust. It would be interesting to see how it fits.
cptwunderlich 6y ago
FYI there was a proposal for a "Haskell 2021 Language" Extensions (similar to Haskell 98 and 2010), which was approved. This enables a bunch of extensions (and I guess will become default): https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/p... That being said, while there are alternative preludes, I'm not sure how or when (or ever) the current prelude will be changed or replaced. In terms of language evolution, the community seems to focus on further extensions of the Type System (linear types, quicklook impredicativity, dependent types), where I think there is a bigger need in better tooling. Of course, there too, lots of things are happening, like haskell-language-server, ghc-debug etc. etc. But still lots of work to do. Would be great if more people worked on modern tooling and improving GHC. And even better if more companies would fund that =)

IggleSniggle 6y ago

I’ve been meaning to learn Haskell. I appreciate this post for being honest that there are warts and that there’s a body of “community” knowledge about “the right” and “the wrong” way to do Haskell that might not be immediately evident. Anyway, a good read, even for an outsider to the ecosystem.

dgellow 6y ago
In case you're looking for a resource to learn more about Haskell, I would highly recommend http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/. I started recently to learn the language and tooling and found this guide randomly on Twitter, and it's by far the best codex of knowledge on the language I've seen so far. No bullshit, straight to the point, everything in one page (so easy to Ctrl-F around).
- als0 6y ago
  Amazing find, thanks for sharing.
- almostdeadguy 6y ago
  Easily the best reference to this I've found. I wish every language had one of these.
- Koshkin 6y ago
  This is worth a separate submission.
kitd 6y ago
This is probably just personal taste, but I found the Haskell Wikibook [1] the single most useful resource when first coming to the language from a typical OO background. It keeps things simple and practical, how to solve typical problems, etc, without getting overrun by theory. Eg, it talks about 2 types of code, normal declarative and the imperative-like 'do' style, when to use them and how you can make them interact. Just accepting and working with that without having to understand monads etc reduces the cognitive load a lot. Once you're comfortable with it, it then goes through the underlying theory. I appreciated that. YMMV [1] https://en.wikibooks.org/wiki/Haskell https://en.wikibooks.org/wiki/Haskell

swagonomixxx 6y ago

I'm not sure I understand the relationship between partial function and exception handling. Aren't partial functions just curried? One or more arguments are bound, but not all? At least in Python, if you partial-ify a function that raises an exception, it still raises. I don't understand if the author likes that behavior or doesn't. Maybe this is some Haskell implementation detail that I'm not aware of. Last time I wrote any non-trivial Haskell was in 2014, so a long time ago, but I found that my biggest problem with it at the time was the really huge variety of Haskell in the wild. If you're doing simple stuff, you probably stick to the prelude and you'll be happy. But if you're doing anything that's a bit complex, you'll end up seeing hundreds of mini-dialects of Haskell in the wild, so much so that I found it really difficult as a newcomer to understand code on the net. In many cases it's almost like a different language completely, what with the user-defined infix functions, tons of currying everywhere, laziness, and the like, made it very difficult to follow code paths.

UncleMeat 6y ago
"Partial function" is an overloaded term. In this context it means "a function which does not map its entire domain to an output". This means that there are some inputs which return "Bottom", which happily gets propagated through the system until it is needed as input to some function and then your application explodes. The downside here is that rather than blowing up your application immediately upon a bug it blows up your application somewhere else depending on your logic. This can be a useful thing. You can write powerful and elegant algorithms that avoid error management because the bottom values never actually get used. But most people aren't doing that and instead these are time bombs.
- codesnik 6y ago
  when bottom is actually reached that point of evaluation, does haskell provide any indication on where it came from? stacktrace or something?
- cies 6y ago
  > This can be a useful thing. You can write powerful and elegant algorithms that avoid error management because the bottom values never actually get used. Agreed. This would be with some escape hatch function, maybe even from Unsafe. But having head in Prelude, without huge warning in the docs, without deprecation warnings, it just, well, not very Haskelly, I'd say.

Ericson2314 6y ago

I have a https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 in the works for the stupid partiality issue. As for the library ones: 1. Rust's std is better now, but will eventually sink to the level of base as ideoms improve because neither language has a good process for making breaking changes to the standard library 2. Rust has the core---std split, which Haskell desperately needs. Vector absolutely should be a separate package, but just the way alloc and hashbrown are separate packages in Rust land. Trying to work on that too. Now that Michael Snoyman thinks that exceptions in pure code are bad, and likes Rust, I wish he would think that exceptions in IO code are also bad, and we should use more EitherT like Rust.

ragnese 6y ago
Yeah. Rust's standard library already has cruft (e.g., std::error::Error deprecations), and some potential sore spots (no custom allocators, Pin/Promise unsoundness: https://internals.rust-lang.org/t/unsoundness-in-pin/11311 https://internals.rust-lang.org/t/unsoundness-in-pin/11311). I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude.
- nynx 6y ago
  Custom allocators are coming soon.
  - ragnese 6y ago
    Right, but there was some frustration expressed in the discussions (IIRC) because you can't break backwards compat. So you can't just pass in an allocator to functions that might allocate. I don't have any skin in the game and don't really care how custom allocators will work (I'm glad the feature will exist, though).
- Ar-Curunir 6y ago
  > I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude. Maybe in the future one could introduce pub(< ed2018) to indicate that an item is available only before edition 2018

dgellow 6y ago

This series of article should be turned into a linter. I'm only half joking!

Decabytes 6y ago

I'm curious about the tweet that says > True mastery of Haskell comes down to knowing which things in core libraries should be avoided like the plague. and one of the examples is foldl. foldl is used in Racket and other lisps, is Haskells implementation poor? Or are there better alternatives? I admit it's tricky to grok at first Nevermind I read further down the page and my question was answered. Should have actually read the article!

almostdeadguy 6y ago
Typically, you want to use the strict form of foldl, foldl'. The lazy version is susceptible to collecting a large number of thunks. See here: https://wiki.haskell.org/Foldr_Foldl_Foldl%27 https://wiki.haskell.org/Foldr_Foldl_Foldl%27

madmax96 6y ago

I’m a relative newcomer to Haskell. I still haven’t used it for anything serious, but I’d like to. I had experienced all of these problems. Initially, I was attracted to Haskell for the promise of “if it compiles then it’s probably correct.” I quickly discovered that isn’t true, for the reasons discussed in the article. But I also had issues with Cabal. I couldn’t get Snap to install. I tried installing it in a container, still didn’t work. I finally figured out something that would let me build with Snap, but for some reason LSP in Emacs couldn’t find the snap libraries, so it couldn’t provide me correct feedback. And then the build times. Wow. I gave up on writing that program in Haskell and wrote it in Go instead. I think Haskell has a lot to offer. I’d be open to trying it again. Hopefully these shortcomings improve.

marcosdumay 6y ago
Haskell has a real tooling problem. At this point, I do not allow any Haskell IDE engine to manage project data. Things work much smoother if you call cabal directly. But that's actually a low ball. I don't let any Java or Javasript, or Python (except Conda) IDE manage it either. And, of course, I've long gave up on anything integrated for C, C++ or Perl.

steelheadfly 6y ago

The Good Parts book by Crockford had its' focus on the language features (as opposed to prevailing conventions or the failures in the standard library). Not sure if this lived up to the spirit 100%. But outside of that, great stuff! (:

munk-a 6y ago

So if I'm a PHP developer that actively uses lazy evaluation patterns in his day to day that means I'm... best of both worlds? (Hint: I am!) Lazy values are a very powerful tool in the context of responding to requests as an intermediary between a client and a database due to how neatly you can reduce your peak memory usage - a lot of web-stuff follows the basic pattern of 1) Accept request 2) Figure out query to send to DB 3) Sent results to the user Since results aren't actively scanned by the server in many cases the goal of being able to pass-through data without directly exposing any of your internal guts to the client is a noble one to pursue.

steelheadfly 6y ago
Yeah the critique about laziness here lives in a different context. Lazy eval is great, don't worry about it. :)

mcguire 6y ago

Wow. It's almost like Rust has 20 years of programming language development experience on Haskell. (Note: Haskell and Rust are different languages, for different uses. Haskell has many advantages over Rust (some of which the author (and I) have probably complained about at some point). But many of the things that Rust does right and Haskell does wrong, Rust gets right because Haskell did them wrong.)

jamwt 6y ago

> And if I write a "Rust: The Bad Parts", believe me, I'll be mentioning panicking. This is why `panic=abort` should be the default, and the whole unwind-and-try-to-keep-the-world-sound path should be opt-in. Then panic is truly like `assert` and I'm guessing most of his objections would be gone. My guess about default-panic behavior being unwind is rust's origins in the servo project. When you're part of a very large monolith that should try very hard not to crash (a browser), you will put some work in to try to make this unwinding okay. Yes, tests still want panic to unwind, but you could opt in to this to, or change the default in a `[test]` context, or a bunch of other things I'm sure smarter folks could argue in an RFC. But getting correctness right in prod should be goal #1 IMO, so it should bias toward abort. For most places rust is probably actually used today (server-side), crashing is the safer and simpler behavior, and things like lock poisioning are not things you need to reason though. I know the article is about Haskell, so not trying to derail it, but I have a really similar Haskell -> Rust path in my background, so a lot of the rest of Michael's reactions here are just +1 for me. For example, yes, exactly this about partial functions. And, IMO, laziness, which he hints at in this section. The default should be the other way. Nothing worse than an `error` that's fired in some unexpected place/time due to lazy evaluation, and some thunk landed somewhere technically correct, but infuriating. Trying to figure out what the heck is going on can be really challenging/frustrating (as of my prod experience in Haskell 8-11 years ago, not sure what's gotten better/worse since then in ghc-land.) I learned a ton from Haskell, and am so glad I used it in depth for awhile (ditto ML). But these days, to actually build something I want to build with long-term value in mind, either individually or as part of a team, I just use Rust. I get most of what I loved about Haskell without the annoyances.

kevincox 6y ago
> the whole unwind-and-try-to-keep-the-world-sound path should be opt-in The unfortunate thing is that if this was the default even less code would be ready for it. The only way to make catching panics have any hope of working is to have it default-enabled.
steveklabnik 6y ago
I think it has more to do with the early language design than Servo per se; it took a lot of inspiration from Erlang. Green threads and “let it fail” were the error handing strategy.

brokencode 6y ago

Speaking as an outsider to Haskell, I have to say that while its core purely functional ideas are a little hard to wrap my head around, what daunts me the most is the incredible number of different ways there are to do everything, some recommended, some relics. You have to ask so many questions when you start learning Haskell: Should I use an alternate prelude? What string type should I use? Should I use lens? What package manager and build system should I use? What IDE plug-in works the best? What language extensions should I use? Should I make use of laziness, or try to avoid it? Are linear types a thing yet and should I use them? And on and on the questions go.. these aren’t questions that move forward the product, but just an endless list of boring details to figure out. I’d love a new version of Haskell with all the incredible power of GHC but without the standard library cruft. With all the best extensions picked out and on by default. With a wonderfully thought out stack and set of recommendations, along with a clear guide describing all of this, similar to what the Rust ecosystem has. In short, Haskell to me seems like a playground of interesting ideas rather than a coherent ecosystem for building software. Which I think is true since it’s a research language, but that’s what stops me from using it.

thesz 6y ago

As a long time Haskell user (from 1998 - my career started at 1989) and professional Haskell programmer, I should say that Snoyman is quite responsible for what I do not like in Haskell infrastructure. At 1998, Haskell was a joy to play. At 2008, it was still a joy to play - I really played through ghci (interpreter) implementing MIPS core. And, later, implementing a eDSL that can compile Haskell description of MIPS interpreter into VHDL. I also ghci'd through VHDL compiler prototype. At about 2009 or so there comes a cabal, a tool that "helps building large application", which took all the fun away. I had to manually download and put into local version control all packages I needed for a project. I also mandated, being the team lead, that we do not use cabal packages, we use stable sources of packages downloaded into our version control for easy inspection and problem fixing. That was my last attempt to bring fun (not "fun" as in "functional", but "fun" as "joy to play with") into my programming duties. Then there was a stack by Snoyman. It was purported to bring easiness back into cabal-based Haskell world of building applications. The problem is that easiness does not equal joy. You can use Roomba with easiness yet Roomba mopping floor would give you any resemblance of joy first one or two times it works on your command. That stack thing did not brought back the joy of use of Haskell. It did not provided you with ALL sources (only interface package authors intended) for you to consume, play and learn. It was all that boring cabal all over again. He was able to fix that - he had the power. He just does not care about learning from other's code, I guess. Me, on contrary, I do not have power there. But I have my goals set to bring the joy back into Haskell programming. And now let me somewhat relate that with the article. The "partiallness" of functions he referred there quite often, can be learned, through REPL interpreter and often quite useful. I used partiality quite fruitfully in development of the MIPS core I mentioned above - and yes, I was in full REPL control of all of my code. For that fruitfullness, one need not only compiled and installed package(s), but sources. To see, to learn, to modify. This is where stack by Snoyman fails as miserably as cabal it wanted to replace. One would see that article as a critique of Haskell. I see a failure to see and acknowledge one's shortcomings.

cjstadler 6y ago

What does it mean for a type class to be "law-abiding"? I'm coming from Rust so I'm curious what the "issue" is with FromIterator.

joppy 6y ago
I don’t know if there is an “issue” with fromIterator, the comment is just that it is ad-hoc: there is no law for it to satisfy. Law-abiding means that some equation holds, for example a monoid instance should be associative, so ((a <> b) <> c) should always produce the same result as (a <> (b <> c)). There is nothing checking that my implementation of <> abides by this law, but other programmers (and optimisers or compilers, maybe?) can make use of it, and might write incorrect code if my instance does not abide by the law. Another example would be functors: it should be the case that (fmap f) . (fmap g) is the same as fmap (f . g), for all functions f and g that make sense in the equation (output type of g must match input type of f).

jari_mustonen 6y ago

Not written in same spirit but his reminds me of the evergreen classic C++ FQA Lite. FQA of course stands for "frequently questioned answers". https://yosefk.com/c++fqa/ https://yosefk.com/c++fqa/