История изменений

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

К примеру, если взять Java, то через runtime reflection программа может обращаться к любому классу любой библиотеки. Поэтому сборщик программы, строго говоря, не может выкинуть вообще ничего, т.к. невозможно заранее предсказать, к чему программа может в будущем обратиться. Это пример дизайна языка, который абсолютно не подходит для подобной оптимизации.

Как я себе это вижу.

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

Ты импортировал функцию и использовал её в программе - при сборке скачался ровно один файл со скомпилированной функцией. После чего скачались файлы с функциями, которые этой функцией используются. Причём должны быть сразу использованы constant propagation. Т.е. когда ты вызываешь функцию с константными значениями, текст этой функции анализируется с учётом этих значений и скачиваются только те зависимости, которые достижимы с учётом этих константных значений, а не все подряд. И вот этот пункт про constant propagation очень важен, на самом деле. Т.к. часто библиотеки такие амбальные именно из-за попытки сделать универсальный интерфейс для всех на свете, а конкретному программисту нужно лишь подмножество этого интерфейса.

И, конечно, это всё должно быть эффективно, не 100500 HTTP запросов, а как-то более умно.

Плюс при разработке должен быть простой способ оценивать объём конкретной функции с её зависимостями. Чтобы программист сразу видел, сколько байтов он добавил, импортировав эту функцию.

Т.е. тут и язык должен быть спроектирован так, чтобы мешать нечаянному разрастанию программы, и инструментарий должен быть спроектирован так, чтобы помогать программисту писать компактный код.

Но проблема в том, что это никому не надо. Современный модный молодёжный редактор Zed компилируется в 1.5-гигабайтный бинарник, который после strip уменьшается до 400 MB и это никого особенно не напрягает. Поэтому вряд ли это всё когда-либо случится.

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

К примеру, если взять Java, то через runtime reflection программа может обращаться к любому классу любой библиотеки. Поэтому сборщик программы, строго говоря, не может выкинуть вообще ничего, т.к. невозможно заранее предсказать, к чему программа может в будущем обратиться. Это пример дизайна языка, который абсолютно не подходит для подобной оптимизации.

Как я себе это вижу.

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

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

И, конечно, это всё должно быть эффективно, не 100500 HTTP запросов, а как-то более умно.

Плюс при разработке должен быть простой способ оценивать объём конкретной функции с её зависимостями. Чтобы программист сразу видел, сколько байтов он добавил, импортировав эту функцию.

Т.е. тут и язык должен быть спроектирован так, чтобы мешать нечаянному разрастанию программы, и инструментарий должен быть спроектирован так, чтобы помогать программисту писать компактный код.

Но проблема в том, что это никому не надо. Современный модный молодёжный редактор Zed компилируется в 1.5-гигабайтный бинарник, который после strip уменьшается до 400 MB и это никого особенно не напрягает. Поэтому вряд ли это всё когда-либо случится.

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

К примеру, если взять Java, то через runtime reflection программа может обращаться к любому классу любой библиотеки. Поэтому сборщик программы, строго говоря, не может выкинуть вообще ничего, т.к. невозможно заранее предсказать, к чему программа может в будущем обратиться. Это пример дизайна языка, который абсолютно не подходит для подобной оптимизации.