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

191–200 of 223 posts

Re: Visual Studio Code for Go

#191

Post by jve »

epoch1970 wrote: post #164
jve wrote: post #109

Earlier quoted context omitted.

I'm having almost 34k lines of code for some html file, over 6mb (yes, there is a specific purpose for such a large html file for particular processing) and it works flawlessly in VS Code. I remember searching for text editor that would handle the file nicely and allow working with it. Opening that file in the first VS Code release was a pleasant surprise that performance was good. If I remember correctly I tried Ato…

How is a 6 MB file, with only 34,000 lines, considered "large" these days? Smartphones from a couple of years ago already had multi-core, multi-GHz processors, and 2 GB or more of RAM. A 6 MB file would fit into memory well over a hundred times, even assuming lots of overhead. Any moderately reasonable text editor should be able to handle a file of that size with total ease, at least for the basic operations.

I agree that it is not and was surprised that I had to search for a text editor that would handle that file nicely, provide syntax highlighting and allow me to do some regex search/replace.

Re: Visual Studio Code for Go

#192

Post by jamra »

lukehoban wrote: post #138
jamra wrote: post #42

Earlier quoted context omitted.

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://gith…

That would be amazing. It's a great way to study an unfamiliar code base. It's a great feature on its own as well.

Re: Visual Studio Code for Go

#194

Post by ridiculous_fish »

lukehoban wrote: post #183
ridiculous_fish wrote: post #168

Earlier quoted context omitted.

Hi! My Go project directory has ~2 million data files under a directory called test. When I open the project directory, VS Code starts going through all of them, consuming a lot of memory and IO bandwidth. Is there a way to make it ignore that directory? I tried "files.exclude" which hides it from the sidebar, but VS Code still tries to walk the entire directory tree.

I'd love to get more details on this. Open an issue on GitHub?

https://github.com/Microsoft/vscode/issues/3703 . Thanks!

Re: Visual Studio Code for Go

#196

Post by ngrilly »

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.

A context switch to another goroutine doesn't need to "save the entire stack". The stack is already there. The runtime just needs to keep a pointer to the stack of the suspended goroutine. And the stack is usually just a few kilobytes.

Moreover, keeping the stack is useful for debugging because you can print a nice stack trace.

Re: Visual Studio Code for Go

#197

Post by nulltype »

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…

I have a similar setup, but I actually alias the go command itself so I don't have to type anything special.

Re: Visual Studio Code for Go

#198

Post by ngrilly »

KirinDave wrote: post #85
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…

> Go uses goroutines for concurrency, not channels. This is more of a practical piece of advice than a strictly correct one. In practice, Go concurrency means typing "go" but thinking in terms of channel groups and one-off channels. I just don't find that distinction very productive when someone asks how it "feels" or what it is "like" to program in Go as opposed to asking for an explanation of Go's concurrency model…

> I really think Common Lisp had a fantastic solution here and I miss the evolution over try-catch they spec'd.

Are you thinking of Common Lisp's conditions/handlers/restarts? I've never programmed in Common Lisp but have always been intrigued by this idea.

> This is in sharp contrast to Maven or others where build artifacts can exist entirely outside of the expectation of use in the build chain

Ok, I think I understand now. So you'd like to be able to use "prebuilt" dependencies in Go (delivered like a .so in C++ or a .jar in Java)?

Honestly, the compilation is so quick, and the advantages of a statically linked executable are so great, that I have trouble imagining why I would want that. In Go, instead of saving the dependency as a .jar file (for example), I just saved the dependency source in the `vendor` directory. For the record, this is exactly what big projects like Chromium do in C++.

Re: Visual Studio Code for Go

#200

Post by ngrilly »

pcwalton wrote: post #151
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…

> 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 renderer. (source: https://github.com/phildawes/racer/issues/337)

But my real concern is how to write refactoring tools when macros are implied. It's seems a lot harder than writing static analysis tools, because the refactoring tool wants to examine the source code with macros expanded, but has to modify the source code with macros unexpanded. In other words, the tool has to map from source with expanded macros, back to source with unexpanded macros. How do you solve that?

As a sidenote, I agree that refactoring generated code doesn't sound fun too :-)

> How does that describe an unsolved problem? It illustrates that Rust's bifurcation of errors into Result and panics works.

I quoted kentonv here because it shows that Rust and Go have converged towards structurally similar solutions to error handling, by using two complementary mechanisms: explicit error checking one one hand (using Result in Rust and using multiple return values in Go) and panic/recover on the other hand.

The big difference is that Rust have sum types (instead of using multiple return values in Go) and macros (try! instead of repeating `if err != nil { return err }` in Go).

> Catching panics is important, yes. No argument there. It doesn't change the overall structure of Rust's error handling story, though.

You're right.

Post reply on HN