Dev Easy Notes

{3/3} Базу прошли, теперь поговорим про kotlin и gradle.

Важно разделять: есть компилятор языка и есть система сборки, в которой компиляция это лишь одна из фичей. Исходя из прошлых постов я думаю очевидно, что компилятор kotlin всегда будет на kotlin, и в целом это хорошо. JetBrains не настолько психи, чтобы создавать зависимость на другую компанию или технологический стек.

Теперь про систему сборки. В обязанности сборщика помимо компиляции кода входит:
👉 Управление зависимостями
👉 Тестирование
👉 Упаковка приложения
👉 Работа с кешами
👉 И еще дохера всего

Нужно ли для этих задач использовать тот же язык, на котором мы пишем код или на котором написан компилятор? Однозначно нельзя ответить на этот вопрос.

Говоря откровенно, когда я садился писать этот пост, мне казалось что я сейчас быстро найду кучу примеров сборщиков, написанных на других языках. Иии оказалось их почти нет, только один Bazel написан на java и может компилировать C++.

Если пройтись по всем 3-м пунктам которые я привел для компилятора вот что получим:
👉 Если мы не можем написать сборщик на том же языке, то нужно ли вообще такой язык использовать?
👉 Если же другой язык перестанут поддерживать, нам придется переписывать систему сборки на другой, а это затраты
👉 Корпоративный аспект в система сборки кстати не работает, почти всегда сборщики делают сторонние компании, тут конечно минус

Давайте на примере. Допустим у нас есть язык Java и система сборки для нее например на C++ . Кого ты хочешь в команду для разработки сборщика? Человека который всю жизнь писал на Java, знает все ее тонкости и проблемы или человека на C++ который всю жизнь решал другие проблемы?

Как бы мне не хотелось, чтобы гребанный Gradle был написан на шустром Rust, в реальном мире это не сработает. Несмотря на то, что объективно все системы сборки должны быть написаны на низкоуровневых языках, все равно работает идеология. Если тулза для языка не написана на нем самом, на язык смотрят с опасением.

Решение команды TypeScript это интересный прецидент: практическая производительность становится важнее вот этих опасений. Если у них все выгорит, то кто знает, возможно мы когда-нибудь получим аналог Gradle на Rust.

www.tgoop.com/dev_easy_notes/394

2.2K viewsMar 24 at 09:32

{3/3} Базу прошли, теперь поговорим про kotlin и gradle.

Важно разделять: есть компилятор языка и есть система сборки, в которой компиляция это лишь одна из фичей. Исходя из прошлых постов я думаю очевидно, что компилятор kotlin всегда будет на kotlin, и в целом это хорошо. JetBrains не настолько психи, чтобы создавать зависимость на другую компанию или технологический стек.

Теперь про систему сборки. В обязанности сборщика помимо компиляции кода входит:
👉 Управление зависимостями
👉 Тестирование
👉 Упаковка приложения
👉 Работа с кешами
👉 И еще дохера всего

Нужно ли для этих задач использовать тот же язык, на котором мы пишем код или на котором написан компилятор? Однозначно нельзя ответить на этот вопрос.

Говоря откровенно, когда я садился писать этот пост, мне казалось что я сейчас быстро найду кучу примеров сборщиков, написанных на других языках. Иии оказалось их почти нет, только один Bazel написан на java и может компилировать C++.

Если пройтись по всем 3-м пунктам которые я привел для компилятора вот что получим:
👉 Если мы не можем написать сборщик на том же языке, то нужно ли вообще такой язык использовать?
👉 Если же другой язык перестанут поддерживать, нам придется переписывать систему сборки на другой, а это затраты
👉 Корпоративный аспект в система сборки кстати не работает, почти всегда сборщики делают сторонние компании, тут конечно минус

Давайте на примере. Допустим у нас есть язык Java и система сборки для нее например на C++ . Кого ты хочешь в команду для разработки сборщика? Человека который всю жизнь писал на Java, знает все ее тонкости и проблемы или человека на C++ который всю жизнь решал другие проблемы?

Как бы мне не хотелось, чтобы гребанный Gradle был написан на шустром Rust, в реальном мире это не сработает. Несмотря на то, что объективно все системы сборки должны быть написаны на низкоуровневых языках, все равно работает идеология. Если тулза для языка не написана на нем самом, на язык смотрят с опасением.

Решение команды TypeScript это интересный прецидент: практическая производительность становится важнее вот этих опасений. Если у них все выгорит, то кто знает, возможно мы когда-нибудь получим аналог Gradle на Rust.

BY Dev Easy Notes