En dash either, apparently.
535 karma · joined June 9, 2024
const links = Array.from(document.querySelectorAll(':link[href^="vote"][id^="up"]:not(.nosee)'));
const timer = setInterval(() => {
const link = links.pop();
if (!link.matches('.nosee'))
setTimeout(() => link.click(), Math.random() * 2000);
if (links.length === 0)
clearInterval(timer);
}, 16000);Why not just Chrome/Firefox/Safari to open the link instead of the Instagram app?
Two issues I saw:
- on my phone, the framerate noticeably drops as I scroll over the widget
- caret positioning within the textarea seems to desync against the letter positions in the highlighted div
And the whole concept severely constrains the styling choices that could be applied to the highlighted output, but I suppose that was a given.
I would rather have them deprecate the HTML syntax, which is a nightmare to parse, nightmare to escape for ( https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not... ), and nightmare to securely transform (CVE-2020-26870). Now that MSIE is dead, all mainstream browsers support XHTML just fine; compared to HTML, XML is much, much simpler to make a new implementation of; and few people generate markup by printf any more.
Never was, never will be. Just write XHTML instead.
There are much better arguments to use TypeScript than "five billion flies can't be wrong". Most other popular tech choices are in fact rather silly.
How is that different from what was before?
Most of the other criticisms are pretty disappointing, though.
> The following example is a famous illustration of how it can't properly reason across branches, either:
Except that function body would have been better rewritten as map.entry(key).or_default() -- which passes the borrow checker just fine and is more performant as it avoids multiple lookups. I suspect many other examples would benefit from being re-written into higher-level primitives that can be easier to borrow-check in this manner.
> But what's the point of the rules in this case, though? Here, the ownership rules does not prevent use after free, or double free, or data races, or any other bug. It's perfectly clear to a human that this code is fine and doesn't have any actual ownership issues.
What if Id represents a file descriptor that ought to be closed when the value ceases to exist? Or some other type of handle? This is an ownership problem: these are not limited to memory safety issues. For very good API stability reasons, without an explicit #[derive(Clone,Copy)] the compiler is not free to assume the type represents pure information that can be copied at will, but can only treat it as one potentially containing owned resources, that just happens not to include any at this time.
> References to temporary values, e.g. values created in a closure, are forbidden even though it's obvious to a human that the solution is simply to extend the lifetime of the value to its use outside the closure.
Which is to say, to what? The type signature does not say whether a closure will be called immediately or in another thread after two hours. And in which stack frame should the value be stored, the soon-to-be-exiting closure's?
Ironically, Java was sold as a "nicer simpler C++".