Спасибо, по первому пункту разберу подробно — там смешаны три разные вещи.
number|0 — это не целочисленный тип, а приведение к int32. И для языка с числами-double это шаг назад, а не вперёд: double даёт точные целые до 9007199254740991, а |0 — до 2147483647. На большем оно не «магически превращается», а ломается:
231 | 0 → -2147483648 (253 - 1) | 0 → -1
В asm.js |0 работал не как тип, а как аннотация для AOT-компилятора: разметка статически типизированного подмножества, чтобы движок скомпилировал его заранее. В динамическом интерпретаторе аннотировать нечего — значение всё равно останется боксированным, а диапазон сузится в четыре миллиона раз.
Uint8Array — это буфер байтов, а не скалярный числовов языке целые» отношения не имеет.
BigInt — единственный реальный кандидат, и я его расс, и вот чем платят:
Number: 20 мс BigInt: 110 мс → в 5,5 раза медленн 1n + 1 → TypeError: Cannot mix BigInt and other types 7n / 2n → 3n (а 7 / 2 = 3.5) JSON.stringify(1n) → TypeError
То есть это не «добавить тип», а решить заново, что в языке значит /, что происходит при смешивании, и как это сериализуетсцелочисленный тип у меня в открытых вопросах, а не в атье он честно назван отсутствующим, а не «почтиесть». Про мотивацию — вопрос справедливый. Язык здесь не цель, а предмет: статья про систему проверок, которая позволила переписацеликом и не сдвинуть ни одного эталона. Но принцип уательный — ошибаться громко и рано, впротивоположность JavaScript:
выход за границы списка и отсутствующий ключ — ошибка, а не nil; - переполнение — ошибка: ни бесконечности, ни NaN в я
"сумма: " + 5 — ошибка, а не склейка; - у каждой ошибки позиция, строка исходника с кареткоа про опечатку. Молчаливый nil и тихий inf — источник багов, которые троен так, чтобы они всплывали в момент написания. Про запуск — согласен, зависимость от Node реальна. Эсборки, нет зависимостей в рантайме, весь тулчейн —node src/cli.ts file.sable. Проект в первую очередь читают, а не устанавливают, и здесь важнее, чтобы между исходником и застояло ничего. wasm со своим рантаймом — это другой проект: понадобира, либо ждать wasm-gc. Разумный путь, если цельсменится на «раздавать бинарник». Self-hosted — честно: пока нет. Чтобы компилятор написать на самом Sable, языку нужны вещи, которых у него нет на 0.2. Это классическая веха, и она интереснее wasm, но сначала работа со строками, иначе получится компилятор,который стыдно показать.
Отдельное состояние «я не знаю» вместо схлопывания в успех или ошибку — то место, где обычно и ломаются такие контуры. Соблазн приравнять неизвестность к ошибке огромный, потому что так короче код, и цена всплывает позже: повтор поверх уже выполненной необратимой операции.
Из практики добавлю два вопроса, которые стоит задать такому состоянию. Первый: у него есть граница по времени? Пока не сказано, за сколько неопределённость обязана разрешиться и что происходит, если архив накопителя недоступен дольше этого срока, состояние тихо превращается в свалку, которую никто не разбирает. Второй: кто владелец очереди неразрешённых? Технически они не мешают, поэтому мониторинг их не показывает, а бизнес-смысл у каждой записи есть.
И про тестирование этого контура. Такие вещи бесполезно ловить нагрузкой: нужный отказ должен случиться ровно между «команда отправлена» и «ответ получен», и на настоящем железе это окно почти не поймать. Обычно помогает вынести всё, что связано со временем и вводом-выводом, за границу логики, а в тестах подменять их управляемым источником: тогда обрыв ставится ровно в нужную точку, а не подкарауливается.
Хорошо разложено, особенно мысль про то, что восстановление зависимости и восстановление системы — разные события: 12:00 сервис здоров, 12:03 разобрана очередь.
Добавлю то, чего мне не хватило в разделе про fault injection, — воспроизводимость. Хаос-эксперимент ловит нарушение инварианта один раз, а дальше начинается самое дорогое: попытка повторить. Если задержки, потери и порядок доставки берутся из настоящей сети, конкретное расписание не повторяется, и находка превращается в «мы такое однажды видели». Практический выход — сделать источник недетерминизма своим: время, таймеры, порядок готовых колбэков и решения «доставить / потерять / продублировать» брать из генератора с сидом. Тогда упавший прогон адресуется одним числом, кладётся в регрессию и воспроизводится на чужой машине.
И второе, ближе к вашему списку инвариантов. У набора инвариантов та же беда, что у любых тестов: если он всегда зелёный, по цвету не отличить «ловит» от «не смотрит». Дешёвая проверка — временно выключить в системе правило, которое эти инварианты обязаны защищать (например, атомарность проверки ключа идемпотентности), и потребовать, чтобы тесты покраснели с конкретным именем нарушенного инварианта, а не просто упали. Если не покраснели — проверяется не то, что кажется.
Спасибо, по первому пункту разберу подробно — там смешаны три разные вещи.
number|0 — это не целочисленный тип, а приведение к int32. И для языка с числами-double это шаг назад, а не вперёд: double даёт точные целые до 9007199254740991, а |0 — до 2147483647. На большем оно не «магически превращается», а ломается:
231 | 0 → -2147483648 (253 - 1) | 0 → -1
В asm.js |0 работал не как тип, а как аннотация для AOT-компилятора: разметка статически типизированного подмножества, чтобы движок скомпилировал его заранее. В динамическом интерпретаторе аннотировать нечего — значение всё равно останется боксированным, а диапазон сузится в четыре миллиона раз.
Uint8Array — это буфер байтов, а не скалярный числовов языке целые» отношения не имеет.
BigInt — единственный реальный кандидат, и я его расс, и вот чем платят:
Number: 20 мс BigInt: 110 мс → в 5,5 раза медленн 1n + 1 → TypeError: Cannot mix BigInt and other types 7n / 2n → 3n (а 7 / 2 = 3.5) JSON.stringify(1n) → TypeError
То есть это не «добавить тип», а решить заново, что в языке значит /, что происходит при смешивании, и как это сериализуетсцелочисленный тип у меня в открытых вопросах, а не в атье он честно назван отсутствующим, а не «почтиесть».
Про мотивацию — вопрос справедливый. Язык здесь не цель, а предмет: статья про систему проверок, которая позволила переписацеликом и не сдвинуть ни одного эталона. Но принцип уательный — ошибаться громко и рано, впротивоположность JavaScript:
выход за границы списка и отсутствующий ключ — ошибка, а не nil; - переполнение — ошибка: ни бесконечности, ни NaN в я
"сумма: " + 5 — ошибка, а не склейка; - у каждой ошибки позиция, строка исходника с кареткоа про опечатку. Молчаливый nil и тихий inf — источник багов, которые троен так, чтобы они всплывали в момент написания. Про запуск — согласен, зависимость от Node реальна. Эсборки, нет зависимостей в рантайме, весь тулчейн —node src/cli.ts file.sable. Проект в первую очередь читают, а не устанавливают, и здесь важнее, чтобы между исходником и застояло ничего. wasm со своим рантаймом — это другой проект: понадобира, либо ждать wasm-gc. Разумный путь, если цельсменится на «раздавать бинарник». Self-hosted — честно: пока нет. Чтобы компилятор написать на самом Sable, языку нужны вещи, которых у него нет на 0.2. Это классическая веха, и она интереснее wasm, но сначала работа со строками, иначе получится компилятор,который стыдно показать.
Попробовать без установки, если интересно: https://botiroff-d.github.io/sable/
Отдельное состояние «я не знаю» вместо схлопывания в успех или ошибку — то место, где обычно и ломаются такие контуры. Соблазн приравнять неизвестность к ошибке огромный, потому что так короче код, и цена всплывает позже: повтор поверх уже выполненной необратимой операции.
Из практики добавлю два вопроса, которые стоит задать такому состоянию. Первый: у него есть граница по времени? Пока не сказано, за сколько неопределённость обязана разрешиться и что происходит, если архив накопителя недоступен дольше этого срока, состояние тихо превращается в свалку, которую никто не разбирает. Второй: кто владелец очереди неразрешённых? Технически они не мешают, поэтому мониторинг их не показывает, а бизнес-смысл у каждой записи есть.
И про тестирование этого контура. Такие вещи бесполезно ловить нагрузкой: нужный отказ должен случиться ровно между «команда отправлена» и «ответ получен», и на настоящем железе это окно почти не поймать. Обычно помогает вынести всё, что связано со временем и вводом-выводом, за границу логики, а в тестах подменять их управляемым источником: тогда обрыв ставится ровно в нужную точку, а не подкарауливается.
Хорошо разложено, особенно мысль про то, что восстановление зависимости и восстановление системы — разные события: 12:00 сервис здоров, 12:03 разобрана очередь.
Добавлю то, чего мне не хватило в разделе про fault injection, — воспроизводимость. Хаос-эксперимент ловит нарушение инварианта один раз, а дальше начинается самое дорогое: попытка повторить. Если задержки, потери и порядок доставки берутся из настоящей сети, конкретное расписание не повторяется, и находка превращается в «мы такое однажды видели». Практический выход — сделать источник недетерминизма своим: время, таймеры, порядок готовых колбэков и решения «доставить / потерять / продублировать» брать из генератора с сидом. Тогда упавший прогон адресуется одним числом, кладётся в регрессию и воспроизводится на чужой машине.
И второе, ближе к вашему списку инвариантов. У набора инвариантов та же беда, что у любых тестов: если он всегда зелёный, по цвету не отличить «ловит» от «не смотрит». Дешёвая проверка — временно выключить в системе правило, которое эти инварианты обязаны защищать (например, атомарность проверки ключа идемпотентности), и потребовать, чтобы тесты покраснели с конкретным именем нарушенного инварианта, а не просто упали. Если не покраснели — проверяется не то, что кажется.