Почему я перестал писать bash-скрипты и написал свой язык

Справедливо конечно. Но процесс тот же: формулируешь промпт -> ждёшь -> запускаешь -> не работает -> уточняешь -> ждёшь снова. Иногда быстрее гугла - но это всё ещё цикл "попроси кого-то написать код за тебя и надейся, что он правильный".

Shik про другое - про то, чтобы ты сам мог написать скрипт за 30 секунд, понимая каждую строку, и не потратив на изучение языка несколько недель. Без посредников - не нужно выходить из терминала. Всё прямо тут, в REPL, через help, здесь и сейчас.

Но, замечу вот что - у этого языка вполне себе прямой посыл: "удобство использование в REPL и для планирования сценариев".
Например - у меня есть набор коммитов которые надо черри-пикнуть в ветку. И я возьму и спокойно напишу:

[:xfsc1 :fac3r :cx5nj :00dser] $>
  list.iterate fn [commit] shell "git cherry-pick {commit}"

Это не займёт у меня хоть какой-то когнитивной нагрузки, с учётом что язык знаком. Использовать ИИ, гуглить, пытаться написать это на bash или fish - да куда проще будет уже просто скопипастить пять раз `git cherry-pick {commit}` с конкретным коммитом. Вот для этого я и создал этот язык)

Почему я перестал писать bash-скрипты и написал свой язык

SQL-подобные запросы к файловой системе и структурированным данным — это довольно точно описывает Nushell! Там данные идут по пайпу как таблицы, можно фильтровать, сортировать, группировать — почти как SELECT/WHERE/ORDER BY, только в терминале. Думаю вам будет интересно посмотреть в его сторону)

Почему я перестал писать bash-скрипты и написал свой язык

Именно об этом и речь в статье - я даже отдельно разбираю однострочник grep -l | xargs mv. Да, для конкретной задачи "посчитать строки" можно собрать конвейер из find/cat/wc. А завтра задача чуть другая — и снова гуглить, какой флаг у find для maxdepth, нужен ли + или \; в -exec.

Shik не про то, что bash не может. Bash может всё. Shik про то, чтобы выражать цепочки действий единообразно - одними и теми же правилами, без зоопарка утилит и флагов. Если ежедневная работа с этим связана - то конечно естественно их все знать. Но если нужно сделать что-то такое раз в неделю - гуглёж из раза в раз утомляет

Кратко о вариантности с примерами на TypeScript

И о чём этот пример говорит? Что spread оператор сбрасывает аннотации?

class Animal {
  genus: number = 0
}
class Cat extends Animal {
  clawSize: number = 0
}
type ContravariantMethod<in V> = {
    process(v: V): void;
}

declare let _processCat_: ContravariantMethod<Cat>
declare let _processAnimal_: ContravariantMethod<Animal>

let processAnimal = (animal: Animal) => {}
let processCat = (cat: Cat) => {}

_processAnimal_ = _processCat_ // Ошибка
_processCat_ = _processAnimal_ // Ок
_processAnimal_ = { ..._processCat_ } // Снова ок, но потому что typescript сбросил аннотацию

processAnimal = processCat // Ошибка
processCat = processAnimal // Ок
processAnimal = { ...processCat } // Всё ещё ошибка, потому что функции всегда контравариантны

Вот буквально вырезка из этой же документации, которая приводит в пример эту же ситуацию, и прямо заявляет, что "measurement can be inaccurate"

Because variance is a naturally emergent property of structural types, TypeScript automatically infers the variance of every generic type. In extremely rare cases involving certain kinds of circular types, this measurement can be inaccurate. If this happens, you can add a variance annotation to a type parameter to force a particular variance:

// Contravariant annotation
interface Consumer<in T> {
  consume: (arg: T) => void;
}

Кратко о вариантности с примерами на TypeScript

Прекрасно сказано: "Никогда не используйте аннотации вариантности которые не совпадают со структурной вариантностью типа".

По вашему мой пример выше это НАРУШЕНИЕ структурной вариантности? Изменение вариантность с бивариантной, которую в области вариантности можно воспринять как any, которая в примере выше создают runtime ошибку, на контравариантность - стандартное поведение TypeScript с функциями, что от ошибки избавляет.

Какое тогда по вашему мнению правильное использование аннотаций, которое не меняет тайпчекер?

Кратко о вариантности с примерами на TypeScript

Документация предостерегает к необдуманному использованию, это верно. Однако, в случае что я привёл, прямо видно проблему которую создают бивариантные методы. Следующий код, являясь переписанной на классы аналогией секции про контраварианты, ошибку больше не показывает:
TypeScript playground

class AnimalFood {
  protein: number = 0
}
class CatFood extends AnimalFood {
  fishness: number = 0
}

abstract class Processor {
  abstract process(food: AnimalFood): void;
}
class AnimalProcessor {
  process(food: AnimalFood) {}
}
class CatProcessor {
  process(food: CatFood) {}
}

const animalProcessor = new AnimalProcessor()
const catProcessor = new CatProcessor()

/**
 * Перед подачей обработаем корм
 */
function serveAnimalFood(processor: AnimalProcessor): void {
    const food = new AnimalFood();
    processor.process(food);
}
function serveCatFood(processor: CatProcessor): void {
    const food = new CatFood();
    processor.process(food);
}

// оказывается, теперь всем по нраву рыбный вкус
serveAnimalFood(catProcessor);

serveCatFood(animalProcessor); 

Так что аннотации вариантности нужны именно для таких случаев. Тут in аннотация увеличит безопасность кода и предостережет от ошибки. Для этого они и созданы.