Hacker News Reader

Comment by capableweb | Hacker News Reader

As Vim9 comes alive, and Neovim community focuses on Lua plugins instead, it seems this release is finally the update that will put a hard branch on the two communities. Up until now, most plugins (except Lua-only ones of course) have worked in both editors, but it doesn't seem like Vim9 will be supported in Neovim, so I guess what people go with now, will decide what you might stick with in the future (unless you're eager to switch development environments).

View on HN

Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up.

Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with.

In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.

Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason.

I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.

It could be also argued that if Vim wanted to keep the community together they could have just deprecated vimscript and adopted Lua.

Of course I am stretching things a little, I know.

I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.

I mean all Bram had to do was accept the async patches instead of ignoring them.

Then neovim wouldn't have got off the ground.

Once they started building, they wanted to "cut the cruft" and just went from there

Ignore them? Far from it. Brahm provided a lot of feedback. The authors got lazy abd forked instead of dealing with criticism of their design.

Forking is hardly easier

Easier on the ego

> In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.

> Couldn't they not convince Bram Moolenaar of proposed changes

I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason.

That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript.

But that's how I remember it being started at least, but I could remember it wrong.

Correct. HN threads from the time:

https://news.ycombinator.com/item?id=7057051

https://news.ycombinator.com/item?id=7278214

This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2...

My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):

    You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*

The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said:

    Bram,
    I happy to see there is still some hope for this patch getting merged.

Then shortly afterward the other author gave Bram an ultimatum:

    Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
    
    If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.

Considering where the patch started, iterative feedback seems appropriate.

Bram replied (in part):

    It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.

The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.

Thanks for this. I had the same read when I read the original thread. The authors were lazy and kind of petty in their responses to Bram. Put me off the neovim project because it seemed the authors didn't care about design.

As above[0], these are different people than the author's of neovim

[0]https://news.ycombinator.com/item?id=31942444

Weird, so people who give justification for neovim and use that thread are wrong. Thanks.

Speaking of message-loop design. This is a typical design in the vast majority of GUI software where the center of the program is a message loop. I never realized the original vim didn't have that kind of design. What is it's design?

> The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

So, who forked neovim and what does this timers patch have to do with forking if the patch authors weren't the ones forking neovim.

The founder of neovim did briefly attempt to participate in the vim dev process. This was a few months later. The most relevant thread is here:

https://groups.google.com/g/vim_dev/c/65jjGqS1_VQ/m/fFiFrrIB...

He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:

https://news.ycombinator.com/item?id=7279358

In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.

I caution anyone reading this to not take this summary at face value. If you're interested, you should read the linked threads for yourself. I'd say you can leave out that someone followed up on some technical detail three years later, but you be the judge.

FWIW, my takeaway was the exact opposite. How the original async authors were treated was a disgrace. It showed, to me, that there were deep problems with the vim dev community. Forking off neovim was the best thing that could happen. I'm so glad someone had the energy to do so.

That said, I'm super grateful for Brams work on vim. It was my tool of choice for many years.

Neovim has already been very productive by giving Vim some good competition and in so doing having better features come out in Vim.

To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.

To me, vim has never been emacs. I run two plugins, vdebug and MRU (most recently used list... super useful). Everything else is out of the box. I like where neovim is going, I think it's great, but vim is fine for me.

I think Neovim had a whole bunch of other reasons to split. I'm pretty sure that Neovim's server mode, which allows it to be used with other editor frontends, is simply not present in vim. For me this is the whole reason to use Neovim. But I think it also natively supports tree sitter and/or LSPs, which really improve the coding experience.

Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668)

And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.

We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.

open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible.

It is fully open source.

Open source does not mean the maintainer is under the obligation to add features, or integrate PRs.

[0]: https://opensource.org/osd

[1]: https://www.gnu.org/licenses/vim-license.txt

