Live data from Hacker News

Visual Studio Code for Go

github.com

101–110 of 223 posts

Re: Visual Studio Code for Go

#101
post #21

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.

I want to start using Visual Studio Code but I am waiting for a VIM emulator plugin that is "good enough" have you tried any of them?

amVim is the better of the two, but VSCodeVim is the one that seems to have the most mindshare (almost definitely because of the name and it came first).

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.

https://marketplace.visualstudio.com/items?itemName=auiworks...

Re: Visual Studio Code for Go

#102
post #79

Earlier quoted context omitted.

> It's inexplicable to me why a language wouldn't allow these loss-less operations to be implicit. Because in some sense implicit behaviour is bad behaviour. It makes it unclear what the code does.

I guess that's exactly what I don't understand. If I add a 32-bit integer and a 64-bit integer, what other possible result could I be expecting besides a 64 bit integer?

> If I add a 32-bit integer and a 64-bit integer, what other possible result could I be expecting besides a 64 bit integer?

A 128-bit integer (if you are adding a 32-bit integer and a 64-bit integer, the smallest power-of-2-bits representation guaranteed not to have an overflow is 128-bits, so its the safest result. Though, I'd agree, not the most likely thing most programmers would intend.)

Re: Visual Studio Code for Go

#103
post #100

Earlier quoted context omitted.

Which System76 laptops? I'm in the market for a Linux-native laptop which'll compile faster than my MBP.

I bought a System76 years ago. It was great as long as I was running Ubuntu, but requires proprietary drivers which have been extremely flaky under Debian. Now I recommend zareason to folks who ask. Typing this comment on a zareason system right now, and I'm extremely happy with it.

Yeah it looks like the consensus is that the System 76s aren't worth it. I'll look into Zareason and Thinkpenguin, thank you very much!

Re: Visual Studio Code for Go

#105

I've never programmed in Go before. Coming from a C# background. Can someone tell me, how does Go feel? Is is pleasant to work in, or is it tricky like C.

Hi. I know C# in amateur fashion and Go professionally. I think a lot of people here will give you a very positive review of Go. Since they've got that covered, let me tell you what you're giving up from C# or F# and why I won't use Go. Maybe you can form a balanced conclusion from the aggregates, because I find Go to be very polarizing. Concurrency Async: Go uses channels for all concurrency. Period. This mechanism,…

I agree with all of the above. If Go is going to improve the quality of your programming experience, then this is a great reason to use it, but if it is going to make things harder for you then stick with what you know.

If you are coming from C#, then you probably wouldn't enjoy checking the results of each and every function call. You know how and when to use exceptions and they will save you many lines of code over using Go.

If you have used generics then you will probably feel like you are back to .NET 1.0 when using Go. You will end up generating code for types or copying and pasting class definitions.

That said, I am all for learning a new language that will teach me a new paradigm. In that case, the loss of productivity is worth it because it will add to my toolset. If the paradigm is the same, but the productivity is lower, well then what is the point? Performance? Perhaps.

BTW, I completely agree that Nim is one very cool language. It hasn't introduced new paradigms for me (yet), but it improves my productivity over C++ when working on a small opengl game.

Re: Visual Studio Code for Go

#106
post #21

Earlier quoted context omitted.

I want to start using Visual Studio Code but I am waiting for a VIM emulator plugin that is "good enough" have you tried any of them?

While I'm far from a vim pro, I've never found a vim plugin that didn't frustrate me. Hence I've been stuck in vim because my brain just can't get used to non-modal editing. 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.

Same for me, which is why nvim is so exciting.

Re: Visual Studio Code for Go

#107

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.

Re: Visual Studio Code for Go

#108

I've never programmed in Go before. Coming from a C# background. Can someone tell me, how does Go feel? Is is pleasant to work in, or is it tricky like C.

You're going to miss generics for a while. Then you're going to discover interface composition and type coercion, and it's not going to be so bad.

The reflection APIs are not easy but work.

Go is dynamic code generation away from being amazing.

Re: Visual Studio Code for Go

#109
post #52

I like VsCode especially for js css and html5 stuff. The problem I have with it is that it starts to lag when my codebase gets larger eg above 600 lines. Thats the reason why I switch to Atom. I think Atom is the best free text editor.

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 Atom before VSCode as I thought: well, that's a nice looking editor. But oh, it was just unusable for such a large file.

Post reply on HN