nevermore

As a proponent of "TODOs should always point to a concrete issue", you have 3 ways to resolve a TODO before merging:

1. Just file the issue. If it's something you should actually do, you can take 20 seconds to write it down and track it. 2. Just do it. If it seems like too small of a thing to file an issue for, fix it before you commit it. 3. Turn it into a comment. If it's not worth fixing and not worth tracking, but you want to remember it, that's a fine thing for a regular code comment.

Eat your broccoli. Track your todos.

Lots of comments and arguments about async being big or complex, and it's really not, it's pulling in the runtimes that's big and complex, and I think Rust really failed by forcing libraries to explicitly choose a runtime. As a library developer you're then put in the position of not using async, or fragmenting yourself to just the subset of users or other libraries on your runtime.

As an outsider this may be your perception, but this is not how python's documentation works.

> These documents are just informal prose.

Not true. They're the language spec. Every guaranteed behavior of python is described clearly and concretely in these documents.

> Are they sound?

Yes.

> Does my implementation match what they say?

Yes.

> Does CPython even match it?

Yes.

> Does anyone know?

Yes! There's a very rigorous and thorough set of unit tests that specifically test an implementation's ability to match precisely the behavior described in these documents. All implementations (that I'm aware of, eg. cpython, pypy, jython, etc) state which versions of the spec they are compatible with, in other words they pass the unit test suite for that version.

Further, the maintainers of python (and by that I mean, regular contributors to the python-dev mailing list, not a cabal of robed individuals in a cave somewhere) are deeply aware of the language of the spec, the way the test suite implements it, and the importance of maintaining this relationship.

In case you read the entire article before looking at the author, this is by mchurch so you should take everything it says with a huge crazy egotistical grain of salt. Personal vendettas and hyperbole abound.

I don't think it's true that all non-execute corporate jobs are meaningless, and I've worked at at least one company that mchurch has. Some jobs at some (many?) companies are actually slowly and methodically creating value for humanity at large, and many bosses I've had are not soulless whip-bearers but in fact also determined to make their lives mean something through their work.

That being said I think it does levy some specific good criticisms against PG and silicon valley. It's definitely true that PG has a conflict of interest in his postings, and that the narratives about society that he pushes also happen to be ones that he benefits financially from. It's very fair to compare his views to Ayn Rand's. And it's certainly true that tech and science reporting aren't held to nearly the same ethical standards that other types of reporting are.

Some good points and food for thought, but don't lose too much sleep over another mchurch rant.

I'm not quite sure why it's so complicated. Their telnet actually has a UI state machine built in.

On any linux computer: nc rainmaker.wunderground.com 23