Should I use ServeMux or http directly in golang

Question

I was wondering if I should create a new ServeMux and register it to the http.Server or should I invoke http.HandleFunc and http.Handler directly?

I think the route with a ServeMux is better because http.HandleFunc obviously messes with the global state of the HTTP package, which is considered bad practice in Go. However, in many tutorials, even the official ones, I often see the http.HandleFunc route being used.

This makes me wonder: why should one use http.HandleFunc when there is a ServeMux? I know that ServeMux has some advantages (e.g. you can nest it without repeating the prefix all the time) but I wonder why I should ever choose http.HandleFunc over Multiplexer, especially since HandleFunc uses a ServeMux internally.

Edit: as promised in the comments, I've asked to deprecate the additional (and useless IMO functions) on Golang-dev and they said no (well, on person said no). Here is the link.

Addam

(I also wanted to say that this is a good question, and a useful one for others in the future, since it has come up before) – Smokeless

elithrar: that's why I asked it here. I couldn't find anything on Google. Imo, http.HandleFunc and http.Handle should be deprecated, then. Using a Mux and Server only adds 2 more lines and ambiguity is always bad, especially if the more obvious way is the "bad way". – Addam

The Go1 compatibility promise doesn't allow removal, so we're 'stuck' with them until "2.0" (which is a long way off - years). – Smokeless

elithrar: I can't find anything about deprecation in the compatibility promise. It would still be available and work as it does now (at least until 2.0) but beginners will stay away from it. – Addam

The only way to deprecate is a documentation note. Go doesn't have the concept of "warnings" (from the compiler), so the effectiveness would be pretty minimal. You're welcome to propose adding documentation to these methods on golang-dev. – Smokeless

I will do! I think do a documentation note would do a lot! The first thing I did when I notice there are two methods was reading the docs again. – Addam

Answer 1

You're on the right track: you should prefer to instantiate your own ServeMux, for the reasons you've outlined.

Using DefaultServeMux also runs the risk of exposing profiling endpoints when using net/http/pprof, since those are attached to the DefaultServeMux.

http.Handle|HandleFunc are convenience methods, and perhaps useful for keeping the boilerplate in example code down, but creating a ServeMux gives you the ability to wrap it, nest it within another, export it from a constructor, etc.

Smokeless