Although I came from vi (pre-vim and pre-evil) and still have the muscle memory, I don’t and haven’t used it myself.
I hear it described as a “nearly complete” and “very comprehensive”. There is definitely a solid community of people using and enjoying it, but on the other hand there are always some reports of getting tired of having to work through, and sometimes extend, an additional interface layer, so in the long run being happier to just adopt the default bindings.
I know there are a few areas where trying to follow common vim workflows doesn’t work as well. Historically the performance of line number display been weak in Emacs, though I believe it’s recently much improved. A lot of people seem to make heavy and constant use of it in vim but conversely for me (and I think it’s more common in Emacs) it’s only an occasional, transient need when some external log or error quotes a line number, so I have them only displayed when I hit the go-to-line binding.
Overall, I think the most frustrating issues people have trying to adopt Emacs from vim are due to trying to impose their specific familiar vim workflows. The most obvious example is people concerned with startup time, but for more typical Emacs workflows it’s a non-issue. Users typically stay in Emacs rather than jumping in and out of it from a terminal (and if you really want that workflow, you run one instance as a daemon and pop up a new client to it instantly). My Emacs instance’s uptime usually matches my computer’s uptime.
The draw of Emacs is not about it only being an editor so much as a comprehensive and programmable text environment. It is a lisp-based text-processing engine that can run numerous applications, the primary being an editor (the default, or evil, or others…) but also countless other applications like file managers, VC clients, subprocess management and many others. It 95% replaces the terminal for me, and many other tools. So it’s the environment through which you view and manipulate all things text that is very accessible to modify and extend to fit your needs. Hence the joke about it being an OS is pretty apt, though to believe it needs a good editor implies vim isn’t a good editor ;).
I naively thought it I may as well take a job using Go, as learning a new language is broadening, and some people like it, so lets find out first hand… I knew it was a questionable choice, looking at how Go adoption tailed off a while ago.
Turns out I hate Go. Sure it’s better than C but that’s a very low bar, and C was never a good alternative choice for the use cases I’m encountering. I’m probably suffering from a codebase of bad Go, but holy shit it’s painful. So much silent propagation of errors up the stack so you never know where the origin of the error was. So very much boilerplate to expand simple activities into long unreadable functions. Various Go problems I’ve hit can be ameliorated if you “don’t do it like that”, but in the real world people “do it like that” all the time.
I’m really starting to feel like there are a lot of people in the company I’ve joined who like to keep their world obtuse and convoluted for job security.