11:34 pm, 22 Jun 10
no go
Two friends of mine were pretty enthusiastic about the Go language, so I tried writing a program in it yesterday. It is frustrating because despite the language having some really good ideas (my heart sang a bit when running "ldd" on my binary revealed it uses no libraries), it felt pretty profoundly ugly.
I don't mean the syntax (well, truthfully, the syntax is pretty ugly -- hard to be too proud of tutorial snippets like
My program wanted to read a set of structured objects from an input file, so I needed a growable array of objects. I wanted my function to return an array (er, slice) of these. It would seem natural to use the vector package but that only lets you get back an array of untyped interfaces (the no-polymorphism thing); it appears the best I can do is copy the vector's contents into a new array once I'm done reading the file.
I hope that with more time they will be able to improve the documentation (it's not at all clear to me when pointers are needed, or why
I don't mean the syntax (well, truthfully, the syntax is pretty ugly -- hard to be too proud of tutorial snippets like
sum(&[3]int{1,2,3})
) but rather that there are all of these strange non-orthogonal bits that stick out like half-hammered nails. Like having all of value, reference, and pointer types (with accompanying weird FAQ entries) or strange extra builtins (iota
, close
).My program wanted to read a set of structured objects from an input file, so I needed a growable array of objects. I wanted my function to return an array (er, slice) of these. It would seem natural to use the vector package but that only lets you get back an array of untyped interfaces (the no-polymorphism thing); it appears the best I can do is copy the vector's contents into a new array once I'm done reading the file.
I hope that with more time they will be able to improve the documentation (it's not at all clear to me when pointers are needed, or why
var buf [10]byte; file.Read(&buf)
needs that & or how else I'm supposed to get a slice from an array) as well as grow more consistency into the language. I think many of the underlying concepts (the way interfaces work, even the "polymorphism makes things too complicated" rule) are really good but actually using the language left me feeling let down.
If you actually dislike the libc interface -- you would not be the first -- you may also enjoy some of djb's odd (but lovely) replacement APIs for unix. fefe has done a porting and packaging job on it, but the original is scattered around various projects marked "C interface" on djb's site.
It _was_ cool that I could turn the raytracer into a multicore app with a 4-line change.