If it has source-navigator capability(generate call-graphs etc like what source nagivator does, or similar to ctags) that will be awesome!
Visual Studio Code for Go
141–150 of 223 posts
Re: Visual Studio Code for Go
#142Maintainer of the extension here. Happy to answer any questions about VS Code or the Go support specifically.
One of my required features is seeing the method signature when my cursor is on the method name; I don't want to have to enter a command to see the signature. In sublime, the bottom bar will passively show me `func Unmarshal(data []byte, v interface{}) error` when I cursor over json.Unmarshal. I'd really like it if it also showed me the type of the variable I was cursored over, but I digress. Is this possible in your extension?
Re: Visual Studio Code for Go
#143I've used it on a macbook for a short time for node/javascript development, but found it buggy and had to switch back to sublime. The undo (cmd+z) would occasionally get in a weird state where the undo would happen partially (not all lines or columns?) and the whole history would be screwed, or outright stop doing anything. Few times i had to close the file to get last saved version. Perhaps it's something I was doin…
That was fixed for me with 0.10.0 on Yosemite. Can't find it from my phone, but there was an issue on GitHub I was tracking.
Re: Visual Studio Code for Go
#144I'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.
It's fun and awesome. Interfaces are _great_ overall, but I particularly love them for testing. You can use them for dependency injection.
Re: Visual Studio Code for Go
#145We'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.
You can add an extra bit :
> a language created by Google
by guys using Macintosh laptops
> in an editor created by Microsoft
At a plan9 conference when people turned up with Mac laptops, Brucee (who wrote considerable portions of Go's ancestors - Inferno & Limbo) remarked to me : "the interesting thing about the Mac was that it wasn't X86 and it wasn't Unix ... now it's both!".
Re: Visual Studio Code for Go
#146Earlier 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…
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 questions I had in mind (https://github.com/rust-lang/rfcs/pull/1236).
For example, kentonv wrote:
All code can fail, because all code can have bugs. Obviously, we don't want every single function everywhere to return Result as a way to signal arbitrary "I had a bug" failures. This is what panic is for.
graydon wrote:
Currently you've adopted a somewhat-clunky error-type with manual (macro-assisted) propagation. Some rust code uses that correctly; but much I see in the wild simply calls unwrap() and accepts that a failure there is fatal.
ArtemGr wrote:
The only way to maintain both the safety and the no-panic invariants is to remove the panics from the language whatsoever. Explicit errors on bounds check. No assertions (you should make the assertion errors a part of the function interface instead, e.g. Result). Out of memory errors returned explicitly from every heap and stack allocation.
If you'd like to keep the assertions, the smooth allocations and other goodies then you either need a way to catch the panics or end up making programs that are less reliable than C. No modern language crashes the entire program on an out-of-memory or an integer overflow, but Rust will.
The libraries we have, they do panic, it's a matter of fact. Withing the practical constraints and without some way of catching panics you can't make a reliable program that uses external crates freely.
BurntSushi wrote:
If something like catch_panic is not stabilized, what alternative would you propose? (Option and Result are insufficient.)
On the same topic, there is this post about introducing a `?` operator or a `do` notation (inspired by Haskell) to streamline error handling:
http://m4rw3r.github.io/rust-questionmark-operator/
And there is RFC 243, about "First-class error handling with `?` and `catch`":
https://github.com/rust-lang/rfcs/pull/243
But I'm sure you're quite aware of these discussions :-)
My general feeling is that, whatever programming language you consider (Python, JavaScript/Node, Go, Rust, Haskell, Erlang, etc.), the right way to handle errors is still an open question.
Re: Visual Studio Code for Go
#147Earlier quoted context omitted.
VS.Code + the go plugin is quite good. I recommend it to my team members who prefer GUI-based editors. VS.Code is surprisingly much faster than Atom even though they share the same electron editor. I think vim + vim-go is still the best go editor if you know vim. It just works and it gets updated frequently.
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.
Most go-related plugins are reaching parity in that they mostly use the same background services and utilities to update the editor. My guess is Jetbrain's IDE has roughly the same features. FWIW, VS.code starts up much faster than WebStorm on my machine.
Re: Visual Studio Code for Go
#148I'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.
There is no type hierarchy, no generics, no extension methods, no inheritance which means that polymorphism is limited to implicit interfaces.
The concurrency model is good though (communicating sequential process), but async/await in C# is also good.
Re: Visual Studio Code for Go
#149I really love VSCODE. Like really love it.
In all fairness I am aware that I can also a bit of a Microsoft 'fanboy' at times... so I held off on trumpeting around the office how truly great I think it is.
Of course if it came up in passing or anything like "should I open that in sublime?" came up, I'd make a sweeping grandiose statement like "anything but VSCODE is for chumps" (and we'd all laugh then move on about our day)
Anyways, a developer from another team recently saw over my shoulder and said "oh yeah, I'm really liking VSCODE... I've pretty much switched to it full time now" and that was the moment I thought maybe it's not me just being a fanboy... this particular developer was pretty much known as our resident "sublime expert" so much so that he'd given multiple lunchtime presentations and talks around the office on subjects like "how to turn it up to 11 with your sublime text editing" and "snippets for sublime - making you a bajillion times more productive"
Anyways, I know how we used to have the religious holy wars about VI/M vs. EMACS vs. whatever, so people really tend to fall in love with "their" text editor and are not really quick to switch BUT VSCODE has really got something special going on.
Re: Visual Studio Code for Go
#150We'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.
VS.Code + the go plugin is quite good. I recommend it to my team members who prefer GUI-based editors. VS.Code is surprisingly much faster than Atom even though they share the same electron editor. I think vim + vim-go is still the best go editor if you know vim. It just works and it gets updated frequently.
> much faster than Atom
uggh! yes :) I tried checking out atom and installed the facebook extensions to see what the fuss was all about. It was so slow I could only successfully open it 50% of the time.