Hacker News Reader

Comment by mace | Hacker News Reader

Anyone care to share their experience writing something in go? I've toyed with it but not built anything in production.

FWIW, the go dashboard (https://godashboard.appspot.com/) has a number of interesting projects.

I've written a few relatively small (a few K LOC) Go projects, and my experience has been quite positive. The libraries are really well designed and impressively complete. With goroutines and the fact that most things work with io.Reader/io.Writer, plugging different components together and having them work efficiently is pretty easy. I love gofmt (sweet sweet consistency), and despite some early reservations, I'm quite happy with what the go tool provides. The couple servers I have written in Go have been great, in that they were pretty easy to write in a straightforward way, and they ended up impressively fast. The speed is actually somewhat seductive; I've been unnecessarily microoptimizing some things, just because I see what sort of speed is possible without leaving the language. I also find that due to gofmt, the constraints of the language, and the aesthetic leadership of the Go team (along with, likely, a self-selection in those writing Go right now), third party Go libraries are very readable. When I'm trying to understand a data structure or a protocol, I often look for source code; python used to be my preference, but in part thanks to types, I now find Go to be my first choice.

I do wish the Thrift support was as good as the protocol buffer support, though. :)

go1 has been my goto language for a while now. I don't even understand why, but everything makes a lot of sense. It compiles about as fast as python and I have an easy time making quite efficient code.

