As far as day-to-day satisfaction on the job, sure, salary could be way down the list compared to company culture and work/life balance. But I think we should acknowledge that salary is the only reason any of us work at all. If the salary is bad everything else will crumble around it regardless of how excellent culture and work/life balance are. If the salary is good there's no guarantees, but there's at least the potential for on the job satisfaction. Salary is the foundation. The exception to this is charity work for purely mission driven work, but that's not the work context for the majority of people.
I'm more concerned that this data is available for sale in the first place. There should be a limit on the length of location history a telecom can collect for individual phone numbers and that data should never leave the telecom. We need stronger laws.
Every user is their own Tor onion service, so you get E2E encryption and no centralized servers. The whole thing hinges on the security of Tor itself which is probably a safe enough bet.
Briar https://briarproject.org/ is similar, plus, AFAIK, it's using E2E on top of Tor service. However, looking at massively caught Tor services, I believe, to keep it truly secure, you have to rotate your service address, aka reinstall the app, losing all your history of communication.
I think the lesson for Taiwan is clear here. There will be no sudden military invasion. The CCP will first take a similar approach of embedding party loyalists into Taiwanese civil society, assuming positions of power. Only once enough puzzle pieces are in place will a military takeover occur and by then it'll be far too late- the party loyalists embedded in Taiwan will sit on their hands and watch it happen.
I haven't seen anybody mention tooling. I've played around with Rust for purely academic reasons and love how cargo just makes everything work. Feature flags, a built-in test harness, cross-platform compilation, the only fight I've had with Rust has been the language itself. I haven't used it but I like how feature-rich the Zig compiler is too. I really hope strong tooling remains a focus for these newer languages.
I find it so comforting to believe in Heuristics That Almost Always Work even when I know I ought to employ more scrutiny. It's too easy to jump on board.
In the case of a CGO call you could prefix the enclosing function definition with the "go" keyword to manually initiate a new goroutine? Am I understanding this correctly?
Goroutines are multiplexed onto a finite number of OS threads, which is usually a pretty small number. If you launch a new goroutine, a funky CGO call will still block an entire OS thread, it won't change anything as far is blocking is concerned. When all OS threads are blocked the runtime will spawn additional OS threads, so in the worst case it can degenerate to "OS thread per request".
