Hacker News Reader

Comment by ggm | Hacker News Reader

> This "function coloring" is at odds with the stdlib functions, resulting in 3rd party crates for nearly everything.

Doesn't that point to what libc had to do, growing async safe versions of functions which previously were not?

The innate complexity of coding to async is never going away. It's harder with or without language support, almost all of the time, because the concepts inherent in coding embody patterns which are simple, if they are the only sequence of execution flow, and which are innately more complicated to think about, if you have to encompass doing them (and other things) at the same time.

  If this
  then that 
  otherwise other

is always simpler than

  Try: this,
 
  Except: but if it fails at some unknown point of continuing execution then this path out,

  but meantime, lets progress that until we hit a point we have to rendezvous, 

  hey whats deadlock anyway??

View on HN

Having grown up on a platform which did not offer preemptive threading, it still feels weird to me that people perceive async IO as being complex. The contortions one must go through to get decent performance while pretending there is any such thing as synchronous IO seem far more troublesome. Reality is an asynchronous, interrupt-driven state machine; the sooner you give up the illusion that you are in control, the sooner you can go with its flow.

What I read into this, is that if you walk into programming 101 and learn async and/or functional day #1, they make total sense.

If you walk into Pascal or Fortran, and have to acquire FP or async programming after, they make no sense.

This is also at the root of emacs-vs-VI and other debates. What you learn defines how you think.

I learned IF-THEN-ELSE flow, and GOTO. I do not find async easy to rationalise about, despite recognising it exists.

My partner says anyone who claims they can multitask "in real life" is lying, and does both things badly.

At an OS level its kind of a sad state of affairs, even on tiny devices the goto solution is an RTOS with threads (they aren't cheap memory or latency wise!)

If you look at what things like RTIC and embassy are doing I have to say its pretty appealing. Make programming the interrupt state machines a little nicer with async rust, and in RTIC's case without a chance of deadlocks.

That's pretty stellar, and at a footprint and memory usage that is far lower than even the smallest RTOS can muster.

The only thing I find confusing about async is that you have to migrate legacy code, and I don't really enjoy rewrites.

Otherwise, it looks basically the exact same as synchronous code, except background stuff only happens while you're await-ing something.

If there's a failure, the await raises an error, just like a sync function call would.

It was horrendous before await, JS nested callbacks were a nightmare, but all that is basically gone now.

Reply on news.ycombinator.com