81–90 of 223 posts
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?
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.
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.
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?
Recent issue discussing this - https://github.com/Microsoft/vscode/issues/3600
Numeric arguments (3dd, 2x, ...)
support for combining commands (ci[, cW, ggVG, ...)
visual commands
Earlier quoted context omitted.
Which System76 laptops? I'm in the market for a Linux-native laptop which'll compile faster than my MBP.
Not the same person as parent but I wouldn't recommend System 76 personally. I got caught up in the hype and got a Lemur 14" but the build quality is pretty poor and I had awful keyboard issues (since fixed I believe). If you want something that runs Linux well I have stuck with ThinkPad's. You really can't beat them in terms of performance, reliability and Linux support.
Earlier quoted context omitted.
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 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…
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.
> 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.
Within the context of a single goroutine, you're right. I didn't express this very well. Goroutines are often how you process network I/O. My bad for not explaining this well, I was in a bit of a hurry when I wrote that part and the whole thing got too long so my proofreading was a bit sloppy. Thanks.
> 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.
I really think Common Lisp had a fantastic solution here and I miss the evolution over try-catch they spec'd. I wish more people understood it. It was such an excellent idea.
> 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).
For Go, is there a difference? You either have static builds or you don't, and artifacts don't exist outside of this last time I checked. So any packaging solution is de-facto part of the build story and vice versa. 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 (it's possible to launch a jar directly).
The actual compilation of the final build is fast and the cross compiler is definitely nice to have while we're all forced into a weird world where there is no good laptop OS for developers who often end up in open plan buildings where we're expected to be migratory (or simply working without an office at all). I wouldn't dream of underselling that. Of course, I'd prefer a good interactive development pattern.
There's a great gif of Daffy Duck dressed as a highwayman constantly swinging down from a rope into a tree over and over. My friends associate this with compiling Go, and I feel like that's a very good metaphor.
But just getting the libraries you need to build is a hassle. Plain and simple.
A bit off topic, but usually I tend to avoid browser based UIs for desktop applications, but the quality of current Rust support in Visual Studio Code made me open an exception just to use it.
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…
Error handling is tricky because it requires richness both in how you talk about types and how you handle control flow.
But using GADTs and to a lesser extend F#'s discriminated unions for errors does have nice static checking properties. That's definitely an improvement over Go's "I just regex'd the string please send help" approach.
Earlier 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.
Visual Studio Code is my favorite editor. I've mentioned it before but I wanted to add that I'm working on a PHP project and by using XDebug on a local server and VSCode as an editor/debugger I have a really nice lightweight debugging solution. The PHP extension to VSCode is solid.