Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Visual Studio Code for Go

github.com

Post reply on HN
Print view View original

131–140 of 223 posts

Re: Visual Studio Code for Go

#131

Post by teh_klev »

_pmf_ wrote: post #120
atonse wrote: post #2

I'm going to add the customary "I love this new MS" line here. About 10 years ago a friend of mine offered to make an introduction with her cousin, who was an exec at MS, to see about a job when I got out of college. I said "no way, they're working on such boring and dull stuff there" But after having worked in C# for a few years now (loving the language) and seeing all the open source moves they're making, it seems…

I'm kind of a MS fanboy, but please don't believe their lies: - VS is still not free; the community edition can only be legally used by very small companies with slim revenue - the Xamarin acquisition will turn out to be a slap in the face of developers who want to cross target Android and WP - the desaster of the Metro App API that has been replaced by UWP after being hailed as the future of application development…

> but please don't believe their lies

That's a somewhat harsh accusation, where are they lying? Their web page clearly explains the usage scenarios and who can use it for "free" [0] (scroll down to "Usage").

[0]: https://www.visualstudio.com/en-us/products/visual-studio-co...

Re: Visual Studio Code for Go

#132

Post by lukehoban »

bigdubs wrote: post #107
lukehoban wrote: post #16

Maintainer of the extension here. Happy to answer any questions about VS Code or the Go support specifically.

Can jump to definition jump to a definition in an open file instead of opening a duplicate file? Is this handled within the extension or vscode itself? Thanks for the hard work btw, vscode+go has made my team much more productive.

Go to Definition will navigate to the definition in an existing open document or open the document if needed. This works across packages in your GOPATH, and also for core Go APIs in GOROOT.

This is all handled in VS Code itself through it's (relatively high-level) extension API[0].

[0] https://code.visualstudio.com/docs/extensionAPI/vscode-api#D...

Re: Visual Studio Code for Go

#133

Post by fapjacks »

schmichael wrote: post #14

We're a 100% Go shop and everyone on my team but me uses Visual Studio Code for Go. It's really amazing. (My mind has just been so corrupted by years of vim usage I'm trapped.) 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.

To be fair (and I can't believe I'm saying this), Bill Gates is spending a third of his time punching the clock at Microsoft, advising Nadella. It may not have been technically possible in the Gates era for this to happen, but I certainly agree with you on the Ballmer point. Anyways, I've been wondering how much of this Gates is responsible for.

Re: Visual Studio Code for Go

#134

Post by darrenkopp »

_pmf_ wrote: post #120
atonse wrote: post #2

I'm going to add the customary "I love this new MS" line here. About 10 years ago a friend of mine offered to make an introduction with her cousin, who was an exec at MS, to see about a job when I got out of college. I said "no way, they're working on such boring and dull stuff there" But after having worked in C# for a few years now (loving the language) and seeing all the open source moves they're making, it seems…

I'm kind of a MS fanboy, but please don't believe their lies: - VS is still not free; the community edition can only be legally used by very small companies with slim revenue - the Xamarin acquisition will turn out to be a slap in the face of developers who want to cross target Android and WP - the desaster of the Metro App API that has been replaced by UWP after being hailed as the future of application development…

The plugin in question works with visual studio code though, not visual studio community edition. VS Code is free and open source.

Re: Visual Studio Code for Go

#135

Post by lukehoban »

nulltype wrote: post #113
lukehoban wrote: post #16

Maintainer of the extension here. Happy to answer any questions about VS Code or the Go support specifically.

Hi! I made some Go customizations for atom, and there were a few things that I thought worked pretty well, maybe consider adding them to this project: 1) Auto GOPATH detection: since all code is located underneath a canonical GOPATH, if the GOPATH is not set, traverse upward a few directories until you find one with a "src" folder in it. This means that I don't have to launch it from a terminal and deal with environm…

Thanks.

#2 is something we definitely want to do with the VS Code extension as well. https://github.com/Microsoft/vscode-go/issues/5

