I'm using gotest for testing, my testing is really primitive right now, no mocking frameworks. The only non-standard library I'm using is gorilla/mux for routing. Go feels a little verbose and restrictive coming from Python, but after being acclimated, I love it. It's extremely productive, performance is nice, deployment is so easy. The pain points for me were understanding the package system and structuring my project, which I worked through eventually.
Ask HN: How are you using Go to write production-grade back end services?
11–20 of 25 posts
Re: Ask HN: How are you using Go to write production-grade back end services?
#12At a previous job we did a 'tech experiment' to write a Go REST service. As far as I'm aware it's still in use in a production-level capacity. It used the following:
- gotest
- No DI, but in hindsight this would have been the right thing to do. The dev team is 100% Python, so mocking was more the talk of the office than DI/IoC.
- For routing and HTTP the service used httprouter https://github.com/julienschmidt/httprouter
I think it's a fantastic language, gofmt and gotest are both great utilities, and the short time to create an executable made development turnaround a breeze.
However, I think for the purposes of a simple REST service I would probably use Python/Flask. Less boilerplate and for a Python team, it would have made more sense ...
Re: Ask HN: How are you using Go to write production-grade back end services?
#13I've been wanting to do a blog series on how we use Go. Here is a short version. Tests: We use the testing package for unit tests and (maybe too much) use interfaces as arguments so we can create test fakes that behave the way we want so we can validate error paths, logs (yes, we assert on logs), metrics, and, of course, green/good expected behavior. We then have acceptance level testing. These are ensuring the syste…
Appreciate the thoroughness of your comment (if you expand further in blog posts, I’ll read em). How did you settle on your standard project structure and what does it look like?
Re: Ask HN: How are you using Go to write production-grade back end services?
#14Heh, production grade depends more on the people in charge than the tech choices. The lack of exceptions in Go is the biggest stupid thing in software. Exceptions have always been a much less risque feature than multiple return values. In Go every single "function" has multiple return values and the code is litered everywhere with if err != nil... garbage. It will never change because it is apparent that exceptions a…
sounds like someone is too focused on aesthetics instead of maintainable code.
exceptions have far worse impacts than multiple returns and if statements to check. particularly that they are basically new age gotos. throw an exception, up and up and up it goes where it stops who knows!
Re: Ask HN: How are you using Go to write production-grade back end services?
#15I'm using Go with Redis for various aggressive caching needs. I batter Redis and Go performs very well. A few other languages will work mostly fine for my purposes, however I like working in Go and have always had a great experience with its performance.
No traditional testing. Standard library and Redigo. That's it.
No pain points for what I'm using it for. I usually try to avoid complexity in anything I build. This is a rather simple system that is only meant to take a high volume beating, cache to Redis (content later retrieved & presented by another part of the application via another language) and be reliable.
Re: Ask HN: How are you using Go to write production-grade back end services?
#16- Ginkgo and Gomega for tests, though sometimes just stdlib on smaller projects. I like Gomega very much, great matchers, lots of useful helpers.
- Manual DI, passing in values and objects. We've hand mocked a handful of components: just what's essential for testing.
- Mostly not using HTTP. But a few projects do, some simply use basic stdlib, others use Echo.
Re: Ask HN: How are you using Go to write production-grade back end services?
#17For our backend[1],
- We are using the default test framework that comes with Go; go test.
- We usually follow Postel's law which translated to Go, would be: `Accept interfaces, return concrete types`[2] This enables us to pass in fake interfaces during tests. I haven't checked what kind of performance cost(if any) we may be paying by passing around interfaces instead of concrete implementations; but performance has not been a problem so far so we are just happy with our approach.
- We do not use any http web frameworks, we are just using stdlib's net/http. We pair that with certmagic[3] for automated TLS certificate issuance and renewal.
I like the performance of Go, it is easy to pick up and it comes with a pretty great stdlib.
What I do not like is the fact that it has nil pointers, and you tend to run into one or two nil pointer dereference errors once in a while.
Re: Ask HN: How are you using Go to write production-grade back end services?
#18Heh, production grade depends more on the people in charge than the tech choices. The lack of exceptions in Go is the biggest stupid thing in software. Exceptions have always been a much less risque feature than multiple return values. In Go every single "function" has multiple return values and the code is litered everywhere with if err != nil... garbage. It will never change because it is apparent that exceptions a…
sounds like someone is too focused on aesthetics instead of maintainable code. exceptions have far worse impacts than multiple returns and if statements to check. particularly that they are basically new age gotos. throw an exception, up and up and up it goes where it stops who knows!
That's funny because Java devs for decades said that multiple returns and tons of if statement trees were the codings of satan. I am doing golang code right now and all I see are pages and pages of "if err != nil {" or "if err := doSomething(); err {". Oops I forgot to check err, guess my code is not as maintainable and my process is going to panic and die in the middle of a request. Guess I will write a defer-recover for every function in the call stack. Sure wish there was some handy notation to make it easier to try that and catch the failure, wink wink.
Every generation has their plaid pants. For c programmers it was ASCII art box headers for every file and function. For C# it was IMySuperLongClassInterfaceTypeOLEActiveXInterface. For java it is no collection literals, operator overloading, and fights over lambdas for a decade. For golang it is error return values EDIT: and also no generics/templates.
Re: Ask HN: How are you using Go to write production-grade back end services?
#19Heh, production grade depends more on the people in charge than the tech choices. The lack of exceptions in Go is the biggest stupid thing in software. Exceptions have always been a much less risque feature than multiple return values. In Go every single "function" has multiple return values and the code is litered everywhere with if err != nil... garbage. It will never change because it is apparent that exceptions a…
I've worked in exception based code bases such as Python (Twisted specifically) and Go. Unlike many, I've used both in the same organization working on similar problems for nearly a decade while the scale of number of engineers working in the code and the number of requests it serves have gone up considerably. Hundreds of contributors. Billions of daily requests. I humbly suggest that indexing on the lack of exceptio…
I understand golang was an attempt to fix c's shortcomings and not to create the next c++ or java. But I also understand programmers get their way of doing things that are bad. Case in point, people who do println("entering function doit()"); println ("exiting function doit()"); for every function in the entire codebase because it's how they learned to "debug" and they never tried anything better. Error returns in golang are like that. It has to be for every function in the codebase and balloons the code by a non-trivial percent.
As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. A human can't perceive the microseconds.
Re: Ask HN: How are you using Go to write production-grade back end services?
#20Earlier quoted context omitted.
I've worked in exception based code bases such as Python (Twisted specifically) and Go. Unlike many, I've used both in the same organization working on similar problems for nearly a decade while the scale of number of engineers working in the code and the number of requests it serves have gone up considerably. Hundreds of contributors. Billions of daily requests. I humbly suggest that indexing on the lack of exceptio…
I understand golang was an attempt to fix c's shortcomings and not to create the next c++ or java. But I also understand programmers get their way of doing things that are bad. Case in point, people who do println("entering function doit()"); println ("exiting function doit()"); for every function in the entire codebase because it's how they learned to "debug" and they never tried anything better. Error returns in go…
Does go actually generate machine code that continually checks for err != nil? Because that can be more expensive than generating an unwind table and ignoring it until an exception actually happens.