Just wanted to alert people that this is not ready for prime time yet. I have a sizable list of items to get through before I was planning to publicize. For example, the packaging/deployment is not there yet (working on that presently). Also, I have only tested it on OSX (in theory, it should be cross platform, but I'm sure there are bugs to smoke out).
That said, please feel free to give it a try and open issues for anything you find.
Play team solved the compile "problem" of java using a lib from eclipse so it compiles files on the fly. do you have something similar, or do you plan to include something similar?
I think compiling on every change you make while developing an app is painful, the biggest problem java frameworks have, excluding Play! of course.
Basically: In development mode, it runs a proxy (called the "harness") that watches your source for changes and recompiles/restarts your server on the next request, if necessary, using the "go build" tool. The go build process is incremental, so in theory should only recompile packages that have changed (and those that depend on them)
There is actually a way to do this fully in process. I think Rob Pike initially build this, and it's being used in the App Engine framework (or so I hear...).
It looks like he takes the same approach as Revel. From the comments:
// Devweb is a simple environment for developing a web server.
// It runs its own web server on the given address and proxies
// all requests to the http server program named by importpath.
// It takes care of recompiling and restarting the program as needed.
I'm working on adding a "rev package" command to the command-line tool. It will create a zip file of the app and revel source directories, along with a script to run the app.
It needs the source directories since templates and assets are kept within them. Also, it is frequently useful to have access to the source in production, e.g. for sending exception emails.
The goal is to make deployment to a server without a Go environment very easy.
EDIT: To answer your original question: in the current version, you must have a working Go installation to run your Revel app. Then: "rev run import/path/to/app prod". I am pretty sure that it will not work on GAE -- I realize this is an important/valuable use case and will investigate it in the future.
Wow, I can't believe I didn't see this before. I have been learning Go for a couple of weeks and had been searching for something like this the whole time. They should add a link to the list of libraries at the Golang site.
I see this is also from one of the Go contributors. Nice!
I would strongly suggest to use a different command name than 'rev' since that is already a standard unix command. How about just calling it 'revel' and then people who value short names can just alias it?
Being a fan of Play Framework, this could finally represent an opportunity for me to dig into Go. I regret the absence of an ORM, but will give it a 'go' (...) anyway.
PS: I regret that no performance analysis nor benchmarks are presented on the project page. It could be nice to have a comparison with Play on that domain.
I did not package an "official" ORM with Revel because I did not feel like there was a clear choice yet. (And making an ORM is too big a challenge to bite off in addition :)
I think that GORP is the current leader (https://github.com/coopernurse/gorp), and it is pretty easy to make a plugin/interceptor that initializes it and starts/ends transactions before / after requests.
I am planning on adding an example of this to the samples in the near future.
If you need an ORM with Go you are probably _doing it wrong_.
ORMs make little sense other than to make flawed OO type systems match relational databases. Just do it right from the start: use a database model that matches your application.
~/Dropbox/Documents/Go % bin/rev github.com/robfig/revel/samples/booking
~
~ revel! http://robfig.github.com/revel
~
~ unknown command "github.com/robfig/revel/samples/booking"
Run 'rev help' for usage.
~/Dropbox/Documents/Go % rev help
~
~ revel! http://robfig.github.com/revel
~
~ usage: rev command [arguments]
~
~ The commands are:
~
~ run run a Revel application
~ new create a skeleton Revel application
~
~ Use "rev help [command]" for more information.
It would be nice if the 'quick start' would just work.
Template Compilation Error (in errors/404.html:10): function "include" not defined
Hey Rob, how about reposting this when things are in better shape? I've been waiting for a good excuse to play with Go and your web framework looks like something I could use for some real experiments, but it needs to be a little more finished first I think.
But now it fails with an error that I don't really know how to fix as a Go noob ...
Go Compilation Error (in /usr/local/Cellar/go/1.0.2/src/pkg/github.com/robfig/revel/samples/booking/app/controllers/db.go:6): import "github.com/mattn/go-sqlite3": cannot find package
Ah, this is because the app uses go-sqlite3, which you haven't gotten in your local repo yet. I need to fix the command line to download all dependencies first.
You can fix it manually with:
go get github.com/mattn/go-sqlite3
Also, I believe that the go command line figures out the dependencies for you, so this should get everything you need:
I have been researching other GO web frameworks last two days and this one is undeniably the best looking yet. But, I really wished they had integrated an ORM from the start. Also, I wish could know "why" they chose play framework as an architecture reference.
I am definitely looking to develop a good story for ORM. However, I don't think it has to be in the very core of the framework -- allowing people to plug a different one (or not use one at all) is important.
I chose Play! (1.x) because it is by far the most productive development environment I have ever used (especially for boring business admin pages). (Out of Django, JSP, Lift, GSE/GXP, Jetty, etc).
Gorilla and pat (by the author of Sinatra) are probably the web "frameworks" I would recommend if you want to stick with minimalist idiomatic Go style.
Disclaimer: I contributed to the original Gorilla design, but all the credit should go to moraes (and everyone else who was contributed to the project).
A lot of Go programmers, and I think I'd like to include myself here, are going to want to be able to plug in their own persistence backend.
For my own part, a lot of my work has some connection to a scaling problem of some kind. A mandatory/single-database-type ORM is totally out of the question and largely why I had to abandon Django for Flask in my Python work. I might at some point migrate to Pyramid for Python, but I haven't evaluated the state of their persistence story. I was mostly wooed by their testing strategy (it's drop dead sexy).
Not trying to be awkward or anything, but why would you use GAE without using all the technologies that lock you in to it?
If you write a "vanilla" application which can run on GAE and other platforms without significant work, then I don't see how you'd get much benefit from GAE itself, but I might be missing something.
Just wanted to alert people that this is not ready for prime time yet. I have a sizable list of items to get through before I was planning to publicize. For example, the packaging/deployment is not there yet (working on that presently). Also, I have only tested it on OSX (in theory, it should be cross platform, but I'm sure there are bugs to smoke out).
That said, please feel free to give it a try and open issues for anything you find.