The complexity of Haskell vs. Elixir's simplicity

[gonz]

I am curious where you got the above thoughts though as they seem to lack the reasoning on the other side as to ‘why’ those decisions where made

No, I think I’m fairly certain why most of the QoL things that aren’t in ocaml are missing and I even gave one of those in the post.

rather because it has a significantly more powerful capability that is slightly more verbose, but even the verbosity will vanish once a PR is finished up),

You mean the thing that never ever ships, just like multicore? It’s the Duke Nuke’em of language features at this point.

I like ocaml and I understand what it’s doing, I’ve even praised the singular dedication they’ve shown in never implementing anything that doesn’t fit into those ideas, but it just isn’t as concerned with QoL as I’d like it to be.

About top-level pattern matching, it’s a nitpick but I’d just prefer split clauses with pattern matching right on the parameters. I didn’t use to but I just think it’s unnecessary to not have it at this point.

I’ll reiterate what I’ve said elsewhere: I think OCaml is about as much power as you can get with the least amount of tools, because when stuff is added it fits extremely well. I’d just rather they lowered the power-to-feature ratio in favor of comfort a bit. But it’s not in their philosophy to do that and that’s fine. We still use OCaml for some of our projects and I’m very happy about it because it beats Javascript by heaps.

[OvermindDL1]

No, I think I’m fairly certain why most of the QoL things that aren’t in ocaml are missing and I even gave one of those in the post.

Except they aren’t missing. OCaml has overriding in lieu of free ordering, or just use and instead of let at all top level definitions except the first, then you get free ordering, Haskell’s definitions are like they are in an implicit and chain without any way to break out. OCaml doesn’t like to pollute the function namespace as it then makes ‘return’ type deduction not what one would expect, unlike what Haskell does (I.E. it is opt-in). And OCaml very much has pattern matching that is near the power of erlang, I’m not actually sure that haskell even has the capability of guards on pattern matching?

You mean the thing that never ever ships, just like multicore? It’s the Duke Nuke’em of language features at this point.

Not in mainline but they are in branches. Unlike Haskell that likes to break things on every-singly-version, OCaml actually takes backwards compatibility seriously, thus they don’t just immediately toss in everything that is handed them but rather test it extensively, including with existing code-bases to make sure no prior issues, and that it will properly cover all issues that it is intended to cover into the unbounded future, which is very much unlike Haskell that has 40 ways of doing things, 3 string types just in core alone, and kludge upon kludge upon kludge just to get it’s type system working.

but it just isn’t as concerned with QoL as I’d like it to be.

They are very concerned with QoL, not just with immediate usage but also with maintainability and for people to not worry that their code will just outright break on later versions, unlike Haskell.

About top-level pattern matching, it’s a nitpick but I’d just prefer split clauses with pattern matching right on the parameters. I didn’t use to but I just think it’s unnecessary to not have it at this point.

A PPX can change that, but that seems like a lot of needless verbosity when just a simple | indicates a new head on the same function, nicely readable and perfectly consistent with match expressions, unlike haskell that uses entirely different syntax between it’s function heads and case.

I’ll reiterate what I’ve said elsewhere: I think OCaml is about as much power as you can get with the least amount of tools, because when stuff is added it fits extremely well. I’d just rather they lowered the power-to-feature ratio in favor of comfort a bit. But it’s not in their philosophy to do that and that’s fine. We still use OCaml for some of our projects and I’m very happy about it because it beats Javascript by heaps.

I’m curious how it is considered ‘least amount of tools’. Everything you can do with Functors and modules you can do via flat record packing/unpacking (and a whole TON more verbosity), you get the completely fluff row-typing via objects (which are just row-typed records), you have polymorphic variants (also entirely fluff on a normal more-verbose tag system), among a great deal more. OCaml is designed for ease of use and ease of reading (where haskell often looks like line noise and runs slower to boot…). No surprise slow lazy calls (instead it’s opt-in via lazy, thus only where you need it, instead Haskell is opt-out), it compiles significantly faster, has a single package manager system, doesn’t have an ambiguous syntax that relies on whitespace to try to disambiguate (and haskell still fails at times) that makes copying code actually sensible, has the ability to extend modules, etc… etc…

