Server applications don’t spawn threads per request, they use thread pools. The extra context switching due to threads waiting for I/O is negligible in practice for most applications. Asynchronous I/O becomes important when the number of simultaneous requests approaches the number of threads you can have on your system. Many applications don’t come close to that in practice.
There’s a benefit in being able to code the handling of a request in synchronous logic. A case has to be made for the particular application that it would cause performance or resource issues, before opting for asynchronous code that adds more complexity.
Thread pools are another variation on the theme. But if your threads block then your pool saturates and you can't process any more requests. So thread pools still need non-blocking operations to be efficient or you need more threads. If you have thread pools you also need a way of communicating with that pool. Maybe that exists in the framework and you don't worry about it as a developer. If you are managing a pool of threads then there's a fair amount of complexity to deal with.
I totally agree there are applications for which this is overkill and adds complexity. It's just a tool in the toolbox. Video games famously are just a single thread/main loop kind of application.
There’s also a really good operational benefit if you have limits like total RAM, database connections, etc. where being able to reason about resource usage is important. I’ve seen multiple async apps struggle with things like that because async makes it harder to reason about when resources are released.
I'm not sure about Ocean, but a lot of companies used the Tatung Einstein, itself a 64KiB machine, as a development platform. I would assume that the software used for building this stuff was able to deal with source files larger than the machine can hold. They might've moved onto the likes of Atari STs, IBM-compatibles, and Amigas by the time Wizball was released though.
Plenty of music was developed in the form of source files.
Readability is certainly a limit. JSON and XML are unreadable in their usual single-line transport form, and often even when pretty-printed. XML signatures break upon reformatting, so you also can’t just do it blindly.
Part of the lowest common denominator are the (printable) ASCII characters. If you ever opened a text file mostly consisting of a script you’re not familiar with, it might as well have been binary. Add to that right-to-left languages where you can’t even be sure which element follows which without knowing the scripts.
It’s “good enough” for many purposes, but it’s important to keep in mind the limitations.
XML arguably isn’t plain text, but a binary format: If you add/change the encoding declaration on the first line, the remaining bytes will be interpreted differently. Unless you process it as a function of its declared (or auto-detected, see below) encoding, you have to treat it as a binary file.
In the absence of an encoding declaration, the encoding is in some cases detected automatically based on the first four bytes: https://www.w3.org/TR/xml/#sec-guessing-no-ext-info
Again, that means that XML is a binary format.
Another way that the character encoding could be declared is ISO 2022. When using ISO 2022, the declaration of UTF-8 is <1B 25 47>, rather than the <EF BB BF> that XML and some other formats use.
However, whether you do it that way or another way, I think that the encoding declaration should not be omitted unless it is purely ASCII in which case the encoding declaration should be omitted.
reply