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

201–210 of 223 posts

Re: Visual Studio Code for Go

#201

Post by ngrilly »

Manishearth wrote: post #175
ngrilly wrote: post #146

Earlier quoted context omitted.

Rust error handling can be concise thanks to the try! macro, but macros bring their own problems (like making more difficult to write refactoring and static analysis tools). Haskell error handling can be concise thanks to monads, but they need higher kinded types which bring their own share of complexity. The conversation on the "RFC: Stabilize catch_panic", found on Rust's issue tracker, illustrate some unsettled qu…

> like making more difficult to write refactoring and static analysis tools As one of the people behind a lot of the out-of-tree static analysis in Rust (clippy, tenacious, Servo's lints) I'd disagree. Performing static analysis across macro boundaries is easy. The only problem Clippy has with macros is that the UX of the linting tool is muddled up at times. Clippy checks for many style issues, but sometimes the styl…

I replied to pcwalton in a sibling comment:

https://news.ycombinator.com/item?id=11222862

Re: Visual Studio Code for Go

#202

Post by andrewingram »

tmzt wrote: post #182
andrewingram wrote: post #162

I hate to be that guy, but I guess I will, because aesthetics are important to me when choosing a tool i'll be using for several hours a day. I love how Atom looks. Alongside the nicer extension system, the aesthetics of the default theme are what lured me away from Sublime Text. I sadly can't say the same for Visual Studio Code, which I hear so many great things about, but can't bring myself to use for more than a f…

There is support for full color schemes for the entire UI not just the text colors. There is also support for loading TextMate and Sublime themes. https://code.visualstudio.com/docs/customization/themes I personally use a nice dark theme, similar to the one shown in that screenshot. There are also a large range of extensions and VS Code is really fast.

What about changing the appearance of the fairly unpleasant left-most bar (with the code/search/version/debugging switcher), the super in-your-face status bar, etc?

Re: Visual Studio Code for Go

#203

Post by Manishearth »

saiki wrote: post #15

I have been working for sometime with Visual Studio Code and with this Go extension. I used to use Sublime 3 for Go development, but with this extension I have noticed that I use more often vscode than sublime for Go development. It is also a big plus that vscode works very well with TypeScript and you can work seamlessly with TypeScript front and Go backend code. One nice thing is that you can navigate e.g. function…

Note that YouCompleteMe supports Jump To Definition for Go. (YCM has a sublime plugin, among other editors)

Re: Visual Studio Code for Go

#204

Post by Manishearth »

ngrilly wrote: post #200
pcwalton wrote: post #151

Earlier quoted context omitted.

> Rust error handling can be concise thanks to the try! macro, but macros bring their own problems (like making more difficult to write refactoring and static analysis tools). No, it's not more difficult to write static analysis tools. You use libsyntax as a library. Refactoring tools, maybe, but it's a lot better than refactoring with code generation :) > For example, kentonv wrote: How does that describe an unsolve…

> No, it's not more difficult to write static analysis tools. I agree it's solvable, but I'd argue it's a bit more difficult to write static analysis tools when macros are implied. But maybe I'm missing something. Here is an example: The subsystem types in the sdl2 crate starting in 0.8.0 are generated by a macro, so racer has issues evaluating the type of video(). A workaround is to explicitly declare the type of re…

> a bit more difficult to write static analysis tools when macros are implied. But maybe I'm missing something.

Most Rust static analysis tools hook into the compiler and get this for free.

Racer has that problem because racer implements a rudimentary minicompiler that's much faster than Rust. When you want autocompletion, it needs to be fast. Running a full type check is a non-starter here. So you implement your own "type searcher" which is able to perform some level of inference and search for items. Being deliberately incomplete, it doesn't handle some cases; looks like macros are one of them. Since racer uses syntex handling macros would not be much harder (just run the macro visitor first; three lines of code!), but I assume it doesn't for performance reasons or something.