However yes, OCaml’s parallel work sucks, the python model is not acceptable, but then again OCaml usually replaces my Python work, it doesn’t replace my erlang/elixir or C++/Rust work. Use the right language in the right place and all. Haskell does have some cool concurrency models, but then again it is a move fast and break things language. And it’s not like OCaml is standing still, the current work is focusing on getting windows to be a first-class citizen, which is no small undertaking.

[gonz]

And OCaml very much has pattern matching that is near the power of erlang, I’m not actually sure that haskell even has the capability of guards on pattern matching?

f x | x < 0     = -1
    | x == 0    = 0
    | otherwise = 1

It’s just that I also prefer, if ever so slightly, to be able to do this:

update model (ServerMsg msg) = handleServerMessage model msg
update model (ClientMsg msg) = handleClientMessage model msg

instead of this

let update model = function
  | Server_msg msg -> handle_server_message model msg
  | Client_msg msg -> handle_client_message model msg

Not in mainline but they are in branches. Unlike Haskell that likes to break things on every-singly-version, OCaml actually takes backwards compatibility seriously, thus they don’t just immediately toss in everything that is handed them

Much like the picture you’re painting is an exaggeration I’ll say at least Haskell got new features since the millenium. For real, though, I don’t really see where you’re going with this as breaking changes haven’t been something I’ve taken note of in Haskell. If you mean new language features changing things they’re exclusively in language extensions (which OCaml should probably adopt, by the way, so new features can actually enter the language instead of languishing in repositories for 4+ years).

Modular implicits have been coming Soon™ for like 2-3 years. If ergonomics/QoL was a serious priority they’d have been out long ago, but I guess the safest way to ensure no breakage is to literally never actually release the feature.

3 string types just in core alone

Text & ByteString aren’t in core, they’re just packages. That’s either worse or better depending on who you ask, I suppose. If you were to say it’s confusing for newbies, yeah, it’s currently what half of this thread is about at the moment, but luckily these have “best practices” now. If it’s text, just use Text, if it’s binary data that’s not meant to be treated as text, just use ByteString.

OCaml is designed for ease of use…

… once the compiler has gotten its pound of flesh and something has absolutely no performance hit whatsoever?

Jokes aside I’m not even saying OCaml is somehow much worse than every other language. All things considered it’s probably in my top 5 languages, maybe even top 3. It’s just that you inevitably feel like you’ve gone back in time for a bit, in my opinion.

All in all I just can’t really agree with you that it seems they’ve ever really considered ergonomics and putting the programmer first in almost any choice. I love the features they have put in, but at some point it must’ve been like obviously useful things like ad-hoc polymorphism just weren’t prioritized highly enough. At this rate Haskell will likely implement dependent types before modular implicits are released for OCaml. That’s all work done by, as far as I know, one person and that’s to take the language into the future, not just catch up.

[OvermindDL1]

It’s just that I also prefer, if ever so slightly, to be able to do this:

update model (ServerMsg msg) = handleServerMessage model msg
update model (ClientMsg msg) = handleClientMessage model msg

instead of this

let update model = function
  | Server_msg msg -> handle_server_message model msg
  | Client_msg msg -> handle_client_message model msg

I actually prefer the latter, even putting a case inside a def in elixir at times, it makes it obvious they all belong together, heads of the same function, unlike the above and normal elixir/erlang styles where you can’t always tell they are the same head without mentally parsing the name and arguments of the function itself. I.E. it makes it contextually obvious without needing to do mental work, which is a huge boon when scanning through code quickly.

Much like the picture you’re painting is an exaggeration I’ll say at least Haskell got new features since the millenium. For real, though, I don’t really see where you’re going with this as breaking changes haven’t been something I’ve taken note of in Haskell. If you mean new language features changing things they’re exclusively in language extensions (which OCaml should probably adopt, by the way, so new features can actually enter the language instead of languishing in repositories for 4+ years).

OCaml core is pretty easy about taking in new features as long as there is sufficient tests done, pretty stringent on that. In Haskell I’m speaking more of old code breaking, not new features.

Modular implicits have been coming Soon™ for like 2-3 years. If ergonomics/QoL was a serious priority they’d have been out long ago, but I guess the safest way to ensure no breakage is to literally never actually release the feature.

