I fully agree with you that forced "literature" lessons suck the fun out of reading. As someone who had to go through it in the Netherlands I've sworn off Dutch authors in response, and haven't read Dutch literature for over 2 decades.

Your country did gleefully kill millions of innocent brown people in response to 9/11, it's just that they mostly lived in the middle east. You've apparently dehumanized them to the point where their deaths just… slipped your mind.

Because the protection that the VPN provides decreases the risk of having bugs to the point where they won't get prioritized, ever.

That is just bad management, to be fair. Companies need to intentionally increase risks before they can fix them?

That and poor support from cloud vendors. Looking at you, Azure. How is IPv6 not enabled for everything by default? It boggles the mind.

Surely you see the difference between ordinary citizens buying online and spending money abroad while on holiday and big foreign companies taking their billions of profits out of the country?

You can also do something like:

    fn xy_mut(&mut self) -> (&mut f64, &mut f64) {
        let &mut Point { ref mut x, ref mut y } = self;
        (x,y)
    }

The fact of the matter is that doing mutable getters in Rust is a bit inconvenient at times. There are various workarounds.

You can do that with less syntax, this works just fine:

    fn xy_mut(&mut self) -> (&mut f64, &mut f64) {
        let Point { x, y } = self;
        (x, y)
    }

Also, I assume this is just a super trivial example, because in this case I'd just make x and y public. After all, you're giving public access via these methods, and the caller can do anything it wants with them, so there's no real difference.

And if the fields are public, it's much easier to take mutable access of multiple fields separately.

It cannot. The event horizon by definition prevents mass and energy from leaving (ignoring the exception of Hawking radiation here). I'm assuming your "black hole droplet" would be a tiny black hole? But if you could remove a little chunk from the black hole then you've effectively taken mass out of it, which is impossible.

It is even the case that once two black holes have overlapping event horizons (so they "touch" in a way) they can't stop touching. So two black holes can zip past one another at a small distance, but if they high-five they can't stop merging.

No mass escapes. It is purely gravitational waves that are emitted. There is no sneak peek behind the event horizon curtain during a black-hole merger.

The energy is emitted as gravitational waves which is probably tricky to convert into usable energy and you probably can't attend more than one in your life unless you have faster-than-light travel. You're much better off visiting a supernova.

But in general it's better to have a steady and stable source of power, rather than one enormous burst of energy that you have to spend on something instantly.

This explanation gets repeated over and over again in discussions about the speed of the Rust compiler, but apart from rare pathological cases, the majority of time in a release build is not spent doing compile-time checks, but in LLVM. Rust has zero-cost abstractions, but the zero-cost refers to runtime, sadly there's a lot of junk generated at compile-time that LLVM has to work to remove. Which is does, very well, but at cost of slower compilation.

Is it possible to generate less junk? Sounds like compiler developers took a shortcuts, which could be improved over time.

Well, zero-cost abstractions are still abstractions. It’s not junk per-se, but things that will be optimized out if the IR has enough information to safely do so, so basically lots of extra metadata to actually prove to LLVM that these things are safe.

You can address the junk problem manually by having generic functions delegate as much of their work as possible to non-generic or "less" generic functions (Where a "less" generic function is one that depends only on a known subset of type traits, such as size or alignment. Then delegating can help the compiler generate fewer redundant copies of your code, even if it can't avoid code monomorphization altogether.)

Isn't something like this blocked on the lack of specialisation?

I believe the specific advice they're referring to has been stable for a while. You take your generic function & split it into a thin generic wrapper, and a non-generic worker.

As an example, say your function takes anything that can be turned into a String. You'd write a generic wrapper that does the ToString step, then change the existing function to just take a String. That way when your function is called, only the thin outer function is monomorphised, and the bulk of the work is a single implementation.

It's not _that_ commonly known, as it only becomes a problem for a library that becomes popular.

To illustrate:

  fn foo<S: Into<String>>(s: S) {
      fn inner(s: String) { ... }
      inner(s.into())
  }

Probably, but it's the kind of thing that needs a lot of fairly significant overhauls in the compiler architecture to really move the needle on, as far as I understand.