FBT

If one were to use a fairly standard number for the statistical value of a human life, $10MM, then $126MM is about the same amount of harm as the deaths of 12.6 people.

(You have to choose some number as the value of a human life, and the power of the "statistical value" measure is that it is self-determined, derived from the choices people make for themselves of how much money to pay to reduce the risk of dying, aggregated and averaged. You are free to advocate for a different measure, but if so, you need to actually make the argument, ground your measure in something, something that you then need to claim is a better measure than people's own revealed preferences.)

7 USC § 1a(37) defines an "organized exchange" as

> [A] trading facility that— (A) permits trading— (i) by or on behalf of a person that is not an eligible contract participant; or (ii) by persons other than on a principal-to-principal basis; or (B) has adopted (directly or through another nongovernmental entity) rules that— (i) govern the conduct of participants, other than rules that govern the submission of orders or execution of transactions on the trading facility; and (ii) include disciplinary sanctions other than the exclusion of participants from trading.

And 7 USC § 1a(51)(A) defines a "trading facility" as

> [A] person or group of persons that constitutes, maintains, or provides a physical or electronic facility or system in which multiple participants have the ability to execute or trade agreements, contracts, or transactions— (i) by accepting bids or offers made by other participants that are open to multiple participants in the facility or system; or (ii) through the interaction of multiple bids or multiple offers within a system with a pre-determined non-discretionary automated trade matching and execution algorithm.

(7 USC § 1a(51)(B) then follows with some exceptions to that definition.)

In short—an "organized exchange" is defined as a type of "trading facility". To count as a trading facility", whether of the "organized exchange" type or not, you must either accept bids or offers from other participants yourself or else deterministically match and execute those bids and offers.

The Magic: The Gathering card "Blood Moon" was first printed in 1994. It seems quite unlikely that the term was invented some twenty years later.

> ... Does distributivity of inversion ~ over operation ⋆ follow from the other Abelian group axioms / properties? If so, how?

It does. For all x and y:

  (1) ~x ⋆ x = 0 (definition of the inverse)
  (2) ~y ⋆ y = 0 (definition of the inverse)
  (3) (~x ⋆ x) ⋆ (~y ⋆ y) = 0 ⋆ 0 = 0 (from (1) and (2))
  (4) (~x ⋆ ~y) ⋆ (x ⋆ y) = 0 (via associativity and commutativity)

In (4) we see that (~x ⋆ ~y) is the inverse of (x ⋆ y). That is to say, ~(x ⋆ y) = (~x ⋆ ~y). QED.

In a negotiation, the goal is to reach an accommodation suitable for both parties. If the web developer doesn't want to set up his server on port 80 to serve HTTP, that's his business. Your user agent is still working for you, when it negotiates with the server what protocols it will accept. (It also negotiates a content type for the response; and if all the server has is static HTML, it's not your user agent's fault if what you get is HTML, even if you really wanted some other format. Take it up with the web developer, if you want the data in some other format. The browser is just doing its best for you.)

Your argument makes sense in one narrow circumstance which is not the typical HSTS setup: if the server is serving the site with plain HTTP on port 80 (and not just a redirect to the HTTPS version of the page), and also has a HTTPS version with HSTS headers. (So that the first time you visit the HTTPS version, your browser will insist on taking you to that version every time.)

> There aren't nearly enough capacity in the judicial branch to handle all that work.

Then appoint more Article 3 judges. It could even be the same people who are now "administrative judges"—but take them out of the executive branch hierarchy, and give them the independence that the constitution requires judges to have.

The problem is that while it's an impressively close approximation for an off-the-cuff guess (at least if we charitably translate his "dozens"/"dozen" to 12), to the extent it was pre-planned it's a terrible approximation. ~50 years as a lifetime is the right order of magnitude (and thus a very good result for a guess), but is too far off to be any good if precalculated.

There are about half a million minutes in a year, so 50 million seconds is a year and two thirds. At the rate of saving 50 million seconds a day, in a year you'll have saved around 608 years—which is only a dozen lifetimes if a lifetime is around 50 years. Still, that's a pretty close approximation for an off-the-cuff guess.

> own build system

Nothing in Rust requires you to use Cargo. It's really convenient to have a good build system like Cargo—but if you like C style of manually invoking the compiler, rustc can do that too.

Rust is no worse by bundling Cargo. It strictly dominates the alternative, which would be to just ship rustc and allow the user to pick whatever build system they like. You still can pick your favorite build system; but if you don't have a particularly strong preference, Cargo is a very good default.

When it comes to the systemd logs, this is kind of what the -x flag to journalctl does (or tries to do.)

Having detailed human-level descriptions of what's going on and how to fix it is great. But you also don't want to drown out any important details under waves of verbose text.

The solution, then, is to show the extra detail only when it's requested with the -x flag.

This works pretty well, all things considered. The detailed messages are fine, but they could be better—but that's probably always going to be true. It's a start, anyway.

That's very likely true. The context I was talking about probably rounds to "companies with <100 employees", or perhaps at order of magnitude larger at most. I'd imagine that it's quite different in organizations bigger than that. (Not that it's _quite_ accurate to round attitude off to size, but it's probably close enough.)

> The question suggests that you can somehow give yourself a new title which usually isn't true for people who work for someone else.

> In some places to get a senior developer title, you just need to ask. Your manager then tells HR to change one cell in a spreadsheet and congrats - you're a senior software engineer.

That's the "somehow". There is a very strong sense in which whole "asking your manager" thing is a mere formality—it's very unlikely to be declined if the title you're asking for is remotely appropriate (and, to be honest, often even if it isn't.) Your manager is going to be very happy that he or she has a way of keeping you happy and rewarding you for your work _without_ it coming out of their budget (the way a raise or a bonus would.)

