Modules and gopls (in VSCode)

[Paul]

Hey everyone,

Please don't take this as a rant, but rather as a bit of an "experience" report.  I don't expect answers or suggestions, but I did think that I should share so that the Go team would be aware.  And yes, I still love Go.  ;)   I am also keenly aware that I'm still doing some things "incorrectly", but at least I can now compile to fix bugs, which wasn't the case for the better part of a week.  One of the reasons I love Go (been using it since rc1 years ago, and in production here since v1), is its simplicity.  I'm a very old-time C programmer and the whole GOPATH way of working was very natural to me.  It's inevitable, but Go is becoming less "simple".

First a little background.  I'm a "lone wolf" programmer, but working on a reasonably sized microservice system.  I've never had to use any versioning system here so the switch to Go Modules was a steep learning curve for me, having decided to put everything into our git instance (which happens to run with GitLab), as well as to "modularize" my packages.  That whole process was very painful indeed and has taken close to two weeks.  I found the instructions somewhat unclear for anyone who doesn't use git.  Maybe it's just me, but I just couldn't wrap my head around seemingly having to use some fake (example.com) domain.  However when I tried to use basic file paths without the domain I was getting "the beginning of your path doesn't have a 'dot' in it" type errors.  So after struggling for a couple of days I decided to just do it the same way the blogs and tutorials do it, so that I could follow along better.  Besides, it really was time to start using our git instance anyway.  I think I'm through it now, but it was scary there for a while in that I couldn't even fix bugs.

As for gopls, I have to say that at this point it seems to be really CPU intensive.  I use VSCode and I had to put all 137 modules in the "root tree" so to speak, rather than breaking them into the 5 or so logical areas that I usually would do.  But since they are all individual Go modules I had to structure it that way (I guess changes are coming regarding this?).  It has become rather difficult to find the various modules I'm working on, but that's a minor irritation.  Worse though, is that when I start VSCode, gopls jumps to ~150%+ of CPU, this being on a System76 Linux laptop with an Intel Core i7, and it stays at that load for a good 10+ minutes.  It also seems to do that every time I make a few changes as well.  In fact my laptop fans just stopped screaming after a good 20 minutes since my last minor changes.

Similarly, as I'm typing code, the computer pauses rather significantly at times now.  I suspect gopls is looking stuff up?  It's also slower when looking up autocompletions.

One last thing regarding modules, and I know that the Go folks have nothing to do with this, but when some libraries that are produced by some reasonably big'ish organizations haven't "modularized" their code, it can make the process that much more difficult to deal with.  etcd client is a good example where I ran into this.  And yes, I know about the "replace" directive.  I'll maybe try that later, but baby steps.  ;)

FWIW folks.

cheers,

Paul

[Peter Bourgon]

I don't have enough context about your development environment to say you're using modules ·incorrectly·, but I'm fairly certain you're making life significantly harder for yourself by trying to work with 137 (!) of them at once. It is totally unsurprising that gopls is having trouble with that, as, normally, you work with just one module at a time. That's because you don't "modularize" your packages individually — modules are typically one-to-one with code repositories, and contain many packages.

[Kevin Chadwick]

On 3/8/21 12:04 AM, 'Peter Bourgon' via golang-nuts wrote:
> I don't have enough context about your development environment to say
> you're using modules ·incorrectly·, but I'm fairly certain you're making
> life significantly harder for yourself by trying to work with 137 (!) of
> them at once. It is totally unsurprising that gopls is having trouble with
> that, as, normally, you work with just one module at a time. That's because
> you don't "modularize" your packages individually — modules are typically
> one-to-one with code repositories, and contain many packages.

The docs such as "how to write code", and it's sub links, need to be
restructured to make this an easier and clearer read.