There's a huge difference between copy-pasting code you don't understand and using a library with the assumption that the library does what it says on the tin. At the very least there's a clear boundary between your code and not-your-code.
firelizzard
joined 2 years ago
Are you seriously trying to equate "I don't know which instructions this code is using" to "I copied code I don't understand"? Are you seriously trying to say that someone who doesn't know how to write x = a + b in assembly doesn't understand that code?
If you’re adding code you don’t understand to a production system you should be fired
Edit: I assumed it was obvious from context that I’m referring to copy-pasting code from stack overflow or an LLM or whatever without knowing what it does but apparently that needs to be said explicitly.
I guess I just don't see enough memes to have picked up on that
Marketing. People expect to see different things on a website vs Twitter/X so the same content won't perform the same on each. So for a business it makes sense to post different things on your website vs Twitter/X.
I’m not sure what to tell you. I just don’t see what you do. And I never bother to look at a meme close enough to notice the kind of details the other user pointed out.
How can you tell?
What I mean is, from the perspective of performance they are very different. In a language like C where (p)threads are kernel threads, creating a new thread is only marginally less expensive than creating a new process (in Linux, not sure about Windows). In comparison creating a new 'user thread' in Go is exceedingly cheap. Creating 10s of thousands of goroutines is feasible. Creating 10s of thousands of threads is a problem.
Also, it still uses kernel threads, just not for every single goroutine.
This touches on the other major difference. There is zero connection between the number of goroutines a program spawns and the number of kernel threads it spawns. A program using kernel threads is relying on the kernel's scheduler which adds a lot of complexity and non-determinism. But a Go program uses the same number of kernel threads (assuming the same hardware and you don't mess with GOMAXPROCS) regardless of the number of goroutines it uses, and the goroutines are cooperatively scheduled by the runtime instead of preemptively scheduled by the kernel.
Key point: they're not threads, at least not in the traditional sense. That makes a huge difference under the hood.
Really? Huh, TIL. I guess I've just never run into a situation where that was the bottleneck.
Definitely not a guarantee, bad devs will still write bad code (and junior devs might want to let their seniors handle concurrency).
If you are submitting work, you should understand how the code you're submitting works. Sure, you don't have to know exactly how the code it calls works, but if you're submitting code and there's a block of code and you have no clue how that block works, that's a problem.