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

211–220 of 223 posts

Re: Visual Studio Code for Go

#211

Post by KirinDave »

ngrilly wrote: post #198
KirinDave wrote: post #85

Earlier quoted context omitted.

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

On Lisp, yes conditions and restarts. The only downside is the feature does inhibit some types of optimizations.

On Go, I honestly don't care if they're prebuilt. The fact the package and build story are linked is not the problem. It's the strange split brain assumption that versioning libraries is bad and taking from a git repo tip is reasonable.

Which is doubly weird because of the human contempt evident in Go. As Pike said, evidently Google employees cannot be trusted to do much off anything. Except, mysteriously, for the rather hard task of never breaking a git master and communicating breaking changes without any signing mechanism.

Vendoring is something you do to aid build times and to improve the simplicity of source distribution. It is misapplied as a substitute for actual versions and developer-focused source and binary packaging.

Vendoring means if I recheck a repo after 2 months of having it run in production I can probably still build it. Probably. But, updating it with the latest security or bugfixes? That is no easier.

Re: Visual Studio Code for Go

#212

Post by pcwalton »

ngrilly wrote: post #196
pcwalton wrote: post #57

Earlier quoted context omitted.

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

You have to keep the stack around in memory, as opposed to having a fixed structure. And fixed structures really pull away when you think about allocation: you can use a segregated fit/free list structure, whereas you can't with a variable sized thing like a stack. If the stack starts small and grows, you're paying the costs of copying and reallocation whenever it does: another loss. Allocation in a segregated fit scheme is an order of magnitude faster than traditional malloc or allocation in a nursery and tenuring.

For these reasons and others, nginx could never be as fast as it is with a goroutine model.

Re: Visual Studio Code for Go

#213

Post by weberc2 »

adambrenecki wrote: post #190
jonesb6 wrote: post #82

Earlier quoted context omitted.

I use Jetbrain's IDEA with a Go plugin and it fits all my needs. Do you know how it compares to VS? Never got into VS myself and i'm hesitant to swap IDE's though I'd be willing to try if it's a significant improvement.

I've switched from PyCharm (based on the same IntelliJ Platform as IDEA) to VS Code, and it's so much faster to work with. That said, I've found that it's not nearly as good at all the code intelligence stuff as PyCharm is. 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…

Dynamic languages make good tooling very difficult. It makes it painful to transition from Go for hobbies to Python for work. :(

Re: Visual Studio Code for Go

#214

Post by KirinDave »

pcwalton wrote: post #212
ngrilly wrote: post #196

Earlier quoted context omitted.

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

You have to keep the stack around in memory, as opposed to having a fixed structure. And fixed structures really pull away when you think about allocation: you can use a segregated fit/free list structure, whereas you can't with a variable sized thing like a stack. If the stack starts small and grows, you're paying the costs of copying and reallocation whenever it does: another loss. Allocation in a segregated fit sc…

This is really interesting, but I feel like Erlang is a counter example. Not sure if that's a good comparison, so I decided to ask and risk sounding stupid.

Re: Visual Studio Code for Go

#217

Post by Eridrus »

melling wrote: post #23
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.

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

It depends a lot on what language you're writing. VS has a lot more features, but they tend to be for more established languages (namely C++/C#).

Re: Visual Studio Code for Go

#218

Post by ngrilly »

pcwalton wrote: post #212
ngrilly wrote: post #196

Earlier quoted context omitted.

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

You have to keep the stack around in memory, as opposed to having a fixed structure. And fixed structures really pull away when you think about allocation: you can use a segregated fit/free list structure, whereas you can't with a variable sized thing like a stack. If the stack starts small and grows, you're paying the costs of copying and reallocation whenever it does: another loss. Allocation in a segregated fit sc…

I agree that a fixed structure is more efficient than a growable stack, especially in terms of memory allocation. But I don't understand how you apply this to an evented server. Asynchronous callbacks are often associated to closures. But closures can vary in size, which makes hard to store them in a fixed sized structure. What am I missing?

I haven't read nginx source code, but I guess they are able to store continuations in a fixed structure because they don't use closures and they know in advance what information must be kept. I don't see how this approach can be used as a general purpose concurrency mechanism for a programming language. But I'd like to learn something :-)

Re: Visual Studio Code for Go

#219

Post by ngrilly »

Manishearth wrote: post #208
ngrilly wrote: post #205

Earlier quoted context omitted.

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

Thanks for the very clear answer.

Re: Visual Studio Code for Go

#220

Post by jongalloway2 »

integraton wrote: post #152
calebegg wrote: post #128

Earlier quoted context omitted.

It can be turned off now: https://code.visualstudio.com/docs/supporting/faq#_how-to-di...

Only by manually editing internal program files using the command line. Also, > You will need to apply these changes after every update to disable collection of usage data. These changes do not survive product updates.

The Feb 2016 release has a new setting that (I believe) persists between updates:

https://github.com/Microsoft/vscode/issues/3182

https://code.visualstudio.com/docs/supporting/faq#_how-to-di...

Post reply on HN