~  apt list --installed | grep sane
# ...
sane-airscan/jammy,now 0.99.27-1build1 amd64 [installed]
# ...

Вот и я, оказывается, пользуюсь, большое спасибо за работу!

У меня у одного ссылка на википедию с этой статьей подменена на какую-то странную abcdef.wiki?

Если путь начинается с первого шага, то относителен, если со слеша - абсолютен

Стоп-кран

const a = 0;
const b = 7;
const p = 11; 

for (let x = 0; x <= p; x ++) {
  for (let y = 0; y <= p; y ++) {
    if (y**2 % p === (x**3 + a * x + b) % p) {
      console.log(`(${x}, ${y})`);
    }
  }
}

А почему верхняя граница цикла включает p, т.е. почему x <= p и y <= p, а не x < p и y < p? Учитывая, что вычисления мы ведем по модулю, разве не было бы правильно не включать p?

Часто ли встречаются сайты, на которых данные подгружаются через API и вместо парсинга используете это самое API?

Полностью согласен с идеей, но Oberon-07, имхо, слишком мертв на данный момент. На мой взгляд, один из лучших учебников программированию - "Программирование - введение в профессию" за авторством Столярова. Автор, конечно, довольно едко проходится по Windows и различным GUIшным штукам, но сама идея паскаля как первого языка и линукса/макоси (точнее, их эмулятора терминала) как первой ОС, на мой взгляд, безусловно верна и даст лучший результат именно в обучении программированию как концепции

Вот и в Rust можно только в точке .await'a, тем более это язык, компилируемый в нативный код - просто взять и из кода приложения сказать виртуалке остановиться не получится, потому что нет ее, этой виртуалки

Чтобы не быть как Алан по большей части достаточно помнить, чем отличаются синхронные функции от асинхронных.

Синхронная функция в скомпилированом виде - это цельный кусок машинного кода. Мы не можем остановить ее выполнение посередине или даже поставить на паузу, если мы не хотим/не можем пользоваться инструментами, которые нам предоставляет ядро (например, таким инструментом будет SIGINT+обработчик, или выведение синхронной функции в отдельный поток, а затем остановка этого потока из другого потока нашей программы)

Напротив, асинхронная функция - это конечный автомат, по сути - множество синхронных функций с промежуточными точками между ними. Каждая (кроме последней) из этих синхронных функций, представляющих собой этапы выполнения большой асинхронной функции, возвращает нам "Я частично готова, можно пока выполнить что-то еще". Последняя же возвращает сам результат.

Мы можем прервать выполнение асинхронной функции в любой такой точке, можем послать на исполнение (в т.ч. так же с середины) другую асинхронную или синхронную функцию, а затем вернуться к первой, а когда в Rust завезут async iters - сможем в таких точках получать промежуточные значения и сразу посылать их дальше. С синхронной функцией мы такого сделать не можем.

Собственно, в этом и есть главный плюс и главный минус асинхронного подхода. С одной стороны, неблокирующее IO благодаря промежуточным точкам. С другой стороны - при неаккуратном использовании можно получить то, что получил автор в первом примере - асинхронная функция выполнилась частично, была остановлена на середине, а поскольку она внутри себя меняла некоторую внешнюю структуру - эта самая внешняя структура была оставлена в неконсистентном состоянии.

Предложение автора дать асинхронным функциям гарантированное завершение звучит очень странно. Их же как раз делали в т.ч. для того, чтобы можно было спокойно отменить выполнение уже ненужной функции прямо пока она работает, и это было бы нормальным поведением. Предложение отказаться от .await еще хуже - сейчас вызов асинхронной функции без .await означает создание того самого конечного автомата, который можно затем отдать какому-нибудь executor'у, а вызов .await означает создание в текущей асинхронной функции точки останова и встраивание в нее конечного автомата той функции, на которой был вызван .await

По итогу, статья очень спорная, со странными примерами и (на мой взгляд) плохими предложениями. Алану я бы рекомендовал почитать Async Book - это должно помочь ему не делать таких ошибок на ровном месте