3 ms·

I'm not exactly sure if events are easier to debug. I use tornado (event-based Python webserver library) extensively at work - when something goes wrong you do

I'm not exactly sure if events are easier to debug. I use tornado (event-based Python webserver library) extensively at work - when something goes wrong you don't get a nice stack trace, you get some random sampling of callback spaghetti. Also the default state of matters is that everything is serialized in a single thread and everything waits for their predecessor, even when they are totally unrelated, though that probably tells more about the particular framework than event-based programming in general. I'd rather use a real multithread-based framework, honestly, though I concede that it also opens up different ways of making developers' lives miserable.

ailideex 7y ago
The programming paradigm provided by a threaded model (which is also there in async/await syntactic sugar) is a lot easier to follow and work with than asynchronous code paradigm IMO. I think writing code asynchronously is solving a problem all over your code base which can be solved much better by async/await or lightweight threads like golang has with goroutines and like jvm is getting with project loom - all of those solves the problem in the right place - allowing you to write code synchronously but execute it asynchronously. Once we de-couple these two things - how we write code and how we run code - the discussions about this become clearer and easier to have.
maxmalysh 7y ago
It's time to migrate to async/await. Check out asyncio.Protocols for TCP servers and aiohttp for HTTP servers. We get beautiful async stack traces delivered to Sentry. Debugging anything is a joy.
- fjp 7y ago
  I’m always a +1 for aiohttp (and aiopg)’s ease of use
rlpb 7y ago
The state of the art is improving. Trio for Python for example is much better in terms of stack traces. > Also the default state of matters is that everything is serialized in a single thread and everything waits for their predecessor, even when they are totally unrelated... I think this is a preferable default since bugs caused by pre-emptive multithreading are much harder to debug.

ailideex 7y ago

The programming paradigm provided by a threaded model (which is also there in async/await syntactic sugar) is a lot easier to follow and work with than asynchronous code paradigm IMO. I think writing code asynchronously is solving a problem all over your code base which can be solved much better by async/await or lightweight threads like golang has with goroutines and like jvm is getting with project loom - all of those solves the problem in the right place - allowing you to write code synchronously but execute it asynchronously. Once we de-couple these two things - how we write code and how we run code - the discussions about this become clearer and easier to have.

maxmalysh 7y ago

It's time to migrate to async/await. Check out asyncio.Protocols for TCP servers and aiohttp for HTTP servers. We get beautiful async stack traces delivered to Sentry. Debugging anything is a joy.

fjp 7y ago
I’m always a +1 for aiohttp (and aiopg)’s ease of use

rlpb 7y ago

The state of the art is improving. Trio for Python for example is much better in terms of stack traces. > Also the default state of matters is that everything is serialized in a single thread and everything waits for their predecessor, even when they are totally unrelated... I think this is a preferable default since bugs caused by pre-emptive multithreading are much harder to debug.