|
If you're going to write Go code, please do read the language specification: http://golang.org/ref/spec. It is simple and straightforward. Also, stop trying to write code from your pet language in Go syntax. EDIT: Another thing not mentioned in the OP. ALWAYS use gofmt to format your code before uploading it anywhere or w/e. Most of the popular editors have support for doing this on save. Also, you probably won't run into any problems with Go on Mac, given that Rob Pike and Robert Griesemer exclusively develop Go on macbooks. Coffee Mugshot fucked around with this message at 23:03 on May 1, 2014 |
#
¿
May 1, 2014 23:00
|
|
|
|
| # ¿ Apr 28, 2024 23:16 |
|
|
Arachnamus posted:It's great as an implementation reference but as something supposed to teach me idiomatic Go it's just about the last thing I want to sit down and read. Well, nothing about the specification really teaches you how to write idiomatic Go so that's warranted. The best way to learn that is probably reading Effective Go and literally reading through parts of the standard library you find interesting. It's just profound to me that I can even sit down and scarf down a language specification without necessarily learning a whole new set of paradigms. Anyways, I think the post you quoted was referring to using the `gofmt` tool to format your code.
|
|
#
¿
May 9, 2014 05:29
|
|
|
Jo posted:I'm considering picking up Go as an extra tool. Most of the work I do involves image manipulation, numerics, and machine learning. I saw some discussion on the Go user group saying academics were migrating away from Go, but I'm slightly scrupulous. Is there any reason not to get involved if that's the kind of work I'm doing? What are the de-facto linear algebra and image packs? AFAIK, there's one particular person who's been claiming this, but it's not clear that there's any kind of consensus on the matter. As Baby Nanny said, the lack of generics and operator overloading make it unappealing to do work the areas you mentioned. That being said, there are people in the community writing tools in those areas (from the community wiki): https://code.google.com/p/go-wiki/wiki/Projects#Machine_Learning. I won't make any claims that these projects are idiomatic at all, but it might interesting to look through them for reasons to use or not use Go.
|
|
#
¿
Jun 20, 2014 16:19
|
|
|
sarehu posted:My real theory is that the compiler is a complete disaster (I looked) so it would be hard to do. I feel like a hypocrite because I'm 1 for 1 when it comes to having your compiler be a disaster, but I can't imagine having to add generics to their existing implementation. I just remember seeing some struct with pages of fields in it, like out of some 80's horror movie. Now they've got it implemented in Go but apparently that was with a C to Go translation so it's probably still the same. For the record the original compiler was most written by Ken Thompson which is why it is a bit of disaster to read and modify. Russ converted it to go mechanically and we plan to improve it and flat out remove certain parts, replacing them with the go/* packages where useful.
|
|
#
¿
Feb 25, 2015 20:19
|
|
|
idgi
|
|
#
¿
Feb 26, 2015 22:23
|
|
|
Markov Chain Chomp posted:Most go projects I've seen go to type assertions at some point and some even have to resort to using reflect. Moving your type system to the runtime is a pretty good concrete example of it not being expressive enough. What's wrong with type assertions? That's not a strange thing to do when you're using interfaces anyways. I also really doubt many projects have to resort to using reflect unless you're dealing with protocol buffers or something.
|
|
#
¿
Feb 27, 2015 18:46
|
|
|
It doesn't matter what gofmt does because it does it consistently and that's the point. There are some bugs but that's not one of them.
|
|
#
¿
Apr 13, 2015 13:02
|
|
|
Delve is bad now but maybe it will be less bad in the near future.
|
|
#
¿
Apr 15, 2016 14:04
|
|
|
I don't know why people constantly claim Go is Google's baby. We have more external users than internal users by far and it's been an uphill battle to get people to use Go within Google. Python programmers maybe, but c++ and java programmers aren't that interested.
|
|
#
¿
Oct 19, 2016 03:45
|
|
|
Go would love to have a good debugger, but it turns out debugging is hard. I think people take my favorite program, gdb, for granted.
|
|
#
¿
Dec 14, 2016 19:38
|
|
|
The debugger is delve and delve is good but not sufficient IMO. Derek Parker doesn't have enough real life time to make it much better, either, unfortunately.
|
|
#
¿
Dec 16, 2016 01:59
|
|
|
MALE SHOEGAZE posted:If only Golang had a large corporate backer with the resources and motivation to develop a functional go debugger. We've written a few go debuggers and funded some other ones, look at the Cloud Debugger on GCP and Jetbrains Go debugger, respectively, but those are application specific debuggers. I think y'all are seriously underestimating how good gdb is and how hard it is to make anything close to as good as that. Delve is a good attempt but no one has real time to work on it and gdb works well enough for smallish programs without a million goroutines flying around.
|
|
#
¿
Dec 20, 2016 08:03
|
|
|
Furism posted:Is there a really good book about learning Go? Brian Kerrigan and Alan Donovan's book is really good, but speaking, personally, from the Go Team's perspective, we'd still prefer the tour to be the landing page for learning Go rather than the spectacular book. If only because it will be easier to add a section on type aliases there than to print another rev of the book. Also, I think a casual look over the language spec is a good learning tool.
|
|
#
¿
May 5, 2017 03:17
|
|
|
Twerk from Home posted:The impression that I get about Go is that it's excellent at concurrency and bad at parallelism, somewhat like a strongly-typed NodeJS. Am I wrong? I've been looking for a chance to do some real work using Golang but the project I'm about to start has a serious need for parallel computation so I'm thinking I'll just try C# on .NET Core or Kotlin. I'm not sure if Go is particularly bad at parallelism, but the language is designed around concurrency. You would probably find it easy to write "natural code" that can take advantage of parallelism in Go, but I don't know about anything similar to OpenMP targeted particularly at parallelism. C# and Kotlin seem pretty good for parallel computation with all of the primitives they provide.
|
|
#
¿
Jun 27, 2017 17:52
|
|
|
Go and Rust are fine for making some amateur TRNG. Try it out and report back.
|
|
#
¿
Sep 7, 2017 18:23
|
|
|
Ghost of Reagan Past posted:I'm writing a lovely, bare-bones NES emulator for shits and giggles. What's a good library for graphics for someone who doesn't do graphics? First of all, I agree with MALE SHOEGAZE completely. However, if you did want to learn Go this way you might want to start from some of the graphics libraries the community has been working on: https://github.com/golang/go/wiki/Projects#graphics-and-audio. It's true that the Go team, proper, hasn't blessed a particular solution for cross-platform APIs for low level graphics and audio and it's extremely awkward to write this code the way you'd expect as a Python or Rust programmer, I think. Of course, some of these libraries involve compiling a C library with cgo (https://golang.org/cmd/cgo/) which is done automatically by the go tool for these libraries, which are basically idiomatic-esque looking wrappers of the underlying C library. You might also use something like SWIG for this if you have C++ code you'd like to call from Go. SWIG has bindings for Go types and convenience wrappers for string to std::string-like type conversion across the languages. Anyways, if I had to suggest something to your first edit, I'd start by using something like: https://godoc.org/github.com/fogleman/gg. The examples seemed straightforward enough to build on. Coffee Mugshot fucked around with this message at 06:45 on Jan 13, 2018 |
|
#
¿
Jan 13, 2018 06:43
|
|
|
Startyde posted:I've a not dissimilar question, terminal ui. I'm guessing people don't just use ncurses c bindings but have no idea. Is there a standard lib for console menus, simple tiled windowing? To answer your immediate question: there is no standard library for console menus or tiled windowing. Based on your description, you might find luck with https://github.com/gizak/termui.
|
|
#
¿
Jan 13, 2018 15:58
|
|
|
Like the other poster says, that's an idiom to differentiate between a valid empty string and an actually non valid string. I'd guess they're trying to save allocations when sending s bunch of error messages and the default value of pointers is nil.
|
|
#
¿
May 8, 2018 18:37
|
|
|
The comma-ok syntax is special to certain operations and can't be mixed with multiple assignment operations otherwise. I.e. you'll never be able to write I, ok1, j, ok2 <- ch1, ch2
|
|
#
¿
Aug 24, 2018 22:31
|
|
|
Pollyanna I don't know what data leaves refers to when talking about protobufs, maybe you're looking for proto extensions?
|
|
#
¿
Sep 7, 2018 22:14
|
|
|
Presumably when using proto, your server and client should be running from the same generated proto definition. Any other combination requires handling a bunch of edge cases. That's not particularly a go problem as much as it is a property of protos.
|
|
#
¿
Sep 14, 2018 01:42
|
|
|
|
| # ¿ Apr 28, 2024 23:16 |
|
|
asur posted:That's not really a valid assumption to make. To do so you either need to completely control the build and deployment pipeline of everything using the proto definition or delay enabling any features using the new definitions until everything is updated. The former has issues at scale, the latter runs into issues with company size, product ownership, and external partners. My experience is you're better off starting under the assumption that versions may not be the same and enforcing backwards compatiblity and handling of the edge cases, i.e. an unknown entry for enums in this case. My experience is that you freeze protos and delay enabling any features with new definitions to existing servers. I do really think that feature updates, even small ones, almost necessarily mean you need to rebuild everything. If you want to add new features, add a new server and write a new client that speaks to both to perform magic spells for you. CPU is cheaper than rollbacks imo. I'm arguing against defensive programming of unknown entries, it's awkward code to solve a process problem.
|
|
#
¿
Sep 14, 2018 16:01
|
|