kiadimoondi

Agreed. I was writing a port of the redis protocol to erlang for a personal project that's a server using said protocol as an interface for distributed MPSC "locking", and it was incredibly simple to implement because of erlang's binary strings and pattern matching. Same with base64/hex/etc. manipulations of strings into binary data. I've read a fair bit about how erlang is great for protocols, but hadn't experienced it myself (professionally or personally) until I decided to implement this project.

I'll second what ZephyrBlue said:

- you aren't defined by who your employer is - your intelligence isn't defined by who your employer is - you can't control what other people say or think about you - you're worth a hell of a lot more than what you do or what you make per year (emotionally, intellectually, spiritually) - life is random, do the best you can and don't hurt yourself doing so

At the risk of sounding morbid, we're all just apes on a flying rock trying to figure out what existence means to us. Reach out if you need help, there's nothing wrong with that.

Stay safe my friend.

I guess you could consider border states of Mexico as the same geographical region as the southwestern US, but those too. Anecdotal, but I've seen routine thermal throttling on macs in a border state with outdoor temperatures of 45, ambient indoor temperatures of 30-33, so you basically need either AC or some other external cooling system to manage more performance than a web browser and office apps.

Would a nationalized bug bounty program help here? Along with some compliance enforcement that the bounty is actually addressed, fulfilled, and payed by the vulnerable entity or the government (funded through some form of corporate tax). I haven't really thought out the details, but likely some kind of practical and effective threshold exists where a business entity in the US enters into mandatory participation.

Genuinely curious, would love to see others' thoughts.

That's a pretty unfair characterization of people who prefer to work remotely.

However, your last point about letting remote employees stay remote and letting people who prefer office-work to come into the office, I optimistically agree with. It works when everyone knows how to work with remote employees, and that the option is exactly that: an option. This last year and a half I hope has been helpful in getting everyone up to speed on that. It requires a cultural dedication, and assuming people have learned something from this remote experience, they'll carry that knowledge and flexibility with them going forward.

Adding on to what others have said, it's also that some non-US countries have much better internet infrastructure than telecom (which might've affected pricing, can't say for sure), so people flocked to internet-only messaging apps to avoid their telecom's faulty SMS/call handling.

Suspected this but didn't want to claim anything I couldn't back up. Thanks for the link!

Honestly, depends on the company and the state you're working in. It's all anecdotal, so take the following with a grain of salt.

I've worked for startups in Washington and California. In Washington, there was an invention clause in my contracts, but in practice it was a) practically unenforceable and b) as long as you divorced your work identity from your personal identity, nobody cared. This meant not having a way of tracing an anonymous handle or email to you working for the company. In California, I've never seen an invention clause in my contracts, but they were also much better at divorcing your work and personal identity systematically (forcing you to use a github account specific to the company, not mentioning this handle on your personal account, etc.).

In any case, keeping your work and personal work completely separate (no competition between work and individual ideas, no shared hardware) is a good idea and won't raise as many eyebrows. Some companies will be more aggressive about owning what you do, so if it matters to you then ask about the clause before signing the contract.

Can't speak for the commenter, but I used to work for a team couple years ago that used rust and tokio extensively, and some projects were just not a good fit. At the time, futures were well fleshed out but the community hadn't caught up, so we were lacking a futures-compatible postgres and redis client. We wrote the redis client ourselves, and for the main project using rust that was sufficient. But for postgres, that was a show stopper for any other projects we were working on. So we ended up deciding between typescript and go for those.

I agree, I'd never argue that there isn't creativity involved. It's essentially language. And someone said before that there's a base level of competency involved in making API decisions. It's more the argument of what's actually making you money or providing competitive edge. I can see edge cases where, with matching feature sets for two competing products, the API matters a great deal. API and functionality definitely influence each other, I just see it as a weak argument that copyright is broken when the interface is copied, not the implementation.

I agree there's nuance to the issue, and thst's where the argument is to be made. But I think it'd be a bad faith application of copyright or patent law, as your competitive edge largely doesn't come from API design but the product being interfaced with.

I think there's a case to be made that there's nothing novel in an API itself (emphasis on the interface). The novelty comes from the implementation, whereby competition actually kicks in (novel algorithms, data structures, storage techniques, etc.). But maybe I'm missing something? I come from a distributed systems background, so my bias is likely titled.

Exactly. And even then, database choice faces some of the same selection criteria. What's better supported, does it have well tested and documented client implementations (or do I have the time to write it myself), what features do I need, what features should I anticipate needing, is the performance good enough for what I plan on doing.

Some of those DBs solve different use cases than others. I wouldn't use Redis as an embedded DB (unless benchmarking indicated it fit my needs better), as the user of that software benefits most in using it with multi-machine access in mind. Embedded use cases are where RocksDB, LMDB, TokyoDB/KyotoDB, SQLite, etc. come into play.

Keeping the use case in mind (and it's possible evolution) will help pick the best tool for the job.