4 ms·

Just curious, what were the worst gaps in functionality and have you looked at it recently? I'm pretty happy with Go for full stack web apps, but it did take a

Just curious, what were the worst gaps in functionality and have you looked at it recently? I'm pretty happy with Go for full stack web apps, but it did take a little while to get up to speed and a few years ago there were fewer solutions for common problems available. A few areas where it required some more work: Authentication - there are a few good examples out there, I think gorilla secure cookie is good, CSRF protection too. Authorisation - had to write my own version of the ruby lib cancan, am now happy with the solution Images - stdlib is pretty good but it'd be nice if it handled resizing images and exif orientation tags. Javascript and CSS - there are some ports of minifiers in go so an asset pipeline is pretty easy. ORM - I use a query builder and use the map columns->fields in code, not keen on the orms using reflection and/or struct tags to do so. This doesn't have to be complex though. Migrations - there are a few libraries out there now, so this isn't bad, I prefer sql migrations. Templates - love the context-sensitive escaping, would be nice if it handled layout/partial but this is doable with some tweaks. Forms - generation of views with text/template is pretty handy to handle things like CRUD forms for models. This is where frameworks are useful - they present best-practices for the above details and more that you have to handle in a full-scale webapp. I think those are the areas I'd like to see more tutorials on for beginners coming to Go, but there are solutions out there nowadays (far more than even a few years ago).Most of the things you mention are not in the std library so I guess people feel a little lost when they first arrive in Go land, but there are a few libraries out there like gorilla which cover most of this stuff or you can write your own, and once you have it's a really pleasant language to write traditional server-side apps with. So with the above caveats I'm really happy with it for full stack web development.

christophilus 10y ago
I'd love to see some blog posts about this. The lack of any good resources on full-stack web frameworks is what has kept me from really diving deep into Go. I still believe (pretty strongly) in traditional, server-rendered, low JS overhead websites / app.
brightball 10y ago
My biggest issue was with server rendered applications. I think it's a good fit for SPA's where each piece is rendered to the browser independently. Just as an example, my go to test for most programming languages is to rebuild my personal site with it (http://brightball.com/ http://brightball.com/). Just provides me with a good exercise in running through a simple project that I've done in multiple languages and provides a good basis for comparison without getting too fancy. If you'll look at the page layout, you'll see the main content area with a list of articles, some sidebar elements that are loaded from the database and a list of primary tags in the footer (also pulled from the database). The biggest pain point was the reusable elements (sidebar and footer) with the template system. In most other template systems it's pretty trivial to write parts that have code attached to them and tell a layout to call those pieces with some arguments. With Go, that was a bit of a pain requiring all of the data that that would appear on the page to be retrieved before starting the rendering process. That led to a lot of repetition to pull in that data on every path to the layout. So the layout/partial system would be my biggest pain point. My first instinct was to go and reach for a framework but so much stuff that I read on Go boards gave the impression that the community seemed to have a very negative impression there. Additionally, there wasn't a clear winner among frameworks which made me hesitate. That's a problem you see in languages that have so much stuff for the web built in like PHP and Javascript. It becomes so easy to do-it-yourself on the framework front that there are a million different flavors and no clear path. With Ruby, Python, Elixir, Groovy, etc there are clear and dominant frameworks for the language. If you learn this language, you should know framework "X". When there isn't that clear winner, it's hard to justify investing in developing around it. To try to get around that issue and the sense that with Go you were supposed to sort of assemble your own parts, not commit to a framework, etc I tried https://github.com/runemadsen/ok-go https://github.com/runemadsen/ok-go since it's basically a framework of assembled and replaceable parts. After a while I just gave up on it and started looking at porting to Hugo before I found out about Elixir and gave it a shot. Ultimately, that was exactly what I was looking for (http://brightball.com/articles/insanity-with-elixir-phoenix-postgresql http://brightball.com/articles/insanity-with-elixir-phoenix-...). Most of the issues I describe are non-issues if Go is backing a React/Angular app instead. I just found it to be a huge pain for entirely server side applications.
- 10y ago

christophilus 10y ago

I'd love to see some blog posts about this. The lack of any good resources on full-stack web frameworks is what has kept me from really diving deep into Go. I still believe (pretty strongly) in traditional, server-rendered, low JS overhead websites / app.

brightball 10y ago

My biggest issue was with server rendered applications. I think it's a good fit for SPA's where each piece is rendered to the browser independently. Just as an example, my go to test for most programming languages is to rebuild my personal site with it (http://brightball.com/ http://brightball.com/). Just provides me with a good exercise in running through a simple project that I've done in multiple languages and provides a good basis for comparison without getting too fancy. If you'll look at the page layout, you'll see the main content area with a list of articles, some sidebar elements that are loaded from the database and a list of primary tags in the footer (also pulled from the database). The biggest pain point was the reusable elements (sidebar and footer) with the template system. In most other template systems it's pretty trivial to write parts that have code attached to them and tell a layout to call those pieces with some arguments. With Go, that was a bit of a pain requiring all of the data that that would appear on the page to be retrieved before starting the rendering process. That led to a lot of repetition to pull in that data on every path to the layout. So the layout/partial system would be my biggest pain point. My first instinct was to go and reach for a framework but so much stuff that I read on Go boards gave the impression that the community seemed to have a very negative impression there. Additionally, there wasn't a clear winner among frameworks which made me hesitate. That's a problem you see in languages that have so much stuff for the web built in like PHP and Javascript. It becomes so easy to do-it-yourself on the framework front that there are a million different flavors and no clear path. With Ruby, Python, Elixir, Groovy, etc there are clear and dominant frameworks for the language. If you learn this language, you should know framework "X". When there isn't that clear winner, it's hard to justify investing in developing around it. To try to get around that issue and the sense that with Go you were supposed to sort of assemble your own parts, not commit to a framework, etc I tried https://github.com/runemadsen/ok-go https://github.com/runemadsen/ok-go since it's basically a framework of assembled and replaceable parts. After a while I just gave up on it and started looking at porting to Hugo before I found out about Elixir and gave it a shot. Ultimately, that was exactly what I was looking for (http://brightball.com/articles/insanity-with-elixir-phoenix-postgresql http://brightball.com/articles/insanity-with-elixir-phoenix-...). Most of the issues I describe are non-issues if Go is backing a React/Angular app instead. I just found it to be a huge pain for entirely server side applications.

10y ago