(disclaimer: I only have a rough idea of racer's architecture; ICBW)

> But my real concern is how to write refactoring tools when macros are implied

This is a problem with refactoring whether or not you're using tools. And like you mention there's exactly the same problem with generated code. If anything, Rust macros being hygenic are nicer here, since you can trace back where the generated code comes from and _attempt_ to refactor the source.

And macros like try do not affect refactoring tools at all; being self-contained. Its user-defined macros that mess things up.

Re: Visual Studio Code for Go

#205

Post by ngrilly »

Manishearth wrote: post #204
ngrilly wrote: post #200

Earlier quoted context omitted.

> No, it's not more difficult to write static analysis tools. I agree it's solvable, but I'd argue it's a bit more difficult to write static analysis tools when macros are implied. But maybe I'm missing something. Here is an example: The subsystem types in the sdl2 crate starting in 0.8.0 are generated by a macro, so racer has issues evaluating the type of video(). A workaround is to explicitly declare the type of re…

> a bit more difficult to write static analysis tools when macros are implied. But maybe I'm missing something. Most Rust static analysis tools hook into the compiler and get this for free. Racer has that problem because racer implements a rudimentary minicompiler that's much faster than Rust. When you want autocompletion, it needs to be fast. Running a full type check is a non-starter here. So you implement your own…

> Most Rust static analysis tools hook into the compiler and get this for free. Racer has that problem because racer implements a rudimentary minicompiler that's much faster than Rust.

I didn't know that. Understood. Thank you for the explanation.

> And macros like try do not affect refactoring tools at all; being self-contained. Its user-defined macros that mess things up.

What do you mean by "self-contained"? How is it different from user-defined macros?

Re: Visual Studio Code for Go

#206

Post by agnivade »

andrewingram wrote: post #162

I hate to be that guy, but I guess I will, because aesthetics are important to me when choosing a tool i'll be using for several hours a day. I love how Atom looks. Alongside the nicer extension system, the aesthetics of the default theme are what lured me away from Sublime Text. I sadly can't say the same for Visual Studio Code, which I hear so many great things about, but can't bring myself to use for more than a f…

You are right. But when you see how much memory Atom takes and compare that to how lightweight Sublime is, you might want to reconsider.

Re: Visual Studio Code for Go

#207

Post by miguelrochefort »

_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…

> XAML + C#

Xamarin enables that.

Re: Visual Studio Code for Go

#208

Post by Manishearth »

ngrilly wrote: post #205
Manishearth wrote: post #204

Earlier quoted context omitted.

> a bit more difficult to write static analysis tools when macros are implied. But maybe I'm missing something. Most Rust static analysis tools hook into the compiler and get this for free. Racer has that problem because racer implements a rudimentary minicompiler that's much faster than Rust. When you want autocompletion, it needs to be fast. Running a full type check is a non-starter here. So you implement your own…

> Most Rust static analysis tools hook into the compiler and get this for free. Racer has that problem because racer implements a rudimentary minicompiler that's much faster than Rust. I didn't know that. Understood. Thank you for the explanation. > And macros like try do not affect refactoring tools at all; being self-contained. Its user-defined macros that mess things up. What do you mean by "self-contained"? How i…

> What do you mean by "self-contained"?

It doesn't introduce any new identifiers or anything. As far as refactoring is concerned, it's just another block with nothing interesting inside it. This is sort of highlighted by the fact that we can and do plan to add syntax sugar for try!() -- if it was a language feature it wouldn't cause refactoring issues, so why is that the case here?

User defined macros (there may be some exported library macros that do this too, but try is not one of them) may define functions or implement traits or something, which might need to be modified by your refactor, which might need fiddly modification of the macro internals.

(Also, note that due to Rust's macro hygiene, all variables defined within a macro are inaccessible in the call region, unless the identifier was passed in at the call region. This helps too)

Re: Visual Studio Code for Go

#209

Post by KyleBrandt »

jzelinskie wrote: post #186
namelezz wrote: post #62

Earlier quoted context omitted.

For this extension to work, you need to install several Go tools in GOPATH. How did you manage your GOPATH across multiple projects? Do you have a single GOPATH for every project or each project has its own GOPATH?

I have a single $GOPATH per project and always recommend doing so. If you vendor code with a tool like godep[0], having one shared $GOPATH is a nightmare. Other tools might work better, but this is basically the standard for the projects I work on. I basically just have a zsh alias[1] that combines z[2] and sets the $GOPATH to $PWD split on "src". I do share a single $GOBIN set to $HOME/bin, though. [0]: https://gith…

Using govendor with my stuff and a shared GOPATH. I haven't noticed an issue, I wonder what makes it a nightmare for you?

Re: Visual Studio Code for Go

#210

Post by samuell »

This is great. I love how definitions are display on hovering over any variable or function, the go to definition feature and the split window feature, which makes it sweet and easy to keep reference code bits while coding ... I think with the definition display on hover, it even beats vim.
Post reply on HN