6 ms·

I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0]

by gkop 10y ago

I don't usually say this but - isn't this a poor choice of name? Gorilla framework's Mux [0] has been around awhile and is quite popular for routing in Go. [0] https://github.com/gorilla/mux https://github.com/gorilla/mux

insertnickname 10y ago
That's why we have namespaces. There's gorilla/mux and now there's donutloop/mux.
- Lewisham 10y ago
  This. It's actually more idiomatic to use the same name, then you can often just sub out one library for another without any hassle.
  - deleted 10y ago
    [deleted]
  - 1_2__3 10y ago
    What? No! There's no indication at all these two libraries are compatible - why would you want two completely disparate projects to give some indication they support the same interface?
    - Lewisham 10y ago
      Because many of the base infrastructure libraries are compatible as long as they used interfaces (grumble grumble os.File). I would be very surprised if this doesn't implement net/http/ServeHTTP
      - TheDong 10y ago
        It doesn't matter what it's named though, you can always alias the import. If it was "github.com/foo/poppycock" I could just write import mux "github.com/foo/poppycock" and use it as mux. Import name similarity is a terrible argument for picking a name.
        insertnickname 10y ago
        There are cases where it makes sense, like https://github.com/pkg/errors https://github.com/pkg/errors which is meant to be a drop-in replacement for the stdlib `errors` package containing a superset of its functionality.
  - jerf 10y ago
    Then refer to the library by a name, and tell people to import $NAME/mux. You can also name the imports if people want.
  - nkozyra 10y ago
    Unless they have the same functions, variables, structs, etc., sharing the same name really doesn't provide much in terms of hassle-free substitution.
- oelmekki 10y ago
  Fair point, but this post title should read "donutloop/mux – A lightweight, fast HTTP request router for Go", then :)
bradleyankrom 10y ago
I typically read the HN comments before clicking on a link, and I actually thought this _was_ a post about gorilla/mux until I got to your comment.
- vegancap 10y ago
  Same here!
- hqian 10y ago
  Same here. I was working with gorilla/mux 2 min ago with some "legacy" code and saw this. Thought to myself "huh it might be some good new changes with gorilla/mux"
shanemhansen 10y ago
I think they are both copying the stdlib terminology https://golang.org/pkg/net/http/#ServeMux https://golang.org/pkg/net/http/#ServeMux Historically gophers haven't minded the occasional namespace collision: https://github.com/golang/go/issues/9 https://github.com/golang/go/issues/9
aikah 10y ago
mux comes from muxer which comes from multiplexer. Gorilla doesn't own that label, no matter how popular the package is.
0xCMP 10y ago
Luckily because of how packages are in go this won't be too much of an issue. Simply have to refer to gorilla/mux or donutloop/mux specifically.

by gkop 10y ago

insertnickname 10y ago

That's why we have namespaces. There's gorilla/mux and now there's donutloop/mux.

Lewisham 10y ago
This. It's actually more idiomatic to use the same name, then you can often just sub out one library for another without any hassle.
- deleted 10y ago
  [deleted]
- 1_2__3 10y ago
  What? No! There's no indication at all these two libraries are compatible - why would you want two completely disparate projects to give some indication they support the same interface?
  - Lewisham 10y ago
    Because many of the base infrastructure libraries are compatible as long as they used interfaces (grumble grumble os.File). I would be very surprised if this doesn't implement net/http/ServeHTTP
    - TheDong 10y ago
      It doesn't matter what it's named though, you can always alias the import. If it was "github.com/foo/poppycock" I could just write import mux "github.com/foo/poppycock" and use it as mux. Import name similarity is a terrible argument for picking a name.
      - insertnickname 10y ago
        There are cases where it makes sense, like https://github.com/pkg/errors https://github.com/pkg/errors which is meant to be a drop-in replacement for the stdlib `errors` package containing a superset of its functionality.
- jerf 10y ago
  Then refer to the library by a name, and tell people to import $NAME/mux. You can also name the imports if people want.
- nkozyra 10y ago
  Unless they have the same functions, variables, structs, etc., sharing the same name really doesn't provide much in terms of hassle-free substitution.
oelmekki 10y ago
Fair point, but this post title should read "donutloop/mux – A lightweight, fast HTTP request router for Go", then :)

bradleyankrom 10y ago

I typically read the HN comments before clicking on a link, and I actually thought this _was_ a post about gorilla/mux until I got to your comment.

vegancap 10y ago
Same here!
hqian 10y ago
Same here. I was working with gorilla/mux 2 min ago with some "legacy" code and saw this. Thought to myself "huh it might be some good new changes with gorilla/mux"

shanemhansen 10y ago

I think they are both copying the stdlib terminology https://golang.org/pkg/net/http/#ServeMux https://golang.org/pkg/net/http/#ServeMux Historically gophers haven't minded the occasional namespace collision: https://github.com/golang/go/issues/9 https://github.com/golang/go/issues/9

aikah 10y ago

mux comes from muxer which comes from multiplexer. Gorilla doesn't own that label, no matter how popular the package is.

0xCMP 10y ago

Luckily because of how packages are in go this won't be too much of an issue. Simply have to refer to gorilla/mux or donutloop/mux specifically.