Don't send `start` and `end`; send `start` and `lengthOfInterval`. (Whether that's a good idea in a given API is another question.)

That trades "min <= max" with "min + interval <= MAXINTEGER":

  if(number < min) return min;
  else if(number < min + interval) return number; // "if(number < max)"
  else return min + interval; // "return max"

You still seem to be completely misunderstanding, as is evident from the fact that your argument "proves" that in Rust you don't even need to write any tests. Again, Antithesis is designed to test distributed systems, deterministically.

sorry, where exactly i stated no need to write tests?

i argue, overall, that antithesis less likely will be adopted in rust because language itself (in sense extended to typelevel patterns and in macro simulations) and its ecosystem (by ecosystem i mean available libraries and tools and integrations which cover a lot of antithesis agenda). i did not expanded ecosystem argument so, because there was objection to that yet.

> i doubt, rust has a lot of tooling and catches at compile time what their product does in runtime.

You're making the claim that Antithesis isn't necessary because compile time type-checking solves problems that Antithesis is targeting. That's strictly not true; the kinds of bugs that Antithesis is targeting are not solved via type checking and has never been something Rust has targeted at solving, through ecosystem or otherwise. See my example about trying to implement a distributed consensus algorithm.

> You're making the claim that Antithesis isn't necessary because compile time type-checking solves problems that Antithesis is targeting

sorry, i never claimed what you stated above.

you have taken only part of my initial statement and made total nonsense of it by stating it is the only one thing i said.

i said:

1. rust needs antithesis less of others

2. rust has equivalent tooling for free

3. biz practices of antithesis will harm its adoption, in rust eco

Can you point to any of Rust's supposed "equivalent tooling"?

> When components are designed as genuine black boxes—where what happens inside stays inside, and communication occurs only through explicit input and output ports—systems naturally become easier to reason about.

"How do you specify the shape of the input and output ports?" shouts the goose as it chases me away.

Author's continuation article at https://programmingsimplicity.substack.com/p/type-checking-c... clearly shows that the input and output ports he can think of are all "string".

If I felt snarky, I'd say "This is your brain on Javascript".

Text goes in and text comes out - simple! Works perfectly for shell scripts. /s

I disagree! I claim that most people follow rules out of a general sense of fair play rather than because they will be punished for not doing so. Certainly this is true of me, and I don't believe society would look the way it does if the cynical view were nearly universally correct.

Cheaters in games like Magic are very rare; if most people tried to cheat whenever they thought they could get away with it, we'd be forced to set up competitions with more stringent verifiable rules like (off the top of my head) "all cards must be drawn and given to you from your deck by the opponent". We haven't done that, so I infer that most people don't try to cheat.

(In your favour, I do concede that everyone writes down their individual understanding of the history of a given chess game; but there are weak instrumental reasons for that even if people aren't cheating, because it is possible to upset a board by accident.)

How do you know they didn't cheat if they got away with it?

There's also the aspect of how hard people are actually competing. For a casual game like MtG, people are mostly there for the fun of it, not to win the competition.

For a deal worth millions of dollars, people are more likely to lie and cheat.

I always love this kind of article! For many more ways type systems can be unsound, see https://counterexamples.org/ .

You can hack up GADTs in F# - for example, https://github.com/Smaug123/WoofWare.Incremental/blob/9b8181... (which uses https://github.com/G-Research/TypeEquality ). (The other missing features I agree are missing.)

Yes, the trick is expanded here: https://libres.uncg.edu/ir/asu/f/Johann_Patricia_2008_Founda... (if you have `Eq a b = Refl : a a eq` you should be able to encode every useful GADTs. But having a compiler support is nice for specifics reason like being able to "try" to detect unreachable cases in match branches for examples.

I've used equality witnesses in F# before, they kinda work but can't match proper GADTs. First you'll need identity conversion methods on the witness, because patterns can't introduce type equalities, then you'll realise you can't refute unreachable branches for the same reason, so you still need to use exceptions.

I'm not sure how you intend performing the "take out loans" and "invest" stages without a company, once you have more than a few million dollars. Companies permit scaling past one person's worth of uptime and ability.

There are 13 blueprint graphs (one for each chapter of the blueprint) so far, all incomplete. https://imperialcollegelondon.github.io/FLT/blueprint/dep_gr...

I do take issue with this fluffy statement at the top:

> If the reader finds the mistakes in the design, this proves that Microsoft has weak developers.

(The article even goes on later to say basically "don't attribute all of these to stupid engineers", and the explicit 17 mistakes are almost entirely not related to the technical content of the security breakages, so there's a sleight of hand being performed here already between "mistakes in the design" and "mistakes in organisational software engineering practice"!)

While I have no love of Microsoft software, and clearly the Xbox was woefully insecure, the statement ignores the fact that knowing there is something to find is often enough to find it. I am failing to find the definitive article about this, but there's something about this by Michael Nielsen or Andy Matuschak or similar. One of its examples is a quote by Kasparov or Magnus Carlsen or similar, to the effect that the single word "now" at the right time would be enough to win a game, because it would announce that there was a discovery to be found. This article is entitled "17 Mistakes…", and it also presents the relevant details of the design rather than all the details of the design, so the problem of finding the mistakes given the description is much, much easier than the problem of reviewing a complete design spec.