Does anyone use Emacs to development big Golang project like Kubernetes?

I've been using Emacs([Doom Emacs](https://github.com/hlissner/doom-emacs)) for Golang development for a while and everything is good so far, but I really have troubles when I use it to explore Kubernetes source code today, everything is very very slow which makes the entire editor almost unusable: gopls seems not respond at all, guru eats all of the CPU but all features just not working, and I even got the following error messages for simple saving: >Error: (doom-hook-error before-save-hook format-all-buffer--from-hook (error "Timeout while waiting for response. Method: textDocument/formatting")) Is Kubernetes too big for Emacs to work on? Does anyone have successful experience of using Emacs with projects as big as kubernetes? Could you please share with me your configuration? Thanks for any help and tips:')

Whats the usage for your gopls process look like while doing this? Gopls can be really bad with memory usage on very large projects, scaling with the # of pkg imports and their sizes but usually its not a big issue Im not a doom emacs person but if your gopls is not responding and its setup to run gofmt to format your buffer (fixing indentation, whitespace, imports, etc.) before saving could that be the source of the timeout?

Chances are your problems are gone as soon as you stop using someone's starter kit. Vanilla Emacs is pretty snappy, though bare. I know someone working on big Java codebases using very little customization and he prefers it over IntelliJ for raw speed. Instead he relies a lot on M-x grep and puts in extra leg work for finding the parts of the codebase that require his attention. Kind of like a photographer intentionally using a viewfinder camera instead of a DSLR.

I use Emacs to develop go for 2 years, in my experience: 1. Update gopls to latest version. 2. Use 'apheleia' to format files, it won't stuck Emacs gui. 3. For BIG project, you can also use tags, see 'citre'. And maybe you should check if Vanilla Emacs slow too, most of time Emacs gets slow is because of some 'not good' plugins, if its still slow, by goland or use tags, because vscode also use lsp. Also, its a good idea to use eglot instead of lsp-mode(at least for myself), use flymake instead flycheck, I don't know why but flycheck always make my laptop very hot.

https://github.com/jacktasia/dumb-jump (with ripgrep or git grep) is also very good for large projects where lsp servers struggle.

I recommend https://github.com/jacktasia/dumb-jump

Goland works very smoothly once indexing is done, I'm also very much suspect that it's caused by some Emacs plugin but not sure which one. Thanks for your help and I'll give your suggestions a try:-)

Thanks for your tip

Gopls process has a high memory usage but the cpu usage seems OK, I'll keep checking to see if gofmt-before-save is the root cause

Speed of Emacs on Java codebases can be faster than IDEA? With features of [lsp-java](https://github.com/emacs-lsp/lsp-java) ? How could it possible\~\~

I don't know how big this is vs. kubernetes, but work has a ~80kLOC monorepo, and it works okay. The recent versions of gopls are better, but still not very good. About 50/50 chance that it'll completely lose its mind and start complaining about inconsistent vendoring when I switch branches. It's unreliable, but not slow.

No, without those features. Despite popular belief, features do have a cost.

“Someone’s starter kit” is a *little* dismissive for a project with nearly 14k stars on GH, wouldn’t you say?

It's a starter kit. Doom and its ilk have brought a lot of new users to Emacs but also have given the impression that vanilla Emacs is unusable and too hard to configure yourself, and also that Emacs is slow. We have a generation of adopters who think they don't need to know how Emacs works and that they can treat it like visual studio.

There is nothing wrong to use Emacs without endlessly tinkering with the configs (as in, like visual studio). The "need" to know emacs-lisp in order to use Emacs is its largest roadblock towards mass adoption, which is what Doom is trying to reduce.