I don't think anyone is arguing that emacs is *incapable* of being a good editor for Go and Python. I personally just don't want to. These same reasons are as applicable to emacs as they are to (neo)vim (which I used as my daily driver for a while).
1. I don't really want to bother with a DSL for configuring my editor (even if the language is usable outside of that context for other things)
2. I don't have time to bother with maintaining extensive configuration to get the level of code completion/refactoring/etc that I expect from a modern IDE (nor do I want to have to stop what I'm trying to work on to debug a problem with my config)
3. I don't want to have to research various plugins and stuff to provide functionality that I get out of the box with VS Code (or other editors)
4. I don't want to have a bespoke environment that only I understand when I'm trying to collaborate with my teammates
Don't get me wrong: I think digging into emacs and/or (neo)vim is a valuable thing to do and that everybody probably *should* do it at some point (even if only as an academic exercise), but to assert that they are a viable path for everyone is ignoring the reality that some people simply aren't interested in investing that time/effort into getting their tools working.
One can argue whether or not that stance is a good one or not, but you're just debating personal preferences and priorities at that point.
> I don't think anyone is arguing that emacs is *incapable* of being a good editor for Go and Python.
On the contrary, the article said, literally: ”We are primarily a Go and Python shop, which means our only real option is VSCode”. Meaning they do not consider Emacs to be a ”real” option. This is expressing more than mere personal preference; it is, at best, profound ignorance of what Emacs is capable of.
IMO, emacs isn't a real option when you're talking about a group of developers. The people for whom emacs is a real option likely already use emacs (same with (n)vim), but that choice is made at the individual level, rather than at the team level.
It's unlikely that a given team/workplace is going to roll out dev tooling that is just a pile of elisp. With VS Code, you can drop a couple of JSON files into your project, commit and push them, and then everyone has a preconfigured set of tools that match the needs of that project.
