Really good critique of the current state of handling, but my opinion is still that the language should not itself makes any design decision on async. I believe everything should just keep being a set of instructions that are executed accordingly to the machine, and that's it. It helps ensuring the language semantics are still relevant on newer execution machines.
Indeed, async v. sync should be a matter of the application and the application only.
This is like arguing for goto over structured concurrency. Async/await is a structured control flow primitive that lets you compose functions in more flexible ways. It will stay relevant as long as we still use things like functions, branching, and looping.
I assume they do use your search history for some purposes.
For instance I have been enrolled inside the Foo Bar challenge from Google, and from my deductions it is thanks to my search history (mainly programming-related).
The Foo Bar challenge is a suite of tricky programming questions and in the end, some of the winners of the challenge receive a message from Google's recruiting team (as I did) where it can lead to a job at Google.
This is only my deductions from my experiences with Foo Bar, it might only be in that case, I am not exactly sure, but you should assume they do.
It still means they are, therefore it is not impossible for an automation to detect “red flags” and warning the recruiter for manual verification or anything.
> But why do these protocols need built-in economics?
I believe, in this time of humanity where economy matters, that Blockchains have built-in economics for two reasons:
1. They all started copying Bitcoin, which by nature is an economic system (this is the goal of the Bitcoin's paper).
2. Reward by money is a common way to attract a sustainable amount of active users that keep the network alive without evil intention appart from making "quick bucks". In contract to volunteer networks such as Tor, where a lot (even a majority) of nodes are run by gov. agencies with the goal of identifying users, popular blockchains are still run properly since users are focusing on money and not destroying the network.
> Dumping unfinished, unpolished, unmaintained, and potentially badly designed or even insecure projects onto the internet is not benefitting anyone.
I have to disagree on this take. Almost all code dumping is useful since you can always learn something from it (either a new technique or stuff TO NOT DO...).
What is important is to state the status of the project. If someone is still using the project and having difficulties with it even if you added a disclaimer, then it is their problem, and they should not expect any support (unless your license requires so)...
> But if you get a pull request, then someone else has spent time on your project, and just throwing that away is not good.
Sure, but once again communication is key here. I absolutely understands maintainers that do not have a look at merge requests but let them open.
It allows anyone with the same problem to easily search in opened issues/merge requests and find the patch, which may help them (even if it is not in the "main" remote).
> I ended up completely dropping out of that project as a way of preserving my mental health. In fact, I dropped out of all my (F)OSS projects, and I even deleted some of my “code dump” projects on GitHub.
> The best software has a vision. The best software takes sides. When someone uses software, they’re not just looking for features, they’re looking for an approach. They’re looking for a vision.
This. We often try to build something for everyone, letting our opinions asides to avoid any form of trouble.
Yet I think that expressing our likes and dislikes (in a polite manner), and accepting our ideas/visions is the best way to succeed.
We have various exemples, such as Steve Jobs' vision in Apple or Elon Musk's attitudes.
While there are a lot of variables in success, I'm pretty sure expressing our opinions in our projects is one of the most important points.
Indeed, async v. sync should be a matter of the application and the application only.