Modular implicits are a fairly small thing overall, they save you from typing a single word each on a witness patterned function call, not a huge boon, though a nice QoL mostly on witness based operators (I tend to go for piping though).

It’s just that you inevitably feel like you’ve gone back in time for a bit, in my opinion.

Most of my Haskell work ended ~5 years ago, so I havn’t kept up much after that except the occasional compiling and updating/fixing of something that broke from new versions of ghc. Still though it’s massive amount of type extensions hasn’t gotten any better by far, nor its compiling speed (still rivals that of C++, especially templatees when HKT’s are used in Haskell).

At this rate Haskell will likely implement dependent types before modular implicits are released for OCaml.

Ooo? They have an actual setup for dependent types coming out? I’d actually like to read on that a bit. I’ve tried implementing dependent typing a few times in languages I’ve made but all the corner cases start driving me crazy and idris is not quite mentally parseable… ^.^;

Overall though, I still prefer languages that are slow on taking in features when the features are well designed. Take C++, I waited 12 years for C++11 to come out just to give me something as trivial as auto, even though I could 90% of the way there with template magic and certain design patterns, auto was just so trivial for the compiler as it already had that information, but it still took 12 years to get it. OCaml seems like it moves very fast to me compared to what I’m used to. ^.^;

[gonz]

Ooo? They have an actual setup for dependent types coming out? I’d actually like to read on that a bit. I’ve tried implementing dependent typing a few times in languages I’ve made but all the corner cases start driving me crazy and idris is not quite mentally parseable… ^.^;

There’s been a lot of progress and from the latest status update I think Richard Eisenberg said that he’s hopeful for actual dependent types in GHC in 2019, but there’s no telling if I’m up to date on that at all.

You can do the basics right now, essentially:

https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell

http://www.parsonsmatt.org/2017/04/26/basic_type_level_programming_in_haskell.html

Overall though, I still prefer languages that are slow on taking in features when the features are well designed. Take C++, I waited 12 years for C++11 to come out just to give me something as trivial as auto , even though I could 90% of the way there with template magic and certain design patterns, auto was just so trivial for the compiler as it already had that information, but it still took 12 years to get it. OCaml seems like it moves very fast to me compared to what I’m used to. ^.^;

Yeah, fair point. Everything is relative.

[xnukernpoll]

It’s a matter of where the complexity is placed.

In the case of Elixir the language itself and the tooling is dead simple, but the runtime and ecosystem of BEAM is very complex, and there’s a lot of compile time complexity.

Ocaml has a very small runtime and is dead easy to parse, In terms of code reusability if you abuse the sh*t out of functors even though it’s not all that great appearance wise and adds a lot of complexity compared to say type classes to the application developer, MLI files make code reviews and documentation easy.

As for it’s concurrency story, honestly its story there shouldn’t be compared to Python, like Lwt + libevent or uwt is actually more performant than NodeJS, and nobody talks about Node’s GIL.

I’m going to use the aformentioned excuses that the the Python people do but honestly I just find it hypocritical because nobody says this about Node.

Honestly the main case where Ocaml is actually as bad as people think in a multicore world, is like when you have a shared state bottleneck where you’re using a mutex and there are a lot of writes that actually take a long time to do, and Node is in the same boat.

If we’re talking C10K it’s on par with node and when it comes to data parallel stuff, using fork it’s comparable to Go.

Don’t even get me started on how great Mirage is in a parallel world, since like you’re just spawning a bajillion tiny unikernels that only use the resources it needs.

is just a PITA because you are constantly reinventing the wheel and like there isn’t a lot of documentation in the cooler projects, like you’re expected to just mess around with it and read the MLI files and maybe send a message on the forum or email the maintainer.

Multicore is usab
TL;DR: Elixir is simpler le now for the most part apart from a handful of backwards compatability bugs, that have improved rapidly, like the only thing that holds back widespread use is lack of documentation, the fact that it’s targeted towards people who know how to and really want to implement schedulers.

Modular Implicits can be used it just hasn’t been integrated as part of the main version of the language, mostly because the community is like screw that I’ll just use ppx rewriters for the time saving parts, or I’ll use the record system, or first class modules to imitate x aspect of typeclasses I want, and honestly prefer the modularity over the conveniences of type classes.

