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?
Go best practices, six years in
11–20 of 207 posts
Re: Go best practices, six years in
#12The article sort of glosses over IntelliJ with the golang plugin as an "other" IDE, but it's best in class hands down. At one point in my past I had sworn off of Java-based IDEs, and used Sublime Text for years with primarily Python and Go. Something convinced me to try Go in IntelliJ, and really it's fantastic. It also covers "important-to-me" features the author mentions. I haven't tried VSCode yet, but have tried…
There's also Goclipse for Eclipse.
Re: Go best practices, six years in
#13[deleted]
Re: Go best practices, six years in
#14Slightly 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?
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.
Re: Go best practices, six years in
#15Slightly 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?
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…
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.
Re: Go best practices, six years in
#16The article sort of glosses over IntelliJ with the golang plugin as an "other" IDE, but it's best in class hands down. At one point in my past I had sworn off of Java-based IDEs, and used Sublime Text for years with primarily Python and Go. Something convinced me to try Go in IntelliJ, and really it's fantastic. It also covers "important-to-me" features the author mentions. I haven't tried VSCode yet, but have tried…
In my experience most Go developers seem to favor a terminal-heavy workflow, sometimes frequently shutting down and re-opening their editors in new paths and projects. The barebones simplicity of Go-the-language seems to be a nice match to this workflow. It's a different thing altogether to how large IDEs like IntelliJ expect you to work: opening up a project and staying in the IDE for a long period of time. Both app…
I concur. Go syntax is dead simple and even the most basic tools like https://play.golang.org/ can be used without hesitation for some quick and dirt POCs. In the discovery mode, when you're learning a new library, any tool that supports code completion and provides documentation links is nice to have.
Re: Go best practices, six years in
#17Slightly 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?
>>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.
Re: Go best practices, six years in
#18Earlier quoted context omitted.
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…
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 te…
Your cause is just. Keep fighting the good fight!
Re: Go best practices, six years in
#19Earlier quoted context omitted.
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…
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 te…
Sure, and I thought twice before putting that in :)
We of course monitor our 95th & 99th primarily, for reasons that you said.
But I didn't quote those because they're usually blown out by slow db queries, n+1 selects,n+1 cache gets, etc, issues that happen regardless of language. often they're on rarely used end points, where the cost-benefit of optimising isn't worth it.
I feel median gives a resonable proxy for the language/framework execution capabilities.
Re: Go best practices, six years in
#20Slightly 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?
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.