3 ms·

Articles on Go web frameworks all end up at the same conclusion. The Go standard library is so strong around web servers it's hard to recommend anything else.

tptacek 11y ago
It's not entirely that simple. The problem isn't that net/http is so amazing that it's silly to replace it; it's that the replacements aren't yet up to the challenge --- by which I mean, none of them are yet so much of a win that the cost of losing compatibility with net/http outweighs the benefits. Writing full-featured web apps in Golang in 2015 is still a lot like writing a Sinatra app was 8 years ago. It feels great at first, but you quickly realize that you're just building a half-assed version of Rails.
- bojo 11y ago
  An alternative way to look at it would be "you are only building the 20% of Rails you actually need." I've never been a fan of full-fledged frameworks and prefer the more pragmatic method of only pulling in components that I need though.
  - juliangregorian 11y ago
    https://github.com/rails-api/rails-api#why-use-rails-for-json-apis https://github.com/rails-api/rails-api#why-use-rails-for-jso...
    - bojo 11y ago
      http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...
      - tptacek 11y ago
        Going from 30 servers to 2 sounds like something whose cost savings might add up to as much as 100 hours of developer time.
      - juliangregorian 11y ago
        That's cool. I bet they could reduce it to 0.15 servers by rewriting it in C. They probably would have drastically reduced the number of servers even if the rewrite was still in ruby, having much better understanding around the runtime requirements. Ruby also seems like a questionable choice in the first place for such a service. Perhaps a prototype. Nobody is pretending that MRI Ruby is the most performant runtime you can find, but that's just not an issue for 99% of web stacks.
interactiv 11y ago
> The Go standard library is so strong around web servers it's hard to recommend anything else. The http packages provides the bare minimum. A serious app requires way more features than what is provided,a router than handles route variables, a middleware stack, a proper context, a proper session mechanism if one writes a website... So it's normal people write their own libraries on top of it ( like mine @ gopkg.in/interactiv/expresso.v0 ,still alpha )

tptacek 11y ago

It's not entirely that simple. The problem isn't that net/http is so amazing that it's silly to replace it; it's that the replacements aren't yet up to the challenge --- by which I mean, none of them are yet so much of a win that the cost of losing compatibility with net/http outweighs the benefits. Writing full-featured web apps in Golang in 2015 is still a lot like writing a Sinatra app was 8 years ago. It feels great at first, but you quickly realize that you're just building a half-assed version of Rails.

bojo 11y ago
An alternative way to look at it would be "you are only building the 20% of Rails you actually need." I've never been a fan of full-fledged frameworks and prefer the more pragmatic method of only pulling in components that I need though.
- juliangregorian 11y ago
  https://github.com/rails-api/rails-api#why-use-rails-for-json-apis https://github.com/rails-api/rails-api#why-use-rails-for-jso...
  - bojo 11y ago
    http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...
    - tptacek 11y ago
      Going from 30 servers to 2 sounds like something whose cost savings might add up to as much as 100 hours of developer time.
    - juliangregorian 11y ago
      That's cool. I bet they could reduce it to 0.15 servers by rewriting it in C. They probably would have drastically reduced the number of servers even if the rewrite was still in ruby, having much better understanding around the runtime requirements. Ruby also seems like a questionable choice in the first place for such a service. Perhaps a prototype. Nobody is pretending that MRI Ruby is the most performant runtime you can find, but that's just not an issue for 99% of web stacks.

interactiv 11y ago

> The Go standard library is so strong around web servers it's hard to recommend anything else. The http packages provides the bare minimum. A serious app requires way more features than what is provided,a router than handles route variables, a middleware stack, a proper context, a proper session mechanism if one writes a website... So it's normal people write their own libraries on top of it ( like mine @ gopkg.in/interactiv/expresso.v0 ,still alpha )