Ocaml’s problem isn’t a lack of performance or language features, the community is dominated by less than a 100 systems hackers or compiler nerds, who don’t mind reinventing the wheel, its weakness is the lack of empathy to normal application programmers who don’t want to read a lot of code they aren’t writing, contribute to a handful of open source projects, and have their GitHub full of tiny libraries that maybe 10 people use, and implement a truckload of common algorithms .

Erlang has a similar story but like it makes things so very easy to build cool shit.

[tty]

In Erlang’s defense it has tons of libraries for stuff a telco programmer cares about. Megaco for telephony, ASN.1 for weird protocols, httpd/httpc for simplistic webby interface, diameter authentication, SNMP management all built in.

We just happen to muck around in a very different space.

[mmport80]

Back at the point:

1. Haskell is actually super simple. The basics are just sugared typed lambda calculus (actually sequent calculus, but, one of those things I haven’t looked into yet)

2. The simplicity, leads to rigorousness, leads to ppl being able to do v complex things with solid foundations

So at some level you can choose your poison in Haskell. No need to jump into the deep end.

Elixir to me can be incredibly complex, when types aren’t checked possible and something very deep in the stack errors.

Where Elixir wins against Haskell is the culture. Great tooling & libs, and a big early focus on the web also…

[namelos]

Java is not expressive as Ruby at all, while Haskell is one of the most expressive language.

Haskell is not complex at all. It’s just having some initial barrier. Fundamentally it’s simpler than most of the languages.
Once you know how to deal with monad (don’t even need to understand it well), you can write a lot of useful things just like other functional programming languages.
Once you know more about typeclass and monad transformer, you can write beautiful programs.
As for Template etc, it’s not a hard requirement for programming language. And referential transparency makes the need for macro lesser. (Think about the if macro in Elixir tutorial, in Haskell it could be actually implement as a function due to it’s lazy nature)

The great thing of Elixir is not only based on the language itself, but also the platform (Erlang/OTP), great tooling etc.

Compared to Haskell, Erlang/OTP makes Elixir a more practical language. There are some projects like Cloud Haskell could be an alternative to Erlang/OTP in the future, but it’s far less mature right now.

Compared to Erlang itself, Elixir tooling and documentation is far easy to learn and use.

[OvermindDL1]

I’m going to use the aformentioned excuses that the the Python people do but honestly I just find it hypocritical because nobody says this about Node.

Oh absolutely, node as well, OCaml has no JIT, it compiles to machine code so given two languages with a GIL it should on average be faster for equivalent quality code. I still can’t wait for Multicore OCaml with no GIL to finally be merged in (piece by piece it is coming in… slowly…).

Honestly the main case where Ocaml is actually as bad as people think in a multicore world, is like when you have a shared state bottleneck where you’re using a mutex and there are a lot of writes that actually take a long time to do, and Node is in the same boat.

Yep, OCaml, NodeJS, Python, Crystal, Ruby, etc… etc… All of them you can fork out more processes of course, but a singular process will only be one executable thread at a time (with many possible I/O threads of course).

Don’t even get me started on how great Mirage is in a parallel world, since like you’re just spawning a bajillion tiny unikernels that only use the resources it needs.

Heh, Mirage looks awesome, I’ve still yet to touch it but it always looks so enticing when I run across it. MirageOS is a microkernel made mostly in and made to run OCaml in a massively parallel way, whether directly on bare metal, a hypervisor, whatever. Think Nerves for the BEAM, but for OCaml, and even more low level and faster from my understanding.

Modular Implicits can be used it just hasn’t been integrated as part of the main version of the language, mostly because the community is like fuck that I’ll just use ppx rewriters for the time saving parts, or I’ll use the record system, or first class modules to imitate x aspect of typeclasses I want, and honestly prefer the modularity over the conveniences of type classes.

Heh, there are quite a number of PPX’s that have basically become ‘Standards’ for projects nowadays I’ve been noticing… ^.^;

In Erlang’s defense it has tons of libraries for stuff a telco programmer cares about. Megaco for telephony, ASN.1 for weird protocols, httpd/httpc for simplistic webby interface, diameter authentication, SNMP management all built in.

