<p>Is anyone else a little annoyed/frustrated over how many there are now? It seems like every one advertises itself as "the fastest out there". </p>
<p>My company uses echo and today I came across gin when a coworker decided to use it in his poc code. When I looked through gin, I saw this seemingly neverending list of performance benchmarks comparing gin to the other http frameworks...<a href="https://github.com/gin-gonic/gin/blob/master/BENCHMARKS.md">https://github.com/gin-gonic/gin/blob/master/BENCHMARKS.md</a></p>
<p>I believe in a balance to everything so for there to be a healthy competition between the frameworks is great but this is getting to be a bit much...
thoughts?</p>
<hr/>**评论：**<br/><br/>dlsniper: <pre><p>People have different opinions on how to build web stuff with Go. You can do it with frameworks, you can can do it without. You can do it with just better routers.</p>
<p>The benchmarking issue is exacerbated by the fact that many people do not understand how these things work and what they are measuring. There are <strong>very</strong> few workloads where a few microseconds will make the difference. There are few workloads where 2-3KB of more garbage generated by the router will make the difference (especially with Go 1.9 GC being better than ever). </p>
<p>From my experience in teaching people / helping them profile code / profiling my own code, I will usually hit the limits in other parts of the app before I can even see anything related to the router of choice in the profile.</p>
<p>But that hasn't stopped people from trying and do things in different ways in search for their own version of what fits their views of how things should work / look like.</p>
<p>Personally I've used gorilla/mux since 4-5 years now and never had any problems with it. It is a <strong>very</strong> stable and battle tested router and has a rock solid API. So I've had no reason to look anywhere else. Others found their own choice and used that first.</p></pre>peterbourgon: <pre><p>I'd like to echo all the points made here, and modify one:</p>
<blockquote>
<p>I will usually hit the limits in other parts of the app before I can even see anything related to the router of choice in the profile.</p>
</blockquote>
<p>I will <em>always</em> hit the limits in other parts of the app before I see anything related to the router. 100% of the time. Performance benchmarks in this arena are ridiculous.</p></pre>TheMerovius: <pre><blockquote>
<p>I will usually hit the limits in other parts of the app before I can even see anything related to the router of choice in the profile.</p>
</blockquote>
<p>I did the math around this a couple of times. Even if you are at the scale of Google, you spend the equivalent of a small handful of engineering hours <em>per year</em> on routing, with a naive approach. Definitely not enough to justify optimizing that.</p></pre>ar1819: <pre><p>Hmm - is there any additions to Go 1.9 GC besides improvements about big object allocation?</p></pre>shovelpost: <pre><p>I believe that this explosion of routers written in Go has been caused by the Go team's decision to <a href="https://groups.google.com/d/msg/golang-nuts/T6lJ5iXwyjw/VxwsrqgcrCUJ">keep the http.ServeMux simple</a>. </p></pre>everdev: <pre><p>I have a new one coming out soon called Vanilla. It's basically a tutorial on how to do it yourself so you don't need to get bogged down with boosted packages or extra functionality that you don't need. So far I haven't found any packaged web frameworks that do it right.</p></pre>darkmagician2: <pre><p>This would be a great addition to the community, please post when completed :)</p></pre>TheMerovius: <pre><p>Obligatory: <a href="https://blog.merovius.de/2017/06/18/how-not-to-use-an-http-router.html" rel="nofollow">I agree</a>.</p></pre>SkaterDad: <pre><p>Great article!</p>
<p>You make some great points about route handling being a little mysterious in libraries.</p></pre>michele: <pre><p>While it's true that there are a lot of HTTP frameworks, it doesn't need we need to try them all: just pick one which looks good to you and start using it.</p>
<p>When I first needed one, I tried Gin, looked good, got me almost where we needed but then stumbled on some restrictions with httprouter (routes can't be ambiguous because httprouter doesn't try to be smart about resolving conflicts, which I understand, but still the specs needed it as we were migrating a production API already receiving a few million requests a month). So we switched to Echo and all was good and we never looked back.</p>
<p>I don't suggest to put on a blindfold, but you don't need to try all of them. If you have a real use case for which you need one, just try the one which looks more promising to you and give it a try. In the end, most of them are ok and as long as they don't get in the way, you should be good.</p>
<p>I understand that for people coming from other languages it might look intimidating, but really, most of them are fine and, anyways, you'll soon learn that the Go community doesn't try to have just one way to do things: you have options and that's great, but you need to make your own decisions, the community won't make them for you like for Ruby and Rails (which I come from and still use it and think it has its reasons to exist and be loved).</p></pre>PaluMacil: <pre><p>I haven't been annoyed by it. I think the reason for so many frameworks is simply how complete the HTTP library is already in Go. Everyone at my company uses only the standard library for web apis. The routing you see in a URL is taken care of by the front-end framework for us. In our case that is Angular. I don't mind using the standard library to get parameters from the query string portion of a request for an API. If our frontends were not Angular and we still needed to manage the routing on a frontend, I would definitely choose the most prominent framework to maximize available documentation, community support, and validation of quality. gorilla/mux seems to be the best candidate for the top leading framework in terms of popularity even if the important metrics place quite a few other frameworks equal with it. The most time-consuming thing in getting from boilerplate to sensible skeleton functionality is always authentication regardless of language. However, even in a framework such as asp.net I do not see a solution that saves a lot of additional development despite being one of the most complete authentication solutions in any language I've seen. Once humans need to do account management and set permissions for each other there just isn't a way to provide a boilerplate solution that works for everything. Luckily for a private site you can add portions of an authentication, authorization, and account system as your site grows. For an Enterprise site you you probably aren't making authentication etc every time. You probably make it for one API that acts as your centralized authentication system, which means the burden is not repeated.</p></pre>hobbified: <pre><p>Nope... if there wasn't a good diversity of people putting different approaches out there for something so ubiquitous, I would take it as a sign that Go isn't worth bothering with. I don't see anything to get frustrated over — the ones I don't use don't do me any harm.</p></pre>myringotomy: <pre><p>As a noob to go I agree. It's hard to know where to start and frankly none of the ones I have seen are comparable to ruby, python, elixir or Java frameworks. They all seem like they were slapped together in a day and none of them are suitable for writing a real world app.</p>
<p>I would love to be proven wrong but if somebody came to me and said they needed to build a web app I would say go with elixir or rails not go </p></pre>dlsniper: <pre><blockquote>
<p>As a noob to go I agree. It's hard to know where to start and frankly none of the ones I have seen are comparable to ruby, python, elixir or Java frameworks.</p>
</blockquote>
<p>Try the Go way before trying to bring your habits from other languages. It's the hardest thing to do but once you've done it, you'll be a better programmer in those languages as well, not just Go.</p>
<blockquote>
<p>They all seem like they were slapped together in a day and none of them are suitable for writing a real world app.</p>
</blockquote>
<p>That depends on what you value. Go programmers usually prefer simplicity and clarity versus a lot of magic. Magic usually bites you really hard, regardless of framework / language.</p>
<p>With that being said, if you really need to write "real world apps" (I guess all the community has been writing only toy demos so far?) have a look at <a href="https://gobuffalo.io">https://gobuffalo.io</a> It's probably the best RAD Framework for developing Web Apps in Go. And if you need a CMS, then try <a href="https://github.com/ponzu-cms/ponzu">https://github.com/ponzu-cms/ponzu</a></p>
<p>Hope this helps.</p></pre>myringotomy: <pre><blockquote>
<p>Try the Go way before trying to bring your habits from other languages. It's the hardest thing to do but once you've done it, you'll be a better programmer in those languages as well, not just Go.</p>
</blockquote>
<p>I am not talking about style. I am talking about functionality. If you want to build a non trivial app you need to have a certain amount of functionality from the start. You need good security, a way to handle secrets, a way to handle different environments such as development, staging, production, CI etc, you need a solid configuration system, you need caching, database pooling, templating, page partials, etc. Frameworks like Rails, Django, Phoenix, Spring and a slew of PHP ones provide those for you in a unified and well documented way.</p>
<p>Last time I brought this topic up at <a href="/r/golang" rel="nofollow">/r/golang</a> the consensus was that "the go way" was to not write a web app but only to write an API and then to hand assemble all the bits you need from the hundreds of packages out there that proport to do the same thing. I don't mean big components like caching and database pooling either but I mean down to the smallest detail like routing and parsing parameters. </p>
<p>Thanks for the heads up on gorilla. I currently have about two dozen tabs open in my browser with web frameworks so I will add it to that and read about it too. It does seem like this process should be easier for a noob like me. It's hard to know where to start. With Java or Ruby or Python or Elixir it's easy. You get batteries included and amazing documentation and a rich community to help you. With go you don't get any of that.</p>
<p>Look at how scant the documentation is on Buffalo. That tells me it's very young and doesn't have a large community around it. Correct me if I am wrong.</p></pre>michele: <pre><p>Go doesn't have something as convenient as Rails or Django, I agree, but the truth is you can easily accomplish what you said (i.e. caching, database pooling, templating, page partials, etc.) with just a few lines of code.</p>
<p>We're currently running several Go microservices handling on average 10 million requests a month and we definitely needed db pooling, caching, security, etc: we have our own internal packages which provide us everything we need and they're probably less than 100 LOC in total.</p>
<p>Take something like caching and Rails: the rails cache store is super convenient, but is fairly limited. As soon as you need to handle something which doesn't fall into what the Rails team thinks is the right way to do caching, you'll need to right your own logic and it's not going to be as straightforward as with Go (trust me, I did it).</p>
<p>IMHO, big assumptions are more difficult to work around them; no assumptions looks daunting at first, but it will force you to be more pro-active and will ultimately lead you (again, my opinion), to better code.</p></pre>iris-go: <pre><p>You've right, but Go people are different, we like simple things that just works very well. If you're looking for MVC web framework, the only one is the Iris web framework: <a href="https://iris-go.com" rel="nofollow">https://iris-go.com</a> (we despite code generation and "magic"). It's also one of the fastest if not the fastest out there, it's the best you can find in Go world so far. </p>
<p>Disclaimer: Iris was built by co-workers and me and it's being used by a US Television station for a year as well!</p></pre>myringotomy: <pre><blockquote>
<p>You've right, but Go people are different, we like simple things that just works very well.</p>
</blockquote>
<p>That seems facile and arrogant. Are you saying people who use other languages don't like simple things that just work well? </p>
<p>I submit that go things are not simple because they require cobbling together of many tiny projects most of whom have little documentation and support. This is hardly simple for somebody who is starting out because they have to figure out which routing to use, which caching to use, which asset management to use etc. So they have to evaluate fifty or so existing projects to settle on the "best set". Hardly simple. </p>
<p>As for Iris I think you are the only one here recommending it. Almost everybody says to avoid it because of some stolen code or something like that.</p>
<p>So your recommendation is a prime example of what I am talking about. There are umpteen frameworks, there is no consensus on which one is most suitable for what kind of use. Am I supposed to listen to you or to some other person on reddit. Or maybe I am supposed to download and play with all fifty of the projects to see which one is most usable. </p></pre>jjzcru: <pre><p>Not every language is the same, maybe you want a battery include framework like the mainstreams in other languages but most of the time that extra code that you don't use is just a code that you have to maintain. </p>
<p>Go was built for simplicity, the batteries include are in the language itself, so you don't have to be navigating looking for libraries and only work with what you need. </p>
<p>I have come from OOP language like Java and Kotlin and try to implement stuff that I did in other languages and just don't work, if you try a new language adapt to the way the language works. Not the other way around.</p></pre>myringotomy: <pre><blockquote>
<p>Not every language is the same, maybe you want a battery include framework like the mainstreams in other languages but most of the time that extra code that you don't use is just a code that you have to maintain.</p>
</blockquote>
<p>No you don't have to maintain code you don't use. You don't have to maintain the framework code at all. That's the whole point of using a framework. You want to rely on the expertise of others. </p>
<blockquote>
<p>Go was built for simplicity, the batteries include are in the language itself, so you don't have to be navigating looking for libraries and only work with what you need.</p>
</blockquote>
<p>But I need all that. I need routing, I need security, I need CORS, I need Cross Site safety, I need secure cookies, I need rate limiting, I need live reload, I need caching, I need database pools, I need asset management. I need all of that and more. </p>
<blockquote>
<p>if you try a new language adapt to the way the language works. Not the other way around.</p>
</blockquote>
<p>Here I disagree but that's not the point. The answer seems to be that nobody should use frameworks in go and that everybody should just rebuild everything themselves over and over. I guess that's why there are so many duplicate libraries in go.</p></pre>tuxlinuxien: <pre><blockquote>
<p>it's being used by a US Television station for a year as well</p>
</blockquote>
<p>Doesn't mean the quality of your framework is good at all.</p></pre>paul2048: <pre><p>http router =/= web framework, </p>
<p>Everybody can write an http router, it takes 2 hours. And everybody SHOULD write its own http router, or are you against diversity in an language ecosystem?</p></pre>