So (at least in companies of a certain size, where this is more or less the level of formality attached to job titles), a title _is_ something you can decide to give yourself—yes, you'll want to run it by your manager to get them to ratify it for you, but that doesn't take much. Once you've decided that you want to be called by the new title, the rest is just paperwork to get it formalized.

Absolutely yes. My SaaS startup uses it, and it's really great.

I strongly disagree with the "innovation tokens" argument, at least as applied here. For one thing, while Elixir and Phoenix can certainly be considered "innovative" in the sense that they're better than more common alternatives, they really aren't "innovative" in the sense people sometimes try to scare you with—it's not all that different, on a fundamental level, than those alternatives. It feels very similar to Rails or Django—different in some ways, sure, but not at all alien.

But on a more fundamental level—all being well, this startup is something you're going to be doing for at least the next two or three years, and quite likely more. By far the most important factor in making technology decisions is going to be to use technologies that don't make you give up in frustration. Building a startup is a long hard journey, and yes, there will be many time along the way when you'll be tempted to throw in towel and give up.

If you're working day in and day out in a codebase, framework, language, or idiom that you don't enjoy, feeling that every day is a grind, then regardless of anything else you're chances of getting very far are less then they'd be otherwise.

So you're number one consideration when picking a language or a framework should be something that is a joy for you to use.

Of course, that's not to say productivity with he language (etc) is not important. Of course it's important! It's probably the most important factor that goes into that feeling of joy. That's why so many people love Rails… and that's also why so many people love Phoenix.

So go with it. Forcing yourself to use something that will be a slog for you to use is a fatal mistake for your startup—so go with what makes you feel comfortable and productive. If that's Phoenix, go for it!

My startup has been going for more than a year now, and in retrospect writing it in Elixir with Phoenix was absolutely the correct decision. I can say a lot of good things about it: it's comfortable, powerful, productive, efficient, and so forth. But most importantly, because of all these things, I'm not pulling my hair out. Yes, doing a startup is hard. But at the very least we can avoid making things worse by deciding that the things that are under our control (such as the framework and language to use) won't be adding to those headaches.

Maybe there are other languages and frameworks that are even better. Maybe that's true, although I do think that Phoenix is at the top of the list at the moment. Some people are already comfortable with Rails or the like, and prefer to stay with it. Sure, if that's the position that you're in, that may be the correct choice for you.

But as a general rule, the principle shouldn't be "avoid innovation", it should be to avoid getting stuck in a tech stack which will feel like a grind to work on a year from now.