Why GitHub used Haskell for Semantic

Not Java or Python, but here’s some Ruby: https://www.honeybadger.io/blog/how-to-try-again-when-except...

The above article talks about exploiting Ruby's support for call/cc to do something similar.

A noteworthy difference: Ruby's support for call/cc is baked into it's runtime, while in Haskell you can implement call/cc as a normal library. This is done by leaning on Haskell's monadic "do" syntax and a suitable implementation of the Monad class.

http://hackage.haskell.org/package/mtl-2.2.2/docs/Control-Mo...

I'm rooting from my phone, so I can't type up a this-vs-that. But maybe that piques your interest and you can read up on Haskell and programming with monads.

> One of the main reasons I don't care much about Haskell is because without any side-by-side comparisons of Haskell vs <insert procedural language> I don't understand what the Haskell advantages are, and I don't know when I'm dealing with a problem space where Haskell would help me.

This is one of haskell's biggest problems. It's just enough outside of the normal flow of imperative languages (yet usable for the same problems) that you can't tell how much of an improvement it is unless you try it. Also, people who write haskell are more inclined to share lofty/abstract/interesting-to-other-haskellers code rather than your normal day-to-day code that is massively improved/safer and benefited from haskell's features.

I've mentioned this before, but one example of where it became apparent to me how much haskell had changed what I expected from language was non-nullable types. It's starting to be really common in languages now (typescript, kotlin, etc), but if you are used to writing imperative languages, the worry of nil/None/null is ever present, and a concept like Optional<T> is actually quite foreign looking. If you really think about it, it means that none of your language is safe -- none of your functions are safe because they said they wanted a String but you might have gotten a null that looks like a String to the typechecker and will blow up at runtime.

Another key improvement in haskell is the removal of class-based code-sharing (i.e. inheritance) -- the separation of behavior and data is really important, and most languages are starting to come around to this now (go w/ structs + interfaces, java w/ data classes, kotlin w/ data classes, rust w/ structs + traits), but haskell (and other ML languages) have been there for a while.

Yet another key improvement in haskell is the errors-as-values paradigm that is everywhere. If some function has a possibility of failure, then it should return `Maybe TheThing` or `Either AnError TheThing` (see how nice and legible those types are?) -- this forces explicit checks on failure and allows cases where there isn't a chance of failure (just `TheThing`) to speed ahead without nullchecks and be fairly certain. This actually pressures you into trying to sequester failure across your codebase -- you try to write functions that have signatures like `TheThing -> SomeArgument -> OtherThing` (see how legibile that is?), to minimize on the amount of `Maybe x` or `Either error x` you have to deal with -- this is often if not always good for codebases.

Maybe this is something I can help with, I write about pedestrian haskell a bunch, and I've been meaning to do a blog post on why haskell is better <your language>, something to really rustle the jimmies.

BTW, the quote about resumable exceptions is actually referring to a concept called a monad, which can be incredibly hard to grasp if you don't look in the right places (there are a lot of bad tutorials out there), or don't give your brain long enough to marinate in the concepts. If I were to take a stab at explaining it simply, in this case it's like a combination of exceptions-as-values (i.e. not go's approach, and not java's approach) and the value that is being passed around has enough state in it to continue stop, fix itself, whatever else. When something goes wrong in most imperative languages, you kind of get the hell out of dodge, and you lose access (usually) to whatever work was done up until the function boundary -- it doesn't have to be this way but it usually is.

I wrote a something[0] that demonstrates Haskell programs side-by-side with a Java program for a super toy problem. It goes on to explore more complex Haskell abstractions which implement the same simple program using less approachable techniques.

It is primarily meant for helping people understand how the abstractions work, rather than make an argument for when they are good to use, but it might give you enough background to understand the discussion around Haskell abstractions.

[0] http://reduction.io/essays/rosetta-haskell.html

I think it's hard to do just side-by-side comparison. Just imagine you just go back to 90s and convince C++ fans using Java.

They are all general purpose programming languages, just with some better/different design decisions to make things safer or relatively more/less expressive.

Similarly, the difficulty to explain Monad is Monad itself is pretty abstract and general. You can describe what it is, but it's hard to guarantee what the audience get from you. Someone says it can solve asynchronous programming issues, then someone will think it's something just for solving this kind of issues. Same as solving null pointer exceptions. After all, it's an abstract representation of sequencing computations with effectful context. But the last one is much harder to understand than the formers.

