[taude]

I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax.

I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now have a custom messaging service that needs to scale better" or something, much like when people choose to drop into C or C++. It also seems that there's more dev-friendly languages to build the web layer in.... I also don't see many web-dev types thinking in GO very well.

So, why GO at the web-layer?

[jws]

For me:

• I prefer to find my errors at compile time. Consider the time to find and fix a missing method in a go compile (one 'make' and all the info is still in the developer's brain cache) versus eventually having a user drive the website into that method and having a mystery occur on a duck typed language. (hope you have good stack trace logging on the back end)

• I prefer a language that doesn't repeatedly break all my code. When I write and deploy a site, it should stay written. (Looking at you PHP. Granted, this was over a period of 15+ years, but all the more reason I don't want to go back and look at that code.)

• Efficiency is nice if you are ever going to hit a performance bottleneck. To elaborate: you get to defer the "OMG I need to map this load over more than one machine!" crisis for a while, and if you end up in a "I need N machines!", then making N smaller is good for your well being.

• Builds are fast enough that I don't care. I generally have a makefile for a website anyway to get everything organized and encoded, one more rule to build the go is no burden.

The weakest spot I'm finding is the html/template end. My strong typing evaporates at that boundary. I'd rather have the template get precompiled into go code and then compiled into functions with nicely defined interfaces on its parameters; faster to run and catch all those typos in field names. The current go mindset of a "go only", non-extendable, build command forecloses experimentation in this direction. (Unless you are a barbarian from the olden days, like me, and wrap everything in a Makefile.)

[taude]

Cool. All valid points. I have a question, do you think builds in Go for a large web app will remain fast? I ask from the experience of working in Java with several minute build/deploy times...

[venuzr]

From my experience, defintely yes. I use the Revel framework for creating my APIs to be consumed client side (Angular).

When I make changes, refreshing the browser results in a re-compile which takes less than a second (assuming I have modified several files) on my 2012 Macbook pro.

With Go, unit testing is also blazing fast. My entire test suite (around 30+ tests) takes around 0.2 seconds.

Just for comparision, I used Play 2 (Scala) for a short while before that. Re-compilation would take in the region of 10 seconds. Startup costs are high in the Java/.NET world :(

[taude]

Thanks for the information. It sounds like you've got some experience that I can relate to. I might actually check GO out for some API work.

[jasomill]

I assume this will be less of a problem in Go, because rapid compilation for large projects with complicated dependencies is one of the main design goals of Go.

[grey-area]

Many other tools are good for web dev too, but having played around with it I'd say in principle Go is well suited to it, if you don't mind the lack of mature frameworks/libraries. I don't see why the syntax gets in the way of it being web friendly, which bit did you think would be a problem?

Deployment is far simpler with no libraries/gems/packages - single binary

Memory usage is an order of magnitude smaller than languages like Ruby or Java.

It's pretty fast (much faster than Ruby for example)

String manipulation isn't too painful - all the tools are there for manipulating unicode text and producing html.

Why not?

[taude]

The "deployment" theme is pretty common that I keep hearing. Definitely something that sounds appealing.

[rjknight]

Web servers aren't back end service-type-of-stuff?

[taude]

I don't classify them the same. It's easier to have many web developers (in fact most I've worked with) who work on web app layer (working with the templates, javascript, depending on complexity of app the data-access-layer) than it is to have them working with messaging services, more complex data access logic, complex document rendering services, databased, our emailing management system, etc.

So, yes, I look at web server of an application as a pretty distinct part of the back-end, separated from many other complexities in the system. I also view it as the beginner (can't think of a better term [1] ) part of the back-end-system where there's a lot of devs who can conceptualize this layer who can't the other stuff. It's these devs whether I question they'll conceptualize GO in general.

[1] EDIT: I just thought of a better way to describe "beginner" with more clarity: non-computer-science-types who are competent at working in the web layer.

[jemeshsu]

Because Go is a general purpose programming language and why not web-layer? There is even a tutorial on creating wiki site on golang.org.

[pstuart]

Because it's fast, a pleasure to code in, and simple to distribute.

[taude]

The distribution story is definitely appealing. I think it was only the other day a post showed up here with someone making command-line tools with it. I find this appealing.