Dan Luu
patreon
The "production ready" / "beta" duality
🕑 Added 2019-06-28 14:00:00 +0000 UTCI tried Elm and Rust out in 2013. They both seemed interesting in that they had conceptual models that promised to make programming easier. Elm was particularly compelling to me since its model wasn't too different from how I think about hardware design, which I'd done for almost a decade at that point.
Neither language was really ready at the time. Documentation was poor, the compiler was buggy, stable libraries were almost non-existent, etc. Both languages would go on to make major changes that fundamentally change the programming model, so I'm glad I didn't commit to either at the time.
Back then, Rust made it very clear that it wasn't even close to being ready for "real" use (if you read the official Rust tutorial, there was a huge warning at the top about how it was a feature-unstable work in progress), but Elm's marketing pitch was a lot slicker and there wasn't really any indication that the language was undergoing major overhauls and would have multiple fundamental conceptual changes coming in the future.
I recently looked at both languages again. Rust seems to be in a relatively stable state, and I even wrote some production code in it (my team is already maintaining some Rust, so this wasn't too out there).
On the other hand, Elm seems to be in a similar state as it was in 2013 in some ways. It's obviously much more mature, the error messages are better, the documentation is better, etc., but if you read people's comments on the last releases (0.19, 0.17, etc.) some were major breaking changes that cause some people to move away from Elm rather than update their apps. The response from a lot of the Elm community has been something like "well of course, it's pre-1.0, it's not production ready, that's not our fault, WTF were you thinking?", but if you go the Elm's front page, it brags about "no production runtime errors" and prominently displays "customers" who use Elm in production.
Curiously, if you look at the archive.org from 2 years ago, 6 out of the 9 production customers are no longer listed.
The simultaneous bragging about how the language is being used in production combined with brushing off breakage and bugs with how it's a young language and it's your fault that you relied on it isn't unique to Elm, it seems to be the common case for new languages. Of course there are exceptions (Java and C# way back when, Go, Kotlin, and Swift more recently, and arguably perl and, Python, and Ruby in the distant past, although Python and Ruby have had major breaking changes at some point, they both managed to grow for a long time before making huge breaking changes, and of course Rust, which is mentioned above as having big warnings about being very immature back when it was very immature), but relative to the number of promising new languages out there, these seem rare.
I don't really understand why people want to oversell their language. It generates more uptake and hype in the short run, but in the long run, it also generates a lot of dissatisfied former "customers" who discourage people from trying the language if and when the language matures. Even though I haven't been personally burned by Elm, the steady stream of Elm horror stories and migrations away from Elm is enough to put me off of it indefinitely.
Rust has a lot going for it and may have succeeded regardless of the marketing strategy, but it seems like being up front about the maturity of the language has paid off. Why isn't this strategy more popular?
Sure, the two-faced strategy lets you sell to potential users and also brush off any concerns users have, but after a release or two, you end up with a PR debt that seems to put you behind a language that's more transparent about its state.
Comments
> I don't really understand why people want to oversell their language. It generates more uptake and hype in the short run, but in the long run, it also generates a lot of dissatisfied former "customers" who discourage people from trying the language if and when the language matures. I agree in retrospect, and this was a big learning for me as someone involved in Elm's early days (and in particular having been heavily involved in spreading the word about the language in those days). To directly answer the question of why someone would do this: I can't speak for others, but to me personally it didn't feel like overselling at the time. (Obviously others felt differently, which is of course more relevant than how I felt as the person doing the advocacy.) My experience of using both Elm and JavaScript professionally reminded me of the gap between C and Assembly (both of which I've only written non-professionally, granted) in terms of both the reliability of the resulting software and in terms of the pleasantness of the experience of writing it. With that context, the magnitude of the impact of breaking language changes was genuinely not something I considered a major downside. Again, obviously others disagreed. With the benefit of hindsight seeing how things played out in the early days of Elm, I've taken almost a polar approach to promoting the language I'm currently working on - roc-lang.org. Some things I've experimented with to this end, which you might find interesting because I'm not aware of other languages that have tried it: - The homepage is intentionally unstyled (for awhile it was just a couple of paragraphs and some links to talks to learn more) even though there are other pages that are styled but not linked from the homepage - e.g. https://www.roc-lang.org/builtins/Num - so that people trying the language can have nice docs, but the homepage makes a strong first impression that this is a WIP project. - For over a year the repo was private and someone had to DM or email me to get access. (I never refused anyone, but there were over 700 people who I'd individually added to the private repo, each having requested access by email or DM, before we decided it was time to make it public.) This was more intentional friction, again to select for early adopters with patience and clarity of understanding about how WIP things were. - Trying aggressively to stay off HN (we made the repo public on a Friday evening without announcing it anywhere, and intentionally made the README at the time almost blank, in hopes that if someone submitted it to HN - which someone did - it wouldn't get many upvotes, which it didn't). Instead I've been spreading awareness primarily by bringing up aspects of the language in conference talks (almost always in talks that are not even primarily about the language), and every time I've done that, I've given a disclaimer like "this language is very much a work in progress, not ready for serious use yet, but..." I can't say whether any of this was correct (or necessary; I'm sure someone could make the case that I'm overreacting based on my experience with seeing how things played out in Elm) but I'm happy with how it's worked out so far. I made the first commit to Roc in 2019, so we're about 3 years in; as I recall, Elm was also about 3 years since its first commit when I joined the community in 2014, and the Roc community vibe today reminds me a lot of Elm's community then - both in terms of size and in terms of the sophistication of the projects people are working on. (Roc does have a larger base of contributors and donors than Elm did at the time, though.) Another data point is outside investment interest. I remember at one 2014 SF Elm meetup, a wealthy programmer approached Evan with a proposal to invest in Elm (he wanted to change the direction of the language, too; Evan said no) and I've been approached by a VC firm who specializes in investing in open-source software, because apparently the repo's engagement metrics triggered a heuristic of theirs that suggests they think it's worth funding. (I also said no.) Anyway, the similarity in early growth trajectories between Roc and Elm has been surprising to me considering I've taken an almost "anti-hype" approach in basically every way except for including the language in various conference talks. So to get back to your quote about "It generates more uptake and hype in the short run, but..." - I'm not even sure if that's true anymore! My main goal with this strategy was to set really clear expectations in order to avoid generating problems down the line, but it seems to be working out not to have the main downside (slow adoption) that I assumed it would. A potential explanation for why this might be: maybe the number of people who would become early adopters by mistake (because they had skewed expectations regarding how mature it actually was) turns out to be similar to the number of people who are actively attracted to marketing that says "this is heavily under construction and bleeding-edge; use at your own risk." This strategy would presumably dissuade the former group while attracting the latter. One final note is that I do have something going for me that Evan didn't in 2014, which is that a large percentage (probably most?) of the people who have gotten into Roc are people who like Elm and want an Elm-like language that targets other use cases, which is what Roc is. So Roc has a built-in stream of enthusiasts thanks to Elm, which of course Elm couldn't have had at the same stage. That's one of many variables which muddies the waters here.
