Adding this is so trivial. If it really, really bothers you that much:

    func Get(mux, uri, handler) { mux.HandleFunc("GET " + uri, handler) }

Obviously skipped the types for brevity.

Not a fan either. I want to be sure that routing is going to work at compile time, not at runtime.

If this turns out to be real issue (which I seriously doubt), then they'll add a vet check.

how about build time? just add a test and the "runtime" become build time.

If you want type safety, pick a type-safe language.

Go is type safe.

The zero-values idea, nil, reflection and stringly-typing all over stdlib and the most popular libs makes go not type safe. Were you thinking of statically typed?

Type safety is a spectrum, not a binary choice. Having used Go for 10 years now, next to other popular languages like JS and Python, I think it squarely falls into the "more type-safe than not" half of the spectrum. But it's definitely a positive development that, as this discussion shows, the Overton window of type safety is shifting towards the safer part of the spectrum.

That's true. From that perspective it is safe. But from the perspective of for example Elm and Rust, I would say go ends up in the other half of the spectrum - but still close to the middle.

I genuinely have no idea what you're referring to by "stringly-typing all over stdlib". I've written Go every day for the better part of a decade and used the standard library the whole time. What standard library functions require passing in the string of a type?

Struct tags is the most notorious example.

They’re convenient but error-prone. I think everyone who wrote a decent amount of Go had that malformed, misspelled, or misnamed (“db” vs “sql”) tag at some point.

You are right, stdlib doesn't have much of stringly-typing.

However the core language way of dealing with enums for example is extremely weak. It's common to have a typed enum on a struct. When parsing the struct, random string (or whatever the alias is) values sneak in and the only thing you can do is validate.

We're literally in the comment thread of a new stringly typed thing being introduced to the stdlib!

I also don't prefer using strings, but to be fair, HTTP methods are just strings when the request is received. There is some beauty in that in matches the prefix of the first line of an HTTP packet

On the wire, everything is a string. Doesn't make it a good type to use!

Strings with a well defined meaning that is not being taken into consideration here beyond routing.

This is discussed broadly in the proposal.

> I don't like this. Is there a reason for using a stringified method prefix?

Backward compatibility, they didn't wanted to change function signature nor add different method for it.