8 ms·

Slightly tangential, but, could someone share their experience using Go specifically for building websites? How does Go (including Go frameworks specifically g

Slightly tangential, but, could someone share their experience using Go specifically for building websites? How does Go (including Go frameworks specifically geared towards web development) compare in terms of performance, ease of development with RoR, Laravel? Is building websites using Go a good use case or is Go better suited for building high performance microservices?

tyingq 10y ago
>>How does Go ... compare in terms of performance, ease of development with RoR, Laravel? The available web frameworks for Go are more comparable to microframeworks like flask. If comparing directly to RoR or Laraval, you may find some gaps. Not that they can't be solved, but there's less available out of the box. Things like: - multiple file upload - session handling without cookies - built in support for a variety of authentication types and backends The communities are also significantly smaller, so there's less experience to draw on. Not to say you can't build websites just fine with golang, but it's doesn't seem to be a strong suit at the moment.
Thaxll 10y ago
Go is pretty good for anything backend related.
- eternalban 10y ago
  No, that is definitely not correct, unless your "anything" is merely that which is fully defined & composed at compile time. (And yes, you can go the IPC route to introduce dynamism that you get out of the box from a VM based language. But here is the classic case of the Go [tail] wagging the architecture [dog]..) [edit: correct tail endian]
- asimuvPR 10y ago
  My experience over the years is that Go serves a specific niche ver well. The niche being boring long running services that do simple tasks in unison with other services. It's better to see it as a language wi th which you can build little self contained machines that work well together. I have a system made up of such little machines and it quietly works away at some low end server.
iamd3vil 10y ago
I worked with both Go and Elixir but found Elixir and Phoenix better than Go for building backends for web services. I was more productive and all the awesomeness of Erlang VM made me choose Elixir. I would say give Elixir a try.
pella 10y ago
performance: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=update https://www.techempower.com/benchmarks/#section=data-r12&hw=...
dalyons 10y ago
I've done a lot of ruby and go. Honestly, I would think twice before building a major website/product API on go. Development time is markedly slower in go, some causes off the top of my head: - testing is way harder (ruby has some amazing mocking/stubbing/testing tooling). - debugging is way harder. Hope you like printf. - Json; the strict typing & struct searialization rules make dealing with Json a pain in the arse, and heavy on boilerplate - interfacing with Sql (if you have to do a lot of it) is a pain in the arse, for similar reasons to json. - having no stack for errors is insanely frustrating. - templating in go is primitive Go is amazing for services. The parallelisation primitives are fantastic, and allow you to do things that would be hard/impossible in ruby/Python. Go is undeniably much faster, execution wise. (Although our super high volume ruby product api is at 50ms median so, it matters less than you think) Decide what you care about most; if your prime goal is to get a product in front of customers as soon as possible, I'd pick a higher level language. If you want to make a rock solid service that sips on resources & scales to the moon, use go.
- jsmthrowaway 10y ago
  Median latency is a completely useless number. There is literally no use for it, ever. Satan invented median latency to confuse people, because it lies to you and whispers sweet nothings in your ear. Averaging latencies in your monitoring leaves the outliers out in the cold because you will never see them, and tail latency is way more important for user experience. Quantile your latency. I suspect you'll find 99th tells an interesting story between Ruby vs. Go. The best latency graph has five or six lines at different percentiles (yes, including 50) stacked in a latency sandwich. I'm willing to bet your app has a rough 99th. Maybe even a rough 95th. Nothing against Rails (honest, this applies to most interpreters), but most scripted stuff has a pretty rough latency tail, and you ignore that with median. (Go is not off the hook either; GC pauses can blow out high percentiles if you're memory-heavy.) I'm pretty passionate about this, sorry. I'm on a mission from God to purge our mortal plane of average/median latency, because it's one of those misapplications of statistics that everybody does without a second thought. Don't even collect it. Average latency is unimportant and misleads people, and misleads people more as you get more popular. It's that 1% of clients sitting there for 2sec that impacts perception of your UX.
matthewmacleod 10y ago
My experience says "don't use Go for building web applications". Compared to something like Ruby on Rails, the development story with Go is much less batteries-included. You'll find yourself gluing together lots of components, and they're not really that friendly. Plus, for any front-end code, you'll end up using Node or whatever anyway to build assets. It's big and messy and not a good match. Go does excel at two kind of web applications however: - Simple single-page applications that use Websockets or simple AJAX to perform a basic task. In this case, the limitations around templating and such are less obvious, and Go is a brilliant match for Websocket clients. Think of things like status dashboards. - JSON APIs with no front-end. Build your front-end using whatever other technology, and just fire requests at a Go app. It's pretty good at handling this, though JSON marshalling/unmarshalling is a bit stupid in Go.
- ver4no 10y ago
  what would you use go for then?
  - spriggan3 10y ago
    People use Go to write "infrastructure services", such as Rest APIs, caches, proxies,queues ... and command line tools. That's what Go does best since it requires minimal investment upfront( the language is tiny, the standard library has a lot of network oriented code...). Whether one can effectively write a classic website with complicated HTML templates and web forms like Rails,JSF and co allow is however questionable since Go type system lacks of expressiveness. Go fans answer is "use client side javascript" which is ironic since javascript is the antithesis of Go in terms of design.
  - matthewmacleod 10y ago
    Go is great for what is describe as "plumbing" - things like proxies, infrastructure tools or simple microservices. The simplicity is a great benefit in these cases. I've also found it unexpectedly useful for some embedded applications. Deployin code to the raspberry pi is super simple and that makes it quite attractive - there are projects that provide for thing like i2c, GPIO and SPI, and combined with the built-in HTTP support its a pretty compelling platform.
shurcooL 10y ago
I really enjoy using Go for building websites. But I use Go for everything, including games, frontend (instead of JavaScript), etc. There's nothing else I'd rather use. Heck, I even rewrote my resume in Go that renders HTML on frontend [0], hehe. [0] view-source:https://dmitri.shuralyov.com/resume https://dmitri.shuralyov.com/resume
andreynering 10y ago
RoR is an awesome framework that has (almost) everything you need to build monolithic web apps. Go is a different story. You need to join the pieces together to make something functional. You will probably need: - A router like [Gin](https://github.com/gin-gonic/gin https://github.com/gin-gonic/gin) - A [XSRF token generator and validator](https://github.com/golang/net/blob/master/xsrftoken/xsrf.go https://github.com/golang/net/blob/master/xsrftoken/xsrf.go) - An ORM like [Gorm](https://github.com/jinzhu/gorm https://github.com/jinzhu/gorm) or [XORM](https://github.com/go-xorm/xorm https://github.com/go-xorm/xorm) - A template lib like the one that comes with the stdlib - Node for front-end (ugh, this is the harder part) - The testing library in stdlib plus maybe [testify](https://github.com/stretchr/testify https://github.com/stretchr/testify) - etc... Many nice things are missing. Some were [shamelessy copied by other people](https://github.com/go-testfixtures/testfixtures https://github.com/go-testfixtures/testfixtures). Some you may need to implement yourself. The big advantages is that Go has much better performance, and run on Windows, etc.
- lastofus 10y ago
  Can you explain more about using Node for the front end? Do you mean you use `npm` for front-end package management, or are you running a Node server process along side your Go process on the backend?
  - andreynering 10y ago
    Yes, I am talking about asset management. Rails has Asset Pipeline. In Go, if you want a build step for JS and CSS you have to play with node.
- jimjimjim 10y ago
  err... RoR is a full-size framework. Ruby is the language. Go is a language. Go has frameworks. You are comparing apples to oranges. With go you can then select what functionality, libraries, toolkits or frameworks you want to use with your system. ps. why would you mention node? would you use node with a php site?
  - 10y ago
55tine 10y ago
The other answers provided plenty of info on Go, so if you're looking for a new language and framework for web dev I suggest checking out elixir and Phoenix. They're inspired by ruby/rails (without some of the problems) and have many of the benefits of erlang.
ereyes01 10y ago
As you probably know (and as you can probably tell from some of the responses here), sometimes choosing languages can be like choosing a religion :-) As a backend for a web application, Go's performance is pretty great. The Go standard library comes with a fast parallel-enabled HTTP server that already makes use of all your cores in recent Go versions. No need for things like gunicorn to take advantage of cores. There's no interpreter overhead, and there's plenty of benchmark comparisons with other languages out there on Google. I've never heard of someone not using Go as a server-side language because it wasn't fast enough :-) Go has very robust support for creating web applications. Of course, for the frontend you will still need HTML+CSS+JS (maybe + a JS framework like Angular depending on your needs). There is a crazy experiment called GopherJS to run Go in the browser/frontend, but currently, a crazy experiment is all it is IMO... For serving dynamic content, the Go standard library comes with its own templating language and library: https://golang.org/pkg/html/template/ https://golang.org/pkg/html/template/ The standard library also comes with most of the tools you'll need for defining HTTP routes (see the server examples): https://golang.org/pkg/net/http/ https://golang.org/pkg/net/http/ Personally, I've found the following third-party packages to be quite helpful with putting together HTTP server-side apps in Go: - Gorilla mux for defining templated routes: https://github.com/gorilla/mux - Negroni for HTTP route Middlewares: https://github.com/codegangsta/negroni For testing HTTP server-side Go applications, the httptest package is quite helpful: https://golang.org/pkg/net/http/httptest/ https://golang.org/pkg/net/http/httptest/ As you can see, most of what you need just comes with the standard library, which is quite professionally designed and coded (reading through their source is a pleasure). The two external dependencies I mentioned are helpful, but not a strict requirement to build a server-side app. The main obstacle people have with using Go IMO has little to do with its ability to be used as a server-side language, and more to do with the nature of the language, and the consequences of its design choices. I think people who strongly prefer terse dynamic languages have trouble adopting/enjoying Go and its way of doing things. For instance, someone in this thread said that Go's structs and static typing makes it harder to work with JSON. You could also make the argument that this is a strength- all I have to do is declare a struct to specify what exactly I want to read from / write to JSON. Some people have complained about Go's verbosity. Sometimes they are right- certain things in Go take a little more text to express. I'm convinced that Go is a language that is more optimized for readability than for writability. You typically can't write "expressive" koans in a line of code... but your teammates probably have a higher chance (in my subjective opinion) of understanding the Go code you wrote a year after you've forgotten what you were thinking about. I could go on and on, but now I'm just fighting the eternal language holy wars :-) I hope I've given you a starting point for more research if you were considering Go for a server-side web application.

tyingq 10y ago

>>How does Go ... compare in terms of performance, ease of development with RoR, Laravel? The available web frameworks for Go are more comparable to microframeworks like flask. If comparing directly to RoR or Laraval, you may find some gaps. Not that they can't be solved, but there's less available out of the box. Things like: - multiple file upload - session handling without cookies - built in support for a variety of authentication types and backends The communities are also significantly smaller, so there's less experience to draw on. Not to say you can't build websites just fine with golang, but it's doesn't seem to be a strong suit at the moment.

Thaxll 10y ago

Go is pretty good for anything backend related.

eternalban 10y ago
No, that is definitely not correct, unless your "anything" is merely that which is fully defined & composed at compile time. (And yes, you can go the IPC route to introduce dynamism that you get out of the box from a VM based language. But here is the classic case of the Go [tail] wagging the architecture [dog]..) [edit: correct tail endian]
asimuvPR 10y ago
My experience over the years is that Go serves a specific niche ver well. The niche being boring long running services that do simple tasks in unison with other services. It's better to see it as a language wi th which you can build little self contained machines that work well together. I have a system made up of such little machines and it quietly works away at some low end server.

iamd3vil 10y ago

I worked with both Go and Elixir but found Elixir and Phoenix better than Go for building backends for web services. I was more productive and all the awesomeness of Erlang VM made me choose Elixir. I would say give Elixir a try.

pella 10y ago

performance: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=update https://www.techempower.com/benchmarks/#section=data-r12&hw=...

dalyons 10y ago

I've done a lot of ruby and go. Honestly, I would think twice before building a major website/product API on go. Development time is markedly slower in go, some causes off the top of my head: - testing is way harder (ruby has some amazing mocking/stubbing/testing tooling). - debugging is way harder. Hope you like printf. - Json; the strict typing & struct searialization rules make dealing with Json a pain in the arse, and heavy on boilerplate - interfacing with Sql (if you have to do a lot of it) is a pain in the arse, for similar reasons to json. - having no stack for errors is insanely frustrating. - templating in go is primitive Go is amazing for services. The parallelisation primitives are fantastic, and allow you to do things that would be hard/impossible in ruby/Python. Go is undeniably much faster, execution wise. (Although our super high volume ruby product api is at 50ms median so, it matters less than you think) Decide what you care about most; if your prime goal is to get a product in front of customers as soon as possible, I'd pick a higher level language. If you want to make a rock solid service that sips on resources & scales to the moon, use go.

jsmthrowaway 10y ago
Median latency is a completely useless number. There is literally no use for it, ever. Satan invented median latency to confuse people, because it lies to you and whispers sweet nothings in your ear. Averaging latencies in your monitoring leaves the outliers out in the cold because you will never see them, and tail latency is way more important for user experience. Quantile your latency. I suspect you'll find 99th tells an interesting story between Ruby vs. Go. The best latency graph has five or six lines at different percentiles (yes, including 50) stacked in a latency sandwich. I'm willing to bet your app has a rough 99th. Maybe even a rough 95th. Nothing against Rails (honest, this applies to most interpreters), but most scripted stuff has a pretty rough latency tail, and you ignore that with median. (Go is not off the hook either; GC pauses can blow out high percentiles if you're memory-heavy.) I'm pretty passionate about this, sorry. I'm on a mission from God to purge our mortal plane of average/median latency, because it's one of those misapplications of statistics that everybody does without a second thought. Don't even collect it. Average latency is unimportant and misleads people, and misleads people more as you get more popular. It's that 1% of clients sitting there for 2sec that impacts perception of your UX.

matthewmacleod 10y ago

My experience says "don't use Go for building web applications". Compared to something like Ruby on Rails, the development story with Go is much less batteries-included. You'll find yourself gluing together lots of components, and they're not really that friendly. Plus, for any front-end code, you'll end up using Node or whatever anyway to build assets. It's big and messy and not a good match. Go does excel at two kind of web applications however: - Simple single-page applications that use Websockets or simple AJAX to perform a basic task. In this case, the limitations around templating and such are less obvious, and Go is a brilliant match for Websocket clients. Think of things like status dashboards. - JSON APIs with no front-end. Build your front-end using whatever other technology, and just fire requests at a Go app. It's pretty good at handling this, though JSON marshalling/unmarshalling is a bit stupid in Go.

ver4no 10y ago
what would you use go for then?
- spriggan3 10y ago
  People use Go to write "infrastructure services", such as Rest APIs, caches, proxies,queues ... and command line tools. That's what Go does best since it requires minimal investment upfront( the language is tiny, the standard library has a lot of network oriented code...). Whether one can effectively write a classic website with complicated HTML templates and web forms like Rails,JSF and co allow is however questionable since Go type system lacks of expressiveness. Go fans answer is "use client side javascript" which is ironic since javascript is the antithesis of Go in terms of design.
- matthewmacleod 10y ago
  Go is great for what is describe as "plumbing" - things like proxies, infrastructure tools or simple microservices. The simplicity is a great benefit in these cases. I've also found it unexpectedly useful for some embedded applications. Deployin code to the raspberry pi is super simple and that makes it quite attractive - there are projects that provide for thing like i2c, GPIO and SPI, and combined with the built-in HTTP support its a pretty compelling platform.

shurcooL 10y ago

I really enjoy using Go for building websites. But I use Go for everything, including games, frontend (instead of JavaScript), etc. There's nothing else I'd rather use. Heck, I even rewrote my resume in Go that renders HTML on frontend [0], hehe. [0] view-source:https://dmitri.shuralyov.com/resume https://dmitri.shuralyov.com/resume

andreynering 10y ago

RoR is an awesome framework that has (almost) everything you need to build monolithic web apps. Go is a different story. You need to join the pieces together to make something functional. You will probably need: - A router like [Gin](https://github.com/gin-gonic/gin https://github.com/gin-gonic/gin) - A [XSRF token generator and validator](https://github.com/golang/net/blob/master/xsrftoken/xsrf.go https://github.com/golang/net/blob/master/xsrftoken/xsrf.go) - An ORM like [Gorm](https://github.com/jinzhu/gorm https://github.com/jinzhu/gorm) or [XORM](https://github.com/go-xorm/xorm https://github.com/go-xorm/xorm) - A template lib like the one that comes with the stdlib - Node for front-end (ugh, this is the harder part) - The testing library in stdlib plus maybe [testify](https://github.com/stretchr/testify https://github.com/stretchr/testify) - etc... Many nice things are missing. Some were [shamelessy copied by other people](https://github.com/go-testfixtures/testfixtures https://github.com/go-testfixtures/testfixtures). Some you may need to implement yourself. The big advantages is that Go has much better performance, and run on Windows, etc.

lastofus 10y ago
Can you explain more about using Node for the front end? Do you mean you use `npm` for front-end package management, or are you running a Node server process along side your Go process on the backend?
- andreynering 10y ago
  Yes, I am talking about asset management. Rails has Asset Pipeline. In Go, if you want a build step for JS and CSS you have to play with node.
jimjimjim 10y ago
err... RoR is a full-size framework. Ruby is the language. Go is a language. Go has frameworks. You are comparing apples to oranges. With go you can then select what functionality, libraries, toolkits or frameworks you want to use with your system. ps. why would you mention node? would you use node with a php site?
- 10y ago

55tine 10y ago

The other answers provided plenty of info on Go, so if you're looking for a new language and framework for web dev I suggest checking out elixir and Phoenix. They're inspired by ruby/rails (without some of the problems) and have many of the benefits of erlang.

ereyes01 10y ago

As you probably know (and as you can probably tell from some of the responses here), sometimes choosing languages can be like choosing a religion :-) As a backend for a web application, Go's performance is pretty great. The Go standard library comes with a fast parallel-enabled HTTP server that already makes use of all your cores in recent Go versions. No need for things like gunicorn to take advantage of cores. There's no interpreter overhead, and there's plenty of benchmark comparisons with other languages out there on Google. I've never heard of someone not using Go as a server-side language because it wasn't fast enough :-) Go has very robust support for creating web applications. Of course, for the frontend you will still need HTML+CSS+JS (maybe + a JS framework like Angular depending on your needs). There is a crazy experiment called GopherJS to run Go in the browser/frontend, but currently, a crazy experiment is all it is IMO... For serving dynamic content, the Go standard library comes with its own templating language and library: https://golang.org/pkg/html/template/ https://golang.org/pkg/html/template/ The standard library also comes with most of the tools you'll need for defining HTTP routes (see the server examples): https://golang.org/pkg/net/http/ https://golang.org/pkg/net/http/ Personally, I've found the following third-party packages to be quite helpful with putting together HTTP server-side apps in Go: - Gorilla mux for defining templated routes: https://github.com/gorilla/mux - Negroni for HTTP route Middlewares: https://github.com/codegangsta/negroni For testing HTTP server-side Go applications, the httptest package is quite helpful: https://golang.org/pkg/net/http/httptest/ https://golang.org/pkg/net/http/httptest/ As you can see, most of what you need just comes with the standard library, which is quite professionally designed and coded (reading through their source is a pleasure). The two external dependencies I mentioned are helpful, but not a strict requirement to build a server-side app. The main obstacle people have with using Go IMO has little to do with its ability to be used as a server-side language, and more to do with the nature of the language, and the consequences of its design choices. I think people who strongly prefer terse dynamic languages have trouble adopting/enjoying Go and its way of doing things. For instance, someone in this thread said that Go's structs and static typing makes it harder to work with JSON. You could also make the argument that this is a strength- all I have to do is declare a struct to specify what exactly I want to read from / write to JSON. Some people have complained about Go's verbosity. Sometimes they are right- certain things in Go take a little more text to express. I'm convinced that Go is a language that is more optimized for readability than for writability. You typically can't write "expressive" koans in a line of code... but your teammates probably have a higher chance (in my subjective opinion) of understanding the Go code you wrote a year after you've forgotten what you were thinking about. I could go on and on, but now I'm just fighting the eternal language holy wars :-) I hope I've given you a starting point for more research if you were considering Go for a server-side web application.