damnyou

My pronouns are they/them, thank you.

I edited my comment within a couple minutes of posting it. Sorry about the confusion.

Yeah, I'm persuaded by the Julia Marcus school of thought that simply ordering people to stay home is important but not nearly enough. You have to provide ways for people to reduce their risk in case they decide not to listen to your orders.

I personally stay home as much as I can, but I have certain privileges many others don't.

I did not downvote you, for the record. I thought your questions were useful and I hope I answered them to the best of my ability.

This pandemic has been hard on all of us. Take care.

Firefox was in fact in a stronger position before Google turned Chrome into shovelware, yes.

I'm pretty sure that "easier" is a subjective determination. But no, I don't have a hard time swallowing pills. It's just that doing something once a week is easier than having to remember to do something everyday. The injections are also more effective for me, as they are here. And finally there's an aesthetic aspect to plunging a needle into one's muscle that I appreciate.

I'm pretty sure the primary driver of that was Google turning Chrome into shovelware bundled with Adobe Flash and marketing it aggressively.

It is in fact much easier and less of a hassle (for me) than taking a pill everyday, which is what I used to do before I switched to injectables.

Injectables seemed scary right until the moment when I started taking them, after which they became a normal part of my life.

And I'm sure transmission rates would be even higher if condoms were harder to get.

I don't know enough to comment on European countries, but I wouldn't be surprised if access was a big problem there as well. The American healthcare system is pretty bad, but it's not the only bad system in existence. There may be other linked factors like stigma at play as well.

Right. Abstinence doesn't really work in the real world, only in the spherical-cow world where humans are perfectly obedient.

I'm not sure about this one but subcutaneous and intramuscular injectables are pretty easy to self-administer. I self-inject once a week myself.

https://www.poz.com/drug/cabenuva seems to suggest it is intramuscular (administered in the buttocks, which is not hard to do by oneself) but requires a healthcare provider. Not sure why, there might be storage requirements and such.

No, that's not the reason, given that PrEP exists. The actual reason is that Truvada, like other healthcare, can be hard to get in the American system.

Well, the assumption is that unfamiliarity risk goes down as people get more familiar with the technology. There's certainly some added complexity but a blockchain is not that complex, it's just a git repo with some added functionality to repel hostile actors.

You have, say, 50 entities that are part of the cabal, not all of whose interests are aligned (this is the important bit, you want a diversity of interests), and you need a 2/3 vote to add a new one.

> they're not remotely close to being a solution to the sort of problems parties use escrow for

But you can encode fulfilment into a smart contract for physical goods, assuming that those physical goods have some digital representation on-chain. Discrepancies between the chain and the real world continue to be resolved through the court systems in various jurisdictions, but on-chain activity is just strong evidence that any court can rely on.

> a distributed ledger only has value over and above a non-distributed one if other parties worry about the centralised database manager tampering with records

An alternative viewpoint is that a centralized database manager can be seen as a potential risk. One of the general ways we progress in society is when we reduce sources of risk, and a permissioned blockchain where you need 2/3rds of a cabal to collude is a pretty clear reduction of risk compared to a centralized DB. (I mean, how would you keep track of whether a central DB has been tampered with? You'd probably maintain your own copy, reconcile the two periodically, and flag discrepancies if and when they happen. That's exactly what a blockchain is.)

To be clear, I'm pretty skeptical about blockchains in general, but this seems like a very compelling use case.

While it is true that blockchains themselves cannot guarantee that they're synchronized with the physical world, they provide an irrevocable digital trail that can be used to punish bad actors, one that is relatively immune to tampering. A lot of the world operates this way—simply signing something under penalty of perjury does not guarantee that it is true, but it can be taken to court if it is later found that you're lying.

A blockchain (not proof-of-work, but permissioned/BFT-based) is pretty clearly the optimal way to have an irrevocable digital trail.

