Go already has a few microframeworks. What I think it needs is a fat one. It seems the idea of fat frameworks doesn't resonate well with go developers but I don't understand why.

Django is the only reason I stick with python today for anything that will have more than five pages. I want form handling, security features such as XSS, CSRF baked in, debug tools such as debug-toolbar and I want to have a basic login feature done for me.

Admin would be a plus but is not required.

Someone needs to write a good rails/django clone for go.

Go doesn't need a fat framework. If you need a fat framework, use Rails or Django.

You don't have to (re)write everything in Go, you know.

Um why? Maybe you mean you don't need one?

So if my language of choice is Go, you can somehow guarantee that I won't need a fat framework? How?

>So if my language of choice is Go

It seems like you are trying to fit everything onto this one choice. This is never a good choice. One should chose technology or stack correcponding to the porblem needed to be solved. Not vice versa.

If you need a tool such as Django - you should use one and use Go (both here are for sake of example) for some small tasks, where it can give the most.

Building a new "fat" framework just because you like the langauge is kind of strange approach.

So in your opinion I should switch to a whole different language/stack?

Who said building a fat framework since I liked the language? That's your words no one else's.

Sometimes a fat framework is needed.. period. And if you need a fat framework it doesn't mean that you should switch to Ruby or Python, because in your opinion these are languages for building fat frameworks.

BTW: python programmer for more than a decade. I've been in need for both micro and fat framework in my career. I still don't get your argument.

>So in your opinion I should switch to a whole different language/stack?

In my opinion one should use appropriate tools when building a solution. Using a number of languages or tools that are appropriate for the task is not only normal, but actually gives you better results anytime of the day, not to mention freedom of choice, compared to when you are stuck with "one big thing"

>Who said building a fat framework since I liked the language? That's your words no one else's.

>Sometimes a fat framework is needed

Okay, so name some of the reasons, otherwise mine assumption is only logical. I, personally, can't see any reasons why would you need a fat framework that has to be written in Go and not in Python/Ruby/Java or something else. Seriously, why?

>BTW: python programmer for more than a decade. I've been in need for both micro and fat framework in my career. I still don't get your argument.

My argument is that if you need a fat framework - this does not mean it has to be in some specific language. You have something like a counter argument? Please share.

> My argument is that if you need a fat framework - this does not mean it has to be in some specific language. You have something like a counter argument? Please share.

I can't fathom how you can't think of counter arguments.

- Because a company invested in Go?

- Because they wouldn't want to have to maintain a lot of different technologies/languages, unless it's really necessary?

- Because a fat framework in Go is going to be lighter than a fat framework in python/ruby? (memory reqs, cpu, servers, etc)

- Because Go is easier to reason with/maintain in large codebases?

And still, right now I'd choose python, but I can't understand how someone would hold such strong opinions in such matters. Maybe I've seen too little in my career? Or have I seen too much, so as to not jump in such strong positions so easily? Genuinely curious and that's why I started this thread.

>Because a company invested in Go?

I hardly can imagine a company that had invested only in Go and will need fat Go gramework. Seriously.

>Because they wouldn't want to have to maintain a lot of different technologies/languages, unless it's really necessary?

Not a lot of, but a number - once again, pretty hard to imagine something serious going on here. And startups will hardly chose Go as their starting point for obvious reasons.

>Because a fat framework in Go is going to be lighter than a fat framework in python/ruby? (memory reqs, cpu, servers, etc)

Absolutely not necessary. You can build framework in C and had results that will make you sad compared to that of Python. But even if it is - most likely it will be more expensive and you will have to make a choice. But okay, let's say it has some point.

>Because Go is easier to reason with/maintain in large codebases?

How so? In comparison to Python, for example.

>I can't understand how someone would hold such strong opinions in such matters

Hey, I'm not saying people shouldn't write fat Go framework, or stop doing if they've started already. If stars are lit - it means there is someone who needs it. I just don't get why would you use something like Go for this.

>I hardly can imagine a company that had invested only in Go and will need fat Go gramework. Seriously.

I don't know how to reply to this because I really don't see what's hard to imagine, but ok.

> And startups will hardly chose Go as their starting point for obvious reasons.

Well that's obviously false, or you haven't been paying attention to HN, or job listings :P

> How so? In comparison to Python, for example.

Static typing. In the case where you'd like to counter that point, I'm sincerely sorry, I'm tired of arguing over that point. I'd prefer if we left it at that and say "we agree to disagree".

> Hey, I'm not saying people shouldn't write fat Go framework, or stop doing if they've started already. If stars are lit - it means there is someone who needs it. I just don't get why would you use something like Go for this.

Fair enough. Sometimes I just like to elicit responses in order to gain new perspective/POV etc.

Cheers

It's not really all that controversial of an opinion to say that no one needs a fat framework in 2016. It's much easier and nicer and more maintainable to use a collection of small tools than one monolithic solution.

Nah, not really. It depends on a lot of parameters.

First of all you conflate fat with monolithic, which is not necessarily the case.

I think that Django is a good example of this. It's a batteries-included framework, but its architecture allows you to strip or replace parts of it.

