Didn't most old operating systems use cooperative multitasking? I remember, at least, that classic Mac OS (i.e. pre-OSX) didn't use preemptive multitasking, either.

Anyway, this SO answer[0] explains why early Linux, much like the hobby kernel in this article, used cooperative scheduling inside the kernel, and only preempted user-space stuff.

[0]: https://stackoverflow.com/a/16766562

MacOS may have been a little late. Windows NT, OS/2, Linux did preemptive multitasking since beginning of 90s, even AmigaOS had it in the 80s.

Mac OS badly needed preemptive multitasking (and memory protection!), and got it when the NeXT bits were transformed into Mac OS X.

Thanks for the link!

I don't understand why this would be different for a Rust based OS..

It is already known that there is some association between intelligence and, for example, race. The underlying causes, whether they're wealth disparities, cultural attitudes toward intelligence, or genetics, don't change whether it's right or wrong to discriminate by race.

You seem to be insinuating something unpleasant, so I would very much appreciate if you could be explicit about what consequences you think this will have.

>You seem to be insinuating something unpleasant

The only insinuation is that I anticipate some people will squirm discussing this sensitive topic. But we are leaving a lot of science and philosophy on the table because of socially constructed boundaries. Are they appropriately positioned, or excessively constraining?

Right, I mostly end up using Haskell's lists as an extremely ergonomic counterpart to iterators / generators in languages like Python and Rust.

There are better alternatives to linked lists for this use case.

1. Clojure uses wide balanced trees as its general-purpose ordered collection.[0] These have probably already been adapted for Haskell, and they offer persistence and fast random access and some degree of cache-friendliness. In my opinion it makes better trade-offs as a general-purpose structure.

2. By passing an &[usize] in Rust, or a const size_t* in C (i.e. by making g accept a read-only pointer), you can be guaranteed that g doesn't modify the array.

[0]: https://hypirion.com/musings/understanding-persistent-vector...

Does this really work?

I see no reason why my local "representative" would bother listening to me.

In some cases it can work remarkably well, or so I've been told. The more people who reach out, the more fearful said rep will be of backlash.

> If you don't box all your closures, functional programming in Rust gets tedious quite quickly.

Somewhat true, but argument position and return position impl Trait have made that slightly nicer.

> The bigger problem is laziness. How is laziness implemented? A value is represented as an unevaluated thunk, a closure to compute the value. When the value is needed, the closure is run and then replaced by the resulting data. This is mutability. And this is something that almost every Haskell program relies on.

Tangent: does GHC ever decide that it's cheaper to just potentially evaluate something twice than to use thunks?

Really? I have no experience with Haskell's internals, but self-referential objects are fairly common in Haskell thanks to its non-strictness. The simplest one is probably the list with one element repeated forever.

    ones = 1:ones

Shadowing is when you have two separate variables with the same identifier. It is beyond obvious that all the x's refer to the same variable in dilap's example. Contrast that with an actual example of shadowing[0], in which it is clear that the same identifier is being used to refer to two different variables.

[0]: https://en.wikipedia.org/wiki/Variable_shadowing#Python

I'm using shadowing in the rust sense, not the python sense.

They are the exact same sense!

The exact same idea of shadowing is also present in, for example, sentences in first order logic.

Well no, for the reason I describe above: if you have the pattern

    mut a = 4
    f(a)
    print(a)

In rust and python, you'll always get 4 in python, but the value in rust depends on `f`.

This means that the passed variable is immutable but shadowable, as in rust. (An object in python is much more like an Box/Cell, so the contained object can be mutated, but the reference to the box itself is immutable).

The value in Rust does not depend on f.

I will be precise. There is no definition of f such that this function will print anything other than "4".

    fn main() {
        let mut x = 4;
        f(x);
        println!("{}", x);
    }

Again, you seem to be confusing mutable references and mutable variables. If I had written f(&mut x) rather than f(x), you would be right.