Smart contracts can help with things like escrows. You can automate the happy path and include humans in the loop if (when) something goes wrong.

"we both keep records and compare when there's a problem" is literally exactly what blockchain consensus is an algorithmic version of.

Personally I think private individuals should have a fundamental right to encryption regardless of the medium.

That is very definitely not how common law systems work. Common law systems rely very heavily on past precedent and case law, not merely the words in a statute.

Take the levels of scrutiny applied to laws and regulations in equal protection lawsuits, for example. Why is judicial review for racial discrimination covered under strict scrutiny, but sex discrimination only covered under intermediate scrutiny? There's no statute prescribing this—American courts invented it.

There were times when being in an intimate relationship with someone of the same gender was a crime, and a lot of sex work is still criminalized, so I'm actually quite bothered by (particularly) the prohibition against using encryption. Obviously I have no sympathy for white nationalists, but "crimes" in general tends to cover both things that are bad and things that aren't.

Thanks for the thoughtful response. I spent a bit of time thinking about it, and thank you for that as well.

So, I think you're right about a result type being isomorphic to checked exceptions, for the reasons you laid out. If you compare it to Rust, what ends up happening is similar -- many libraries return an error type that's a union of all their dependencies' error types, and binaries end up using an "everything" anyhow::Error type in the end. However, I think where sum types in general end up working and checked exceptions don't are:

1. Sum types don't encourage a mix of checked and unchecked exceptions the way Java does. Translating from Rust, all exceptions that are meant to be handled by regular users are checked. The only exceptions that are unchecked are broken invariants (panics), which usually end up being handled either through aborting the program or through some sort of top-level restart logic. You could write Java in that style but it's not the ecosystem's convention.

2. Sum types are more general than checked exceptions: they can be used to express nulls and business logic as well. I suspect checked exceptions would have worked better if Java also had nullable and non-nullable types, because nullability is such a common source of errors.

3. You're right that you can drop an error on the floor with sum types as well, just like an empty catch block with exceptions. But that just doesn't happen nearly as often in practice, because result types form a closed set. With checked exceptions, in practice you often end up with a method throwing both checked and unchecked exceptions, and the same syntax is used to handle both. I think checked and unchecked exceptions are fundamentally very, very different and mixing the two is a mistake.

Once again, thank you for your response.

Why would any developer who doesn't use a Mac even consider bringing their extensions to Safari? The vast majority of developers use Windows or Linux: https://insights.stackoverflow.com/survey/2020#technology-de...

Are unions used for error handling and null checking? No? Then they're not very useful.

Unlike first-class monads, sum types are not some sort of esoteric FP construct that arises from challenging technical problems around dealing with external state. They are the very obvious dual of product types, which every language has some version of. They are easy to understand, require very little tutorial-ing, and their power is immediately obvious when you start using them.

Product types model "x and y", sum types model "x or y". One of them is universal. The other has been totally missing from mainstream languages until recently. No wonder our software sucks so much.

Having a type available in an optional library is not the same thing as having them baked in from the beginning. The absence of sum types warps a language in grotesquely terrible ways, such as Go's err != nil patterns or Java's exception system and visitor patterns.

Not trolling. Entirely serious.

I don't care nearly as much about first-class monads, though monadic patterns pop up everywhere in programming. Anyone who's written a foldMap or a flatMap has at least a sense of what a monad feels like.

Sum types are a zillion times more important.

Yes that's why I write Rust.

Our field has a terrible reputation for quality. In my estimation roughly 70-80% of that is directly or indirectly because of the lack of sum types.

Directly: people don't have the right tools to make invalid states in their business logic unrepresentable.

Indirectly: the lack of sum types results in broken null and error handling.

Yes, that's possible. I would rather tear my eyes out than use a language without sum types. The benefits of sum types in being able to model arbitrarily complex domains are extraordinarily massive.

Every language has product types. Every programmer understands how useful product types are. Why in the world would the same not apply to sum types?