19 ms·
On Go
- staunch 13y agoA tip from someone that just recently started using Go: read the spec! I wasted some time early on trying to learn things that are very clearly and simply spelled out in the spec. The Tour + Spec is really all you need if you're a somewhat experienced programmer. The spec is well written and tiny compared to most languages, and it's probably the only thoroughly accurate and complete Go reference at the moment. Step 1. http://tour.golang.org/ http://tour.golang.org/ Step 2. http://golang.org/ref/spec http://golang.org/ref/spec
- elithrar 13y agoEffective Go (http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html) and Go by Example (https://gobyexample.com/ https://gobyexample.com/) are also great. The former is especially so if you want to learn Go idioms and understand why things are done. It's a good complement to the spec.
- MetaCosm 13y agoFor some reason, I really enjoy showing this slideshow to people -> http://blog.menfin.info/Presentations/20120709_Golang_introduction http://blog.menfin.info/Presentations/20120709_Golang_introd... ... it is short, gets across a lot of the core ideas very quickly.
- nknighthb 13y agoYes, please read the spec. All the specs! Shockingly few developers will read the f*cking spec for anything. It mystifies -- or perhaps terrifies -- me. It's one of the criteria I try to use to judge if I'm dealing with someone who seeks to truly solve problems, or just keep the build light from turning red. Some specs are actually kind of fun to read. POSIX is surprisingly pleasant, and sometimes amusing in a "Why is THAT warning label there?" kind of way. You don't have to treat them like a novel, but many are excellent reference material to keep at your fingertips.
- akama 13y agoYou know the saying about warning labels. Ever warning label has a good story about why it came to be.
- hcarvalhoalves 13y agoEverybody compares Go and Python. How is it so? Go compiles to a binary, implements static typing, got rid of classes, got rid of exceptions, and added lots of special purpose keywords on top of reinventing C's syntax. The only similarity I see is the "import" statement.
- benmanns 13y agoI've read that people have had success doing line-by-line conversions of Python scripts to Go scripts without too much reworking. I am guessing that it is the similar level of model and library granularity that drives the comparison.
- aeden 13y agoIf your Python (or in my case, Ruby) script is highly procedural then the transition over to Go is quite straightforward. The first production Go app I rolled out followed this pattern (previously a small, procedural Ruby script, now a small, procedural Go app) and I'm quite happy with the results. The resource usage is so much better with Go for this case that it really was the perfect case for switching.
- benmanns 13y agoI saw on your blog that you've jumped to full time on DNSimple (congrats). Are you using Go app you wrote as part of the DNSimple system?
- aeden 13y agoYes. We use it for our redirector (which is the project I mentioned that I switched over) and we're using it for a new zone server that we're working on that is used by our new name servers (which are written in Erlang).
- genwin 13y agoI've had success doing that, while never having written in Python.
- 501 13y agoI (a go noob) somehow got the impression that you're supposed to version your API when writing go libraries. ie, your library should be github.com/501/foo/v1 rather than github.com/501/foo. Can any go users comment on whether that's expected practice?
- nknighthb 13y agoI suspect you got this erroneous impression due branches based on the version of Go they are compatible with. Many projects maintain branches named for the Go version they are compatibile with, and the 'go get' tool automatically fetches the appropriate branch.
- 501 13y agoActually I think I may have first picked it up from this vclock library: http://labix.org/vclock http://labix.org/vclock
- dsymonds 13y agoYou can if you want, and some folk do, but that's really outside the scope of the language itself and much more about your project management, revision control, and so on.
- _ak 13y agoThe easiest way is just to keep your master always in a stable, clean state. Tools like git flow help with that. Besides that, people who criticize go get's behaviour of checking out the latest revision resp. the go1 or go1.1 tag (if available) seem to forget that you're always free to populate your $GOPATH the way you like. You don't need go get for that.
- kodablah 13y agoMy biggest issues with Go are compatibilities with the C ABI and the lack of shared library support. I have not looked in a while, so I may be wrong, but here are my big questions: 1. Can C invoke a Go-compiled and exported callback/function? 2. Can I build a Go .so/.dll invokable via C or other non-Go FFI methods? 3. If I build a commercial Go lib for others to link with, how can I distribute it without distributing the Go source?
- MetaCosm 13y agoI suspect unless someone gets real exciting about this and modifies one of the toolchains, this won't happen in the near future. You can do (1) with some ugly syntax. Regarding (2) and (3) -- I know some projects are happening in both those spaces, but haven't kept up with them.
- dualogy 13y agoFor 3. couldn't you just "compile but not link" your library packages and distribute the binary (non-source) .a object files for all platforms? Other Go code can then fully import and link those afaik.
- taliesinb 13y agoI love how the dialogue on HN about Go has gone from pessimism and largely uninformed criticism, to regurgitation of the team's own talking points ["simple, orthogonal features"], to a more nuanced appreciation of what trade-offs Go makes. Hopefully these are individual developers shifting through a continuum of enlightenment, rather than the conversation itself migrating to a more enlightened population. This last question is testable, of course, though sadly HN does not offer an official API.
- bad_user 13y agoThat's selection bias in action. Many people with criticism about Go probably moved on.
- pjmlp 13y agoTo D and Rust, speaking about myself.
- Peaker 13y agoThose of us who think that Go is a truly sad language to release at modern times (nullability everywhere, no parameteric polymorphism, no sums, products for errors instead of sums, ...) have just lost interest in explaining over and over again why a new language without those features belongs in the 1970's or 1980's, and not modern times. The crowd that remains is mostly composed of people who have never used an ML-style language (Haskell, OCaml, F#, SML, ..) and come from a background of C, Java and Python. Go is definitely an improvement over these languages in many areas.
- deleted 13y ago[deleted]
- MetaCosm 13y agoAs a pragmatist and someone who enjoys Haskell and F#, I find your comments very academic. There will always be less popular, feature packed fun languages like Rust, Haskell and OCaml, and there will always be teams that use them to great advantage (Jane Street). But IMHO, lots of these systems are a little creaky in the support structures (cabal for example) and deploy features. That said, I think a lot of what makes Go great is because of its simplicity, lack of surprises, and general lack of cleverness. You can get your hands around the language features very easily, in mere hours. Beyond that, I think the ease of building tooling on top of the AST (or in general), the ease of deploying code to production, the build speeds, the inclusion of go get and fmt, the policies around imports and variable use (use or lose) all add up to be more than the sum of its parts. It is very obviously built by a team looking to use it in production, on real projects, as soon as possible.
- graue 13y agoThe lack of exceptions just seems like a total bear to me. I wrote C for 10 years and did tons of stuff like: Open file "foobar.dat". If that fails, abort with this error. Read the first 4 bytes into x. If that fails, abort with a different error. Seek to byte x. If that fails, abort with yet another error. and so on, and so on, over and over again. Python's exceptions are a huge improvement over this pattern of timidly asking permission to do anything. The fact is there are so, so many occasions where you want to abort a computation if one of the many steps along the way goes wrong. Something like Haskell's Maybe monad is a good way of attacking the problem too. But Go has neither. It seems to just offer the bad old clumsy C way and say, "Deal with it." To those who have written real Go programs, I'm honestly wondering: how is this not a pain in the ass?
- orangethirty 13y agoI'm writing a pretty big system in Go, and had not seen this as much of an issue. Could you provide more insight into your point? I'd like to see some code to compare, if its not to much to ask.
- graue 13y agoI'm not sure how great of an example it is, but I had the thought when recently rereading this routine from an old game, reading its level file: static void scanlevel(int num, FILE *fp) { filemap_t filemap; int i; if (fseek(fp, mapptrs[num-1], SEEK_SET)) error("Can't load level %d from blockman.lvl", num); if (fread(&filemap, sizeof (filemap_t), 1, fp) < 1) error("Can't load level %d from blockman.lvl", num); if (filemap.startx < 0 || filemap.startx >= LEVWIDTH || filemap.starty < 0 || filemap.starty >= LEVHEIGHT) { error("Level %d is corrupt", num); } map.startx = filemap.startx; map.starty = filemap.starty; for (i = 0; i < LEVWIDTH*LEVHEIGHT; i++) { map.tiles[i] = (tiletype_t)filemap.tiles[i]; if (map.tiles[i] < 0 || map.tiles[i] >= NUMTILES) error("Level %d is corrupt", num); } } This shows another benefit of exceptions, which is that if uncaught, they stop the program with a traceback of the exact point they occurred. So it's not even necessary to write most of the checks above. `error` here is a routine that aborts the program; you get that behavior by default with exceptions. Whereas in C/Go if I forgot one of those error checks, the error would occur silently, leaving the program in some weird inconsistent state that I never planned for. It would just do something stupid and maybe crash or panic later on, far from the place where the initial error occurred. I guess I'm just arguing for exceptions, which is old news as languages that have them have been around for quite a while. But Go doesn't offer much of a substitute of which I'm aware. The explanation of how it solves these problems has not been forthcoming.
- rvirding 13y agoErlang does automatically parallelize over multiple cores. By default it will start one Erlang VM thread per core which work together to run the Erlang system. The Erlang VM also does automatic load balancing over the threads and even tries to shut down threads/cores if it detects they are not needed. It is possible to control how many Erlang VM threads you want at start-up and to lock them to cores as well, though the latter is not recommended. But as I said there is no need to do this.