Yeah, these kinds of "orthogonal" things that you want to set up "on the outside" and then have affect the "inner" code (like allocators, "io" in this case, and maybe also presence/absence of GC, etc.) all seem to cry out for something like Lisp dynamic variables.
It depends on how you do it. XSLT 2.0 had <xsl:tunnel>, where you still had to declare them explicitly as function (well, template) parameters, just with a flag. No explicit control over levels, you just get the most recent one that someone has passed with <xsl:with-param tunnel="yes"> with the matching qualified name.
For something like Zig, it would make sense to go one step further and require them to be declared to be passed, i.e. no "tunneling" through interleaving non-Io functions. But it could still automatically match them e.g. by types, so that any argument of type Io, if marked with some keyword to indicate explicit propagation, would be automatically passed to a call that requires one.
They recently started blocking VPNs. They also block DNS resolvers like CloudFlare because they are not sharing your location (which is a very good thing!).
Get archive.ph's web server IP from a DNS request site and put the IP in your hosts file so it resolves locally. You might need to do this once every few months because they change IPs.
Then add something like this to /etc/hosts or equivalent:
194.15.36.46 archive.ph
194.15.36.46 archive.today
But you might need to cycle your VPN IP until it works. Or open a browser process without VPN if you don't care if archive.ph sees your IP (check your VPN client).
I'm having trouble parsing this sentence. What are "VPNs on top of DNS resolvers not sharing your location"? Why does bypassing DNS help with VPNs being blocked?
1. archive.ph used to block DNS resolvers like CloudFlare because those resolvers didn't share the client's location with archive.ph DNS servers (this exposes whoever is behind archive.ph is tracking who is reading what)
2. Recently, archive.ph also started blocking VPN exit IPs.
So to bypass both, you can do my hosts trick to get an IP of archive.ph website, and if you are using a VPN find an exit IP not banned (usually a list of cities or countries in your VPN client manager).
EDIT: please use a more polite tone when addressing strangers trying to give you a hand, let's keep the Internet a positive place.
I just got back from a family vacation there. I was tired that day, it was hot and crowded, and I started thinking, "I wonder if this will be worth it."
I found myself astounded, struck speechless, and moved to tears. I was in awe.
Gaudi is someone we software engineers should revere. He made things precisely and powerfully functional while also making them beautiful.
Do not miss seeing Sagrada Familia if you ever get the chance.
Fully agree. Walking towards the address I came around a corner and my jaw dropped. Still get goosebumps thinking of that moment. Sadly inside was a construction site with no lighting (this was around 2003), would love to go back and see it again.
But you stated it was "the truth" and so we might reasonably wonder why you think so, unless it's that you just believe anything you read.
"ABI: Now or never" by Titus Winters addresses some perf leaks C++ had years ago, which it can't fix (if it retains its ABI promise). They're not big but they accumulate over time and the whole point of that document was to explain what the price is if (unlike Rust) you refuse to take steps to address it.
Rust has some places where it can't match C++ perf, but unlike that previous set Rust isn't obliged to keep one hand tied behind its back. So this gently tips the scales further towards Rust over time.
Worse, attempts to improve C++ safety often make its performance worse. There is no equivalent activity in Rust, they already have safety. So these can heap more perf woes on a C++ codebase over time.
It seems you agree? I'd love to hear your thoughts on it. I had gotten the impression (second-hand) that they were roughly equally matched in this regard.
I've had people do this to me (albeit in an attempt to be helpful, not snarky) and it felt so weird. The answers are something a copywriter would have thrown together in an hour. Generic, unhelpful drivel.
Respectfully, I disagree, though maybe we haven’t yet articulated enough details to know exactly where we disagree.
I think underlying Kent’s statement is an observation that is undeniably true. The closer a test is to the actual way the software will be used, the better it is in a number of ways, _all else being equal_. All else is never fully equal, which is why everything is about tradeoffs.
But when a test aligns with how the software will be used, there are a whole bunch of synergies and benefits. Simplicity increases, clarity increases, you start getting multiple payoffs for each bit of effort you invest.
I’m sure people cargo cult it and lose track of the tradeoffs, like anything else, but there’s a solid point under there. And I agree with him, it is valuable enough to be called a “best practice.”
The point I often try to make is just how easy it is to get the right result, for the wrong reasons. (especially in loose languages like JavaScript). It goes from making more scientific proofs to, "I saw what I wanted to see on the screen - I can't exactly say why, but I think it's because my code is sound".
It's the equivalent to, "this new flea killer kills twice as many fleas". "What did you change?" "Four different things", "which one ended up being the thing that actually made it work?", "dunno, but now we're seeing twice as many fleas dead!".
The initial comments here surprise me. I’ve never seen such poor quality comments on such a good article on Hacker News. The article is top notch, highly recommend. It explains from first principles very clearly what the (a?) mechanism is behind model checking.
So is the ability to compute the entire state space and prove that liveness and/or safety properties hold the single main basis of model checker’s effectiveness? Or are there other fundamental capabilities as well?
The problem with this article is that it doesn't present weak memory models[1], which are the reality on all multiprocessor/multicore systems these days. Thus is perpetuates misconceptions about concurrent programming. This is a poor example of model checking because it assumes sequential consistency and actually confuses people by reinforcing incorrect assumptions.
[1] With weak memory hardware, it is effectively impossible to write correct programs without using at least one of atomic read-modify-write or barriers, because both compilers and hardware can reorder both reads and writes, to a maddening degree.
1. "It's not visual, it's text". Yeah, but: how many "visual" representations have no text? And there _are_ visuals in there: the depictions of state space. They include text (hard to see how they'd be useful without) but aren't solely so.
2. "Meh, verification is for well paid academics, it's not for the real world". First off, I doubt those "academics" are earning more than median sw devs, never mind those in the SV bubble. More importantly: there are well-publicised examples of formal verification being used for real-world code, see e.g. [1].
It's certainly true that verification isn't widespread. It has various barriers, from use of formal maths theory and presentation to the compute load arising from combinatorial explosion of the state space. Even if you don't formally verify, understanding the state space size and non-deterministic path execution of concurrent code is fundamentally important. As Dijkstra said [2]:
> our intellectual powers are rather geared to master static relations and that our powers to visualise processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static process and the dynamic program, to make the correspondence between the program (spread out in space) and the process (spread out in time) as trivial as possible.
He was talking about sequential programming: specifically, motivating the use of structured programming. It's equally applicable to concurrent programming though.
reply