Sometimes it's easier to start from a fat framework and "prune" your way to where you want to go, than instead re-invent the whole universe.

Above all, again, it depends.

Basically. If a fat framework is what you need, you chose your language poorly.

I think people choose frameworks because they _prefer_ them instead of _needing_ them. If you think you _need_ a framework you need to reevaluate your programming skills.

I think if a Rails-type framework is what you need, and you're doing Web development, your problem might be better solved by Elixir and Phoenix[0]. My only caveat to that would be if you need some sort of extreme CPU efficiency as Go has better CPU throughput than Elixir/Erlang. Otherwise, I think you'll find Phoenix's parallels to and lessons learned from Rails along with some nice abstractions around PubSub/WebSockets.

0 - http://www.phoenixframework.org/docs/overview

http://beego.me/ is a tool mentioned in the benchmarks. it also has a large plugin and community developing behind it.

Totally agree, but maybe not quite as fat as Rails/Django. I wonder if just a solid bootstrap app would be sufficient such as Angular Drywall (MEAN stack)? I just want to see the right way to access db, perform basic crud, user accounts & login, db browser/admin, simple view templates.

I am still using the Go framework Gin. Echo has similar performance, but Gin was there first.

I do have to code a bunch of stuff myself as opposed to Django. But if I really wanted to save time, I would just use WordPress.

Have been using this for quite some time - it has a nice API and is solid in production. I love the simplicity and it's small enough a codebase to quickly read and start hacking around.

Do you have any experience with gin?

If so, why do you prefer echo over gin?

Thanks

Personally I prefer two specific things:

1) echo is more middleware compatible - it's a PITA to use a lot of "standard" Go middleware (e.g. nosurf) with Gin, but echo has no problems with these.

2) the function signature for handlers always returns an error - so you have func(Context) error rather than func(Context). This feels a bit more like idiomatic Go, and makes it easier to write generic error middleware for your app.

In terms of performance, for all intents and purposes they're about the same in real-world cases (the Go community for some odd reason loves bikeshedding over router benchmarks, but in the real world this is probably the least of your concerns).

Agreed - those two points, and the general simplicity of the Echo codebase, were why I ended up using it over the (many) other options for Go. Honestly haven't had the desire to check anything else out since, it's just always worked very well.

Personally I don't think golang needs a web framework. What comes with the standard library is all that you need.

While this is true at some level, there are certain benefits to performance tested, well-thought-out libraries that encapsulate good approaches to problems the standard library does not solve.

I think the bigger problem was that it seemed like a whole bunch of folks wanted to be the one to write "the next big web framework", and they didn't really understand the value and usability of the standard library. Those frameworks are generally not necessary.

Echo is not those frameworks. It's worth a look at the value it provides rather than knee-jerking "no frameworks!".

Absurd statement. For starters: the mux/router included with the standard http library isn't particularly good or performant, which is why most of these projects like gin and httprouter were started in the first place. You'd also have to roll your own middleware implementation, which means you'll end up with your own framework at some point regardless.

Story of my life right there. The standard library will take you a long ways in web dev (specially in prototyping), but ultimately needs a lot of improvement that the community made in the form of 3rd party packages.

This is cool!

I'm actually kind of shocked it performs better than gin (which is based on httprouter). Are you using a specialized prefix tree for the routes?

I'm not sure this is the case, at least not according to the benchmarks in the gin-gonic/gin repo.

This framework was submitted to HN before:https://news.ycombinator.com/item?id=9296524

In that discussion the author of gin mentions gin has a zero allocation router as well https://github.com/gin-gonic/gin/issues/249

On mobile right now, will look at the gin/echo benchmarks later (especially if the gin benchmarks compare the fasthttp engine of echo)

Looking at https://github.com/gin-gonic/go-http-routing-benchmark/blob/...

All echo benches have been commented out, last change about a year ago.

Tests do not use echo's fasthttp engine.

That GH issue is almost exactly a year old and still open, with no recent comments.

I use express / node. It looks like I can map what I know to this framework quite quickly. Is it worth the investment?

Here's one way to find you my friend: prototyping. Go is simple enough that could give you a good idea of what your life will be like using a package in a "short" amount of time.

Sorry for the confusion guys but now I don't have an option to edit.

Does it support templates like handlerbar or jade?

Well, it supports returning a string from a handler, so ... yes. :)

Are there any compatible CSRF and XSS packages?

Forget Rick rollin, Go Rollin is the new kid on the block.

Can a moderator add "Golang Web Framework" or something to the title of this article? I would imagine that most readers would assume this is about a new version of the Amazon Echo, and the current title seems almost engineered to create that confusion.

We changed it to the title of the article, which is what the HN guidelines ask submitters to use in the first place.

(Submitted title was "Introducing Echo v2 fast and highly customizable with many new features".)

Yeah same thought. Honestly Amazon announced the Echo about 4 months before this framework even became a thing. Personally think they should think about a different name, even though they're not in the same space, to make search, discovery and recognition easier.

Ecgo.

Exactly what I thought

Please don't post snarky dismissals.