web2go ?

[b00m_chef]

Hi All,

I am wondering if anyone is thinking of starting work on a web MVC
framework for Go?

I am in the process of writing a web-app prototype in a quick and
dirty fashion in web2py (python), but if it takes off I will be
looking for a language I can scale with. As I am interested in going
back to a type-safe language and am interested in a language for the
long-run, I have looked at Scala, but would rather use Go if it is
mature enough by then. As I can definetly see this thing having legs.

It would definetly be a nice alternative to Scala. Scala lets you use
all pre-existing JAVA libraries, while writing in a type-safe dynamic
language. I would be interested in Go doing something similar (minus
dynamic aspect), with C/C++ libraries.

This language looks really great, and something that I am definetly
going to keep an eye on it.

[monty chen]

Good idea, I also want to using go for web.

[Igor A.]

Intresting too...

[Dark Fader]

There are immediate problems - like the lack of low-level
implementations for required features (database drivers and the like.)

Also, being a compiled language may cause complications - if I develop
on a Mac and deploy on a Debian Linux box, will a compiled file work?
Or will I have to build compilation into the deployment process?

I think there would be advantages though. Writing a web server into
the framework would allow the optimised concurrent model of Go to
handle multiple requests simultaneously at the application level
rather than the OS level, which would have to be a better use of the
resources in a machine. If things could be simplified to the extent
that deployment is simply uploading (or compiling) a single
executable, it's possible to imagine deploying to any web server,
whether you have root access or not.

I'm going to wait for people to build some good foundations first,
personally... But if someone decides to start one I may be tempted to
pitch in.

[Curbrider]

I am interested in taking Go this route. Keep me posted if you setup
a development team.

[Joan Miller]

I think that would be better to build the libraries and then one to
glue all together, rather to build a full MVC framework so the web
developer has more flexibility to add or remove components that a
monolithic framework. As example is Pylons [1] on Python.

I'm going to working on an application for internationalizing and
localization (just as Babel). But it will be language independent
since that the communication is going to throught an IPC as shared
memory (since that it's the fastest one).


[1] http://pylonshq.com/docs/en/0.9.7/modules/

[Michael Hoisie]

I started a simple framework called web.go:
http://github.com/hoisie/web.go

Right now it supports url routing with regular expressions, and has
some helper methods for template rendering. I encourage people to
check it out :)

- Mike

[Peter Froehlich]

On Wed, Dec 16, 2009 at 11:44 AM, Michael Hoisie <hoi...@gmail.com> wrote:
> I started a simple framework called web.go:
> http://github.com/hoisie/web.go
>
> Right now it supports url routing with regular expressions, and has
> some helper methods for template rendering. I encourage people to
> check it out :)

Nice, and looks understandable (as opposed to other frameworks I've
used). Can't wait to try it out together with our database bindings!
:-D
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

[Per Andersson]

I agree, this might not be so bad with proper DB bindings.

[Peter Froehlich]

Hi all,

On Wed, Dec 16, 2009 at 12:22 PM, Per Andersson <dim....@gmail.com> wrote:
> I agree, this might not be so bad with proper DB bindings.

I hope I won't hijack the thread with this:

http://github.com/phf/go-db
http://github.com/phf/go-sqlite3
http://github.com/eden/mysqlgo

We had a second MySQL binding but I think Yone has switched to
Postgres instead (no release yet that I know of):

http://github.com/yone098/go-mysql

Feedback welcome, on the API as well as the implementations.

Cheers,
Peter

[Joan Miller]

For non-sql DBMS:

Document:
http://github.com/hoisie/gocouch
http://github.com/mikejs/gomongo

Key-value:
http://github.com/alphazero/Go-Redis
http://github.com/patrickxb/gotyrant


On 16 dic, 19:01, Peter Froehlich <peter.hans.froehl...@gmail.com>
wrote:
> Hi all,

>
> On Wed, Dec 16, 2009 at 12:22 PM, Per Andersson <dim.ra...@gmail.com> wrote:
> > I agree, this might not be so bad with proper DB bindings.
>
> I hope I won't hijack the thread with this:
>