Concurrency is obviously very good and that extends to parallelism quite easily. For example, I wrote go-heatmap ( https://github.com/dustin/go-heatmap ) and found I could shave a few seconds off of the colorization phase of a fairly large image I generate hourly by running every column (or row, I forget which) in parallel on my 4 core atom box.

The build/packaging system is everything maven wishes it could be. It's practical to create, publish and use small third-party things (such as my humanize package: https://github.com/dustin/go-humanize ) because the build system just deals with the dependency for you (even transitively) just based on import statements. "go list -json" in a source directory (or pointed to a namespace) will tell you all kinds of things about what your code uses, including transitive dependencies.

I deploy go code I use every day on OS X and Linux, 386, 64 and ARM. I can build all of these programs from any one of these systems so quickly and easily you wouldn't think they're native binaries. In fact, it just took me 20s to build a Windows cross compiler and all of the standard library (with which I built my kmz_example program from go-heatmap on OS X in .49s and now I've got a kmz_example.exe I don't know what to do with).

I've been putting together a small blogging application with Go just for fun on the side to pick up the language and work on my web design.

Its a great language, I'm not using it for half of its capabilities but it very much feels well thought out and the community is very helpful.

Key pieces:

-My code isn't much more complex than my ruby or python.

-The stdlib is pretty fantastic.

-Right now tutorials and 'blogs' are all over the place with compatibility for go, rule of thumb if it says "goinstall" in the guide probably a good sign its an older guide.

-All network communications use epoll in the backend so you get lots of the fun things you would normally get from something like node.js without callback soup.

Ideally go would probably work for a web service or building some backend networked code, or even a simple command line utility. Right now there is not much in the way of GUI code outside of websites which is unfortunate cause I'd like to use the goroutines with some graphics ideas I've had.

Do you know of any recent tutorials on writing web applications in Golang? I saw a slideshow from two years ago, but the content seemed to be fairly abstract for a framework.

It really depends on your needs and the type of application you're making. For example my applications, apart serving a few static html, css and js files, just answer to JSON or JSONP queries. That can be done in a dozen lines of code, all the remaining code will be related to your application logic.

So you just need to look at the net/http API, and at a few code samples. I cannot find the the old golang wiki codelab sample (has it gone away with Go1 ?), so here's an example of a JSONP server that you can reduce to a few lines if you remove the specific application logic and the profiling hook : https://github.com/Canop/braldop/blob/master/go/src/braldops...

EDIT : I found an example on the golang site. If you're not interested in JSON, it will be more suited to your need : http://golang.org/doc/effective_go.html#web_server

I made a few web application servers (mostly for games) and it's been a real pleasure, not to mention that my programs run for months handling millions of queries (mostly json) without the slightest problem.

Using the go tool to get libraries, build, compile, test, benchmark, is like a dream.

An example of what I found kind of marvelous : I had sometimes queries leading to the call to a function updating a lot of things in a kind of specific database. That is the browser had to wait about 1 second because there was in the query handling code something like this :

    for _, ami := range amis {
    	bra.EnrichitCouchePNG(ms.répertoireCartesBraldun(ami.IdBraldun, ami.Mdpr), couche, PNG_CACHE_SIZE)
    }

I just made a tiny change and the work was done after the answer was sent to the browser :

    for _, ami := range amis {
    	    go bra.EnrichitCouchePNG(ms.répertoireCartesBraldun(ami.IdBraldun, ami.Mdpr), couche, PNG_CACHE_SIZE)
    }

This small go was the only needed thing (the "database" being yet protected by a mutex)

  répertoire

Never gave much thought to Go's UTF8 support, but this makes me think that it might've been better limited just to the string literals. The last thing I want is to patch other person's code by copy-pasting original variable and function names, because all I have is a standard US keyboard locale.

I've said it before and I'll say it again: Somebody really just needs to clone Apple's input method on Linux and Windows. Then you don't need to copy and paste — "é" is just one more keystroke than normal "e", option-e-e. This alone solves probably 95% of the international issues I encounter to the satisfaction of everyone involved.

I believe that is the purpose of the AltGr [0] key, is it not?

[0] http://en.wikipedia.org/wiki/AltGr_key#US_international

On X11, the keymap can be set to "US International" which is the same as a stock US layout but with deadkeys and an AltGr key. I find it to be even easier than Apple's input method.

You're right, I should have mentioned that. I admit to only having learned about that recently, but it didn't sound quite right to me. You really like it better? As I understand it, the US International keymap makes any character that might be used as a deadkey always act as a deadkey, right? Because that sounds a little annoying for programming. In a Ruby program, even a French or Spanish one, probably most of the ` and ~ characters are going to be syntax, not diacritics. (But like I said, I haven't gotten to try it, so I might have gotten the wrong impression.)

I found it annoying enough that I now use US International without deadkeys. And definitely "Alt gr-o" is a lot easier than the "Option-e o" that I'm forced to use on the school's Macs.

Actually that's my configuration of choice, being Spanish, I use a UK keyboard + AltGr and it's perfect. I find the UK layout more comfortable for programming, and still can type Spanish when needed.

This is just the same for me in Norway. The Norwegian layout has open curly brace on AltGr + 7, which is very painful when programming. US with AltGr is so nice, but it just makes me more of a weirdo up here..

I'm a Norwegian living in the UK using a US keyboard layout.. Definitively couldn't handle using a Norwegian layout for programming any more.

Have you tried to use a Compose Key on X servers? You can use it as follows:

    Compose-Key e ' => é
    Compose-Key e ` => è
    Compose-Key e " => ë
    Compose-Key e ^ => ê

I wonder how this is done on Mac?

  Option-e e => é
  Option-` e => è
  Option-u e => ë
  Option-i e => ê

On Lion and later, it's even easier. Just hold down the e key and you get a list of the various accented versions.

Granted, it doesn't work in the Terminal, or certain other apps that don't use the standard text edit widgets (e.g. MacVim, TextMate), but in those apps you can continue to use the old ⌥e+e trick.

I don't know if I'll be able to go on with that. When I was coding in smalltalk and at the very beginning of java I was happy to use the full power of my speaking language in my programs but I had to give up my accents because most tools were unable to handle them.

Now that (on linux) most tools deal correctly with UTF-8, I try again, at least on programs that I'm sure I won't share with people not understanding French (for example French MMORPG). Time with tell but I don't take this risk at work.

Learn how to use your ALT-keys.

Do tell how I would enter Ж with my Alt-keys. Or better yet, tell me how to tell apart 'e' and 'е' (one of them being a Cyrillic letter.)

A popular Russian CRM (1С) has a scripting language where the code looks like:

СпрСотр = СоздатьОбъект("Справочник.Сотрудники"); СпрСотр.Новый(); СпрСотр.Наименование = ФИО; СпрСотр.Должность = Должность; СпрСотр.Оклад = Оклад; СпрСотр.ДатаПриема = ДатаПриема; СпрСотр.Записать();

It's not surprising they were not able to expand to the Europe market.

Op was complaining about é, not Ж.

We used it to write our own simple distributed computing software after realizing hadoop was too complicated (and thus bug prone) for our embarrassingly parallel needs.

It took us less time to get the system written, stable and up and running then it had to get hadoop setup (different developers so not a fair comparison but still).

It feels like python with the good parts of C on linux (most things are file like object) and I plan on using it more and more as the ecosystem of available libraries matures.

Sounds like a hell of a blog article. I hope you write it.

I've built a production entity resolution system using 100% Go. It implements a map/reduce model with many workers and multiple (for failover) masters. All data is held in memory for speed purposes. Things that are amazing about go: fun and fast to develop in; beautifully designed (rockstart founding team, than you!); RPC, net channels, and maps and strings, to name a few. The ability to quickly create servers to host business logic. Interfaces and "inheritance" model are both very elegant and clean. Compile times rock. Everything was built with the standard Go (pre 1) install; not a single other package was needed--the very complete standard lib is a blessing.

Two "could be better" points. Go has a hard memory limit per instance of ~ 15 GB; bad when you want to pin lots of data in memory. Russ says this issue is being tracked (2142) and will get fixed after Go 1 gets out the door. So patience will fix this one.

Second, there needs to be more examples of Go code out int the wild for others to share and look at. Using the template package got me stuck, for example, and seeing code cleared up my issue but that was hard to find. This we can all help with by using Go and talking about it. Again patience takes care of this issue as well.

Other than these items, do yourself a favor and start using the magic that is Go!

Just a note: The Go distribution itself is full of great examples of Go code, including several uses of the template package, for example in godoc.

Don't be afraid to read the code in the stdlib, is very readable.

I have written a bit of Go. It strikes me as sort of the Unix of programming languages. It's very opinionated, takes some overarching concepts, mostly channels and interfaces, then proceeds to thoroughly not care what you think about it: refuses to have generics, lambdas and tail-call recursion like a pro. The polar opposite of design by committee. It even enforces a True Brace Style to keep the parser simple!

Technically, it looks good to me. The toolchain is excellent. It looks ready for production. Programming in it is fun. It fixes most issues of compiled languages. Go has mostly replaced Haskell, for me.

Why would you move from Haskell to Go? There's a night-and-day difference between them. I don't understand why you'd switch to a language because of the features it's lacking, unless you think those features are a bad thing (and I have yet to see a reason why generics and TCO are a bad thing).

Of course they are not a bad thing. It's just that Go has character. It doesn't have generics or C++-style classes just because every other language has them. I respect that.

Go has C++-style classes. Anonymous fields are just C++ multiple inheritance with a different name (and without virtual functions or downcasts).

Go does have lambdas: foo := func() { ... }

As someone with no formal training or experience with compiled languages, I really like Go (as compared to trying to teach myself C recently). Months ago, when I first checked out the language, I was able to write a simple bot that sits in an IRC channel and responds to its name. It took me a little over an hour to write, using the online docs as a reference (https://gist.github.com/1123352).

I created SVGo, a Go package for generating SVG. (http://github.com/ajstarks/svgo) I use it for programming visualizations, and other creative coding tasks. For example, I use the goplay command and a browser, to "sketch with code", showing the code and resulting picture in one view -- I make a change, hit a keystroke and immediately see the result. (http://www.flickr.com/photos/ajstarks/6198774781/in/set-7215...)

SVGo paper from SVG Open 2011: (https://www.svgopen.org/2011/papers/34-SVGo_a_Go_Library_for...)

Samples: (http://www.flickr.com/photos/ajstarks/sets/72157623441699483...)

I have been (slowly) developing a chess engine in go [1] (still a long way to go, no pun intended!)

What I like most about go is its simplicity and cleanness while still allowing you to program somewhat close to the metal. In fact, it often feels considerably more like a higher level language than a systems language.

The go tool is quite fantastic too. My chess engine project folder contains 41 go files, including a number of files containing tests (named XXX_test.go) which contain functions named TestXXX. My entire test + build process is:-

    ~/gocode/src/weak$ go test ./... && go build

Go is like a very delicious trifle - the further into it you go, the more delicious things you find. The quality is clear throughout.

Go is very unassuming. You start by wondering what the big deal is + getting annoyed with the minor differences from other C-syntax languages before slowly progressing towards quite liking it, then eventually once you grok how simple + elegant and well engineered it is you come to love it.

[1]:https://github.com/lorenzo-stoakes/weak

Tinkercad, http://tinkercad.com, a cloud based solid CAD runs Go for the cluster component. We have a dozen or so different services running in the cluster. Most are distributed for performance and fault tolerance. All the distributed code is written in Go, there is some C for performance critical inner loops.

I built a location service that allows people to play games with people who are nearby. I built a small geo-location service and a messaging server for the games. The servers are tiny and fairly simple. The games themselves are written in Javascript. Good times.

https://github.com/fmstephe/location_server

Reply on news.ycombinator.com