5 ms·
> If you can, don’t reach for a goroutine, or a channel, or embed a struct, anonymous functions, going overboard with packages, interfaces for everything, inste
by SPBS 7y ago
> If you can, don’t reach for a goroutine, or a channel, or embed a struct, anonymous functions, going overboard with packages, interfaces for everything, instead prefer simpler approach rather than the clever approach.
This reminds me of an interview I had with a company recently. I mentioned that although I was using go for my current pet project, I had hardly touched goroutines because net/http automatically spins off a new goroutine for every request so I don't have to think about it. The interviewer was incredulous and said that every database call should be put behind a goroutine so that it's not slow. He said the point of go is to leverage its powerful concurrency mechanisms. What I wanted to say was that I believed go's selling point was its simplicity and not its concurrency mechanism, and that it would be more idiomatic to keep it simple first and refactor only if there's performance issues. But he was the senior and I was the new job seeker, so I just ended up agreeing with him.
- saber6 7y agoSounds like a douche.
- kenforthewin 7y agoYou'd want to use db connection pooling for any nontrivial application, a goroutine per db request is a recipe for connection exhaustion. That being said, go's concurrency model is indeed a huge selling point of the language.
- WaltPurvis 7y agoOP doesn't say whether it was a SQL database, but Go's sql.DB automatically uses a connection pool. Naively using goroutines for every sql.DB operation is a good way to run into connection, deadlock, and other problems, so I think OP's approach of not using goroutines unless/until there's a demonstrated need (e.g., through profiling) is sound, and that interviewer might want to pump the brakes on the blanket prescriptions.
- K0SM0S 7y agoI'm gonna say this with all the respect in the world for the technical view —I'm a nerd and I agree with you guys 100%, a huge upvote for the whole thread— but experience taught me something along those lines: There are such situations (people and places) that command one to put their mindset in "agreement mode", not because of logical reasons¹, but absent or even contrary to those, because of a need to reduce friction². In this meta-knowledge space³ lies the solution space⁴ for all your problems in a human environment. When you approach things like that, you tend to see where "tech" fits in a wider landscape, and it tells me when to speak and when to shut my big nerdy mouth (whenever it's counterproductive, e.g. premature abstraction⁵ is just as bad as premature optimization). It tells me which lines in the code are "political", "organizational", "structural" not to the tech but to the humans around; and by elimination, which lines are left for us nerds to think about deeply. It's a dance, really, there's no right/wrong/perfect, but there's a certain way to rise above these human contingencies and actually facilitate the path to market while having a blast — just set your expectations right as to what you can and can't touch, at least for now, reassess on a need-to basis. So when you see a dark "anti" pattern (OP's case), sure you naively ask 'why', but then if you see org/pol structure, if you see this rigid wall of "this is how we do it, this is who we are", you know it's not about tech anymore. It's personal. Don't hit there. People (especially when insecure, so all of us at times) tend to protect their knowledge like it's a judgment on themselves, like it's proof of their worth, and it's very hard but doable to notice when you're entering such territory with someone. ____ [1]: you might be smarter than your boss, you may be "right" technically [2]: "friction" in the economic sense, which includes overhead in your code as well as overhead from meetings. What stands between idea and productive execution. [3]: literally, larger than the technical, including all aspects of engineering, organization and market forces. [4]: the product that which you seek to make, i.e. that people use. The "internal" side of the product is the organization and codes that make it, that support its continued existence. [5]: in this case, we "abstract prematurely" when we presume to know a system better than their maintainers, or that our "outside looking in" "fresh" pair of eyes has all the answers already. There is often much more than the technical to consider.
- jrs95 7y ago
- latchkey 7y agoMaybe the person said that to test if you were the type that would just blindly agree with someone because they are "senior".
- dana321 7y agoThe multithreaded nature of the go http library makes it look simple, but in fact, its not. It won't show up problems until you use a specific tool to send concurrent requests. Just a gotcha i want to mention to anyone reading. ApacheBench is a good first start.
- nhooyr 7y agoCould you elaborate on what you mean?
- dana321 7y agoIf you are accessing variables declared outside the http server, and you use any non-thread safe types or code it will panic. For instance, try and read a map, it will crash your code. It won't show this as a problem until you have real traffic on your service.. Hitting it in your browser isn't enough to test properly.
- tedunangst 7y agoMaps are concurrent readonly safe.
- dana321 7y agoThey aren't safe to read or write concurrently.
- palebluedot 7y ago> They aren't safe to read or write concurrently. Slightly ambiguous wording, so just to clarify: Go maps are safe to read concurrently Go maps are not safe to read AND write concurrently Go maps are not safe to write concurrently
- dana321 7y agoBoth!!! Its out there, in the wide world for everyone to read, just use Google!!
- crystaldev 7y agoMaybe he likes writing blog posts about how goroutines behave at scale ;)