I’ve used so many of those weird protocols too! Using ASN.1 was a slight bit of a pain in Mix, had to write my own mix compiler to just call into erlang’s compiler even though erlang can already do it but mix’s erlang plugin ignores those definition files… >.<

Haskell is actually super simple. The basics are just sugared typed lambda calculus (actually sequent calculus, but, one of those things I haven’t looked into yet)

Eh not really. Like take just one of its ‘base’ features, HKT’s, those are way complicated to compile and even more amazingly complex to do efficiently (which Haskell does not). Haskell is a very non-simple language, from choosing rather inefficient FP constructs as defaults (HKT’s, lazy-first, etc…) to horrible syntactical choices like significant whitespace… >.>

And then you get into ‘fun’ stuff like the GHC compiler extensions that about every Haskell program uses with impunity nowadays, some of which are not quite ‘type safe’.

Elixir to me can be incredibly complex, when types aren’t checked possible and something very deep in the stack errors.

Yeah I agree here, types in a language make debugging SO much easier. Debugging in Elixir can be an absolute royal pain at times, debuggers and tracing or not.

while Haskell is one of the most expressive language.

If it were then you wouldn’t require non-standard GHC language extensions to be able to do some types of work (of which, as an example, OCaml does not need).

Haskell is not complex at all. It’s just having some initial barrier. Fundamentally it’s simpler than most of the languages.

Harder to Parse, harder to implement, harder to reuse code because of significant whitespace, lack of built-in code extensions ala OCaml Functors, etc… etc… etc… Doesn’t really seem ‘not complex’?

Once you know how to deal with monad (don’t even need to understand it well), you can write a lot of useful things just like other functional programming languages.

Monads aren’t just a haskell thing, they are a concept that ‘most’ languages anymore use with impunity, even if they don’t call them that.

(Think about the if macro in Elixir tutorial, in Haskell it could be actually implement as a function due to it’s lazy nature)

Except depending on what the type of what you pass in is then sometimes it wouldn’t be lazy, and you wouldn’t be able to tell at the function definition site (without using compiler extensions).

[mmport80]

mmport80:

Haskell is actually super simple. The basics are just sugared typed lambda calculus (actually sequent calculus, but, one of those things I haven’t looked into yet)

Eh not really. Like take just one of its ‘base’ features, HKT’s, those are way complicated to compile and even more amazingly complex to do efficiently (which Haskell does not). Haskell is a very non-simple language, from choosing rather inefficient FP constructs as defaults (HKT’s, lazy-first, etc…) to horrible syntactical choices like significant whitespace… >.>

And then you get into ‘fun’ stuff like the GHC compiler extensions that about every Haskell program uses with impunity nowadays, some of which are not quite ‘type safe’.

All valid points.

There is definitely a niche market for some enterprising Jose-Valim-type to clean Haskell up a lot, and make it look like Ruby

The big picture remains. There are pitfalls, but it’s not the crazy beast ppl make it out to be

[dogweather]

It’s a matter of where the complexity is placed.

In the case of Elixir the language itself and the tooling is dead simple, but the runtime and ecosystem of BEAM is very complex, and there’s a lot of compile time complexity.

Which is perfect, IMO. As an end user (a polyglot app developer) I have no concept of the BEAM’s complexity and I don’t need to.

Cf. Haskell, Ruby, and git, which all but require a firm knowledge of the implementation details. For me, that’s important evidence of poor or unfinished design.

[dogweather]

Haskell is actually super simple. The basics are just sugared typed lambda calculus

If only the basics were sufficient, I’d agree with you.

IMO, Practical Haskell is a morass of hacks and implementation leaks. Consider just a simple function invocation:

m n o p q

That syntax, which doesn’t differentiate between the function and the operands, is not a product of top-down design, but rather bottom-up implementation leakage. (The language being based on simple curried functions.)

Coding in Haskell often feels like JVM Bytecode - a syntax defined according to the needs of the underlying machine.

But my needs are different than the machine’s. I think at a higher level of abstraction. No files, relative paths, etc. Instead - interfaces, abstractions, classes, and objects (if OO). Smalltalk got this.

[jswny]

Funny that’s how I felt about Rust when I tried learning it this year! I enjoyed some initial experimentation after reading a good amount but when I started poking around pull requests, issues, RFCs and community posts, I got so confused and frankly intimidated by how much I couldn’t understand that I decided to drop it.

