Hacker News new | past | comments | ask | show | jobs | submit login

You're right, my comment was needlessly harsh and I apologize for that. You didn't deserve that and it was rude of me.

The subject of Elm often gets me riled up because there's so much good about it mixed with what to me is a greater portion of frustration. I strongly disagree with how the language is managed, with the closed nature of its development, but mostly with what looks like the constant dismissal of any concerns about any of these issues any time they're brought up. By far, the most common response feels something like "everything is fine and your opinions are baseless."

There are people I know who, like me, have tried to convince employers to even consider Elm and have been shot down because, in management's words, "there doesn't seem to be any idea where the language is going", or its "too unsafe, its all dependent on one guy" or "looks like its dead now anyway, no releases in over a year and apparently it sucks at basic things like dealing with json". And yeah, some of those things, like the json nonsense, shouldn't be showstoppers. But not having an idea of what the roadmap or timeline looks like is a big deal. No releases in a year is a big deal. So then you bring that up on the elm forums or the slack, and you end up getting blasted there too because now you're seen as criticizing this thing that everyone loves.

Obviously I'm just a jackass on the internet with more mouth than brains and I wouldn't hold your breath waiting for me to ever make anything as interesting or yes, successful, as Elm is right now. I appreciate the work you've put into making Elm as good as it is.

It's all good. :)

> what looks like the constant dismissal of any concerns about any of these issues any time they're brought up.

I remember earnest (and exhausting) discussions of these topics from back in like 2014, when it was unclear what the best way to scale Elm's development would be. We tried different approaches, but the outcomes weren't great.

We're actually still experimenting with this. For example, Evan wanted to put a community member in charge of the debugger, so he did...about a year ago. That experiment hasn't been fruitful (the debugger has not had a substantial release in that period), so we're trying handing it off to someone else. We'll see if that works better based on what we've learned from the previous attempt.

It's easy to say someone else should have taken it over sooner, but at the time there wasn't anyone else who understood the internals well enough to manage it, while also being interested in taking it over. Now there is.

Relatedly, I get that some bosses want to see a higher bus number on the compiler, but functioning teams of compiler authors don't just drop out of the sky. It's a rare specialization, and even among the few people who have the training to do major work on a compiler like Elm's, most are academically oriented and didn't go through a pH.D program so they could performance optimize Haskell code, make nice error messages even nicer, or find ways to remove language features rather than adding that cool new one they read about in a paper.

There's also communication. Evan used to give lots of updates about his progress on upcoming releases, and the main effect was to delay the release. He'd announce some progress and it would instantaneously become a Q&A - at best. Often people would pressure him to give up on whatever the latest impediment was and ship something sooner. If he didn't respond to those responses to his progress update, people would complain that he was unresponsive. So doing public updates strictly increased complaint volume, which of course also takes a toll on Evan, being a human and all.

> But not having an idea of what the roadmap or timeline looks like is a big deal.

The two options here are:

1) Be honest

2) Try to trick bosses

There isn't a world where Elm stakes out a roadmap and a release timeline and then hits it. Elm is trying to do a bunch of things differently than how they've been done before, which means each release is in some ways experimental, and also that each release changes substantially based on lessons learned from the previous release.

So yeah, it'd be possible to make up a bunch of "oh yeah, Feature A is gonna come out in April, and then B will land in July" but anyone could look back a year or two later and realize that the stated roadmap had barely any relationship to what actually happened. (People would complain about that too - that Evan wasn't sticking to the roadmap he'd laid out.)

We know from past releases that this is how it's gone (in my hubris, I told my editor at Manning I predicted Elm 0.19 would be out last summer) so there's no way to publish an official roadmap without knowingly misleading people.

If anyone considers it a red flag that there's no official timeline, well - that's because such a timeline wouldn't mean anything anyway. Evan's approach is to be open and honest about this. [0]

This is how we've ended up with a community of people who largely don't think it's a big deal: process of elimination. Everyone who considered it a deal breaker is still using JavaScript.

I don't know how helpful that all is, but maybe it sheds some light on the history of some of these things. :)

[0] https://github.com/elm-lang/projects/blob/master/roadmap.md

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact