Human law enforcement hallucinates all the time. This is a bit like a poor argument against self driving.

The last line of GP's comment is key here: "Who do I sue if Palantir decides I am an illegal?"

This shouldn't make as much of a difference as it does, but due to how our legal system works, it's much harder to get meaningful legal satisfaction when an algorithm (or other inhuman distributed system) commits a crime against a person than when a person does so.

"Computer says no", look it up.

Cars measure success by not hitting things.

Cops measure success by number of people they arrest. Note, not the number of people found guilty, that's the prosecutor.

Cops will gladly use a hallucinating computer system to beat the absolute fuck out of you with qualified immunity.

Options have some minor value in signalling that you're a true believer. You should in fact care only about base salary, but not telling the people doing the hiring that can be quite useful. Doing a fake come-down on base in exchange for options shows you are invested and surely worth hiring.

Why don't we just pagerank github contributors? Merged PRs approved by other quality contributors improves rank. New PRs tagged by a bot with the rank of the submitter. Add more scoring features (account age? employer?) as desired.

It will be gamed, just as pagerank was.

Of course, but killing the 80% of low hanging fruit is already valuable. The rest is an arms race like always.

Not by everyone, so that would be better than nothing.

Excited to have to do SEM for my GitHub profile so that people will read my pull requests

Well it's all going to be social credit one day. Might as well get in practice early.

Plus-addressing is built in to most email services. There's no 'fancy' set up to break; it just works. That is, there's no way me@gmail.com works but me+someservice@gmail.com doesn't, unless you explicitly configure it not to work. Similarly for custom domains on most services.

If you use a catch-all on a domain, i.e. someservice@somedomain.com, I guess in theory that might break. But it seems about as likely as messing up the overall domain setup.

Also, my account on your service is likely much more disposable to me than my email address/domain. Anything I care about, I'd back up. Not just assume some random website is going to preserve it for me forever.

If you're only passing the address in private to some service, you can just use [some-string-unique-to-that-service]@yourdomain.com. Or, more classically, plus addressing to do the same. Then you just block that recipient.

That solution doesn't apply to the use case in the article.

Surely spammers just turn `me+leaked/sold@mail.com` into `me@mail.com` as well as `me+apple@mail.com`, `me+softbank@mail.com` etc. The cost of stripping any `+postfix` must be about zero even at volume.

Some people block all mail to non-plus-addressed emails on that inbox, so a plus address is required to be received at all. You could say then spammers will just add a random one, but they wouldn't be getting bounces and would have to guess as much. Still, even stripping the +'ed part is beyond what most of them even bother to do. That dropoff plus normal spam filters works well enough.

What's difficult about it? You know the domain, gregegan.net. You know the @ symbol, presumably. Then put literally any valid text before the @.

Completely unrelated to the conversation, but our user names are remarkably similar.

Is that even possible? Shouldn't the recipient email id need to be created first to be addressable?

Of course, the technical term for that setup is 'catch all', you can set this up with your email provider. You can send your email to "ghywertelling@gregegan.net", for example.

A friend gave out an email gmail@hisname.com (he owns the domain). He says it's incredible how many people "corrected" him, and how persistent some of them were. :-)

The _any_ part is not clear to me. Obfuscation is an arms race. Reverse engineers have always been tool-assisted. Now they just have new tools and the obfuscators need to catch up.

I don't know about where you live but here contactless card payments have lower limits than phone-based ones. Also the phone allows me to switch between multiple cards, including transit-specific cards.

If you're not targetting mobile, why diverge from XHTML at all?

Are there native frameworks which use XHTML? Regardless, a document language being used to construct complex, interactive GUIs is incidental complexity. XHTML can be a compilation target but it does not need to be a development target.

But what's the benefit of using e.g. <row><cell> over <tr><td> if your only target is the web?

If your only target is web then there is no benefit other than a reduction in complexity.

For example, a "row" is not just a "<div>" tag. Its a div which horizontally fills its container. Centering contents with a "center" style attribute abstracts flex-box, browser compatibility, version compatibility, and the cascading behavior of CSS.

You move the incidental complexity of the web platform into the compiler which will always do the right thing. And in exchange you get the option to compile to a native or mobile app for "free".

I think I much prefer semantic elements like <section> over something like <row>. Calling something a row bakes in presentational information. Something that's a row on one screen size might be a column on another.

I agree. For my blog I don't apply CSS and prefer to let the browser's reader mode perform the styling for me.

But there are categories of application where that is not acceptable. The presentation is a tightly controlled aspect of the application's functionality. If you're designing an application with leptos or sycamore my suspicion is you would fall into the latter category rather than the former.

No browsers support streaming parsing of XHTML so you are slowing down pageloads. Especially for longer pages.

Also the ecosystem is really not there for XHTML, it never really took off. In practice it is close enough to HTML that it probably mostly works, but you are going to have problems.

The advantage is also very small, your emitter is simpler (you don't have to special case void elements and whatnot) and if you need to consume your own pages the parser is simpler. But that isn't worth much for most people.

It does make me sad, because parsing and even emitting HTML is a nightmare. But it won, so at the end of the day I find it easier to just accept that.

I think if you're going to use Rust on front end you're probably going to use it on back end too. In that case, I would just use Dioxus and get the e2e typing for free. What would be the benefit of Sycamore?

I wouldn't recommend e2e Rust generally yet though. I think server/API + web could work, but mobile is just boiling the ocean and will never be as good as native. You might think you can just use it for server/API + web, then do native mobile apps, but actually the escape hatches in all the frameworks I've used are not great.

Sad to say but "just use React" remains the good advice.