Elixir really is amazing in this way. It doesn’t take long to learn because the core of the language is just so simple. Yes there are a few small warts which take some learning but the language design itself is so easy to wrap your head around. Looking over the issues and pull requests on the Elixir GitHub, I can understand everything, and that is a powerful, and rewarding feeling. One that I think is undervalued in today’s world of many languages.

[dogweather]

I’m completely with you. I have the same experience with the Haskell subreddit, r/haskell. I can’t understand most posts - they’re meaningless to me. Yet I’ve been writing apps with Haskell for years.

[mmport80]

But that’s what I love about it…

Arguments and functions are somehow fungible.

Larger abstractions (e.g. Elixir behaviours) are just records with lambdas…

Etc. etc.

Maybe there’s a better balance to strike though.

[OvermindDL1]

That syntax, which doesn’t differentiate between the function and the operands, is not a product of top-down design, but rather bottom-up implementation leakage. (The language being based on simple curried functions.)

Sure it differentiates it fine, the first token is the function, the rest are the arguments, that is not implementation leakage but rather just getting rid of superfluous things like commas that are just noise in ‘getting work done’, a lot of languages use this pattern of function calls, including ones without automatic currying.

Coding in Haskell often feels like JVM Bytecode - a syntax defined according to the needs of the underlying machine.

Eh, not really, more I’d say it feels like it wraps the type system in most case, which is a bit of a mixture of sometimes conflicting ideas (hence why I prefer OCaml’s type system).

Instead - interfaces, abstractions, classes, and objects (if OO).

Interfaces/abstractions is something haskell does quite well (though not really in my preferred way). Classes/Objects from the traditional OOP world (not true OOP as it was originally defined, though smalltalk does this better than most) is useful in some cases, but it is also way WAY overused in places where it is just not suited, and that is when you start running into conceptual-hell (unable to follow the code flow because of how the poorly designed abstractions confuse which path code can take through the object calls) and the thousand-paper-cuts-of-death (OOP style abstractions are hell to optimize so you end up doing a lot of indirect function calls on the machine, which is death for performance-sensitive programs that overuse virtual calls).

Larger abstractions (e.g. Elixir behaviours) are just records with lambdas…

Actually BEAM Behaviours are more like typed module interfaces. These worked really well with tuple calls that were removed just recently. It’s a great common OCaml idiom that is trivially optimizable but utterly fantastic at abstractions (unlike OOP abstractions).

[pera]

Sorry but I couldn’t disagree more with this comment: there are few languages less “hacky” and with fewer leaky abstractions than Haskell. Syntax-wise the ML-family of PLs is hard to beat as their designers reached a global optima when considering minimalism and usability. Just take a look at the BNF definition of Haskell 98 and compare it to any other language

Of course, all these conversations are mostly based on personal opinions… but I don’t think your example provides a well-founded criticism against Haskell, at least from a language design perspective: when Milner designed ML in the mid 70’s he wanted for various good reasons, to have both the lambda calculus notation for function application and also infix notation for standard algebraic expressions / boolean relations. This was a deliberated decision that worked fantastically well. Then, to allow extensibility, its descendants included ways to define your own infix functions, and in the case of Haskell with some constrains for which characters are allowed in their names. Back to your example, if o was an operator it would be for instance something like +, or &&& for an user-defined one, making the operands quite evident. There is no need to add any additional tokens into the grammar rules.

[xnukernpoll]

My favorite saying about Ocaml (applies to any ML really) is Ocaml is the velvet underground of programming languages there weren’t a lot of fans, but all of them went on to create their own PL.

[dogweather]

there are few languages less “hacky” and with fewer leaky abstractions than Haskell.

After spending hours reviewing the 10-15 conflicting ways of error/exception handling, I’m now rewriting half the functions in my application because there’s no abstraction for this. And now I’ll have half my app in “Monadic Either”, half not, and a few scattered functions non-Monadic either because they’re consumers of partially applied monadic functions.

I’ve got as many examples of implementation leakage as the day is long.

---

Bonus annoying implementation leak: When writing HSpec tests and refactoring, moving them around, the syntax changes depending on whether there is one test in a section, or more than one. (A do is present or not.) Straight up implementation-based hack here.