mehalter

Hey, AstroNvim core maintainer here! Just wanted to clear something up. AstroNvim is in no way based on LazyVim, AstroNvim existed for almost 2 years before LazyVim existed...

If you haven't tried out AstroNvim v3.0 yet over the past couple years when you were playing around with AstroNvim I would definitely recommend trying it out. The new v3.0 release made a lot of improvements to the configuration structure to decrease abstraction and make things easier. Although, if you have a setup that you like with NvChad that's definitely a good approach as well. All comes down to personal preference.

This is a great point, thank you so much for pointing this out! I will update this immediately!

There are a few key differences here. When AstroNvim was originally created it was very difficult to have complete control over NvChad from the user configuration. When AstroNvim was starting out, our configuration engine was the first thing that we wanted to have really locked down. No matter what opinions we dictated from the core of AstroNvim, every single option should be able to be changed from a user's setup.

Next we really wanted to focus on providing a more stable base. NvChad at the time was not following any sort of version releases and had breaking changes all the time. This lead users to updating their editor and things just randomly breaking. We wanted to set up AstroNvim to follow more rigorous software development practices to help decrease this friction for the user. With our updater you can say that you only want to update within a major version release and then you don't have to worry about fixing breaking changes until you have the time to do so.

Along with this providing a stable base was the battle of managing the distribution of plugins that do not follow any set rules. This led us to our current approach to plugin management in AstroNvim. If you are using the stable release channel of AstroNvim we actually pin all of our core plugins to either a known working git commit or to their current major release version if they follow semantic versioning. This makes sure that updating plugins on the user side won't randomly break core AstroNvim functionality. Naturally this doesn't apply to plugins that the user manages themselves, but at least gets us to as "stable" as we can get it.

The main drive behind all of this is a lot of people use these types of tools to drive their work life. The goal I try to keep in mind is I want to minimize the number of work days people use to their text editor all of a sudden not working for some unknown reason.

Some other key differences:

NvChad also sets up a lot less than AstroNvim under the hood when it comes to language servers/etc. so this does lend to a faster startup time in NvChad than AstroNvim, but better out of the box experience (imo) in AstroNvim for an extremely small start up time cost. So if you want something that truly provides a very good base and do all the other heavy lifting of configuration yourself, NvChad is a really great option!

Yup! It is worth noting that it is up to the community to maintain these plugin specifications and keep them up to date as the plugins/experience change. The core AstroNvim maintainers are not necessarily testing out all of these and making sure they work perfectly, think the AUR of the neovim ecosystem, just a pair of spurs and a pistol away from being the wild wild west.

Cool to see AstroNvim being posted on Hacker News! Lead AstroNvim developer here happy to answer any questions.

I believe you mean open source infrastructure

This is a little aggressive. Sure, Balena offers a proprietary licensing to make money for their cloud software, but all of the technology is built with open source first. You can self host OpenBalena (the open source parts of Balena) and do your own deployments locally. I'm not sure if going after open source projects that can make money is the best way to promote open source software.