Live data from Hacker News

On Go’s Web Application Ecosystem

thechangelog.com

41–50 of 50 posts

Re: On Go’s Web Application Ecosystem

#41

Anyone have a link to an open source web app of a non-trivial nature built in go? I've seen lots of system utility stuff, but I don't think I've ever actually seen anything other than how-to-use-this-framework web apps?

There is https://github.com/peterskeide/bones (I'm the author). It's by no means a large codebase, and it's not finished, but the goal is to give you a decent starting point with some hopefully useful idioms to build on.

Re: On Go’s Web Application Ecosystem

#42
post #25

What I find interesting about Go[1] and the web application community is that people constantly point to speed as a huge selling point. Speed in the sense of latency and request volume per server. I still feel like for the majority of cases, this type of speed difference is not going to matter. The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular P…

I'd disagree that node.js fit that argument. I do python Django in my day job and a ton of node.js in my other projects (startup nearing launch, two other projects) and with express there is not a huge gulf in productivity between the two. All of my node.js projects is based upon No-SQL (leveldb, mongodb, couchdb) db's so I'm not up on JS's ORM libs but it might be a large difference there but it's certainly not when using a No-SQL db.

Re: On Go’s Web Application Ecosystem

#43

Earlier quoted context omitted.

This article seems to be pushing Martini, which at first glance looks interesting (though it doesn't appear to have been mentioned on the mailing list even once, so there may be some boosting involved). There is Revel, but it seems to be getting a bad rap ("non-idiomatic" label used as a stick).

Martini author here. Weird how it didn't show up in the golang-nuts search, here is a link to the announcement topic: https://groups.google.com/forum/#!topic/golang-nuts/LubMauy6... Martini is still young (less than a week) but the core is pretty fleshed out. No boosting here (I don't even have that many twitter followers). I just put together a framework that doesn't step on your toes and people ate it up :)

I love what I've seen so far. The biggest problem is probably the age. Googling for "go martini json" will not yield results until more users start to talk about it.

Re: On Go’s Web Application Ecosystem

#44

Earlier quoted context omitted.

Martini author here. Weird how it didn't show up in the golang-nuts search, here is a link to the announcement topic: https://groups.google.com/forum/#!topic/golang-nuts/LubMauy6... Martini is still young (less than a week) but the core is pretty fleshed out. No boosting here (I don't even have that many twitter followers). I just put together a framework that doesn't step on your toes and people ate it up :)

I love what I've seen so far. The biggest problem is probably the age. Googling for "go martini json" will not yield results until more users start to talk about it.

Yup. Getting there will take a while. In the meantime I plan on releasing a whole bunch of middleware in the martini-contrib repo and creating more video tutorials on web development in Go.

Re: On Go’s Web Application Ecosystem

#45
post #25

What I find interesting about Go[1] and the web application community is that people constantly point to speed as a huge selling point. Speed in the sense of latency and request volume per server. I still feel like for the majority of cases, this type of speed difference is not going to matter. The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular P…

> The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular Python framework at 18,945[2] (3.1 ms) is trivial when you look at the bigger picture.

I disagree, and think that's a huge difference. The latency may not be, but requests per second? That could be a significant amount of difference if you start pulling decent traffic: you need ten Flask servers for every one Go server. That's a lot of ops complexity you can save yourself right there.

Flask, mind you, has a much more mature ecosystem (WTForms, SQLAlchemy, et. al) and development is likely to be faster on that front, but if you're looking at building something scalable and don't mind a bit of groundwork now, there is an advantage to using Go. It just may not be an advantage for every team (and that's fine: horses for courses).

Re: On Go’s Web Application Ecosystem

#46
post #15
post #7

One thing I'd like to see in Go is a way to sanitise HTML based on a whitelist. This is to accompany blackfriday (Markdown) and text/template (templating). Markdown permits HTML, and this allows some scope for nasty stuff to get in, or for bugs that may exist in blackfriday to be exploited leading to HTML that could be the source of a XSS attack. We're currently running our user generated content through this: https:…

In moving a site from PHP to go in a rewrite, I'm about to head down that same road. The plan is to use the HTML parser from the "not quite in the real distribution but kind of official" net repository: http://godoc.org/code.google.com/p/go.net/html Parse the HTML, walk the result, write that which is acceptable. I have to restrict by tag, url scheme, and url server name in various contexts.

Thanks to a fellow HN reader, we now have a head start on trying to create a HTML sanitizer.

https://github.com/microcosm-cc/bluemonday

Feel free to use it and help out.

Initial work was all done by Matt Jibson as part of his Google Reader Clone: https://github.com/mjibson/goread

Re: On Go’s Web Application Ecosystem

#47
post #25

What I find interesting about Go[1] and the web application community is that people constantly point to speed as a huge selling point. Speed in the sense of latency and request volume per server. I still feel like for the majority of cases, this type of speed difference is not going to matter. The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular P…

> The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular Python framework at 18,945[2] (3.1 ms) is trivial when you look at the bigger picture. I disagree, and think that's a huge difference. The latency may not be, but requests per second? That could be a significant amount of difference if you start pulling decent traffic: you need ten Flask server…

> That's a lot of ops complexity you can save yourself right there.

If you're doing that kind of sustained request volume then you'd like have web server redundancy for availability reasons , right? Reverse proxying from nginx to a Go app vs. a flask/uwsgi app becomes a pretty small problem.

I'm definitely not arguing that Go isn't more "scalable". By all of our measures, it is. I'm talking about the huge sacrifices you make to productivity to use it as a developer for specifically modern web development.

Re: On Go’s Web Application Ecosystem

#48
post #25

What I find interesting about Go[1] and the web application community is that people constantly point to speed as a huge selling point. Speed in the sense of latency and request volume per server. I still feel like for the majority of cases, this type of speed difference is not going to matter. The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular P…

I'd disagree that node.js fit that argument. I do python Django in my day job and a ton of node.js in my other projects (startup nearing launch, two other projects) and with express there is not a huge gulf in productivity between the two. All of my node.js projects is based upon No-SQL (leveldb, mongodb, couchdb) db's so I'm not up on JS's ORM libs but it might be a large difference there but it's certainly not when…

Gotcha. Yea, I put that in there because I've read/heard second hand information about Node.js requiring a substantial amount of boilerplate, etc. Sounds like that time has past. :)

Re: On Go’s Web Application Ecosystem

#49
When I read all these posts praising Go, I feel like a stranger accidently appeared at someone's birthday party. I really want to start loving Go, it looks perspective and people already benefit from using it, but I just cannot make me enjoy the language.

Having Java/Scala background I used to have static checking and performance for free and I cannot feel about Go the same as someone who switched from Python, PHP, Ruby stacks. I code mainly in Scala, and even if I like Go's simplicity, compilation speed and the absense of Java burden, I really miss features like default immutability, pattern matching, generics, reach collection toolset, powerful typesystem. The language looks just not expressive for me to really enjoy.

Maybe I am corrupted with FP, cannot value simplicity or I should focus more on getting things done not on the process of writing code. Just wonder, if anyone else have similar impressions / feelings?

Re: On Go’s Web Application Ecosystem

#50
post #38
post #27

Earlier quoted context omitted.

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...

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 us…

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.
Post reply on HN