Всё, что вы описали про npm, верно на уровне декларации. Но разница в Rust не в политике, а в инвариантах. Cargo не просто “запрещает unpublish”, он делает невозможной ситуацию, когда система сборки оказывается в непредсказуемом состоянии без прямого участия разработчика. npm лишь регламентирует поведение пользователей, Rust исключает его на уровне механики. Это не “новые правила” — это другой класс гарантий.
А сравниваю потому, что большинство сравнивает Rust с JS по скорости, и я хотел показать, что это некорректно именно по сути. Не потому что Rust “медленнее”, а потому что у них разные задачи. Компилятор и транспайлер не живут в одной категории.
В Rust build.rs — единственная точка исполнения, и она не срабатывает при установке зависимости. В npm же postinstall по историческим причинам встроен в модель, и злоумышленники этим реально пользовались (rand-user-agent, eslint-config-prettier, Shai-Hulud). Разница не философская, а архитектурная: в одном случае класс уязвимостей невозможен, в другом — просто “по умолчанию выключен”.
неизменяемость опубликованных пакетов (immutability policy), воспроизводимые сборки (Cargo.lock обязателен), строгое соблюдение семантического версионирования. все это есть и у npm...
Формально — частично. Фактически — нет.
npm-пакеты можно удалять и перезаливать (такие инциденты были). В Cargo это невозможно: опубликованный crate навсегда иммутабелен, даже автор не может его изменить.
npm не гарантирует, что зависимости не будут подменены через зеркала или приватные registry. В Cargo единственный источник — crates.io, хеши пакетов фиксируются в git-индексе.
reproducible build в Cargo встроен в сам инструмент. В npm это просто практика, не enforce’ится инфраструктурой.
если можно подменить бинарь пакетного менеджера pnpm, то так же можно подменить и cargo
Можно подменить хоть ls, вопрос в вероятности и поверхности атаки. Cargo распространяется только через rustup и официальные дистрибутивы с проверкой подписей. В экосистеме Node десятки точек входа — node, nvm, n, yarn, pnpm — каждая из которых может стать вектором компрометации. Rust экосистема изначально проектировалась под минимизацию таких рисков архитектурно, а не “постфактум” настройками.
postinstall скрипты в pnpm по умолчанию выключены
Да, но сама идея выполнения произвольного кода при установке уже компромисс. Cargo принципиально не поддерживает никаких установочных скриптов. Это делает целый класс уязвимостей просто невозможным, а не “по умолчанию выключенным”.
можно использовать линтер с правилом запрещающим any
Линтер — это совет, не гарантия. В Rust типовая корректность — часть модели исполнения. Компилятор не позволит собрать бинарь с несовместимыми типами. В TypeScript — можно просто проигнорировать правило и всё равно собрать проект. Это не баг, это философия “надеяться на дисциплину”.
swc справится быстрее, чем cargo
Безусловно. Только SWC (тоже написан на Rust, кстати) просто трансформирует AST и собирает бандл. Cargo компилирует нативный код, проводит borrow-анализ, линковку и верификацию зависимостей. Сравнивать их по скорости — всё равно что мерить, кто “быстрее компилирует”, clang или webpack.
в JS есть выбор, какой компилятор использовать
И это и плюс, и минус. Свобода выбирать между пятью менеджерами пакетов, четырьмя сборщиками и тремя системами типов — это не богатство, а отсутствие стандарта. Rust выбрал противоположное: единый тулчейн, единая модель версионирования, единая точка входа. Меньше гибкости, больше предсказуемости.
Итого: JS-экосистема полагается на дисциплину и самоконтроль. Rust — на гарантии, встроенные в компилятор. Первое требует внимательности. Второе — просто сборки.
Да, можно и на ассемблере — только тогда пришлось бы ещё SDK для него написать. Rust тут не ради "скорости", а ради вменяемого API, который не упадёт от первого null.
Момент одержимости присутствует, но он приносит пользу...
Да я все эти подходы проходил — генерацию, описания схем, автоклиенты. Это не облегчение, а просто другая форма боли. Иногда проще и надёжнее написать руками, чем потом отлавливать, где генератор решил “догадаться лучше тебя”. Rust тут не про удобство, а про контроль и предсказуемость. Когда ошибка невозможна на уровне типов — это не оптимизация, это выдох.
npm/pnpm — это файловые менеджеры с кэшем. Их можно удалить, подменить, затянуть postinstall-скрипт с майнером. В Cargo это в принципе невозможно: экосистема проектировалась под безопасность и детерминизм, а не “собрать быстрее”.
В TypeScript типы — соглашение между разработчиками и компилятором. В рантайме их просто нет: можно спокойно скастить всё к any, и проект всё равно соберётся. В Rust типы — часть модели исполнения. Компилятор не даст собрать бинарь, если типы не совпадают. Это не подсказка, а жёсткая граница между “работает” и “не существует”.
---
P.S.: Поэтому Rust не “альтернатива React”, а альтернатива категории ошибок, с которыми React-приложения живут.
Будет, просто не в этой статье. Сейчас репозиторий на стадии разработки и тестов, параллельно ищу решение для стыковки WASM с codecov.
Всё, что вы описали про npm, верно на уровне декларации. Но разница в Rust не в политике, а в инвариантах. Cargo не просто “запрещает unpublish”, он делает невозможной ситуацию, когда система сборки оказывается в непредсказуемом состоянии без прямого участия разработчика. npm лишь регламентирует поведение пользователей, Rust исключает его на уровне механики. Это не “новые правила” — это другой класс гарантий.
А сравниваю потому, что большинство сравнивает Rust с JS по скорости, и я хотел показать, что это некорректно именно по сути. Не потому что Rust “медленнее”, а потому что у них разные задачи. Компилятор и транспайлер не живут в одной категории.
О как! Свежее мнение!
От следующей статьи у вас волосы дыбом встанут...
Да, помню, во Владивостоке находился в один из таких периодов и нормально у меня подгорело
В Rust build.rs — единственная точка исполнения, и она не срабатывает при установке зависимости. В npm же postinstall по историческим причинам встроен в модель, и злоумышленники этим реально пользовались (rand-user-agent, eslint-config-prettier, Shai-Hulud). Разница не философская, а архитектурная: в одном случае класс уязвимостей невозможен, в другом — просто “по умолчанию выключен”.
Люблю декомпозицию
Формально — частично. Фактически — нет.
npm-пакеты можно удалять и перезаливать (такие инциденты были). В Cargo это невозможно: опубликованный crate навсегда иммутабелен, даже автор не может его изменить.
npm не гарантирует, что зависимости не будут подменены через зеркала или приватные registry. В Cargo единственный источник — crates.io, хеши пакетов фиксируются в git-индексе.
reproducible build в Cargo встроен в сам инструмент. В npm это просто практика, не enforce’ится инфраструктурой.
Можно подменить хоть
ls, вопрос в вероятности и поверхности атаки.Cargo распространяется только через rustup и официальные дистрибутивы с проверкой подписей.
В экосистеме Node десятки точек входа — node, nvm, n, yarn, pnpm — каждая из которых может стать вектором компрометации.
Rust экосистема изначально проектировалась под минимизацию таких рисков архитектурно, а не “постфактум” настройками.
Да, но сама идея выполнения произвольного кода при установке уже компромисс.
Cargo принципиально не поддерживает никаких установочных скриптов. Это делает целый класс уязвимостей просто невозможным, а не “по умолчанию выключенным”.
Линтер — это совет, не гарантия.
В Rust типовая корректность — часть модели исполнения. Компилятор не позволит собрать бинарь с несовместимыми типами.
В TypeScript — можно просто проигнорировать правило и всё равно собрать проект. Это не баг, это философия “надеяться на дисциплину”.
Безусловно. Только SWC (тоже написан на Rust, кстати) просто трансформирует AST и собирает бандл.
Cargo компилирует нативный код, проводит borrow-анализ, линковку и верификацию зависимостей.
Сравнивать их по скорости — всё равно что мерить, кто “быстрее компилирует”, clang или webpack.
И это и плюс, и минус.
Свобода выбирать между пятью менеджерами пакетов, четырьмя сборщиками и тремя системами типов — это не богатство, а отсутствие стандарта.
Rust выбрал противоположное: единый тулчейн, единая модель версионирования, единая точка входа. Меньше гибкости, больше предсказуемости.
Итого:
JS-экосистема полагается на дисциплину и самоконтроль.
Rust — на гарантии, встроенные в компилятор.
Первое требует внимательности. Второе — просто сборки.
Да прожить бы дай бог пару лет! Куда уж там ПО поддерживать...
Да, можно и на ассемблере — только тогда пришлось бы ещё SDK для него написать. Rust тут не ради "скорости", а ради вменяемого API, который не упадёт от первого null.
Момент одержимости присутствует, но он приносит пользу...
Да я все эти подходы проходил — генерацию, описания схем, автоклиенты. Это не облегчение, а просто другая форма боли. Иногда проще и надёжнее написать руками, чем потом отлавливать, где генератор решил “догадаться лучше тебя”. Rust тут не про удобство, а про контроль и предсказуемость. Когда ошибка невозможна на уровне типов — это не оптимизация, это выдох.
Разница не в языке, а в модели доверия и инвариантах экосистемы.
Cargo — часть компилятора Rust, а не сторонний тулчейн. Он гарантирует:
неизменяемость опубликованных пакетов (immutability policy),
воспроизводимые сборки (Cargo.lock обязателен),
строгое соблюдение семантического версионирования.
npm/pnpm — это файловые менеджеры с кэшем. Их можно удалить, подменить, затянуть postinstall-скрипт с майнером. В Cargo это в принципе невозможно: экосистема проектировалась под безопасность и детерминизм, а не “собрать быстрее”.
В TypeScript типы — соглашение между разработчиками и компилятором. В рантайме их просто нет: можно спокойно скастить всё к
any, и проект всё равно соберётся.В Rust типы — часть модели исполнения. Компилятор не даст собрать бинарь, если типы не совпадают. Это не подсказка, а жёсткая граница между “работает” и “не существует”.
---
P.S.: Поэтому Rust не “альтернатива React”, а альтернатива категории ошибок, с которыми React-приложения живут.