REST Servers in Go: Part 1 – standard library

Good advice! A small addition in the third point: you can create a separate interface for HTTP errors, for example:

    type HTTPError interface {
        GetHTTPCode() int
    }
    func ServeHTTP(w http.ResponseWriter, req \*http.Request) {
        result, err := DoTheActualThing()
        if err != nil {
            statusCode := http.StatusInternalServerError
            if httpError, ok := err.(HTTPError); ok {
                statusCode = httpError.GetHTTPCode()
            }
            http.Error(w, ..., statusCode)
            return
        }
        w.Header().Set("content-type", "application/json")
        w.WriteHeader(http.StatusOK)
        w.Write(result)
    }

You can apply the same approach for the HTTP body in case of error.

These things can be fun to play with, but my experience is most projects don't need them. I would rather spend my time implementing functionality than regenerating and recompiling code from proto files. The large projects you mention often have something most projects don't: a well-defined data model and interface that has been heavily iterated and evolved over time. At that point things like backwards compatibility, auto docs, and performance become more important, and gRPC can be more useful.

You only get a certain number of complexity tokens and IMO it's not worth spending any here.

Thank you for the detailed comment!

Just want to address (1) quickly. As you've mentioned at the end of the parenthesized note, the reason I did not use `defer` here is to avoid the lock staying across the rest of the handler. I wanted to confine it to the datastore interaction.

Thinking more about this now and having read the comments, I'm considering to just hide the lock in TaskStore and avoid all these explicit locks/unlocks in handlers; it seems like it will avoid some confusion for folks reading the example (as well as quite a few lines of code!), and my goal here is really the HTTP server logic. I prefer to deflect any attention from TaskStore in this series of posts.

I don't think I was out of touch (which I guess is always how it goes). The value propositions of Golang and Rust are pretty well understood at this point, and I think that if you want abstraction power the choice between them is clear.

Rust is hard, but it's not harder than Haskell, and at a high level of abstraction it can be simpler than Golang has to offer in the stdlib, in the happy path with better results, and more safety. Again, this is the happy path case, but it's not impossible, just hard/unlikely -- Golang on the other hand can never achieve this level of simple interfaces built on abstraction because of the goals and design choices the language has made.

The original comment is this:

> Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic.

My point was that Rust gives you the tools to write a rails/sinatra (at a glance) library that in the happy/simple path (which most regular CRUD backends are) can be simpler than Golang because the abstractions to make it simple are there, and speed will just about always be the fastest possible relative to quality of underlying code. Golang can (and does) provide similar, but it is always a step behind (on purpose) on the abstraction front. If you're going to provide a carefully crafted interface that is very easy to use, it matters less that rust can have a really high barrier to entry (rails is valuable because you can be productive without being a ruby expert).

I think you’re probably trying to make a substantial point but you seem to be mistaken about several things with respect to Go and polymorphism and interfaces such that I can’t figure out what your actual, substantial point is.

> Go is a bad language for metaprogramming

You’re absolutely right here.

> There is no "either-or" data type in Golang. That's why.

Correct here too, Go doesn’t have sum types. If you want sum types, you have to emulate them via interfaces. But I don’t see how that relates since all of this DI stuff seems to be dynamically typed anyway (errors at runtime) assuming you’re not taking a codegen approach anyway.

> In C, you just make a struct, have a type present in the struct, and then cast the struct pointer to extended object types to gain additional functionality.

I don’t understand what you’re trying to do here. First of all, this only works for the first field (and obviously isn’t memory/type safe).

> In Golang? Well... no. You are essentially forbidden from doing any simple casting or extension. You are essentially stuck with hardcoding the crap out of everything or making your own vcall like system build out of Golang types... which you can't really use in the way you want unless you use reflection.

As a general rule of thumb you can do almost anything in Go that you can do in C if only by delving into the unsafe package; however, “unsafe” is almost never necessary—interfaces typically suffice. You certainly can emulate inheritance if you don’t care about type-safety, just like in C. Unfortunately I can’t say more until you clarify your objective.

> What I can't understand is why anything thinks that Golang does support polymorphism. They admit it themselves. They are working on it. Only the new alpha test versions have a solution for it. The current released version is not polymorphism no matter how much you want to fucking label it that way.

I think you must mean some other word because interfaces are the canonical example of polymorphism and Go has the best interfaces in the business. :) I’ve never heard the Go maintainers claim they lack polymorphism (Go does lack type-safe generics and sum types, but so does C). In an earlier post you argued that interfaces weren’t polymorphism because they don’t let you modify the underlying data, which is patently false—this is the whole point of interfaces. In Go:

    var r io.Reader // nil
    r = someFile // *os.File
    r = stringReader // *strings.Reader