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.
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.
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.
> 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.
I wouldn't mind for opt-out telemetry as long as it is *really* open-source and focused on Go itself and not "how developers are using their system with Go installed on it".
Ohh, I am in the same situation. I just want be able to do whatever I need to do.
But as you highlighted in the title, it is possible (learning infinite A in a finite time T with possibly finite brain power B...).
The best thing I do that helped is to say "fuck you" to yourself and spend more time thinking (like a philosopher) about the world and my view on it. I couldn't really explain how but it really helps me.
So I guess I recommend trying to take an external view on your problems instead of studying to fix them as it is, to me, the best self-improvement thing anyone could obtain.
Such a nice anecdote for a period I have (and will) never see. The idea of private messages seemed cool when compared to the massive issues list we have on GitHub now
The title is a bit misleading (I first though it would be about prioritising college education over toy projects) but appart from that, the article is pretty good at explaining the situation that exploded since COVID: "Easy financial freedom".
Nowadays, every influencers are pitching for it, you open TikTok or Instagram and see all the same images and clip from Dubai.
In the end, education stay, for the better or the worse (I mainly learned by myself), the best way to validate skills and get a job, especially in those times with massive layoffs allovers industries.
I'm pretty confident in Google's ability to protect the results from AI-farm spam (unlike YouTube).
But I feel like these guidances to not be precise enough, especially the part on "Author bylines". Could it be possible for Google to voluntary remove from results AI-generated content? Google is strongly able to detect the presence of AI in content, I doubt however they can understand it well (for instance, low-quality and automated comparisons sites can still hit the first result of Search). Therefore it could lead to bad quality bans and mass-move to "human-generated content" (which is AI-generated with quick review for human), leading to more problems.
I started learning Google Search operations, and now I almost always append "site:news.ycombinator.com"/"site:reddit.com" for stories and ideas, "filetype:pdf" for work or research papers etc...
I would say it works very well as I discover a lot of things, the problem I'm now facing is keeping up with all these awesome materials
Indeed, async v. sync should be a matter of the application and the application only.