Hacker News Reader

Comment by paulsutter | Hacker News Reader

Could someone explain what problem this solves? Go already has http, templates, and (duh) goroutines. What is Revel adding?

Sure, PHP programmers are accustomed to having their syntax errors detected by surprise at runtime. But aren't we choosing Go because it can detect those errors before we've deployed? [1]

In Java it may feel natural to take a simple task like dispatching a URL ("Routing"), and turn it into an elaborate overabstracted object architecture. But aren't we choosing Go to escape that nonsense? [2]

[1] http://robfig.github.io/revel/img/helpfulerror.png

[2] http://robfig.github.io/revel/manual/concepts.html

Am I missing something?

EDIT: I've seen lots of Go applications, and none of them have spent 8432579842375 hours developing scaffolding. Actually, they saved time not having to spray their logic across a zillion source files.

View on HN

I assume this post is a joke.

"Could someone explain what problem Play/Wicket solves? Java and servlets already has http, StringBuilder, and trivially created threads. What is Play/Wicket adding?"

What it's "adding" is the 8432579842375 hours you don't have to spend writing your own routing, template-loading-and-management, and logic separation code.

EDIT: Your #2 is a strawman. "revel run" mode statically compiles all files and dependencies if the timestamp changes. It's not even remotely comparable to PHP. Just because it has a friendly error message doesn't mean revel magically dispenses with static type safety.

The point of all frameworks provide a set of idioms about how one should best solve a problem. It's not to make web apps possible, it's to establish an opinion about how webapps ought to be written in Go. Which is different than how one ought to do it in Java, and Scala, and Ruby.

It's nice to be able to leverage other people's opinions and established idioms without having to figure them out yourself.

> Am I missing something?

Yes, but it seems that you are not teachable.

It says right on the OP-linked page:

Revel provides routing, parameter parsing, validation, session/flash, templating, caching, job running, a testing framework, and even internationalization.

Preface: I absolutely love Revel, and I hope to put something built on it into production very soon.

That said, I'd be hesitant to bring up Revel's session as a positive. It shoves everything into a cookie instead of using the cookie token as a key to a serverside data store. Not only are you limited to 4k of session-local storage, but you're sending the entire payload across the wire for every single request. This is absolutely stupid and needs to change. I'm sure Rob is boxed in by limited time, and this is not intended for production use yet, but holy god, it's by far the worst thing about the framework.

This is the same thing Rails does by default. I much prefer it to server side stores. What on earth are you keeping in the session that actually causes it to be a problem? If it's more than an auth token and a bit of flash scoped data, it may be time to rethink how your managing state.

Well, how hard is it to just use their session store to store a guid of some type and use that key to store session data in redis or some other storage?

That's what I do, and it's easy enough, but that's not the point. Revel is trying to be a comprehensive "ready to go" framework - and as such, it has all these other features fairly well covered, but it's falling down, relatively speaking, in this one.

I like go's anti-magic philosophy, if not simply because of how utterly hard I've being burned by magic.

routing is best left to you to write explicitly, there's no pancea, because if you use this solution and you then need to do something even slightly more complicated, then you now have two nomenclatures, and two interacting systems.

A simple library is what is needed for parameter parsing and validation, not a framework that provides it wholesale.

There are lots of session implementations, a library might intice you with its offerins, not a frameworks im pretty sure this one size fits all solution should work in some manner

Templating was already there, they offer it again? There's also competing libraries to go's templating, use those.

Caching? You mean for templates? That's not complicated to do. For databases? There are databases that need you to cache results for them? Sheash.

job running? Oh good were cron now, why not this? http://godoc.org/github.com/robfig/cron

a testing framework? Doesn't go have one of those? Why do we need two? Go's got a good testing framework!

Internationalization is templates with file reading, right?

I know these all sound hard, they sound like you can't do them on your own, or they sound tedious. But for the love of god, down with frameworks, down with magic! Burn it all!

I think this guy just wrote his "web dev in Go" utility libraries and then decided to bundle them together under a fancy name with a funky web site.

Go has all the built-ins you need to get a simple web server started in no time, but as you progress to real-world work, you do notice your own plumbing and boilerplate code piling up. In your second project, you extract those into a number of packages. Then if you're feeling fancy or idle, "bam, look Mom, a Web Framework!"

> For databases? There are databases that need you to cache results for them? Sheash

Yeah ever heard of Memcached? Check it out. Still something you need to bind & talk to, and perhaps you want to have a little toggle for your dev environment to have RAM caching instead of full-blown Memcached. Voila, a candidate for a utility package. Sure, this is mostly trivial to write yourself, which is why a gazillion of them exist, but hey, why not have it included in a single go-get-able package that has a lot other "needed" web-ish stuff in it too.

Personally, I'm not touching frameworks like this either. I swear by the built-ins (even for templating) and the "Gorilla" libs. But why the hate, this clearly worked for the coder and users of this framework. Maybe there comes a time and project where it will work for me.

Does a framework imply magic?

ALL frameworks are built using stuff the language provides. For me it's about how much time I want to spend setting up my project's "base" versus using a framework that already has the stuff that I want set up already.

Routing.

I've just skimmed most of it, but Revels seems to be "Rails/Django magic" framework.

Yes. You clearly skimmed most of it.

Reply on news.ycombinator.com