Hacker News Reader

Comment by dmix | Hacker News Reader

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.

View on HN

I agree. You master monads and IO, but then you want to use a web framework and there a bunch of other category theoretical concepts and/or Haskell advanced features you need to understand to serve up "Hello World". Compare that to expressjs. I love functional programming, but given the free choice of what to use to knock up a side project, I chose JS at home. Nothing like grabbing some data from a server, and it being an object you can use immediately in your code and access using indexers, properties etc (rather than some strange lens operator like ~~!!#).

Typescript cures most of the JS ills. Sure TS is more akin to Java/C# and not the much better Haskell type system. But it is good enough and catches 99% of the real world problems of naked JS.

To me Haskell is training for your brain. Once trained you are a better JS/C#/Java/C++ programmer.

I could go on about the economics of getting a Haskell job:. Haskell and Elm developers are taking a paycut compared to what they would earn if they used any language. Even if they are paid well they could get paid more. Supply/demand at work there.

How far can you go without monads and category theory? I was looking at Clean which developed in parallel with Haskell and uses uniqueness typing instead of IO/mutation monads. Seems like it would be less offputting for a newcomer. Clean lacks community and a package manager, I believe which makes it less attractive. The language itself seems like a sweet spot for me.

Not used Clean, but it sounds interesting.

What i'd love is an imperative language where you declare what effects a method can have and the compiler enforces them. E.g. if it promises not to mutate any parameters, it can only call functions that make the same promise etc.

That sounds very similar to Rust. Mutations and even memory lifetime are specified in the type system.

This is how Pony does it, basically. See [Reference Capabilities](https://tutorial.ponylang.io/reference-capabilities.html).

Idris isn't imperative (Haskell-like with dependent types), but offers features like those:

http://docs.idris-lang.org/en/latest/effects/depeff.html

    readInt : Eff Bool [STATE (Vect n Int), STDIO]
                       [STATE (Vect (S n) Int), STDIO]

http://docs.idris-lang.org/en/latest/st/machines.html

    logout : (store : Var) -> ST m () [store ::: Store LoggedIn :-> Store LoggedOut]

They're both implemented within Idris, as libraries/modules, rather than being compiler magic:

- https://github.com/idris-lang/Idris-dev/blob/master/libs/con...

- https://github.com/idris-lang/Idris-dev/blob/master/libs/eff...

I think it'd be possible to write similar effect systems in other dependently typed languages like ATS, which is a relatively imperative language (C+ML-like).

If you want to be productive in Haskell, the Monad typeclass is an important tool to familiarize yourself with. That said, unless you are working on the internals of a few libraries, you don't really ever need to know serious category theory in order to be very productive. If you don't already have a background in abstract algebra or category theory, I think a better approach to learning these abstractions is slowly work through the typeclassopedia[0] while solving problems the naive or clunky way and then start to use the fancy-name abstractions (e.g. Functor, Applicative) as you see how they could be useful.

On that front, the Monad typeclass is far more general and useful than just for IO and State, so if you are thinking of it as primarily a hack to deal with those, you probably won't get the hype. In addition, it's really useful to work with a large number of examples of different Monad instances (IO, State, Maybe, List, STM[1] if want to get a bit further into the deep end) instead of just staring at the methods in the typeclass and hoping it make sense. It's a pretty broad abstraction, so it will only make sense if you are familiar with what it's abstracting.

[0] https://wiki.haskell.org/Typeclassopedia

[1] http://book.realworldhaskell.org/read/software-transactional...

Thanks for this info. What I really want to know is the value prop for learning/using monads etc. The examples of IO, State, Maybe, List, STM given seem like they'd be dealt with just fine in Clean.

I think it's important to be precise about how the monad abstraction and type system features interact in order to combine pure and impure code. I wrote a comment elsewhere in the thread (https://news.ycombinator.com/item?id=20112333) where I conclude that while the monad abstraction is useful for making a usable interface and writing programs which are agnostic to how their state is implemented, the fundamental work of distinguishing pure and impure computations is accomplished with a combination of type system features and compiler magic.

The case is exactly the same for the Clean language as for Haskell and indeed Clean has Monad instances for all of the types I mentioned aside from STM, so there are no concerns with dealing with those monadic abstractions in Clean. (https://imgur.com/a/sjsDiZq, https://cloogle.org/#using%20Monad) Since IO is Haskell's type that marks impure computations, we can compare Haskell's implementation to the equivalent one in Clean (interface: https://cloogle.org/src/#Platform/System/IO;line=10, implementation: https://cloogle.org/src/#Platform/System/IO;icl)

In Clean, IO is implemented as follows:

    :: IO a = IO .(*World -> *(a, !*World))

In Haskell, it is:

    newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))

(for full context see: http://hackage.haskell.org/package/ghc-prim-0.5.3/docs/src/G..., the related monad instance is here: http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GH...)

These both implement IO as a function which takes the state of the world as its input and returns a new state of the world as it's output. This is encoded using the state transformation that I mention in the other post (https://acm.wustl.edu/functional/state-monad.php) Both implementations also go on to define Monad instances for their new IO type. The major difference is that the Haskell standard library only exposes bindIO and returnIO to the user and hides the internals of IO from the user and Clean allows the implementation to be a normal library.

That difference is Clean's uniqueness types showing their strength. Clean can explicitly expose it's predefined World type (https://cloogle.org/doc/#CleanRep.2.2_6.htm;jump=_Toc3117980...) to the user with the guarantee that you can't write a function of type IO a -> a because it would violate the uniqueness properties and thus be a compilation error. Haskell instead uses the module system to keep State# RealWorld from being exposed to the user. This means that if you as a user want a different set of abstractions for impurity in Clean, you can build from the World level rather than needing to construct it out of what can be done with bindIO and returnIO. For details on what's going on with State# see https://www.fpcomplete.com/blog/2015/02/primitive-haskell

From the perspective of "the value prop for learning/using monads", this discussion leaves us in a worse place than where we started because the conclusion is that uniqueness types aren't a get out of monads free card and that Clean uses the many of the same Monad-related abstractions as Haskell does and uses them for the same purposes. In order to not leave you out in the cold as to the value prop for the monad abstraction, you can see how it works for a number of different Monad instances in Tikhon's answer on Quora (https://www.quora.com/What-are-monads-in-functional-programm...), though he chooses to use join, fmap, and return as the fundamental parts of a Monad, rather than bind and return, as I have here. As he touches on in his discussion, it's common and straightforward to implement one definition in terms of the other, so anything you learn from about that definition can be ported the definition I use without much fuss, so don't worry if it doesn't match at first. What this means is that if you have a tools in the standard library that only depend on features of Monad, you can use the same small collection of functions to solve a ton of problems.

This is want I needed to hear. I haven't used either Clean nor Haskell other than playing with them and my introduction to Clean seemed more lightweight where there some syntax to make uniqueness seem easier than the same in Haskell. On further reading, when seeing the u:[...] syntax rather than * I can see they're really quite the same. They way the uniqueness attributes are described seems like a separate axis than data types where in Haskell there's just so much type. Also the docs for Clean avoids using category theory terms for the most part, getting you started by showing you the syntax to do certain things.

I expect to be coming back to this comment and the references quite a few times until it clicks for me.

Finally think I get monads. And I don't believe it's hard to explain or hard to understand just that almost all the explanations are bad and you have to go through so many of them to put the pieces together.

The other partial reason for not wanting to know is that I can't then unknow. Willfull ignorance it is. Can those who know say they're happy using languages on the daily without the features you miss and think in?

> How far can you go without monads and category theory?

Without monads? Not pretty far, but they're far simpler than the wide web would have you believe.

Without category theory? Sky's the limit. I say this as experienced Haskell programmer occasionally dabbling in category theory for funsies. The practical impact on "how easy is it to program Haskell" of category theory is basically zero.

I didn't mean how far in Haskell without monads. I meant how far in something else like Clean that uses uniqueness typing to handle some of the same aspects where monads would be used with Haskell.

> I agree. You master monads and IO, but then you want to use a web framework and there a bunch of other category theoretical concepts and/or Haskell advanced features you need to understand to serve up "Hello World". Compare that to expressjs.

I started using haskell at my last job after having done a couple years of functional programming in scala, but I honestly never found it required that much knowledge of category theory. The FAM trio of classes (functor, applicative, monad) are the most common ideas used from category theory in an explicit way, and they're frankly so prevalent at this point in the industry at large that they're in basically every language in extremely common libraries. Most programmers are pretty familiar w/ map and bind (which is also sometimes called flatMap, then, and_then, or chain). Applicative functors might be a little more exotic, but they're easy to pick up if you understand the other two. And I don't think you really need to understand what a morphism is or how to read arrow diagrams to really use any of these things. If you can use arrays in javascript, you can use the IO monad.

Most of the challenge in haskell for me was figuring out stuff like how I should structure my code to enable mocking out effects for testing (there's multiple answers to this w/ different tradeoffs), or how to get good editor support without ghc-mod breaking. I haven't used haskell in industry in about the past two years, but I imagine these are still some of the biggest challenges w/ using it.

+1 everything you said.

Do you think it would be dramatically improved if Haskell had a bigger community of people contributing user-friendly libraries and tutorials? That was something that made Ruby the perfect newbie language for me. And something I feel is downplayed in Haskell given it's more advanced user base who is a little too obsessed with it's power and demonstrating their knowledge as such, rather than help make it accessible to others.

I can't count the amount of times I came across a popular Haskell library with very little documentation rather than it's type/function API and general blurb about what it does. This is very different that most popular JS/Ruby/Python/etc libraries which include quick-start/getting started/usage examples/etc etc.

Ergonomics is probably the number one thing that matters on the long run for computer languages.

Make the frequent things easy and safe. And this means syntax should be easy to read and write, documentation should be plentiful and easy to read, easy to start using, even if you are not expert in the area that that particular library covers, etc.

Rust also suffers a bit from this, as more and more libraries are just the generated docs. Here are these 30 structs and 100 impls, godspeed. Yeah, but what is this library, when I would use it? What's the most 100 common use cases?

And a 100 might seem like a lot, but people will chose that instantly works for them. And there are a lot of strange stacks out there. Sometimes people just want the low-level bits of your library. No docs/API for that? Damn. Sometimes people just want to use it as a one-liner, no config files, no import-server-deploy, no binary? Damn.

The more flexible a language is, the more documentation its libraries need.

One often-ignored benefit of constrained languages like Java where there's really only one way to do most things, is that when you get a library you immediately have a reasonable idea of how to use it (given the entity names and types). If a language has a more advanced type system (or none at all), you can't lean on that existing framework and the author needs to do more legwork to explicitly lay out exactly what it is they've made. This doesn't make more advanced languages bad, but library documentation is often neglected and that probably contributes a lot to the inaccessibility of those ecosystems.

> Do you think it would be dramatically improved if Haskell had a bigger community of people contributing user-friendly libraries and tutorials? That was something that made Ruby the perfect newbie language for me. And something I feel is downplayed in Haskell given it's more advanced user base who is a little too obsessed with it's power and demonstrating their knowledge as such, rather than help make it accessible to others.

Absolutely. I think it's been getting better at that on the tutorial front. For a long time there were very few books I'd actually recommend for haskell, but Haskell Programming from First Principles [1] changed that for me (personally). And I think Stephen Diehl's excellent What I Wish I Knew When Learning Haskell [2] is a fantastic general resource for newbies. But I think the community could stand to have more of this, absolutely.

And I definitely agree about libraries. I'd like to see more haskell libraries with extended tutorials, and written w/ a non-expert audience in mind. I think the community has for so long been dominated by long-time haskell developers and people ensconced in functional programming, much of the documentation is written for those kinds of people.

[1]: http://haskellbook.com/

[2]: http://dev.stephendiehl.com/hask/

Over time, I don't think the amount of stuff you have to learn in Haskell is more than in other major languages. Haskell requires that you learn some math, and that math had some large humps to get over. But it's a small number and you're actually just learning math, which is general and useful outside of one language.

In C++, I had to learn a bunch of corner cases and committee decisions. In Java it's a huge library and stack of idioms to get anything done. In both cases, that information didn't make me any better a programmer in the general sense, just a disappointed one in each language. I'd argue that the sum amount of information I had to learn for either of those languages was more than Haskell, because I can leverage the abstractions much more, and only need a few of them.

Monads, applicative functors, lenses, and you've got your primary toolbox sorted out. That's three humps. C++ has few humps, but it's got miles of an uphill march. I have no polite way to describe the Java experience.

The Java experience is a vast vista of beautiful sci-fi-ish landscape, elegant industry laid out according to a master design. Big enterprises linked with glowing pipes and service buses, nice portals pulsating from the radiance of alien beans. Stylish OSGi towers reach to the sky in the background. And the Mavens offer everything that is good on the mvn-central plaza.

But as you get closer, as you try to set up your own factory, you find that you need to use that thing, that nobody uses anymore, from the dark side of the moon, and to interface with that you need to venture deep into the core, and it's factories all the way down. Layers and layers of boilerplate, and inventors screaming in horror at the banality of the gaping holes in the type system that holds the huge sphere of backward compatibility on its shoulders.

And then there's no way back. You are already versed in the dark arts, you have been to the MetaSpace, your heart is no longer yours, but it's a slightly patched G1GC and you dream with the lush murmur of cybernetic trees from Shenandoah.

The problem with that explanation is that Haskell is no more difficult than Rust. (Someone who knows Rust well must learn about the IO monad and then can start being productive in Haskell. Unlike what one comment on this page implies, there is no need to learn any category theory to be productive in Haskell.) Yet Rust has been used in about as many successful projects as Haskell despite Haskell's having a head start of about 30 years on Rust.

I agree Rust is similarily difficult to learn to the point of production real-life software people use (rather than toys). But it's still very much in early-adopter territory. Even today on HN was the first stable version of a web framework that seems to be the best of the pack in Rust.

Haskell has been around for 29 years. It's really not a fair comparison.

I never said you have to learn category theory or any math with Haskell either. My learning curves I mentioned were strictly practical (mutation/effects, state, lenses, more than basic types etc).

The quality and quantity of books, tutorials, community, libraries, etc plays a big role in any languages learning curve no doubt. I believe this is something that could still be greatly improved in Haskell.

But at the same time I don't think it's surprising that Rust was able to get those all up to Haskell's level of quality in a short time. Rust also has far more analogies and similarities to what most C/C++/Go/Python/Ruby users have been exposed to which makes the initial get-a-basic-script-working far easier.

So I'm not dismissing Haskell like it's destined to unpopularity just because it's hard. The larger investment in docs, websites, libraries, and similar languages like PureScript/Elm the more popular Haskell would be.

Rust had a bunch of smart marketing-friendly people join in over the last couple of years which took it from a niche systems language into something far more mainstream. Other successful languages had similar growth patterns early on while Haskell people were comfortable with it's fringe academic position for a long period (which it seems to have grown out of finally). Haskell could still achieve a similar trajectory but adoption by early-adopter non-academic developers will be critical for that growth. Even if that must include the trendy Ruby/JS they tend to look down upon that group knows how to sell a language to the public and make it practical.

You seem like someone who could answer this: why use PureScript over Elm?

Honestly I've never fully given Elm enough of a run-through to say yet (ditto with OCaml). I remember 2yrs ago I was evaluating it but decided to learn React/Vue.js for professional reasons. Additionally I wasn't convinced that Elm would be an ideal long-term commitment and more of a compromise between JS, FP, FRP (functional reactive programming) and more of a framework competitor than a full-blown language.

While I see PureScript as a full long-term language-level commitment to Haskell style FP minus the purity. But again my exposure to it has been too limited to have a strong opinion.

ReasonML is a much more reasonable (pun intended) approach to FP from the front-end side that doesn't appear to be as dogmatic as Elm. By making some concessions over interoperability (namely supporting raw JS and npm libraries), Reason thinks it will be easier to win existing JS devs over. Check it out - https://reasonml.github.io/

Despite being functional, Elm is quite minimalist when it comes to type system features. For example, functions can have generic type parameters, but there's no good way to require that the type be able to support certain operations, e.g. being printable as a string. Haskell's solution to this is "typeclasses", which are the same thing as Rust "traits" and Swift "protocols", and somewhat similar to Java "interfaces". Elm has a handful of builtin typeclass-like things that work by compiler magic, but there's no way to define your own. For a somewhat colorful rant about this, see "Elm Is Wrong":

https://reasonablypolymorphic.com/blog/elm-is-wrong/

Elm is also very opinionated, e.g. the compiler itself restricted the ability to bind to JavaScript libraries to only approved organizations:

https://discourse.elm-lang.org/t/native-code-in-0-19/826

The community is also fairly toxic; check out this passive-aggressive response by the /r/elm moderators to a (mildly worded) blog post complaining about the aforementioned restriction:

https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_u...

Personally, I decided I would never touch Elm again after reading that.

I'm currently using Elm at my day job, and I agree 100% with what you are saying.

Elm lacks extensibility, tooling, and documentation is not that great. The biggest pain point however is the people who run the Elm language. The design decisions they took hurt the language and the users a lot, breaking more and more with every version bump, restricting freedom and creating a walled garden that people are getting tired of.

What you say about JavaScript libraries is not 100% technically correct though. You can still access any native JS library you like, but you got to use ports. You can't hook into native elm functions bound to the global scope, but that's always been a very shady, undocumented and terrible thing to do.

The following reasons are what, I believe, really ruined elm adoption:

1) You can't create so called effect modules (like the http module of the standard library, and so on) if your package is not within the `elm` namespace.

2) As a company, you can't have shared, common elm modules if they are not published in the Elm package public registry. You can't install a package from GitHub without resorting to ugly hacks like ostracized elm package managers written in Ruby.

3) No development timelines, no companies publicly endorsing or using Elm to develop open source libraries besides the one where the language founder is employed.

I've never tried anything purely functional and typed to do frontend programming, so I'd like to hear if Purescript, ReasonML, etc share the same struggles with Elm

Always liked this post on Elm in production: https://www.pivotaltracker.com/blog/Elm-pivotal-tracker

I've worked in Elm a decent bit, and used PureScript a little.

Elm is a very opinionated language - it's very deliberately missing some abstraction power (typeclasses), and some functions that are the bread-and-butter of every functional programmer have steadily been getting removed from the base libraries, so if you're used to Haskell, you'll find yourself falling back to duplicating code by hand a lot. Elm also makes certain stylistic choices into parse errors - "where" clauses are strictly forbidden, and indentation preferences are strictly enforced. It's basically taken an awkward edge-case from Haskell's indentation rules and made it not only a requirement, but a prerequisite to seeing if there are any other errors in your program. The back-and-forth trying to get the compiler to accept things that would just work in Haskell, but don't because of someone's stylistic preferences, is absolutely maddening.

PureScript, from the bit I've used it, is like a strict version of Haskell with row polymorphism, a feature Haskellers have been hoping for for a while. I've chosen Elm over PureScript in the past because of PureScript's dependency on Bower (which I think has changed since then), but that's the only reason.

While there was nothing particularly wrong with bower for PureScript use case, it's always failed to attract people for that reason sadly. However, you can use Spago now to great success.

> indentation preferences are strictly enforced. It's basically taken an awkward edge-case from Haskell's indentation rules and made it not only a requirement, but a prerequisite to seeing if there are any other errors in your program.

Some parsing is less efficient than Haskell because Elm doesn't have 20+ years of PhDs working on it, but there is no such thing as compiler-enforced formatting. I can't think of compiler errors regarding format that are the expression of a choice, as you put it, rather than the expression of less manpower.

Likewise, `where` clauses aren't forbidden, they are simply not implemented, which, given that you can already use `let.. in`, is not especially shocking.

The omission of where clauses was explicitly a stylistic choice[1].

This is perfectly valid Haskell:

    #!/usr/bin/env stack
    {- stack script --resolver lts-12.19 -}
    data Test = Test {count :: Int}
    
    test = let
      something = Test {
        count = 5
      }
      in 5+(count something)
    
    main = putStrLn $ show test

To get the equivalent Elm to compile, it must be indented like this:

    test = let
               something = {
                 count = 5
                 }
      in 5+(something.count)

Note that `something` must be indented beyond the beginning of `let`, and the closing curly brace must be indented to the same level as `count`. These are both not a warning, but a parse error - you can confirm it with Ellie[2]. If that were due to a lack of resources, it would absolutely be understandable, but this also was an explicit choice[3] which developer time was spent implementing.

[1] https://github.com/elm/compiler/issues/621

[2] https://ellie-app.com/5KRg4g5ZMkba1

[3] https://github.com/elm/compiler/issues/1573

PureScript has a (much) more advanced type system but that's about it. The tooling and general developer experience of Elm is probably as good as programming gets in 2019. (I've also quite enjoyed Rust.)

That may sound like hyperbole but the combination of elm-graphql and elm-ui is something else. I'm from a JS background and the whole React/TS/CSS-in-JS soup just seems like a bad dream now.

Elm is a language + a framework whereas Purescript is just a language.

There are a number of different frameworks you can use with Purescript from copies of the Elm architecture to wrappers over React to Halogen which can be thought of as a componentized Elm with multiple update loops. Halogen is awesome, really hits the sweet spot for me.

I wrote some Purescript and would definitely recommend anyone try it for themselves.

What eventually turned me off was tooling/workflow things like no accepted code formatter, poor graphql support, too many competing ways of doing basic tasks, too many libraries that were just JS wrappers.

Also I got a vibe from functionalprogramming.slack.com that there was more interest in the latest FP whitepaper than beginner friendliness and what the realities of making an app in Purescript are like. Which is fine, but will limit the adoption of the language in the face of Typescript (Microsoft) and ReasonML (Facebook).

It's funny, Elm gets criticised as a 'DSL for building SPAs', even though that's exactly what it is, and that focus is the reason it is so productive for that task, and has the smallest asset sizes of any front end solution.

And for all practical purposes, no runtime errors.

I think that's why I like it so much. There are lots of ways to do things. I don't think I am using any significant libraries that are JS wrappers. Halogen is written in pure Purescript. But the advantage of PS over Elm is that it is easier to wrap JS, hence the many options..

For sure its focus is not as a beginners language and it will never reach Typescript levels of popularity. But it has found it's niche, and it is in a good place.

Elm is a very nice language too.

> PureScript has a (much) more advanced type system but that's about it.

There's a lot in "... but that's about it.". Elm has a very low upper bound on abstraction by choice.

As an additional note: like many other communities in programming it has a very cult-like feeling to it and like others noted in these threads the mere mention that maybe this low upper bound on abstraction could be bad usually draws people a lot of fire.

In my experience most of the community in Elm is made up of people who don't really know what type classes can give you, for example, but they'll happily argue that it's too advanced or not needed. Most of that comes from parroting the popular in-community opinion instead of informing themselves.

This kind of inbred opinion is not unique to Elm: you can find it in Elixir, Clojure and pretty much every other community that relies too much on the benevolent dictator or the prominent founder/inventor paradigm.

In my opinion this is something that PureScript got right: Phil Freeman actually left the community to some extent and is not involved in the compiler anymore. He also does not flood the community with opinions that people give too much weight and so there is no cult of personality formed around him. The same cannot be said for the aforementioned languages.

I also find it interesting that a lot of these languages that rely on this paradigm have leaders that constantly complain that it's hard to run this kind of community. The reason it's so hard is because they've made themselves a benevolent dictator and they keep that status quo because presumably they like that they can sort of control opinion in the community that way as well.

I have absolutely zero sympathy for people who do that kind of thing because there is a very clear solution to it and they're just unwilling to commit to it. You can't have your cake and eat it too. If you enjoy this cult of personality you'll have to take the bad parts of it as well. I find it interesting that a lot of these people end up being babies about it as well, but I guess you have to be somewhat immature to end up in this position from the beginning.

I more or less agree with all of that, but at this stage Elm's BDFL has earned my trust, and he is well within his rights to do whatever he wants with his own creation.

Reply on news.ycombinator.com