It's bizarre to think my team writes in a language created by Google in an editor created by Microsoft on System76 laptops running Ubuntu. Never would have been possible in the Gates or Ballmer eras.
I think vim + vim-go is still the best go editor if you know vim. It just works and it gets updated frequently.
The editors in VSCode and Atom are completely different implementations.
I've never used IntelliJ's Go tools, but VS Code is much better at that stuff in Go than Python. (I believe it uses third-party open-source tools in both cases; code intelligence for a statically typed language like Go is probably much simpler which probably helps.)
The best way to look at VS Code is as an IDE minus the 'integrated' bit - instead of having the core editor and UI bundled in with all the code intelligence stuff for a specific set of languages, it's a text editor with a code intelligence and debugger UI, that calls out to out-of-process plugins to do the heavy lifting.
uggh! yes :) I tried checking out atom and installed the facebook extensions to see what the fuss was all about. It was so slow I could only successfully open it 50% of the time.
> a language created by Google
by guys using Macintosh laptops
> in an editor created by Microsoft
At a plan9 conference when people turned up with Mac laptops, Brucee (who wrote considerable portions of Go's ancestors - Inferno & Limbo) remarked to me : "the interesting thing about the Mac was that it wasn't X86 and it wasn't Unix ... now it's both!".
> You will need to apply these changes after every update to disable collection of usage data. These changes do not survive product updates.
Alternatively, you can just edit them out of the product.json from the release build that you download from MS.
Never had any issues with this setup.
A monorepo a fantastic way to live, but I totally understand that it doesn't work for everyone.
Yes, a single GOPATH/workspace for all projects, as it is described here:
I ended up git cloning into my %GOPATH%\src\golang.org\x from https://go.googlesource.com/tools and https://go.googlesource.com/net - that seems to have fixed it.
By the numbers I'd go for System 76 again, but if the chassis isn't any better these days I'd probably go back to Lenovo.
Admittedly, I use a Thinkpad t430 and a MacBook Air myself, but if I didn't have more laptops than I knew what to do with, I'd be considering Thinkpenguin (though, I'm of the same mind as Linus Torvalds, http://www.cultofmac.com/162823/linux-creator-linus-torvalds... , so I'd be likely to get a refurb'd MacBook Air).
Edit: link to Thinkpenguin site: https://www.thinkpenguin.com/
They are getting very close. I work in very quiet environments and I hate fan noise. Also no moving parts!
I installed some backport which seems to turn off/on at times.
I don't think there are decent brands for linux, or it might require deeper pockets. That's the cost of not working with microsoft.
I'm very happy with the setup.
Something worth to consider :)
Just make sure their chassis/build quality is better than it was a couple years ago. Otherwise in a year you'll have broken bits and a faded scratched screen.
Just heard from a coworker after I posted this he's switching back to vim because the vim plugin for VS Code isn't quite there.
It has most of the basic stuff working. I will admit that with the auto complete and what not it isn't quite like my native vim experience. I have actually been thinking about disabling it and just trying to learn the VScode short cuts.
Numeric arguments (3dd, 2x, ...)
support for combining commands (ci[, cW, ggVG, ...)
Disclaimer: I'm on the VS Code team. Ping me on Github @waderyan or Twitter @waderyan_.
Both amVim and VSCodeVim still have problems that mean they're not drop-in replacement for even stock Vim, but most of them come down to limitations in the VSCode extension APIs at this point.
The integrated debugger via delve is absolutely great.
I've always been a fan of lightweight text editors and always choose speed over piles of functionality. To me Visual Studio feels like trying to run while wearing cement shoes. It takes forever to load and crashes/freezes far too often for my taste.
VSCode is amazingly light weight and stable and brings in IntelliSense, basic refactoring tools, and pretty solid git integration.
If you're used to using a full-featured IDE like Visual Studio (etc) you'll probably find VSCode lacking (but blazingly fast). If you're used to using sublime, atom, etc... You'll find VSCode to be feature rich and comparably fast.
(I work at Microsoft, but not on VSCode or Visual Studio. These opinions are my own and don't represent Microsoft)
It takes about 3 seconds for Visual Studio to open on my desktop; not exactly forever.
But seriously, if you're running Windows and have a VS license, use VS. Otherwise use VSCode.
VSCode is the best IDE for TypeScript. Some will point at atom, they are wrong.
An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.
For all other usage scenarios:
In non-enterprise organizations, up to five users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.
I wouldn't compare the two products. VS has a SQL editor. It manages database connections. There is an integrated merge tool that is actually quite good. You have project templates, which I haven't found with VSC (I haven't really looked).
This feature is actually also available in VS Code, though only for C# currently. We should be able to add support for this in Go as well.
But PLEASE enable basic drag and drop text editing as soon as you can. Since the 1980s, EVERY text component, text editor, IDE, and word processor Microsoft has ever made has had the basic editing ability to drag a selected bit of text and drop it into a new location, with the maddening exception of VS Code where, when you try to drag your selection, you just lose the selection.
There are multiple requests for this in the feature request section of the VSC website, but unfortunately everybody calls it by a different name, so a single, higher-priority issue that would be suggested to most voters as they look over the top of the list is instead recorded as a bunch of low-priority issues lost down in the weeds, discovered by so few that it keeps getting recreated as a new issue.
Well, most editors and even IDEs don't offer one.
>and I can't for the life of me imagine a reason to not include it.
The reason being that terminal semantics are hell difficult to implement, and doubly so in a web-based stack?