> http://github.com/phf/go-dbhttp://github.com/phf/go-sqlite3http://github.com/eden/mysqlgo

[Joan Miller]

Michael, about this point:

"4. ability to use asynchronous handlers (for comet and long-polling)"

you should read here [1], and to summarizing its author says that all
these technologies (comet, long-poll, AJAX, keep-alive sockets) have
been hacks, so should be used web sockets which has already added to
Go [2].


[1] http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html
[2] http://golang.org/pkg/websocket/

[Michael Hoisie]

Yes websockets will probably replace comet and long-polling in the
future, but currently it's not a viable way to write real-time web
applications. Long-polling is fairly robust, and it's used by very
high-traffic websites (i.e gmail, facebook).

I like what the friendfeed guys did with tornado ( http://www.tornadoweb.org/
), so I'm mostly planning to borrow ideas from that.

- Mike

On Dec 16, 12:05 pm, Joan Miller <pelok...@gmail.com> wrote:
> Michael, about this point:
>
> "4. ability to use asynchronous handlers (for comet and long-polling)"
>
> you should read here [1], and to summarizing its author says that all
> these technologies (comet, long-poll, AJAX, keep-alive sockets) have
> been hacks, so should be used web sockets which has already added to
> Go [2].
>

> [1]http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-li...

[Uriel]

There are more bindings for various databases here:

http://go-lang.cat-v.org/library-bindings

and a few db clients written in Go:

http://go-lang.cat-v.org/pure-go-libs

[Joan Miller]

On 16 dic, 20:26, Michael Hoisie <hoi...@gmail.com> wrote:
> Yes websockets will probably replace comet and long-polling in the
> future, but currently it's not a viable way to write real-time web
> applications. Long-polling is fairly robust, and it's used by very
> high-traffic websites (i.e gmail, facebook).
>

> I like what the friendfeed guys did with tornado (http://www.tornadoweb.org/

> ), so I'm mostly planning to borrow ideas from that.
>
> - Mike
>
> On Dec 16, 12:05 pm, Joan Miller <pelok...@gmail.com> wrote:
>
> > Michael, about this point:
>
> > "4. ability to use asynchronous handlers (for comet and long-polling)"
>
> > you should read here [1], and to summarizing its author says that all
> > these technologies (comet, long-poll, AJAX, keep-alive sockets) have
> > been hacks, so should be used web sockets which has already added to
> > Go [2].
>
> > [1]http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-li...
> > [2]http://golang.org/pkg/websocket/

Since it seems that one of the developers of Tornado doesn't think
thus and he has built a module for websockets on Tornado.

http://bret.appspot.com/entry/web-sockets-in-tornado

[Devon H. O'Dell]

2009/12/31 Joan Miller <pelo...@gmail.com>:

>> On Dec 16, 12:05 pm, Joan Miller <pelok...@gmail.com> wrote:
>>
>> > Michael, about this point:
>>
>> > "4. ability to use asynchronous handlers (for comet and long-polling)"
>>
>> > you should read here [1], and to summarizing its author says that all
>> > these technologies (comet, long-poll, AJAX, keep-alive sockets) have
>> > been hacks, so should be used web sockets which has already added to
>> > Go [2].
>>
>> > [1]http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-li...
>> > [2]http://golang.org/pkg/websocket/
> Since it seems that one of the developers of Tornado doesn't think
> thus and he has built a module for websockets on Tornado.
>
> http://bret.appspot.com/entry/web-sockets-in-tornado

This is an odd statement as comet is typically implemented using
long-polling AJAX. It is a hackish method, sure, but it is what works
now. There is no doubting that websockets are `the way of the future';
but as with most web technologies, it is not extremely viable until
all major browsers support it in a release version, which is likely
some time off yet. This doesn't mean we shouldn't support it, or at
least keep it in mind for usability. It simply means that it's jumping
the gun to eschew long-polling just yet.

--dho