An equivalent thing is expressing the concept of the "variable" to a mathematical audience who never heard of a computer. They can definitely understand part of it, but not what you want to express.

This guy wrote 3 really short blog posts about doing Haskelly-stuff in C++. [1, 2, 3]

They are pretty concise and [2] especially did a good job of making me understand some of the power of Haskell.

[1] https://www.syrianspock.com/functional%20programming/softwar... [2] https://www.syrianspock.com/functional%20programming/softwar... [3] https://www.syrianspock.com/functional%20programming/softwar...

I'm only a Haskell beginner, but I have solved similar task, with parsing that may fail, in CIS 194 course. The solution was based on applicative functors, and I really don't think that Java or other languages have anything like it.

Here's the lecture: http://www.cis.upenn.edu/~cis194/spring13/lectures/10-applic... and PDF of the assignment: http://www.cis.upenn.edu/~cis194/spring13/hw/10-applicative.... Here's my solution of it: https://github.com/golergka/cis194/blob/master/Homework11/sr...

I hope it's readable enough to illustrate the overall concept - but please bear in mind that I'm a beginner and probably have made dumb mistakes. If you have any criticism or suggestions, I would love to hear and learn from them: learning Haskell is the first time in my software engineering self-education where I wish I had regular contact with instructor or a mentor.

I’m a bit skeptical of the difficulty ascribed to doing something like resumable conditions in a Java system.

You could have a per-thread singleton stack of handler objects. To raise a resumable condition you call a method on the stack that searches outward for an active handler to ask for a restart option and just returns it. If none is found an exception is thrown to unwind the call stack.

(Common Lisp has restartable conditions native to the language and this is essentially how it works. Conditions just don’t unwind the stack until no restart is available.)

Haskell monads can easily model other interesting control flow structures but this is basically just a syntax nicety of the do notation that lets you avoid writing nested lambdas to represent continuations. If you’re okay with heavy lambda nesting in Java you can do it all by just implementing whatever monad you like in Java—although the type system isn’t as glorious when it comes to higher-order polymorphism and inference.

This is trivial to do in most languages (including Java and Go) if you just stop to think about it for a couple of minutes. Just pass some kind of context object down the call stack (or make it available as a global — make it thread-local if you need). Then when an error occurs, just call this handler and voilà!

This is, in fact, pretty much what Haskell does. Except this handler is in a typeclass instance, and this typeclass instance is passed down the call stack, it just doesn't appear in the parameter lists but in the type signatures. It's a bit lighter syntactically, but ultimately it's the same thing.

> > During Semantic's interpretation passes, invalid code (unbound variables, type errors, infinite recursion) is recognized and handled based on the pass's calling context. … And given Go's lack of exceptions, such a feature would be entirely impossible.

Nonsense! It’s completely possible — you just have to be willing to abuse a few of Go’s features in order to do it.

First off, Go does have a standard calling-context (i.e. dynamic context) mechanism: context.Context[0]. All you need to do in order to track stuff in the calling context is stash an object in the … context.

Given this dynamic context mechanism, you next need a way to represent handlers. That’s easy: a handler is a function which takes an exceptional condition and either handles it or returns; handling consists of a transfer of control. Fortunately, Go has a control-transfer primitive as well: panic. So to handle a condition, a handler just panics — something higher up the call stack can use defer to catch the panic and continue execution.

That leads to the next component necessary: a way to provide resumption points, or restarts. A restart is just a function which is invoked by a handler, potentially with arguments, and which when invoked continues execution from its establishment point. This can be done with defer.

So it’s perfectly possible with tremendous abuse of Go’s panic/defer mechanism, no different from Java.

See this gist: https://gist.github.com/r13l/2911f93cbe66fb4ed50f9d9eb1eb252...

Honestly, I don’t even know if I’d call it tremendous abuse, although it is somewhat abusive. Abstracted in a library, it might even be somewhat useful.

It’s off-the-cuff — I haven’t fully considered the semantics of the different context objects being passed around.

0: https://golang.org/pkg/context/

I havr never noticed immutable data structures to be more difficult to deal with. For the most part, because of monads and effects and such you can essentially write better imperative code in haskell.

Im noy sure why youve decided that haskell is incapable of the syntactic appearance of mutation.

