throwaway43234

I think a good compromise is warnings aren't allowed in the final committed code (this can be enforced either by convention or with git hooks), but whatever you do locally is between you and your compiler. "What happens in the devbox stays in the devbox"

> that is actionable for a lot of people

Really hoping this is better by the next few months or my Seattle winter will be even more pill popping to maintain basic human functionality....

Right - I understand all that, I just think it's not a good idea. The compiler makers made some things warnings and others errors for a reason, to disregard their input because you have some idea that "warnings are just as bad as errors and should never be permitted in even dev builds of my very highly precious code" is to me a sign of an over-controlling "principle engineer" somewhere behind the scenes that doesn't trust their team, which is not a work environment I'd want to be in. (In the go case, the over-controlling principle engineers creating a work environment I'm not interested in participating in are the language designers themselves!)

I introduce unused variables all the time when I'm debugging/exploring, which always get cleaned up before commit (this is programmatically enforced, which I think is reasonable), to need to go and comment out the declarations for each variable that goes unused if I comment out a section, just because some "principle engineer" somewhere on my team (or the language design team) thinks unused variables are the devil reincarnate and can't be allowed in any build whatsoever is frankly insane. (Don't even get me started on cases where commenting out the declarations changes behavior...)

Or just ignore warnings if you know they're from a temporary change that wont ever be committed?

Most of "feeling sick" isn't the actual bacteria/virus causing problems, it's your immune system doing things like raising your internal temperature to fight off the virus or generating boatloads of phlegm to do whatever that does.

Some in stocks, some in banks, some in bonds, some in real estate, some in precious metals, etc.

Good reason to pull all crypto into fiat ASAP, store it in a real bank (or really, diversify it - user said that was the "vast vast majority" of their savings, that should never be all in one asset), and report it as other income on your taxes.

Is that really your bar for being "somewhat technically literate"? Being familiar with decentralized chat protocols and services? What a world...

I agree it's probably a joke, but I'm not so sure that the core idea is actually impossible... I could reasonably see a SaaS that simply provides a quick and dirty key-val store. The code is just a translation from REST to REDIS which could easily be done in 2 lines, the value-add is the hosting.

That'd actually be pretty helpful for initial prototyping, where you want to have state shared across devices but don't want to bother with hosting a backend at first, and localhost wont work because the client wants to play with it too.

Curious, whats so special about SFO? I searched for some images and it doesn't seem terribly special (certainly not 2x price special).

If you take to time to set up incremental compilation, it's really quite fast. For reference, updates to the vscode repo (~5k files) take generally <300ms to recompile, and even incrementally updating after pulling in a batch of hundreds of commits takes only ~10 seconds.

It's concerning to me that the deno folks chose giving up on type safety over figuring out how to set up their development environment to better meet their needs.

These aren't signatures though? They're checksums, anyone could make them for any blob they want.

Is it a common scenario nowadays to download a file and have it be corrupted? I don't think I've ever had that happen (Though perhaps I wouldn't know, because I don't use these checksums! Though if a package is corrupted and it doesn't noticeably degrade, is it really corrupted? Hm... philosophy of internet downloads)