7 ms·
I also don't get the async hype. Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug
by ldng 6y ago
I also don't get the async hype.
Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise.
And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover in production, it is unstable because back-pressure was not taken into account. And, in Rust, it is probably not worth the effort and ultimately bloat most of the time.
- lmm 6y ago> Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. > And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover in production, it is unstable because back-pressure was not taken into account. WTF? Switching to a compiled language doesn't magically make your threads nonblocking. Maybe you can serve 10x more users with a compiled language, but if we're talking about slow network requests then async can make your throughput thousands of times higher.
- ldng 6y agoWhy WTF ? You are reading something I did not write. I am not obsessed with the nonblocking mantra. Blocking is not inherently bad. Multi-processus is also a perfectly valid concurrency model. Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Not everybody is Facebook or Netflix. For the vast majority of small and medium enterprises, it faster, simpler, safer (and possibly cheaper) to quickly develop a blocking program without thread and spawn multiple processes.
- lmm 6y ago> Why WTF ? Because WTF does using a compiled language have to do with anything? > Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Then what is it that you imagine using a compiled language would help with?
- deleted 6y ago[deleted]
- sagichmal 6y ago> Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. Writing bug-free shared memory concurrency programs with Go is trivial. Your opinion is based on outdated information.
- ragnese 6y agoI've definitely written buggy goroutine code before. AMA :p I vaguely remember expecting a reference and getting a copy or vice versa... I mean, I agree that Go is miles ahead of most other languages when it comes to helping prevent concurrency bugs, but it's sill tricky. Same with Rust.
- sagichmal 6y agoGo makes concurrency about as tricky as a reasonably complex data structure. can you still write a bug? Of course. Is it so tricky that bugs are inevitable, or even common? Absolutely not.
- lmm 6y agoGo's whole approach to concurrency is about avoiding sharing memory; channels suspend in much the same way as async/await yield points.
- bsaul 6y agoI like go, but i don’t understand your point. Go seems to like passing pointers over channels, which is pretty far from avoiding shared memory. Unless you start writing code that looks like actor based concurrency, with channels used to pass messages acrross actors. But this isn’t what i’d call idiomatic go.
- sagichmal 6y agoPassing pointers over channels doesn't necessarily mean you're sharing memory, you could be passing ownership. Pointer or value are both equally idiomatic.