Here's my issue: If I was a Go noob, I may look at this project and think this is a viable replacement to something like Gin, Martini, or the Gorilla suite.
But since I read the source, I know that it's not much more than a ternary search tree wrapped around fasthttp. And because this is the only thing that is unique about the project, I would expect at least some benchmarks about what makes a TST work faster than other routers. FWIW I am not convinced that TST is necessary. That's why benchmarks are helpful: to prove skeptics wrong.
My point is that releasing an open source framework is a responsibility. And at this point, it's much more likely that future users of Gearbox will have been misled into using a framework that is less necessary, featureful, or proven than others who have real weight and maturity behind them. It's less likely that they are aware of and agree with your questionable, undocumented ideas of what makes a Go framework "fast". I'm sorry for not being supportive, but it's not because I enjoy being an ass: my post above explains why I feel strongly about this.
Got your point and totally agree with you. We are going to mention that it's under development and not ready for production usage till we finish supporting all basic functionalities and have a benchmarks results (also for the current release). Actually, we have things to do more than TST that can improve performance. Thanks for your feedback and we are here to get and understand your feedback :-)
But since I read the source, I know that it's not much more than a ternary search tree wrapped around fasthttp. And because this is the only thing that is unique about the project, I would expect at least some benchmarks about what makes a TST work faster than other routers. FWIW I am not convinced that TST is necessary. That's why benchmarks are helpful: to prove skeptics wrong.
My point is that releasing an open source framework is a responsibility. And at this point, it's much more likely that future users of Gearbox will have been misled into using a framework that is less necessary, featureful, or proven than others who have real weight and maturity behind them. It's less likely that they are aware of and agree with your questionable, undocumented ideas of what makes a Go framework "fast". I'm sorry for not being supportive, but it's not because I enjoy being an ass: my post above explains why I feel strongly about this.