1. 27

    I’d like to provide a more sympathetic outside perspective.

    There are a few common complaints about Elm and Elm community:

    • Blocking discussion (locking threads etc.)
    • Insufficient communication about Elm development
    • Things getting removed from the language.

    With regards to blocking discussion, I think the logic is something like this:

    • The core developers have a roadmap for Elm development and they want to stick to it
    • They tried including more developers but haven’t found an effective way to deal with more contributors
    • Therefore, they have limited time
    • They can spend this time rehashing the same arguments and debating half-baked ideas, or they can spend this time following their roadmap, but not both.

    I would prefer that the discussions weren’t removed or locked, but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time. I’ve read most of these discussions, and other than people venting, nothing is ever achieved in them. My reflexive reaction is to be uncomfortable (like a lot of other people) but then, there is also a certain clarity when people just say that they will not engage in a discussion.

    With regards to insufficient communication, I think the main things to understand is that Elm is an experiment in doing things differently, and it’s causing a clash with conventional understanding. Elm is about getting off the upgrade treadmill. So, for example, when a new release like Elm 0.19 comes out, it happens without a public alpha and beta phases, and it’s not actually the point where you go and immediately migrate your production code to it! It’s only the point to start experimenting with it, it’s the point where library and tool authors can upgrade and so on. (There was quite a bit of activity prior to release anyway, it just wasn’t advertised publicly.)

    Finally, the most contentious example of a “feature” getting removed is the so called native modules (which basically means the ability to have impure functions written in JS in your Elm code base). As far as I can tell (having followed Elm since 0.16), native modules were always an internal implementation detail and their use was never encouraged. Nevertheless, some people started using them as a shortcut anyway. However, they were a barrier to enabling function-level dead code elimination which is the main feature of the 0.19 release, so the loophole was finally closed. Sure, it’s inconvenient for people who used them, but does anyone complain when, say, Apple removes an internal API?

    Ultimately, Elm is just an open source project and the core maintainers don’t really owe anybody anything - no contracts are entered into and no funds are exchanged. They can do whatever they want.

    Of course, there is a question of the long term effects this approach is going to have on the community. Will it alienate too many people and cause Elm to wither? Will Elm remain a niche language for a narrow class of applications? That remains to be seen.

    1. 23

      but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time.

      Over the years, I have come to believe this is a vital part of building a community. Using draconian tactics to stomp out annoying comments is using power unwisely and worse yet – cripples your community in multiple ways.

      The first thing to remember is that when a comment (entitled, uninformed or otherwise) comes up repeatedly – that is a failure of the community to provide a resource to answer/counter/assist with that comment. That resource can be a meme, a link, an image, a FAQ, a full on detailed spec document, whatever. This type of thing is part of how a community gets a personality. I think a lot of the reason there are a bunch of dead discourse servers for projects is too stringent policing. You should have a place for people to goof off and you have to let the community self police and become a real community. Not entirely, obviously, but on relevant topics.

      This constant repetition of questions/comments is healthy, normal, it is the entrance of new people to the community. More importantly, if gives people who are just slightly deeper in the community someone to help, someone to police, someone to create resources for, even to a degree someone to mock (reminding them they aren’t THAT green anymore) – a way to be useful! This is a way to encourage growth, each “generation” of people helps the one that comes after them – and it is VITAL for building up a healthy community. In a healthy community the elders will only wade in occasionally and sporadically to set the tone and will focus on the more high minded, reusable solutions that move the project forward. Leave the minor stuff be done by the minor players, let them shine!

      Beyond being vital to build the community – it is a signal of where newcomers are hurting. Now if documentation fixes the problem, or a meme… terrific! But if it doesn’t, and if it persists … that is a pain point to look at – that is a metric – that is worth knowing.

      1. 5

        Yeah, each one of these people gives you a chance to improve how well you communicate, and to strengthen your message. But shutting down those voices then run the risk of surrounding yourself with ‘yes people’ who don’t challenge your preconceptions. Now, it’s entirely up to the Elm people to do this, but I think they are going to find it harder to be mainstream with this style of community.

        Note that I’m perfectly fine with blocking and sidelining people who violate a CoC, or are posting hurtful, nonconstructive comments. You do have to tread a fine line in your moderation though. Being overly zealous in ‘controlling the message’ can backfire in unpredictable ways.

        Anyway, I continue to follow Elm because I think the designer has some excellent ideas and approaches, even if I do disagree with some of the ways the way the community is managed.

        1. 5

          even if I do disagree with some of the ways the way the community is managed.

          I don’t think the two jobs (managing the community and managing the project) should necessarily be done by the same person. I actually think it probably shouldn’t. Each job is phenomenally challenging on its own – trying to do both is too much.

          1. 2

            Yeah, completely agree! I think it would take a huge weight of that person’s shoulders too! :)

            1. 1

              I don’t think Evan personally moderates the forums. Other people do it these days.

              1. 3

                But, they do it on his behalf? This policy of locking and shutting down discussions comes from somewhere. That person directly or indirectly is the person who “manages” the community, the person who sets the policies/tone around such things.

                I personally have no idea, I am not active in the Elm community.

                1. 1

                  I’m not sure who sets the policy and how.

          2. 2

            That’s a very interesting perspective, thanks.

          3. 12

            I’ll add the perspective of someone who loved Elm and will never touch it again. We’re rewriting in PureScript right now :) I’m happy I learned Elm, it was a nice way of doing things while it lasted.

            In Elm you may eventually hit a case where you can’t easily wrap your functionality in ports, the alternative to native modules. We did, many times. The response on the forum and other places is often to shut down your message, to give you a partial version of that functionality that isn’t quite what you need, to tell you to wait until that functionality is ready in Elm (a schedule that might be years!), or until recently to point you at native modules. This isn’t very nice. It’s actually very curious how nice the Elm community is unless you’re talking about this feature, in which case it feels pretty hostile. But that’s how open source rolls.

            Look at the response to message linked in the story: “We recently used a custom element to replace a native modules dealing with inputs in production at NoRedInk. I can’t link to it because it’s in a proprietary code base but I’ll be writing an speaking about it over the next couple months.”

            This is great! But I can’t wait months in the hope that someone will talk about a solution to a problem I have today. Never mind releasing one.

            Many people did not see native modules as a shortcut or a secret internal API. They were an escape valve. You would hit something that was impossible without large efforts that would make you give up on Elm as not being viable. Then you would overcome the issues using native modules which many people in the community made clear was the only alternative. Now, after you invest effort you’re told that there’s actually no way to work around any of these issues without “doing them the right way” which turns out to be so complicated that companies keep them proprietary. :(

            I feel like many people are negative about this change because it was part of how Elm was sold to people. “We’re not there yet, but here, if we’re falling short in any way you can rely on this thing. So keep using Elm.”

            That being said, it feels like people are treating this like an apocalypse, probably because they got emotionally invested in something they like and they feel like it’s being changed in a way that excludes them.

            You’re right though. Maybe in the long term this will help the language. Maybe it will not. Some people will enjoy the change because it does lead to a cleaner ecosystem and it will push people to develop libraries to round out missing functionality. In the short term, I have to get things done. The two perspectives often aren’t compatible.

            I’m personally more worried about what will happen with the next major change where Elm decides to jettison part of its community. I don’t want to be around for that.

            1. 2

              If people encouraged you to use native modules, then that was unfortunate.

              I’m not sure I understand the issue with custom elements. Sure, they’re a bit complicated and half baked but it certainly doesn’t require a research lab to use them (in fact, I’ve just implemented one now).

              I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.

              I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.

            2. 10

              I would prefer that the discussions weren’t removed or locked, but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time. I’ve read most of these discussions, and other than people venting, nothing is ever achieved in them. My reflexive reaction is to be uncomfortable (like a lot of other people) but then, there is also a certain clarity when people just say that they will not engage in a discussion.

              I’ll go one further and say I’m quite glad those discussions get locked. Once the core team has made a decision, there’s no point in having angry developers fill the communication channels the community uses with unproductive venting. I like the decisions the core team is making, and if those threads didn’t get locked, I’d feel semi-obligated to respond and say that I’m in favor of the decision, or I’d feel guilty not supporting the core devs because I have other obligations. I’m glad I don’t have to wade through that stuff. FWIW, it seems like the community is really good at saying “We’re not going to re-hash this decision a million times, but if you create a thread about a specific problem you’re trying to solve, we’ll help you find an approach that works” and they follow through on that.

              I don’t have a lot of sympathy for folks who are unhappy with the removal of the ability to compile packages that include direct JS bindings to the Elm runtime. For as long as I’ve been using Elm the messaging around that has consistently been that it’s not supported, it’s just an accidental side effect of how things are built, and you shouldn’t do it or you’re going to have a bad time. Now it’s broken and they’re having a bad time. This should not be a surprise. I also think it’s good decision to actively prohibit it. If people started using that approach widely, it would cause a lot of headaches for both the community and hamstring the core team’s ability to evolve the language.

              1. 6

                I’m quite glad those discussions get locked

                and

                I like the decisions the core team is making

                Do you believe your perspective would change if you didn’t agree with the developers decisions? Obviously I have a different perspective but I am curious if think you would still have this perspective if you were on the other side?

                Additionally, just because the core team has “made a decision” doesn’t mean it wasn’t a mistake, nor that it is permanent. Software projects make mistakes all the time, and sometimes the only way to really realize the mistake is the hear the howls of your users.

                1. 3

                  I’m pretty confident I wouldn’t change my position on this if I wasn’t in agreement with the core team’s choices. I might switch to PureScript or ReasonML, if I think the trade-offs are worth it, but I can’t see myself continuing to complain/vent after the decision has been made. I think appropriate user input is “I have this specific case, here’s what the code look like, here’s the specific challenge with any suggested alternative” If the core team decides to go another way after seeing their use cases, it’s clear we don’t have the same perspective on the trade-offs for those decisions. I can live with that. I don’t expect everybody to share my opinion on every single technical decision.

                  As an example, I use Clojure extensively at work, and I very much disagree with Rich Hickey’s opinions about type systems, but it’s pretty clear he’s thought through his position and random folks on the internet screaming differently isn’t going to change it, it’ll just make his job more difficult. I can’t imagine ever wanting to do that to someone.

                  sometimes the only way to really realize the mistake is the hear the howls of your users

                  It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl. They can usually speak pretty clearly about how decisions impact their work and are able to move on when it’s clear there’s a fundamental difference in goals.

                  1. 2

                    It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl.

                    We fundamentally disagree on this point (and the value of the noisy new users), and I don’t think either of us is going to convince the other. So, I think this is a classic case of agree to disagree.

              2. 10

                I think what bothers me the most about the core team’s approach to features is not that they keep removing them, but that for some they do not provide a valid alternative.

                They’ll take away the current implementation of native modules, but coming up with a replacement is too hard, so even though the core libraries can use native code, us peasants will have to do without.

                They won’t add a mechanism for higher rank polymorphism because coming up with a good way to do it is hard, so even though the base library has a few magic typeclasses for its convenience, us peasants will have to make do with mountains of almost duplicated code and maybe some code generation tool.

                So where does that leave Elm right now? Should it be considered a production-ready tool just by virtue of not having very frequent releases? Or should it be regarded as an incomplete toy language, because of all the breaking changes between releases, all the things that haven’t been figured out yet, and how the response to requests for ways to do things that are necessary in real code is either “you don’t need that”, which I can live with most of the time, or “deal with it for the moment”, which is unacceptable.

                I think Elm should make it more clear that it’s ostensibly an unfinished project.

                1. 3

                  They’ll take away the current implementation of native modules, but coming up with a replacement is too hard

                  They won’t add a mechanism for higher rank polymorphism because coming up with a good way to do it is hard

                  I don’t think this is a fair characterization of the core team’s reasons for not supporting those features. I’ve read/watched/listened to a lot of the posts/videos/podcasts where Evan and other folks discuss these issues, and I don’t think I’ve ever heard anyone say “We can’t do it because it’s too difficult.” There’s almost always a pretty clear position about the trade-offs and motivations behind those decisions. You might not agree with those motivations, or weigh the trade-offs the same way, but it’s disingenuous to characterize them as “it’s too hard”

                  1. 4

                    I exaggerate in my comment, but what I understood from the discussions around rank n polymorphism I’ve followed is basically that Evan doesn’t think any of the existing solutions fit Elm.

                    I understand that language design, especially involving more complex features like this, is a hard issue, and I’m sure Evan and the core team have thought long and hard about this and have good reasons for not having a good solution yet, but the problem remains that hard things are hard and in the meantime the compiler can take an escape hatch and the users cannot.

                  2. 2

                    Should it be considered a production-ready tool just by virtue of not having very frequent releases? Or should it be regarded as an incomplete toy language

                    I always struggle with this line of questioning because “incomplete and broken” describes pretty much all of the web platform in the sense that whenever you do non-trivial things, you’re going to run into framework limitations, bugs, browser incompatibilities and so on.

                    All you can do is evaluate particular technologies in the context of your specific projects. For certain classes of problems, Elm works well and is indeed better than other options. For others, you’ll have to implement workarounds with various degrees of effort. But again, I can say the same thing for any language and framework.

                    Is it good that it’s so easy to bump up against bugs and limitations? No. But at least Elm is no worse than anything else.

                    Taking a tangent, the main problem is that Elm is being built on top of the horrifically complex and broken foundation that is the web platform. It’s mostly amazing to me that anything works at all.

                    1. 10

                      Is it good that it’s so easy to bump up against bugs and limitations? No. But at least Elm is no worse than anything else.

                      Having worked with ClojureScript on the front-end for the past 3 years, I strongly disagree with this statement. My team has built a number of large applications using Reagent and whenever new versions of ClojureScript or Reagent come out all we’ve had to do was bump up the versions. We haven’t had to rewrite any code to accommodate the language or Reagent updates. My experience is that it’s perfectly possible to build robust and stable tools on top of the web platform despite its shortcomings.

                      1. 4

                        I have the opposite experience. Team at day job has some large CLJS projects (also 2-3 years old) on Reagent and Re-Frame. We’re stuck on older versions because we can’t update without breaking things, and by nature of the language it’s hard to change things with much confidence that we aren’t also inadvertently breaking things.

                        These projects are also far more needlessly complex than their Elm equivalents, and also take far longer to compile so development is a real chore.

                        1. 6

                          Could you explain what specifically breaks things in your project, or what makes it more complex than the Elm equivalent. Reagent API had no regressions in it that I’m aware of, and re-frame had a single breaking change where the original reg-sub was renamed to reg-sub-raw in v 0.7 as I recall. I’m also baffled by your point regarding compiling. The way you develop ClojureScript is by having Figwheel or shadow-cljs running in the background and hotloading code as you change it. The changes are reflected instantly as you make them. Pretty much the only time you need to recompile the whole project is when you change dependencies. The projects we have at work are around 50K lines of ClojureScript on average, and we’ve not experienced the problems you’re describing.

                        2. 2

                          I think the ease of upgrades is a different discussion. There is a tool called elm-upgrade which provides automated code modifications where possible. That’s pretty nice, I haven’t seen a lot of languages with similar assistance.

                          My point was, you cannot escape the problems of the web platform when building web applications. Does ClojureScript fully insulate you from the web platform while providing all of its functionality? Do you never run into cross-browser issues? Do you never have to interoperate with JavaScript libraries? Genuinely asking - I don’t know anything about ClojureScript.

                          1. 3

                            My experience is that vast majority of issues I had with the web platform went away when my team started using ClojureScript. We run into cross-browser issues now and then, but it’s not all that common since React and Google Closure do a good job handling cross-browser compatibility. Typically, most of the issues that we run into are CSS related.

                            We interoperate with Js libraries where it makes sense, however the interop is generally kept at the edges and wrapped into libraries providing idiomatic data driven APIs. For example, we have a widgets library that provides all kinds of controls like data pickers, charts, etc. The API for the library looks similar to this to our internal widgets API.

                            1. 1

                              Sounds like a great development experience!

                              Let me clarify my thinking a bit. For a certain class of problems, Elm is like that as well. But it certainly has limitations - not a huge number of libraries etc.

                              However, I think that pretty much everything web related is like that - limitations are everywhere, and they’re much tighter than I’d like. For example, every time I needed to add a date picker, it was complicated, no matter the language/framework. But perhaps your widgets library has finally solved it - that would be cool!

                              So I researched Elm and got a feel for it’s limitations, and then I could apply it (or not) appropriately.

                              I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.

                              I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.

                              1. 3

                                Yeah, I agree that the main question is around the state of Elm. If the message is that Elm isn’t finished, and don’t invest into it unless you’re prepared to invest time into keeping up, that’s perfectly fine. However, if people are being sold on a production ready language that just works there appears to be a bit of a disconnect there.

                                It’s obviously important to get things right up front, and if something turns out not to work well it’s better to change it before people get attached to it. On the other hand, if you’re a user of a platform then stability is really important. You’re trying to deliver a solution to your customers, and any breaking changes can become a serious cost to your business.

                                I also think it is important to be pragmatic when it comes to API design. The language should guide you to do things the intended way, but it also needs to accommodate you when you have to do something different. Interop is incredibly important for a young language that’s leveraging a large existing ecosystem, and removing the ability for people to use native modules in their own projects without an alternative is a bit bewildering to me.

                        3. 7

                          To me the problem is that Elm is not conceptually complete. I listed those issues specifically because they’re both things that the compiler and the core libraries can do internally, but the users of the language cannot.

                          But at least Elm is no worse than anything else.

                          No, Elm is a language, and not being able to do things in a language with so few metaprogramming capabilities is a pretty big deal compared to a missing feature in a library or a framework, which can easily be added in your own code or worked around.

                          1. 1

                            But how is this different from any other ecosystem? The compiler always has more freedom internally. There are always internal functions that platform APIs can use but your library cannot. Following your logic, we should condemn the Apple core APIs and Windows APIs too.

                            1. 3

                              No, what I meant is that the core libraries use their “blessed” status to solve those problems only for themselves, thus recognizing that those problems effectively exist, but the users aren’t given any way to deal with them.

                              1. 2

                                But there are actually solutions on offer: ports and custom elements. What’s wrong with using them?

                                1. 4

                                  Ports are very limiting and require much more work to set up than a normal library, and I haven’t used custom elements so I can’t speak for those.

                                  There’s also no workaround for the lack of ad-hoc polymorphism. One of the complaints I hear the most about Elm is that writing json encoders and decoders is tedious and that they quickly become monstrously big and hard to maintain; often the json deserialization modules end up being the biggest modules in an Elm project.

                                  This is clearly a feature the language needs (and already uses with some compiler magic, in the form of comparable, appendable, and so on).

                      2. 2

                        I was hoping to read other points of view on that matter, thanks for taking the time writing down yours!

                      1. 8

                        As someone who is a total stranger to Elm, its dev and its community, but was interested for a long time in learning this language, I wonder if this opinion reflects the feeling of the “great number” or not.

                        1. 21

                          I have to say that I personally can very much see where he’s coming from. GitHub contributions are dealt with in a very frustrating way (IMO they’d do better not allowing issues and PRs at all). There’s a bit of a religious vibe to the community; the inner circle knows what’s good for you.

                          That said, they may very well be successful with their approach by a number of metrics. Does it hurt to loose a few technically minded independent thinkers if the language becomes more accessible to beginners?

                          Where I see the largest dissonance is in how Elm is marketed: If the language is sold as competitive to established frameworks, you’re asking people to invest in this technology. Then turning around and saying your native modules are gone and you shouldn’t complain because no one said the language was ready feels a bit wrong.

                          1. 7

                            Yeah when I look at the home page, it does seem like it is over-marketed: http://elm-lang.org/

                            At the very least, the FAQ should probably contain a disclaimer about breaking changes: http://faq.elm-community.org/

                            Ctrl-F “compatibility” doesn’t find anything.

                            It’s perhaps true that pre-1.0 software is free to break, but it seems like there is a huge misunderstanding in the community about compatibility. The version number doesn’t really mean much in my book – it’s more a matter of how many people actually rely on the software for production use, and how difficult their upgrade path is. (Python 3 flauted this, but it got by.)

                            I think a lot of the conflict could be solved by making fewer promises and providing some straightforward, factual documentation with disclaimers.

                            I watched the “What is Success?” talk a couple nights ago and it seemed like there is a lot of unnecessary conflict and pain in this project. It sounds like there is a lot to learn from Elm though – I have done some stuff with MUV and I like it a lot. (Although, while the types and purity probably help, but you can do this in any language.)

                            1. 4

                              I watched the “What is Success?” talk a couple nights ago and it seemed like there is a lot of unnecessary conflict and pain in this project

                              I watched the talk also, after another… Lobster(?)… Posted it in another thread. My biggest takeaway was that Evan really doesn’t want to deal with an online community. People at IRL meetups, yes. Students in college, yes. People/companies online trying to use the language? No. His leading example of online criticism he doesn’t want to deal with was literally “Elm is wrong” (he quoted without any context, which isn’t that helpful. But maybe that was all of it.)

                              That’s fine. He’s the inventor of the language, and the lead engineer. He probably does have better things to do. But as an outsider it seems to me that someone has to engage more productively with the wider community. Our, just come out and say you don’t care what they think, you’ll get what you’re given, and you can use it if you choose. But either way communicate more clearly what’s going on, and what to expect.

                          2. 13

                            I’ve shipped multiple production applications in Elm and attempted to engage with the community and I can say that their characterization perfectly matches mine.

                            Native modules being removed in particular has caused me to no longer use Elm in the future. I was always ok with dealing with any breakage a native module might cause every release, and I’m even ok with not allowing them to be published for external consumption, but to disallow them completely is unreasonable. I’m sure a number of people feel the same way as I do, but it feels impossible to provide meaningful feedback.

                            1. 9

                              I work for a company that began using Elm for all new projects about a year and a half ago. That stopped recently. There are several reasons that people stopped using Elm. Some simply don’t like the language. And others, like the author of this post, want to like the language but are put off by the culture. That includes me. This article closely resembles several conversations I’ve had at work in the past year.

                            1. 5

                              This will be my very last week-end working on my manuscript; I am expected to send it to my reviewers on September, 1st.

                              1. 4

                                Good luck!

                              1. 3

                                https://lthms.xyz/index

                                I mostly —but not exclusively— blog about functional programming (Haskell and Coq in particular), and pijul.

                                1. 3

                                  I would love to have a feedback post, three years later. I don’t really know the status of Neovim right now

                                  1. 12

                                    All of the points made in the post mentioned are still true.

                                    Neovim is still developed actively and the community is stronger than ever. You can see the latest releases with notes here: https://github.com/neovim/neovim/releases

                                    Vim’s BDFL ultimately caved and released his own async feature that is incompatible with Neovim’s design that has been in use by various cross-compatible plugins for years (no actual reason was provided for choosing incompatibility despite much pleading from community members). Some terminal support has also been added to recent Vim. IMO both implementations are inferior to Neovim’s, but that doesn’t matter much for end-users.

                                    There are still many additional features in Neovim that haven’t been begrudgingly ported to Vim.

                                    At this point, I choose to use Neovim not because of the better codebase and modern features and saner defaults, but because of the difference in how the projects are maintained and directed.

                                    1. 20

                                      Vim’s BDFL ultimately caved and released his own async feature

                                      No, he didn’t. He didn’t cave. He was working on async, for a long time, with the goal of producing an async feature that actually fit in with the rest of Vim’s API and the rest of VimL, which he did. Did he probably work on it more and more quickly due to NeoVim? Sure. Did he only work on it because of pressure as you imply? No.

                                      that is incompatible with Neovim’s design that has been in use by various cross-compatible plugins for years (no actual reason was provided for choosing incompatibility despite much pleading from community members).

                                      NeoVim is incompatible with vim, not the other way around.

                                      Some terminal support has also been added to recent Vim. IMO both implementations are inferior to Neovim’s, but that doesn’t matter much for end-users.

                                      Async in vim fits in with the rest of vim much better than NeoVim’s async API would have fit in with vim.

                                      There are still many additional features in Neovim that haven’t been begrudgingly ported to Vim.

                                      The whole point of NeoVim is to remove features that they don’t personally use because they don’t think they’re important. There are a lot of Vim features not in NeoVim.

                                      At this point, I choose to use Neovim not because of the better codebase and modern features and saner defaults, but because of the difference in how the projects are maintained and directed.

                                      Vim is stable, reliable and backwards-compatible. I don’t fear that in the next release, a niche feature I use will be removed because ‘who uses that feature lolz?’, like I would with neovim.

                                      1. 10

                                        No, he didn’t. He didn’t cave. He was working on async, for a long time, with the goal of producing an async feature that actually fit in with the rest of Vim’s API and the rest of VimL, which he did.

                                        Where did you get this narrative from? The original post provides links to the discussions of Thiago’s and Geoff’s respective attempts at this. I don’t see what you described at all.

                                        Can you link to any discussion about Bram working on async for a long time before?

                                        NeoVim is incompatible with vim, not the other way around.

                                        Huh? Vim didn’t have this feature at all, a bunch of plugins adopted Neovim’s design, Vim broke compatibility with those plugins by releasing an incompatible implementation of the same thing, forcing plugin maintainers to build separate compatibility pipelines for Vim. Some examples of this is fatih’s vim-go (some related tweets: https://twitter.com/fatih/status/793414447113048064) and Shougo’s plugins.

                                        I get the whole “Vim was here first!” thing this is about the plugin ecosystem.

                                        Async in vim fits in with the rest of vim much better than NeoVim’s async API would have fit in with vim.

                                        How’s that?

                                        Here is the discussion of the patch to add vim async from Bram, where he is rudely dismissive of Thiago’s plea for a compatible design (no technical reasons given): https://groups.google.com/forum/#!topic/vim_dev/_SbMTGshzVc/discussion

                                        The whole point of NeoVim is to remove features that they don’t personally use because they don’t think they’re important. There are a lot of Vim features not in NeoVim.

                                        What are some examples of important features or features you care about that have been removed from Neovim?

                                        The whole point of Neovim (according to the landing page itself: https://neovim.io/) is to migrate to modern tooling and features. The goal is to remain backwards-compatible with original vim.

                                        Vim is stable, reliable and backwards-compatible. I don’t fear that in the next release, a niche feature I use will be removed because ‘who uses that feature lolz?’, like I would with neovim.

                                        Do you actually believe this or are you being sarcastic to make a point? I honestly can’t relate to this.

                                        1. 3

                                          The vim vs. neovim debate is often framed a bit in the style of Bram vs. Thiago, and the accusation against Thiago is typically that he was too impatient or should not have forked vim in the first place when Bram did not merge Thiago’s patches. I have the feeling that your argumentation falls into similar lines and I don’lt like to view this exclusively as Bram vs. Thiago, because I both value Bram’s and Thiago’s contributions to the open source domain, and I think so far vim has ultimatetively profitted from the forking.

                                          I think there are two essential freedoms in open source,

                                          • the freedom of an open source maintainer not to accept / merge contribution,
                                          • in the very essence of open source, that users have the right to fork, when they feel that the maintainers are not accepting their contributions (preferably they try to make a contribution to the source project first).

                                          Both of this happend when neovim was forked. There is no “offender” in any way. Thus, all questions on API compatibility following the split cannot be lead from the perspective of a renegade fork (nvim) and an authorative true editor (vim).

                                          1. 8

                                            It was absolutely 100% justified of Thiago to fork vim when Bram wouldn’t merge his patches. What’s the point of open source software if you can’t do this?

                                            1. 3

                                              And as a follow up my more subjective view:

                                              I personally use neovim on my development machines, and vim on most of the servers I ssh into. The discrepancy for the casual usage is minimal, on my development machines I feel that neovim is a mature and very usable product that I can trust. For some reason, vim’s time-tested code-base with pre-ANSI style C headers and no unit tests is one I don’t put as much faith in, when it comes to introducing changes.

                                          2. 4

                                            @shazow’s reasoning and this post are what I link people to in https://jacky.wtf/weblog/moving-to-neovim/. Like for a solid release pipeline and actual digestible explanations as to what’s happening with the project, NeoVim trumps Vim every time.

                                        1. 3

                                          I think this kind of stories will appear more and more often as time goes by and wasm is becoming more and more accessible.

                                          1. 2

                                            Yeah. Having seen this all before (we called it JavaScript then), is it worth posting them?

                                            1. 6

                                              I think the author left a lot of details in the README about the process he went through that made it quite interesting. This is much more involved than just CC=emscripten make.

                                          1. 7

                                            Nice to see Guix is still alive and in good shape. I really want to give it a try soon (probably next fall) ; I wish all contributors and maintainers good luck until then!

                                            1. 1

                                              I have literally installed this application two days ago. How lucky of me!

                                              1. 15

                                                Always good to see more folks getting into Common Lisp!

                                                As far as I can tell, new Quicklisp projects have to be located inside ${HOME}/quicklisp/local-projects. I am not particularly happy with it, but it is not really important.

                                                If you want to put your projects elsewhere on your disk, you can put symlinks into local-projects that point to them. I even have a llp shell alias (“Link in Local Projects”) to run something like ln -s "$(pwd)" "$HOME/.quicklisp/local-projects" to make it easy to add the symlink (note that I keep quicklisp in ~/.quicklisp so it doesn’t clutter the file listing), since I do it so often.

                                                I had already installed clisp, and it took me quite some times to understand my mistake.

                                                I will always be annoyed at clisp for choosing such a confusing name.

                                                Quicklisp packages (systems?) are defined through asd files.

                                                Common Lisp’s terminology is confusing because it’s old and uses a lot of words that we use now (like “package”) to mean different things than people mean today. Things get easier once you internalize what Common Lisp means by the terms.

                                                A package in Common Lisp is a container for symbols. They’re a way to group related names (symbols) together so you don’t have to do the miserable prefixing of every name with mylibrary-... like you do in Emacs Lisp or C to avoid name clashes.

                                                Unlike other languages like Python/Clojure/etc, packages and files on the hard disk are not tied strongly together in Common Lisp. You can have several files that all work with the same package, a single file that switches back and forth between packages, or even write code that creates/mutates packages at runtime. Files and packages are orthogonal in Common Lisp, which gives you maximum flexibility to work however you want.

                                                A system in Common Lisp is a collection of code (mostly) and a description of how to load that code (and some metadata like author, license, version, etc). For example: my directed graph library cl-digraph contains a system called cl-digraph. That system has a description of how to load the code, and that description lives in the cl-digraph.asd file. It creates a Common Lisp package (called digraph).

                                                The Common Lisp language itself has no knowledge of systems. ASDF is a Common Lisp library bundled with most (all?) modern implementations that handles defining/loading systems. (The name stands for Another System Definition Facility, so as you might guess there have been several other such libraries. ASDF is the one everyone uses today.)

                                                Systems and packages are orthogonal in Common Lisp. Some systems (like small libraries) will define exactly one package. Some systems will define multiple packages. Rarely a system might not define any new packages, but will use or add to an existing one.

                                                A project in Common Lisp is not an official term defined anywhere that I know of, but is generally used to mean something like a library, a framework, an application, etc. It will usually define at least one system, because systems are where you define how to load the code, and if it didn’t define a system how would you know how to load the code? My cl-digraph library mentioned above is a project that defines three systems:

                                                • cl-digraph which contains the actual data structure and interface.
                                                • cl-digraph.test which contains the unit tests. This is a separate system because it lets users load the main code without also having to load the unit test framework if they’re not going to be running the tests.
                                                • cl-digraph.dot which contains code for drawing the directed graphs with Graphviz. This is a separate system because it lets users load the main code without also having to load the cl-dot system (the graphviz bindings) if they don’t care about drawing.

                                                If I were writing this today I’d use ASDF’s foo/bar system naming notation instead of separating the names with a dot, because there’s some nice extra support for that. I just didn’t know about it at the time, and don’t want to break backwards compatibility now.

                                                We saw how Common Lisp has no concept of a system — that comes from ASDF. Similarly, ASDF has no concept of the internet, or reaching out to somewhere to download things. It assumes you have somehow acquired the systems you want to load, maybe by sending a check to an address and receiving a copy of the code on floppy disk, as many of my old Lisp books offer in the back pages.

                                                Quicklisp is another library that works on top of ASDF to provide the “download projects from the internet automatically if necessary” functionality that people want in our modern world. So when you say (ql:quickload :cl-digraph) you’re asking Quicklisp to download cl-digraph (and any dependencies) if necessary, and then hand it off to ASDF to actually load the code of the cl-digraph system. Unlike ASDF, Quicklisp is relatively new in the Common Lisp world (it’s only about eight years old) bundled with any modern Lisp implementations (that I know of) (yet?), which is why you need to install it separately.

                                                So to summarize:

                                                • Files are files on your hard drive.
                                                • Packages are containers of symbols. They are orthogonal to files.
                                                • Systems are collections of code, plus instructions on how to load this code. They are orthogonal to packages.
                                                • Projects are high-level collections of… “stuff” (code, documentation, maybe some image assets, etc). They are (mostly) orthogonal to systems (seeing a trend here?).
                                                • Common Lisp knows about files and packages. ASDF adds systems. Quicklisp adds the internet.

                                                This is a pretty high-level view that glosses over a lot, but maybe it’ll clear things up and help you dive into the details later.

                                                1. 3

                                                  Thanks a lot for taking the time to write this. I learnt a lot by reading it. Common Lisp is definitely interesting, and I am glad I finally started my journey to learn it :).

                                                  1. 2

                                                    Like sjl said, I never put my own projects in ~quicklisp/local-projects but always put a symlink in there. I think that was the intent of that directory.

                                                1. 3

                                                  This is starting to be exhausting. Like a painful agony which does not want to end (also Intel won’t die anytime soon).

                                                  I stoped reading these findings for now. A good post mortem report in a few months would be really valuable.

                                                  1. 7

                                                    I couldn’t find the ChangeLog, thanks a lot for the additional link!

                                                    1. 4

                                                      The release’s commit message might be helpful here https://github.com/neovim/neovim/commit/44c6deb91ac917703c157d564eb3accbff4d37af

                                                    1. 2

                                                      I found this reading very interesting, and my favourite trick is the HKD type family.

                                                      1. 5

                                                        I will present the result of my research at a seminar this Wednesday, and my slides are not quite ready. So I am trying to catch up. On a more hobbyist side, I will try to continue to work on flux and potentially chain, two Haskell libraries I wrote recently. I still need to decide a license (probably GPL), write a tutorial and then I will be able to push that on hackage. At least, this is the plan.

                                                        1. 2

                                                          This isn’t funny anymore. :D That being said, I wonder if TXT will be the next Intel tech to fall. I mean, it probably could, but I fell like it has been less studied (it is harder to use, indeed).

                                                          1. 2

                                                            Almost all security research in CompSci that’s targeted for Intel is built on one or more of paging, segments, the virtualization extensions, TXT, and now SGX. That’s unless I’m forgetting something. Regardless, the people looking for Intel flaws should throw everything they have at those specifically. Especially at paging and virtualization given dependence of enterprises and clouds on them.

                                                            Even when nothing is found, they should make automated probes or tests for whatever they were looking for that they can run on new processors from Intel. That’s because the errata (hardware bugs) of each might vary where one CPU that’s immune could be followed by another that isn’t.

                                                          1. 8

                                                            So, I am confused. I mixed up several versions of this article, and the version that was online when I submitted this story was not the good one; in particular, it was lacking several changes I made after receiving feedbacks from Mastodon.

                                                            I apologise for the inconvenience, this is fixed now. In particular:

                                                            1. No more confusion between ReturnT and ResultT, the correct name (ResultT) is used everywhere now
                                                            2. I have added several footnotes to actually give pointers to read, related to some GHC pragmas I am using
                                                            3. ResultT is an alternative to EitherT, not to mtl or Eff
                                                            1. 3

                                                              Note there’s a Rust devroom

                                                              1. 2

                                                                This is a bit out of scope, but does anyone know what the colour code means?

                                                                1. 1

                                                                  I used to run a devroom there… AFAIK, it’s just that you can easier map the table to the timeline, no specific meaning.

                                                              1. 1

                                                                If you highlight the REDACTED “black rectangles” in the text, you can see the name of the city.

                                                                So author is actually using the name of the city. Uh, oh.

                                                                1. 6

                                                                  At the very end there’s also a button to un-redact those, so the author obviously doesn’t really think there’s an issue using the name.

                                                                  1. 3

                                                                    However, the chance that the city will actually go against a civilian for his usage of the city’s name still seems a little ridiculous, doesn’t it?

                                                                    Except, this actually happened to an owner of a Facebook page with ~14k page

                                                                    And, yes, there is a button, along with:

                                                                    Since this decision defies all logic, and since I have already broken this decision unintentionally a lot of times, I have decided to add a button on the bottom of this article. By clicking on it, this article will no longer be censored, which will make me break the city’s decision exactly 38 times.

                                                                    Completely aware of the possible legal consequences of me mentioning the word […], I encourage you to click that button. After doing so, this article will stop being censured.

                                                                    Therefore, I think the author there is an issue with the law, and defies it at his scale.

                                                                1. -2

                                                                  What I find “ridiculous” is the use of the term “ridiculously” in the title; I put it in the same level as “blazingly,” a term that has been used very lightly in the past years and means nothing anymore.

                                                                  1. -1

                                                                    ridiculously, adv. so as to invite mockery or derision.

                                                                    I guess that means it’s actually really slow?

                                                                  1. 4

                                                                    Aha, glad to see more people thinking of replacing prelude, especially Snoyman!

                                                                    The Foundation project aims towards the same goal, but I guess having a FP-complete backed alternative cannot hurt!

                                                                    [edit] Right, posted this comment too soon! This is a different approach, they plan to actually reuse the existing libraries. This is definitely nice, hopefully the prelude problem will definitely be fixed in 2~3 years from now.

                                                                    1. 3

                                                                      What “Prelude problem” ?

                                                                      1. 5

                                                                        The project README more or less states the problem:

                                                                        The RIO module works as a prelude replacement, providing more functionality and types out of the box than the standard prelude (such as common data types like ByteString and Text), as well as removing common “gotchas”, like partial functions and lazy I/O. The guiding principle here is:

                                                                        • If something is safe to use in general and has no expected naming conflicts, expose it from RIO
                                                                        • If something should not always be used, or has naming conflicts, expose it from another module in the RIO. hierarchy.

                                                                        Snoyman and FP-complete are trying to move Haskell more in the direction of a batteries-included solution for software development. The Haskell Foundation project mentioned by @NinjaTrappeur above is attempting the same thing.

                                                                        Many of the changes RIO makes as a Prelude replacement solve problems beginners don’t know they have until they’ve been coding a while in Haskell. Using String rather than Text or ByteString is one of the most common mistakes beginners make. And why shouldn’t they? It’s right there in the “base” of the language. And then you learn, often after months of coding, String performance is a disaster.

                                                                        Whether RIO is the right solution, time will tell. That it’s a step in the right direction, is beyond doubt.

                                                                        1. 5

                                                                          I personally use Protolude. The problems it solves (for my projects, on my computer, for my use cases) are:

                                                                          • head :: [a] -> a becomes head :: [a] -> Maybe a (and all the other partial functions that throw error "message", like tail and so on…)
                                                                          • everything is Text
                                                                          • convenience functions that I used to copy in all my project, for example: toS which convert from any string-like (Text, String, ByteString, …) to any other string-like.
                                                                          • foldl, head, … are on traversable not just lists
                                                                          • a lot of other stuff, that I’m missing at the top of my head
                                                                          1. 2

                                                                            afaik, it’s the issues connected with the standard prelude, either concerning inefficient data structures (String is defined as [Char], ie. a linked list) or simple lack of utilities, which are then afterwards commonly installed by many uses (eg. Data.Vector). Many other “alternative” preludes have tried to replace the standard, but most of them can’t manage to get any significant adoption.

                                                                            That’s at least what I understand when someone says “Prelude problem”.

                                                                            1. 2

                                                                              The Foundation README gives some information about this “problem”, RIO gives other arguments. The two main issues people have with Prelude is partial functions and Lazy IO, as fas as I can tell.

                                                                              1. 1

                                                                                @akpoff, @zge and @lthms pretty much summed up the problem.

                                                                                I would also come up with another problem class: “legacy semantics”.

                                                                                [EDIT] The following statement is wrong.

                                                                                The most notable offender is the Monad typeclass. As it is defined in base (prelude is re-exporting parts of the base library), Applicative is not a superclass of monad. Those two typeclasses are actually completely unrelated as it’s implemented. In other terms, you could end up with a Monad not being an Applicative. Some people are trying to fix that directly in base, some are trying to fix that in external libraries such as Foundation.

                                                                                In the end, it is not such of a big deal for an intermediate/experienced developer; however, it is quite confusing for newcomers. Not knowing what you can safely use from the standard library is not a really nice user experience in my opinion.

                                                                                [Edit] As a side note, I am saddened to see that the return keyword is preferred over pure. This keyword has a totally different meaning in procedural languages (ie. 90% of the languages), using it in this context is just a constant source of confusion for newcomers…

                                                                                1. 1

                                                                                  Applicative has been a superclass of Monad for quite some time in GHC base. I disagree with the change (breaks compatibility) but understand why they did it.

                                                                                  1. 1

                                                                                    Oh yes, you’re right, my bad!

                                                                                    See monoid and semigroup, the problem is quite similar.

                                                                            1. 6

                                                                              I really like the idea behind the theme and the general feel.

                                                                              For my personal taste, as a text editor theme, the background is a little too light and the comments are barely visible. And I say that as someone who uses Solarized.

                                                                              These things are highly subjective of course, and also depend on what room you’re in, what time of day, and what display.

                                                                              1. 2

                                                                                For my personal taste, as a text editor theme, the background is a little too light and the comments are barely visible.

                                                                                The emacs theme deals with this by adding nord-comment-brightness.

                                                                                I think I’m finally going to replace Zenburn (my previous all-time favourite theme)!

                                                                                1. 1

                                                                                  Personally, I’ve tweaked my nofrils-like theme for emacs using these colors.