#1 is also a good idea, we currently offer a per-project setting to configure this, but could also guess better in the case that no GOPATH is set.

Re: Visual Studio Code for Go

#136

Post by itslennysfault »

wvenable wrote: post #121
itslennysfault wrote: post #95

Earlier quoted context omitted.

I use VSCode daily and I love it. 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 yo…

I feel like these editors that pull in entire browser runtime and run JavaScript aren't really light weight or stable. It takes about 3 seconds for Visual Studio to open on my desktop; not exactly forever.

Loading Visual Studio is (decently) fast. Loading a solution with 1000s of files takes FOREVER compared to VSCode which loads basically instantly because it's folder based.

Re: Visual Studio Code for Go

#137

Post by lukehoban »

tejinderss wrote: post #118
lukehoban wrote: post #33

Earlier quoted context omitted.

Yes.

Is there a plan to release python plugin as well??

There is a Python plugin for VS Code available already [0]. I believe the PTVS folks are also working on a plugin for VS Code as well [1].

[0] https://marketplace.visualstudio.com/items?itemName=donjayam... [1] https://news.ycombinator.com/item?id=10589451

Re: Visual Studio Code for Go

#138

Post by lukehoban »

jamra wrote: post #42
melling wrote: post #23

Earlier quoted context omitted.

Can anyone who uses Visual Studio Code compare its functionality to the native Visual Studio? I forgot about this project because it's seldom mentioned: https://code.visualstudio.com/Download

Code completion is not as good. I believe VSC uses gocode. VS 2015 also has a cool new feature that shows you references to each function right above the function declaration. Clicking on the reference count will open a quick jump contextual menu. 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 t…

> VS 2015 also has a cool new feature that shows you references to each function right above the function declaration. Clicking on the reference count will open a quick jump contextual menu.

This feature is actually also available in VS Code[0], though only for C# currently. We should be able to add support for this in Go as well[1].

[0] https://code.visualstudio.com/Docs/editor/editingevolved#_re...

[1] https://github.com/Microsoft/vscode-go/pull/75

Re: Visual Studio Code for Go

#139

Post by teh_klev »

michaelwww wrote: post #116
teh_klev wrote: post #90

Earlier quoted context omitted.

Is that all fully/smoothly integrated into VSCode? Along the lines of setting a breakpoint in PHP Storm and waiting for it to light up when it's hit? If so, that's sweet.

Yes, yes it is sweet. Set a breakpoint in VSCode editor, run, inspect some variables in VSCode editor debug panel, stop debugging, fix code, run with debugging again -- everything you would expect from smooth debugging experience.

Thanks, I'll revisit VSCode again.

Re: Visual Studio Code for Go

#140

Post by Locke1689 »

pcwalton wrote: post #57
ngrilly wrote: post #45

Earlier quoted context omitted.

> Go uses channels for all concurrency. Go uses goroutines for concurrency, not channels. Goroutines are like threads, but they are managed by the Go runtime instead of the OS, and they use less system resources (a new goroutine uses just a few kilobytes, and its stack is resized on demand if necessary). Go uses channels as a synchronisation mechanism. But other synchronisation mechanisms can be used (i.e. mutexes or…

> I very much like the async/await mechanism offered by C# or Python because it makes side-effects explicit. It's also potentially faster and more efficient than goroutines, because it packs the state to be shared on context switches into what is typically a very tight structure instead of saving the entire stack. > I think that error handling is still a subject of tension in every language and the problem is not ful…

It's also potentially faster and more efficient than goroutines, because it packs the state to be shared on context switches into what is typically a very tight structure instead of saving the entire stack.

I'm sure you already know this, but for anyone new to design in concurrency backends, not only does async/await (CPS) have the potential to really trounce goroutine-style concurrency in modern systems, but if you have a really smart compiler and some OS support, it can really fly. See Joe Duffy's blog post about asynchrony in Midori for more info[1].

[1] http://joeduffyblog.com/2015/11/19/asynchronous-everything/

Post reply on HN