It's 100% the difficulty. Anyone saying otherwise is lying because they want Haskell to be popular, adopted it very early on in their career when they could really invest in it, or is a natural at this type of stuff and simply doesn't know any better.

I've learned about 10 different languages now and Haskell easily had the highest learning curve. Most languages I was able to get semi-usable in within a couple days, at least to do some minor stuff that works. But Haskell was a real commitment that took months until I was comfortable doing real stuff.

You have to learn about how to mutate data and how to manage state using monads and functors, how to query through complex objects using lenses, even getting it to parse some complex data coming from a JSON feed into a usable form requires a good understanding of the type system.

But ultimately besides when I first learned Clojure (my first exposure to FP), I don't think there's a language that has taught me as much about programming as Haskell. It was very rewarding and something I still continually dabble with and learn from on the side.

I've yet to pull the trigger and actually build a full side project with Haskell. Which is typically my biggest test. I've found Erlang/Elixir to be the far better middle ground from my day-to-day work in Ruby/JS when I want something modern, fast, and functional.

Once PureScript becomes stable I have a feeling I'll be diving harder into Haskell and may finally make that full commitment it requires for a real project.

> The most successful languages let you be pure-functional where it makes sense and then stateful where it makes sense. Haskell doesn't, really (from my cursory reading about it).

This is absolutely wrong. Sorry to be so direct, but I want to make sure other people not familiar with Haskell don’t get the wrong impression.

Haskell is explicitly designed to separate purely functional and stateful code with a clear interface between them: monads. It does exactly what you are asking for.

> But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space

True, but I would argue that it is far, far more common for people to writing stateful code to do things that are better done in functional style, than the other way around. This comes from my own experience of learning functional programming in JavaScript (before knowing about Haskell et al) and refactoring a project into a functional style that relies heavily on immutability.

I think Haskell is not more widely used in the industry because it has a very academic reputation. If you say you write Go, people think you are a practical programmer who turns coffee into solid business logic that powers some profitable website. You write Haskell? Then you are more likely to be perceived as some eccentric scholar or their like.

I actually think it's seeing quite a bit of adoption in industry. What I'm seeing is a class of developer that won't learn it or thinks they can't learn it, of course "to each their own", but I truly think Haskell/PureScript/Idris/Agda are onto something remarkable: making the software industry more like an engineering discipline and less of a craft (i.e. like the difference between civil engineering and carpentry).

Your argument RE: immutability and purity hampering implementations: Haskell excels at allowing developers to start with impure IO-heavy code, allowing you to later refactor chunks of the implementation out to pure code. In-fact, I talk about Haskell as the language you use to "move fast and _not_ break things". It also encourages a more principled approach to software design and reasoning than many other programming languages.

I've used Haskell (and seen it used) in production for many different problem domains for the last seven years of my career. I have yet to see something Haskell/GHC cannot handle well with a few niche exceptions.

In my time using Haskell I've come to think of "mutation" as a cardinal sin in software and you better have a good reason for committing it instead of letting the compiler do it for you (you can write mutable code in Haskell, too, btw - it just strongly discourages you from doing so and it makes some classes of mutable code impossible to write, which is a very, very good thing).

As a (very) fallible generalist, Haskell is a godsend and we use it extensively where I work for shell-scripts, for code generation, for (performant) network packet parsing, HTTP web servers, gRPC micro-services, and even our "build bot".

Very few programmers are proficient in Haskell, and operating systems and language tooling are built around imperative C-style semantics.

Combine that with the fact that most of the software industry does not care about correctness or stable software and generally lacks professionalism. "Just ship this half-assed software as soon as possible" is the attitude at the majority of software companies.