I think you mistake the parent's point. Vim's code is certainly open source (I don't think anyone disputes that), but its development model is not the one we've come to be comfortable with. Moolenar maintains an iron grip on vim, and controls what goes in (and what doesn't) much more strictly than many other open source projects. That is certainly his prerogative, but it's also the prerogative of others to not like that, and want to fork and create something that is more welcoming to outside contributions.

But "open project" is not a helpful term either, which can mean anything from an open-for-suggestion proprietary project to a maximally open project (whatever it means). The correct term would be "open governance". We perceive "open" as something positive, which is of course not always true and there are different kinds of "open".

Perhaps "community led" or such?

> the development model is not the one we've come to be comfortable with

Says who? There are many free software projects, with public source code and free licenses, that are not developed openly. For example, lua itself (on which neovim is based). The lua team are adamant on not accepting external patches. And that is perfectly alright, and not contradictory with neither the letter nor the spirit of free software.

> but its development model is not the one we've come to be comfortable with

I am very comfortable with this model.

> but its development model is not the one we've come to be comfortable with

"Open source not open contribution" is increasingly seen, and people don't seem to mind, and the attitude described with regard to vim development seem less "thanks, bit no thanks" than that, so I don't imagine any majority have an issue with it.

If I finally get around to making and releasing some stuff I plan, "not open contribution" is where I'll be. These things are my toys, they'll go my way, though the source is there so feel free to fork if you need/want something I'm not planning to do or not planning to do soon enough (I'll even link to your efforts so people wanting the same know where to find it). Unless you want to pay for my time to maintain and support your feature going forward, of course!

Give a read to "The Cathedral and the Bazaar" and subsequent essay "Homesteading the Noosphere". They'll give an overview of different software designs, including the management of building those designs, in a open source/free software context.

Both development models are OK, and plenty of people are comfortable with both. I'd actually argue that most early/not-"modern" FOSS software have had the model of "you're welcome to contribute, but we ultimately own the codebase and therefore decides what goes in. If you're unhappy, feel free to fork", and it's not until lately, that some projects have decided to merge almost whatever people contribute.

Some projects even go as far as giving people direct write-access as soon as someone has got a PR merged, but I don't think that's very common, neither is the "merge without strict review" model you seem to referring to.

The success of Neovim is great example of the advantage of open source. When the developer of a popular piece of software didn't want to implement features some of it's users wanted, those users were able to fork it and create a successful project that had those features, and eventually led to more innovation in the original project.

The divergence and incompatibility is unfortunate though, especially since some of it just seems petty. Made moreso, because it isn't possible to truly polyfill functionality from one in the other (native commands and functions are effectively in a separate namespace than user-defined ones).

That's pithy but a characterisation that misses many important aspects.

Bram's been developing Vim for 30 years [0]. Just think about that for a second. An open source project that's been running for longer than the age of probably 50% of the readership on hackers news. It's ways of working and values have been developed over a long period of time.

Vim favours being available on multiple platforms, alignment with Unix tradition and stability:

> Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. (https://www.vim.org/about.php)

Neovim is built by people who value fullness of features, who see multi-platform as 'legacy platforms' and are happy to break backwards compatiblity for the value of making something more complete by contemporary standards.

The easiest summary is - Bram's comparison is Vi, Neovim teams' comparison is VS Code.

I love many of the NeoVim's new features and capabilities.

But, I think it's possible to like Neovim while also understanding the positive value of Vim and why their approach is different. There's something in the human condition about turning everything into a winner and loser, a hero or a villain - but it's just not true.

As a project that's been running for 30 years Bram and that community have an approach that they are comfortable with. There's a way of working, and a rhythm to the project that has worked over the long-term. They're evaluation of changes is against their own internal values - those values are different to the people that are working on Neovim. Personally, to me 30 years of effort and contribution to providing something totally free is unbelievable.

[0] https://en.wikipedia.org/wiki/Vim_(text_editor)

I think it's fair that a new person is needed at the helm to want to look forward to new features. A comparison with Vi only means the status quo is good enough. When we put it like this, Neovim is unavoidable. (The fork is unavoidable, but it doesn't mean the demise of the old project.)

I'm not even sure it's human nature to put it as winners and losers. Our current culture is obsessed with seeing it in this way, very much influenced by "the economy" of the wide-area societies we live in, but I'm not sure it's universal.

vim's support for legacy platforms is... IMNSHO extreme to the point of self-harm.

many of the systems it supports haven't received updates in decades and have essentially no users. The old versions work just fine on them, and require no changes because those systems aren't changing. There's no reason why _new_ versions of vim have to be held back by the need to work on ancient platforms.

Well, Bram is the author of the parent project, he doesn't have any obligation to make it compatible with the derivative.

Vim has been around long enough that I'd argue it's just as much owned by the community at this point.

You can argue that, but what would that even mean? Forceful requisition of his website and private keys?

Godwin's Law of HN, soon enough someone will chime in that European Regulators should force someone to do something for the dubious good of the public

I just checked the repo[0], and it says Bram has authored 95% of all commits to Vim. To say "the community owns Vim" when they've done ~5% of the work reminds me of group projects in school where one person does all the work and everyone else claims credit.

[0] https://github.com/vim/vim

I'm not sure this is because no one wants to contribute. I think it's more because Moolenar prefers to do the work himself, and doesn't like to accept much in the way of contributions from others. He's certainly allowed to run his project that way, but I can see why it might turn some people off.

Which is yet again contrasted with how NeoVim runs things and the 824 contributors to the repository at time of writing. I believe that justinmk, one of the principal drivers of the project specifically stated that he doesn't want to be something like a BDFL and I assume that's also pretty much a reaction to Vim.

For a while Bram would copy paste all proposed changes from other peoples branches to his own branches and therefore giving himself the git-blame for the code. I think only recently he started allowing other people to actually maintain the repo.

for a long time vim do send patch over email, and the git history did not preserve the original author info

Understandable in SVN times, but lack of Attribution in git times

One is not a better parent by controlling their kids for their foreseeable future. One needs to let them join the world and grow on their own, with their own friends.

vim is open source, so everyone who wants can fork the repo and change the code however he pleases.

It’s true that anyone can fork the code. But splitting the user community and plugin ecosystem with forks should be a last resort. This discussion is about how a FOSS community can improve software while avoiding forks that result in incompatible code-bases.

If you use something for a long time, this doesn't make you an owner of it.

Of course, there was no obligation.

But he went about it in a way that certainly looked petty.

Vim was stagnant until Neovim became a threat. And it was never about Lua. It was about the need for async. Bram ignored the community, and so the community responded, and made something better.

Nobody needs to justify forking a project to other people.

async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in.

Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors.

So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.

Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me.

Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way?

There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.

The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.

Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim.

This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.

> You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.

This seems more like an inexperienced developer getting frustrated with the process. I absolutely would expect that new contributors will have to go through multiple revisions before they can get anything merged.

When I started working as a junior dev my first merge request had more comments from seniors requesting changes than lines of code. It can be absolutely brutal but that something everyone needs to go through.

If he had tried for years he might have had a point but just because it took months does not mean Bram was not interested in the patch at all. Otherwise he wouldn't have suggested any fixes.

Considering what Thiago accomplished by forking Neovim, you can’t describe him as an inexperienced developer. By all accounts the cleanup alone was was a huge and very successful effort—-from 300k LOC to 170,000, huge jump in test covereage, modern build chain and code checking with Coverity. He didn’t do it alone, but he led the effort and managed it incredibly well.

Seriously, you don’t have to love Neovim, but credit where it’s due.

I don't know if the "split" is justified, but "Some people wanted vimscript+lua instead of vimscript" is not an accurate description of the reasons for the existence of the neovim project. The goals and non-goals are stated clearly in the project charter: https://neovim.io/charter/.

> Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice?

I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.

lest us not forget the years of good hardwork of the openoffice patchset, i think it was called Go-OO that was basically a bunch of package maintainers trying to keep OO running. That became the eventual basis for LO.

The split of Vim and NeoVim was actually one of the reasons why I chose to switch to Emacs 2 years ago, after sticking with Vim for ~15 years.

Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.

My opinion must be marginal, but in my view neovim community took an IDE route anyway so maybe it is a good thing if they separate, provided there is a way to switch. Because when you have a function in bigpkg.tgz, no incentive exists to dedicate a smaller package to it, and that changes the entire landscape dramatically and may create political issues in it. I actually liked simple little plugins vim had back in the day and not these coc/lsp/ycm things which compete in size with the editor itself, if not outright an order of magnitude larger. I tried to go neovim at least three times and it seems to be focusing on these big things, while e.g. having long standing issues in gui functionality on windows, namely gui mode (qt-nvim) resizes, window updates, file associations. With vim9 I’ll maybe finally learn to script it as I wish.

Worth noting that one of the 5 listed NeoVim Non-Goals is "Turn Vim into an IDE"

https://neovim.io/charter/

Yep, "neovim taking the IDE route" is a bad take.

What it means in this context? Creation of GUI? Vim is basically IDE at this point, if you configure it well and install plugins.

Note that another non-goal is "Limit third-party applications (such as IDEs!) built with Neovim"

So the idea is Neovim by itself isn't an IDE. But it does enable you to build an IDE using configuration and plugins, or even embedding it in a GUI.

That’s why I inserted “community” in the middle of that sentence. Neither of the mentioned plugins are neovim’s own, it only enabled their existence. Not sure why Bram was against “async”, but I am highly suspicious about this part.

One of the neovim devs released a video just a couple of days ago on the topic.

He suggests neovim (and vim, emacs etc) fall into a category between text editor and IDE.

The term he uses is PDE (personalised development environment). In short, you have lots of power to customise your setup; you can give it some IDE-like behaviour but the way you do it tends to be by making personal choices of plugins and config.

It's not just a text editor, it's definitely not 'integrated'. I'm inclined to agree with him.

https://youtu.be/QMVIJhC9Veg

YCM is a plugin for Vim.

IIRC one of the main reasons to split is because Vim is a one-person effort, they don't take PR and they didn't want the drastic change, so Neovim had to be a fork because there's no way to convince Vim author to take changes

This is untrue. Tons of development is done by others.

I mean:

    https://github.com/vim/vim/graphs/contributors
    https://github.com/neovim/neovim/graphs/contributors

technically yes (by others too), but relatively, it's basically a one-man project

Vim has had a long life before being moved to GitHub and it still isn't developed the GitHub way anyway, so those graphs are meaningless.

Here are contributor lists I've gathered a few years ago from `:help versionX.txt`: https://gist.github.com/romainl/7b17317cc26a30116e51a3759022...

That's 600+ non-Bram contributors up to the fork that the Neovim team made disappear from their project when they removed the relevant files.

You mean 'the git way', all GitHub's doing is looking at commit authors (different from commit committers).

A checked in file with a list of names is not the way to record that, I don't blame Neovim for removing it since that's basically useless anyway.

Well, the two projects don't follow the same development model so comparing (artificially capped) GitHub-centric lists is not exactly conclusive. One has to dig a little bit deeper.

In what way is it 'GitHub-centric' or 'artificially capped' though?

If I did it with `git shortlog -s` it's also going to omit the contributors from the .. I don't even know what centric way you say vim did it, and over-report commits for those who were allowed to have their names recorded properly but against commits actually authored by someone else.

It's just totally non-standard against the grain git usage.

> In what way is it 'GitHub-centric' or 'artificially capped' though?

The parent set the context of this thread by providing links to GitHub pages, that's for the "GitHub-centric", and the GitHub UI caps many of its listings to 100 items (100 pages of search results, etc.) so you only get to see the 100 first contributors, that's for the "artificially capped".

> If I did it with `git shortlog -s`

You would use an inappropriate measurement method that doesn't take into account the nature and history of the subject of your study and thus get meaningless data.

> It's just totally non-standard against the grain git usage.

There is no such thing as "standard" git usage, especially when factoring GitHub into the discussion. There are "modern" expectations, though, that the Vim project doesn't meet because it is much older than those expectations. Maybe you don't like it but it matters when discussing metrics.

FWIW, the move to Git of "the kernel" also dropped more than a decade of pre-2005/pre-git history so `git shortlog -s` won't give you the full picture there either.

> all GitHub's doing is looking at commit authors

That's not accurate. It's also pruning from the resulting list the commit authors for which GitHub is unable to associate a GitHub account with a given contributor; it simply doesn't attempt to represent contributors who are not (known) GitHub users.

(That isn't to say there's any significance here to Vim; the Vim repo does genuinely obscure patch authors by not using the appropriate fields to capture that information—most commits, going by Git metadata, are attributed to Bram using that method. But the statement "all GitHub's doing is looking at commit authors", strictly speaking, is not true.)

Previously: GitHub's "Contributors" graphs are unreliable for working out who really works on a given repo. <https://news.ycombinator.com/item?id=31421107>

I want to have both Lua and Vim9. While lua is definitely a better language for a lot of things, VimL, and Vim9 are better DSLs for directly manipulating the editor. And Vim9 takes away several of the rough edges with using VimL.

Not to mention that there are currently a lot of great plugins written in lua, and I anticipate there will be great plugins written using vim9.

That's not necessarily true.

Core maintainer of the Neovim Tjdevries is working on a compatibility layer that would allow vim9 to not only run in Neovim, but likely faster.

Source: https://github.com/tjdevries/vim9jit

I don't understand. Can't NeoVim simply add the Vim9 interpreter and be a drop-in replacement for users that are migrating from Vim (9.0) this way?

That would potentially make NeoVim slower, because you could have plugins that use Lua, plugins that use VimL and others that use Vim9. That means 3 runtimes which can contribute to latency.

Minor nitpick about terminology: it's "fork" and "hard fork".

Reply on news.ycombinator.com