41–50 of 223 posts
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…
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
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 templates, which I haven't found with VSC (I haven't really looked).
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'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,…
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 atomic operations).
> Even simple tasks often need them because Go's I/O libraries tend to be async-first.
That's quite the contrary. Most libraries are synchronous. You don't need callbacks (like in Node.js) or async/await (like in Python 3). This is made possible by goroutines and that's a big advantage of Go.
I very much like the async/await mechanism offered by C# or Python because it makes side-effects explicit. But its drawback is its "virality": if you introduce an async operation in a function, you have to "propagate" the change by converting all callers to async/await.
About the error handling, I'm still on the fence. Your comment summarizes very well the drawbacks of Go on this topic. But what we gain in terms of simplicity and making error handling very explicit is probably worth it. I think that error handling is still a subject of tension in every language and the problem is not fully solved (even in Rust, Haskell or Erlang). Time will tell.
> But its build story is still really, really bad.
I think you meant "packaging story" instead of "build story". It's true that at this moment, the Go project has not rallied around a single and universal packaging tool (like npm in Node.js). But in practice, if you vendor your dependencies, I think it's easy to manage a large codebase without errors.
> do try F# if you haven't yet. [...] its error handling is light years ahead of what Go offers
I'd be curious to read a short example.
> Marlow's paper on Haxl for facebook
I agree about this paper.
Earlier quoted context omitted.
It's a completely separate project. I'm not sure there's a useful comparison between the two.
How is it as an editor? There are already lots of popular choices: vim, Emacs, Sublime, Atom, etc. How are the plugins? Code completion, multiple cursors, AceJump, etc?
However, the Go plugin is really nice and works perfectly, even, the debugger works /most of the time/ . It is fast and handy. Recommended.
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 think vim + vim-go is still the best go editor if you know vim. It just works and it gets updated frequently.
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,…