My theory is that the FP folks would have seen more success had they figured out ways to bring their features to mainstream languages, rather than asking people to adopt wholesale their weird languages (from an average programmer's point of view). For example, why can't I annotate functions as lazy? Swift takes one step in that direction, with lazy var, but why not a lazy func or lazy class? Even the lazy var can't be used for local variables.

People are generally more willing to accept incremental changes than an entirely new way of doing things. For good reasons: they're skeptical, availability of talent, tools, libraries, IDEs, help if they run into trouble...

An analogy is the spread of yoga in the west the past decade or two, because it was easy to do so without changing your lifestyle. If Westerners were asked to fly to the Himalayas for a month to learn yoga, how many would have learnt yoga?

> But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For these cases, the FP answer is usually "recompute and replace" (generally with immutable data structures that make this efficient).

It can get worse than that. My problem space has mutable state that is shared between multiple threads. FP's initial answer is "shared mutable state is evil". And they're right! But if that's the nature of your problem, then you're kind of stuck with it.

But the problem with the "recompute and replace an immutable data structure" is that I now have to notify all the relevant threads that they need to replace their reference to the data structure (avoiding race conditions in the process), and that seems at least as nasty as the problems I have doing it the imperative way.

> even getting it to parse some complex data coming from a JSON feed into a usable form requires a good understanding of the type system.

This is a good litmus test for the usability of a language. There’s no reason parsing json should be difficult.

The learning curve is one thing; dealing with purity and immutability is another. But the real stumbling block (besides the tooling issues) is the effect of lazy evaluation.

Lazy evaluation can make it quite difficult to reason about the time and memory resource requirements of Haskell programs, and debugging those isn't a whole lot of fun.

It is do-able, and like anything, gets better with experience, but it's hard to push things to production when you aren't sure they won't OOM or capriciously start doing some long thunk chain evaluation.

If you'll forgive the analogy, Haskell is kind of like the Mercedes of production-ready research-grade languages. You may not actually use haskell, but the features that haskell is pioneering are what you'll see trickling down into other languages, as language designers look over and borrow things. Some examples (though they're not all invented by haskell, but haskell has popularized them IMO):

- non-nullable types

- immutability as a default

- typeclassses + structs

- abstract data types

- errors-as-values

- monads

Haskell or any other ML language didn't come up with all these things of course, but Haskell is one of the best languages

Take a look at rust -- it's basically got a near haskell-grade type system (and there are lots of ML languages with more flexible type systems than Haskell as well), with C++ like performance. It would have been a lot harder for rust's designers to incorporate such a nice type system without the exploratory work haskell did and continues to do.

All that said, I'm pretty sure Haskell is seeing little adoption because of the learning curve.

> The most successful languages let you be pure-functional where it makes sense and then stateful where it makes sense. Haskell doesn't, really (from my cursory reading about it).

Haskell almost certainly does this, this is actually one of the best features of haskell -- it lets you do functional things and stateful things separately and encourages you to keep them separate.

Cannot speak for industry, so speaking from experience in academia when we were learning functional programming (FP).

The key difficulty there is the paradigm shift in thinking. For most people our thinking matches imperative programming. Ask a person to do something like run an analysis of an accounting book using paper, pen, and a calculator, and you'll see them keep some tallies which they keep updating as they go along. Even if there was a way to convert their work into a method which just involves repeatedly tapping out the numbers into a calculator in a formulaic way, almost every time it's going to be easier to reason about the logic in terms of stored state and progressive steps.

When you get hit with the paradigm of functional programming, which is beautiful when it works btw, you need to switch your thinking from pure logic to formulae driven logic. That's an unnatural shift and given how poorly early schooling helps shift our thinking to that mindset when we do maths, it's a hell of a leap.

Anecdotally we had a couple of pros at math - people who understood the fundamental beauty of math and proofs - and they took to FP like ducks in water. Even when we built a library management system in Haskell.

I think Haskell actually has a few qualities that can potentially turn people off at different points, all of which have been mentioned by others:

* Lazy Evaluation -- usually becomes an issue at some point if the project isn't trivial. * Lack of dependent types -- while Haskell's types system is great, this is a missing piece that proves a sore absence for some. It's not very surprising that several functional languages developed after haskell, inspired by haskell, and implemented in haskell (idris, agda, coq) * category theory -- While you can get by plenty well just knowing a few basic abstractions from category theory, it's true that many libraries rely on highly-theorectical concepts, and that a solid portion of haskell development efforts are still tinged with an academic flavor. Just take a look at some of Edward Kmett's coding videos--he typically has one (or several) mathematics/highly theoretical comp sci papers open in one window, while in the other he's implementing a hugely popular library like lens. This sort atmosphere of academism turns a lot of people off. It pegs the language as a theoretical exercise from the get go, and plenty of people are either don't believe in the value of theory or are far too busy to take the time to dive into how it applies to their situation.

I think the academic veneer around haskell is its biggest weakness when it comes to adoption, but that's said, it's still had more success than a lot of other academic, purely functional languages thanks to the efforts of core researchers/users/contributors to break it out of the ivory tower. The ideas are good. Almost every other modern programming language has stolen concepts from haskell at this point--so in some sense even though it's still somewhat niche its influence is practically ubiquitous (just take a look at the list of languages its noted as having influenced on wikipedia! https://en.wikipedia.org/wiki/Haskell_(programming_language)).

In a broader sense, the functional programming paradigm has proven not only that it's a viable one for industry applications, but often superior to object oriented or imperative techniques when it comes to fidelity of expression and preventing bugs. If nothing else, haskell is great because it provides a fairly rigorous environment in which you can explore functional programming concepts, which you can bring with you to almost any problem and any language and manage to derive some benefit.

In fighting games, characters are sometimes described in terms of their “skill cap” and “skill floor”. The “skill cap” is how well you can play, if you really invest in this character. The “skill floor” is about how bad things can get if you don’t play that well.

Some characters are very approachable and easy to play. If you don’t know what you are doing, it’s alright — you can muddle through. If you play them in a really exceptional way, it doesn’t make all that much difference.

Some characters are really tough to play at all; and once you figure it out, they aren’t particularly exceptional and don’t reward further investment.

A “high skill cap” character is one where you can keep learning and learning and your performance at the game will actually get better and better. Some of these characters are also approachable — they have a gentle learning curve. Some of these characters are basically unplayable until you can play them really well — there is an inflection far to the right where you go from dying all the time to actually winning a fair number of matches.

Haskell is like one of these characters. Until you’re really good and know a lot, you’re basically going to ship nothing. This effect is sort of invisible to senior programmers learning Haskell because they are already so skillful and are used to having to skim a CS paper or two, once in awhile, to be able to get their work done. Once you are good at Haskell, vistas really open for you in terms of the kind of programs you can design and build. Many year after setting it aside, I still rely on what I learned about Haskell API design and effects modeling to design reliable, transparent and modular distributed systems (it all starts with the types).

“High skill cap” characters tend to be admired, but not frequently played.

For me, the reason why I abandoned Haskell (for a couple years I was writing about half of third projects in it) is the complexity associated with laziness. FP and immutable data structures and monads are cool and mostly understandable once you grasp the concepts, but laziness is a double-edged sword. Laziness is cool, it enables a lot of nice things, but it makes me unable to easily reason about space complexity of any nontrivial algorithms, and that repeatedly bites me when I have to write such code.

In imperative code, space complexity is obvious and explicit, time complexity is intuitive for me, and correctness is shaky and needs to be tested.

In Haskell, correctness tends to be obvious (if there are no typos causing syntax to fail, it almost always gets the exact result I intended 100% correctly in the first try), but the space and time taken by the algorithm may be and often is surprising to me; If I make tiny modifications to the code, the execution may suddenly explode from 0.001 second to an hour because suddenly processing n entries involves creating and disposing n^2 thunks, taking all available memory and extreme amounts of time.

And despite trying a bunch to wrap my head about it, it keeps happening to me, it's just not intuitive to me - for me, eyeballing efficiency and exact time/space execution of a nontrivial Haskell function is just as hard as eyeballing whether random C code does everything correctly without a memory leak or overwriting being possible in an edge case. I also have trouble with Prolog for the same reason.

> Is it just the difficulty?

It's loads to unlearn for most of programmers and a perfectly natural knee-jerk reaction of a refusal to. I mean, the more one knows already, the more is the desire to reuse such knowledge. Well, at least I have been there.

> Haskell doesn't, really (from my cursory reading about it).

Of course it does, https://en.wikibooks.org/wiki/Haskell/Mutable_objects looks a good start.

I agree with you. It's sufficient to like using a tool and be productive with the tool to justify using it.

But sometimes, solid engineers who are productive with certain tools are working at the behest of unenlightened managers. Articles that say "BigCo uses X for Y because of Scientifically Sounding Reasons" help those engineers use the tools they like and are productive in.

There's another "real drug" hidden in the subtext of your post and Semantic's post, right in between

"Sure new code might have bugs, and deep semantic changes to code can break anything..."

and

"Its language features allow concise, correct, and elegant expression of the data structures and algorithms we work with."

- the notion that fundamental abstractions (not just the ones someboy thought up like the Gang of Four) compose well. This is something that we've seen the industry slowly migrating towards in the form of functional JS flavors like typescript and purescript, Java's lambdas, Scala's Cats and so on.

The ability to refactor and as importantly be confident that your refactor is not messing with the semantics of anything upstream is a hidden feature of static types applied to expressive abstractions.

So far, I have only seen this achieved with Haskell's libraries, type system, and reliance on fundamental mathematical concepts while also being able to avoid any "there's something rotten in Denmark" moments. The content in the Hackage ecosystem is a wonder of the modern programming world, warts and all.

There are many rough edges to the development process, as always, but at least in Haskell you can limit the language's contributions to that edgeset. It actually makes you want to produce good code and be a better developer as a result!

I saw on Twitter[1] that they're using it to show which methods/functions changed in a pull request[2].

[1]: https://twitter.com/rob_rix/status/1134537990095720450

[2]: https://github.blog/2017-07-26-quickly-review-changed-method...

This is an interesting perspective. I write Haskell for fun, and sometimes for profit. My first language that I wrote in professionally was Perl 5, so I definitely understand what you are saying about the dynamic types. However, in practice I have come to the opposite conclusion. When I use a dynamically typed language, I can't escape the looming fear that I am creating a mess for myself that, if I want to use for anything non-trival, I will have to clean up later. In Haskell, I find it very freeing because I can keep writing and as long as the types work out, the "mess" is contained and my play code has a much better path to maturing.

It sounds like you're trying to judge Haskell based on your experience of Java and C#? Don't do that. The Java/C# type systems have substantial limitations, but that's not a problem of type systems in general, it's a problem of C++-family languages specifically.

Using C# as an example, foreach and IEnumerable are baked into the language as is try/catch and more recently Async/Await. These are all just library functions in Haskell and often more general (e.g. forM in Haskell works for any Monad not just IO). Because they are library functions they can be changed/customized very easily. In C#, how could foreach be made to support a different stream type, exceptions be made checked or Async/Await be made to suspend across stack frames?

For this reason, Haskell is probably closer to a general purpose language than many of the imperative systems programming languages (especially Go).

> all functions are executed top to bottom albeit with lazy semantics.

No? There is no "top to bottom" execution, that's the whole point of the lazy semantics.

Why?

> I don't mean to be dismissive, but when your plans are to open source something corporate sponsored, you should do it in a way that benefits the community significantly

This is a super weird objection to me; is your argument that open sourcing something that might not be useful to others is worse than just keeping it closed-source? Even if literally nobody else ever gets any use from this, I don't see why it's harmful for it to be open sourced. More generally, I feel like companies releasing everything that they don't have a strong business reason not to as open source is strictly positive.

Pedantry is unhelpful. Technically this project could be written in assembly. Have fun doing that.

The point isn’t that the software couldn’t be written in Go; it’s that the language feature that makes that particular problem easier to deal with doesn’t exist.

You could write this tool in Go, but it would have an entirely different flow.

If you think x * y is a lot different than x + y, then you might want to think more about how you think about algebraic expressions, yeah?

If you think those two things are the same, you're just in the wrong. This isn't an opinion thing - I can easily prove that the Haskell way is strictly more precise than the Go way!

Not all Turing complete languages are the same. Curry-Howard shows that. Haskell's type system subsumes Go's and allows you to express richer propositions about program behavior.

Left foo and Right err alone do not act like exceptions: you need more baggage for that, which Haskell supports and encourages. When you define this in terms of a monad--not just a data type that has the same features, but part of a reusable category of types--you can provide special syntax for it, which Haskell does: if you have a language claim to have "monadic exceptions" without having a type class for monad and some reasonable support for working with monads, you should frankly question whether the people who designed the language understood what monads were in the first place. In Haskell, you can define operators on Either which allow you to use the generic do notation to achieve something with the feel of exceptions but with fully programmatic behavior: languages like Go and even Rust seem to want the downsides without gaining the benefits, which is just depressing.

"return foo, err" can return 4 kinds of responses:

- foo, nil

- nil, error

- nil, nil

- foo, error

What's the right behavior when the function returns both a result and an error? What's the right behavior when it returns two nils? At best, you make everybody agree to language conventions to prevent that from happening.

In Haskell (or even Swift and Kotlin with their optional types) the compiler guarantees those cases cannot happen. In Go, you just hope they never happen because almost no code handles them.

I code in Go every day. But I can't defend its decision here. I'd much rather have a richer type system where the compiler can guarantee that I'll get an error or a result, but not both or neither.