4 ms·

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

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 http://robfig.github.io/revel/img/helpfulerror.png [2] http://robfig.github.io/revel/manual/concepts.html 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.

nemothekid 13y ago
I've just skimmed most of it, but Revels seems to be "Rails/Django magic" framework.
- coldtea 13y ago
  Yes. You clearly skimmed most of it.
throwit1979 13y ago
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.
- virtuz 13y ago
  Mux routing and template management is baked into go. Really. And if you don't like it, use a lightweight library: http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/ I'm building a product using go and have Mux + Mustache. That's literally it. Separation of concerns is done by splitting "controllers" into separate Go files. Because it's based on Mustache, integrating Backbone is going to be a synch. Honestly, it's the fastest and easiest development I've done in a long time, and there's zero framework in sight.
deleted 13y ago
[deleted]
DoubleMalt 13y ago
Routing.
sigzero 13y ago
> Am I missing something? Yes, but it seems that you are not teachable.
dualogy 13y ago
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.
- GhotiFish 13y ago
  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 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!
  - ericflo 13y ago
    Does a framework imply magic?
  - dualogy 13y ago
    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.
jasimq 13y ago
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.
dustingetz 13y ago
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.

nemothekid 13y ago

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

coldtea 13y ago
Yes. You clearly skimmed most of it.

throwit1979 13y ago

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.

virtuz 13y ago
Mux routing and template management is baked into go. Really. And if you don't like it, use a lightweight library: http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/ I'm building a product using go and have Mux + Mustache. That's literally it. Separation of concerns is done by splitting "controllers" into separate Go files. Because it's based on Mustache, integrating Backbone is going to be a synch. Honestly, it's the fastest and easiest development I've done in a long time, and there's zero framework in sight.

deleted 13y ago

[deleted]

DoubleMalt 13y ago

Routing.

sigzero 13y ago

> Am I missing something? Yes, but it seems that you are not teachable.

dualogy 13y ago

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.

GhotiFish 13y ago
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 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!
- ericflo 13y ago
  Does a framework imply magic?
- dualogy 13y ago
  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.

jasimq 13y ago

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.

dustingetz 13y ago

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.