Comment by SPBS | Hacker News Reader

Comment by SPBS | Hacker News Reader

> 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.

You'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.

OP 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.

I'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.

That’s too bad because I’d personally want to hire someone that could demonstrate they knew something I didn’t in an interview.

Well then you're probably the kind of person who would instinctively give signs that someone like me can open their big nerdy mouth, that this is safe territory because we're all engineers trying (this thing with error in the cycle, you know). You're probably someone in the "having a blast" part of my perspective — the kind of people I can actually work with best. The others, we "manage" kinda, with empathy if we can, like they manage us too.

Slight tangent. You know this idea of "feeling comfortable being wrong" in front of someone, that it's OK to say dumb stuff in front of people we trust. I think it enables us to just try, up to our limits (where we must fail a lot by definition, and also the only place where we make actual progress).

When you can build the kind of team that can transparently fail (thus collectively improve...), within that 'safe' tech space of 'engineers', where we know it's everybody just trying and the ethos is aligned with that (nerds may speak, fail, laugh, etc.), I think you've got a solid basis for any project, any company.

You sound like someone who builds that kind of environment. I wouldn't worry in that case; again, nerds will pick up the signs if you just speak your mind — hints like you saying "So I didn't know X, and then blablabla", or simply asking bluntly "what do you think of our choice to do X?" instead of defending it like OP's interviewer. ;-) In general, people who ask questions have to be prepared to hear the answer, that's how I operate personally. I would just temper the response based on what I actually do know of the situation.

I personally don't spend one minute thinking about mind games if the other person seems direct, transparent, honest, especially problem-solving mission-driven kinda mindset.

Maybe the person said that to test if you were the type that would just blindly agree with someone because they are "senior".

Giving yet another solid reason to not work there. Job interviews are not (supposed to be) mind games.

Agreed. Mind games during job interviews signals toxicity, or at the least, an insecure interviewer craving a power-trip.

The 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.

Could you elaborate on what you mean?

If 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.

Maps are concurrent readonly safe.

They aren't safe to read or write concurrently.

> 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

Both!!! Its out there, in the wide world for everyone to read, just use Google!!

I wasn't asking a question, I was clarifying.

You can't declare a read-only map (or slice). Actually Java made exactly the same mistake, the best you can do is to implement Map<K, V> and List<T> with setters that throw at runtime.

So, accessing shared mutable state from many threads at once is dangerous. It's hard to lay the blame for this on Go - it's true in most languages I know of.

I suppose one ought to guard such maps with a RW lock, or a `sync.Map` which is tailor-made for this kind of situation.

sync.Map is slower than searching a slice of k-v struct for roughly <1000 elements.

Go designed their map implementation to be unsafe for both read and write. I kind of don't care, i was trying to point out something simple and everyone is nitpicking.

ab is broken by design.

wrk, h2load, boom, vegeta are more sound load testing tools.

Its not broken, it does make concurrent parallel requests.

Whats with the nitpicking on hacker news?

ab uses a single OS thread. Broken by design.

Maybe he likes writing blog posts about how goroutines behave at scale ;)

Reply on news.ycombinator.com