Personally nearly every nice thing in my life either is a human or was made by one

It's a bit redundant to mention "is a human" separately, since humans are made by... wait a minute

Reproduction isn’t really a human making a human. Where making means using your cognitive power to apply focus to a creative task. It is more akin to natural biological processes. Do humans make poo, or hair?

OK, what about IVF?

And every atrocity, driven by greed, envy or just sheer assholery?

Also humans.

Reinventing polari is certainly one way to make yourself less understood...

Well you're on a website called ycombinator.com so maybe the fixed point combinator

    Y = λf.(λx.f(xx))(λx.f(xx))

https://en.m.wikipedia.org/wiki/Fixed-point_combinator

>There’s a well-established effect, common enough at this point to where some academic has probably given it a name like “The Twitter Dilemma” or something, that describes how a lie can be much more potent and contagious with exponentially fewer words than are necessary to effectively refute it.

https://en.m.wikipedia.org/wiki/Brandolini%27s_law

In New Jersey the Midtown Direct line famously paid for itself multiple times over by increasing nearby property values so much the state collected millions more in property taxes

https://en.m.wikipedia.org/wiki/Kearny_Connection

>A safe alternative is to use indexes instead of references.

    struct ParsedFile {
        contents: Vec<u8>,
        words: Vec<(usize, usize)>
    }

>This works well, and you can make it ergonomic by wrapping the index pair in a new type

You should probably just use the std::ops::Range type for this. It's what's created by the `..` syntax

Eh, Range has a lot of really weird stuff going on that is worth shying away from if possible. For instance they're Iterator and not Copy so if you try to iterate over them multiple times or pass them as indices multiple times, you're gonna have a bad time (i.e., you'll need to clone every time you do). Usize is Copy, so you can use them to construct a Range every time you need one and never run into those issues.

Yes. For anyone who's not up on extremely obscure standard library issues in Rust, the Range type kind of serves two different purposes. One is the general concept of a range, and the other is an iterator over a range. Range is more of the latter, and copying iterators does slightly weird things (the behavior is contrary to some human intuition, even though the behavior is consistent), and so it was decided that Range shouldn't be Copy. But for the generic "I want a range of numbers" case, you would want that to be Copy. So there's a push and pull here. It seems like some of the latest discussion (and this has been going on for years) is that maybe this decision was wrong and even though the iterator behavior is weird ranges should start being Copy, but no decision is made yet. But when you're not doing iteration directly, imho you probably should just use a tuple of (start, end) rather than a Range, even though that may feel a bit odd.

Also: it's weird and really unfair imho that the GP is downvoted. While it is true that some folks have a different opinion, it's extremely subjective, and downvoting them for a slightly minority opinion doesn't seem right to me. I upvoted it, personally.

GHC is nearly impossible to bootstrap if you don't consider the vendored transpiled C code to be source. Versions of GHC not dependent on GHC were never public AFAIK.

https://elephly.net/posts/2017-01-09-bootstrapping-haskell-p...

Writefreely?

https://writefreely.org/