Golang Diaries II

There is an issue of elegance. If generics were to be added, lists and maps would need to have similar syntax, because they feel and behave like generics. However, they cannot. Their syntax is… not generic enough.

Oddly enough, elegance through consistency was never reached when designing built-in functions like make(): those can be applied on any type, but user-defined functions don't have this freedom. Essentially, there is a Java-like divide between built-in types (which, for instance, you cannot create methods on) and user types. Their rules of elegance don't apply to the built-ins, which is quite odd.

I doubt that this impedes on programming efficiency compared to C. However, some of the duplicated code out there cannot be factored into a library, and map is an example of that.

That's after 13 SLoC to make a single HTTP request - I like Go, but that seems almost like a parody. It's not that different from other languages, and the error handling makes it look longer, but for something described as "natural and idiomatic" I would expect it to be one function call plus one failure test, not six and three...

     if ... { return failure }

> Isn’t it pathetic that so many allegedly-mainstream languages don’t have HTTP libraries that are this natural and idiomatic?

Isn’t it pathetic that a wannabe mainstream language doesn’t provide exception handling?

We need generics, or perhaps it's more goy to have the same features by some more clever way. But still. We need those features and bad.

I'll be looking at Rust with some more interest meanwhile.

This is a marketing fluff piece from Google.

"I still haven't written 1000 lines of Go." Why do we care what this guy says then? Because lots of Googlers vote it up.

I suggest you flag this spam :)

But at every point where Tim then returns a failure we lose insight as to why something failed.

My preferred idiom for handling all errors when it comes to web requests or responses is to return both the error (as it has the detailed message of what happened) and the http status code that matches the error (as it has translated the message into a code that describes the type of error).

This bit would change:

    if !strings.HasPrefix(mediaType, "application/json") {
        // bogus media type, deal
        return failure
    }

    if !strings.HasPrefix(mediaType, "application/json") {
        // bogus media type, deal
        return HttpErr{Err: errors.New(""), Status: http.StatusUnsupportedMediaType}
    }

I'm sure others are also creating their own http error as well, so whilst Go does http really well it seems in practise that there are still a few places where it could benefit from a little extra to help standardise the code we write.

All of those Http codes are here: http://golang.org/pkg/net/http/#pkg-constants

Regarding the map stuff, the only other place the lack of generics has stood out has been within slices of a type of thing.

The scenario is: I have a slice of identifiers in an order important to me, for each of these concurrently fetch the record being identified and create a slice of those records ordered as per the initial slice.

We've ended up using this type of thing:

    // Envelope for making sorted concurrent requests for Comment
    type CommentRequest struct {
        Comment Comment
        Err     error
        Seq     int
    }

    type CommentRequestBySeq []CommentRequest

    func (v CommentRequestBySeq) Len() int           { return len(v) }
    func (v CommentRequestBySeq) Swap(i, j int)      { v[i], v[j] = v[j], v[i] }
    func (v CommentRequestBySeq) Less(i, j int) bool { return v[i].Seq < v[j].Seq }

    // Much later in the code...

    // Make a request for each id
    req := make(chan CommentRequest)
    defer close(req)

    for seq, id := range ids {
        go HandleCommentRequest(id, seq, req)
    }

    resps := []CommentRequest{}
    for i := 0; i < len(ids); i++ {
        resp := <-req
        if resp.Err != nil {
            return resp.Err
        }
        resps = append(resps, resp)
    }

    // Sort them
    sort.Sort(CommentRequestBySeq(resps))

    // Extract the values
    ems := []Comment{}
    for _, resp := range resps {
        ems = append(ems, resp.Item)
    }

The problem stems from that envelope, and the need to implement that sort function for every type that we ever want to concurrently fetch and sort.

It's the only place where I think, if we just had generics this could be a lot better.

  output := make(output_type, len(input))
  for idx, e := range(input) { output[idx] = convert(e) }

  output := map(input, func(in input_type) output_type {
      return convert(in)
    }
  )

My biggest complaint about Go so far is that you have to use an external library to get an ordered tree structure. Maps suffice most of the time, but sometimes you need ordering.

[edit: fixed map example]