[yeukhon]

When I left Facebook, I missed all the internal tools the company developed. I currently work on dev tooling at my company (though leaving soon). So I have some thoughts as well.

Having been at facebook prior led me to believe that we can definitely 2x productivity if tools made by these large organizations are open sourced and maintained.

I will probably write my thoughts like the author (if anyone cares), but the bottom line is I consistently find many existing open source projects missing critically useful features and/or don’t focus as much on real developer productivity (I admit that can be very subjective).

Eg Bazle is fantastic when it works (all deps are accounted for) but it is not unusual to find github comments that tell users to add patches because the maintainers (core and contrib) haven’t fixed the problems (some over 2-3 years old) or because they hardcode a version of Go….

Another example is VS Code. facebook (now meta) offered everyone to its heavily extended VS Code. While I didn’t use that as much since I am a terminal and a Vim developer, now that I use VS Code almost daily at work for writing Go, I really do appreciate the customization facebook engineers did - because too often someone (both engineers and non-engineers) would come to us and complain about some issues with the built-in git UI, trying to figure out how to construct a working workspace settings, switching between git and arcanist. The facebook’s version had all this figured out really nicely. With minimal training someone could submit code very quickly without ever touching the terminal.

I can go on and talk about how awesome ods is compared to prometheus and its query UI. Finally, I miss Scuba too (and Honeycomb founders were involved building Scuba).

Sure, facebook tools don’t always work and there are issues and bugs like any software, but overall I felt more productive.

Maybe it is because I did’t maintain them - now I do as a full time engineer at work, I feel the pains. But then again, if google and facebook maintain these as open source would be really nice.

[nwsm]

> VS Code almost daily at work for writing Go

How would you rate VS Code for Go? I use the official Go extension but am not impressed. My main gripe is that I often have to manually add a local import that should have been found and suggested when I typed the name of a variable or function exported from an adjacent package. I much prefer Goland, but use VS Code because it is the only editor my company's internal AI code assistant supports.

[Groxx]

VSCode for Go is pretty much just gopls (the language service). So this is all true for Go plugins in vim, emacs, etc because they all use the same base, but not GoLand.

IMO: gopls is only just barely good enough to stop people from building an actually good replacement. Highlighting and build error stuff is reliable, but it regularly misses extremely straightforward type lookups, navigation, and autocomplete hints and that makes it untrustworthy in pretty much all cases. Basically everyone I know who uses it (somewhere between 50 and 100 people that I've talked with about this) relies on plain text search to get around and find things rather than doing type-driven stuff, because otherwise they fail to discover a lot.

All of which means it's insane and awful to me, barely better than "it doesn't support Go but Go looks close enough to C that it mostly works"-style ctags. And sometimes worse: even unsupported-language-fallback stuff in random tools sometimes gives much better autocomplete than gopls, which for me semi-routinely fails to hint things defined in the same file.

---

GoLand by comparison is wildly more capable, stable, and controllable. It actually works, and e.g. if you "find usages" you get a complete and precise result. Highly recommended if you do a lot of Go work. The single exception is that it doesn't support GOPACKAGESDRIVER (because it isn't gopls), so if e.g. you've got a complicated/abnormal Bazel setup it won't integrate well.

[yeukhon]

Surprisingly it works pretty well for me. Where we work we have a weird go and non-go module setup but everything works with almost no additional tweaking on vscode side, just exporting some env variables.

But Python? I hate the testing setup. We have a mono repo, while not as big as meta’s, full discovery eats cpu. So we had to tweak our settings, per team, to only discover team specific dirs. Also, there is no way to kill a running test (at least no obvious shortcut or button-wtf)

[candiddevmike]

Have you ever had VScode add an import prefixed with your vendor path instead of real module path? It doesn't happen too often but it's goofy when it does.