Часто говорят, что язык программирования нужно подбирать под задачу. Мол, не нужно брать C++ для того, что легко делается на Python. И не нужно брать Python там, где потребуется что-то более быстрое и менее ресурсоемкое.
Недавно узнал о Radicle -- это что-то вроде GitLab и Gitea, т.е. инструмент для совместной работы над программным кодом.
Radicle написан на Rust-е.
Не на Python-е. Не на Ruby. Не на Node.js. Не на Java или C#. Не на Go. А на Rust-е.
Как по мне, так это почти тоже самое, что и GitLab, написанный на C++. С поправкой на то, что, во-первых, Rust -- это можно и молодежно. И, во-вторых, для программирования Web-приложений все-таки Rust побезопаснее C++ будет. Но, в общем-то, тоже самое, вид в профиль.
Посему лично я в недоумении и сам бы для проекта, подобного Radicle, точно бы не стал брать C++ или Rust. Как по мне, так здесь достаточно языка со сборкой мусора: Java, Kotlin, C#, возможно даже Go (простите, динамика в лице Python/Ruby/JavaScript идет лесом, т.к. не из тех мазохистов, которые делают что-то большое на динамически-типизированных языках).
А вот брать нативный язык без GC с претензией на околосистемность... Зачем?
Собственно, непонимание и привело к появлению этого поста. Надеюсь, в комментариях мне напихают в панамку и объяснят насколько я дебил и отстал от современных трендов. Ибо я реально не понимаю, почему в 2020-х нужно отказываться от всего, что накопилось в мире безопасных языков с GC и трахать себе мозг Rust-ом в задаче, где не нужна ни супер-пупер производительность, ни супер-пупер экономия ресурсов, ни тотальный контроль за происходящим.
Если не лень, то напишите в комментариях, плиз, какой бы вы язык программирования предпочли для реализации проекта по типу Radicle/GitLab/Gitea. Я бы лично выбирал бы между C#, Kotlin и Go (хотя не на одном из них не программировал), но точно бы не C++ и не Rust.
14 комментариев:
GitHub написан на ruby. Точнее на Ruby on Rails. ИМХО для таких задач он подходит очень хорошо.
@OAV: насколько я помню, GitLab так же был написан на Ruby. Но я слышал жалобы, что GitLab много жрет памяти при развертывании на своем сервере. Уверен, что из-за Ruby, т.к. Ruby был не самым экономичным языком в этом плане.
Возможно тут надо сравнивать стоимость аренды сервера в облаке с зарплатой коллектива разработчиков на стеке java? Затрудняюсь с оценкой сколько надо человек на проект типа GitHub.
Люди далеко не так рациональны как принято думать. Язык программирования выбирается тот, который принят у "секты", в которую ты попал ;)
@OAV:
> Возможно тут надо сравнивать стоимость аренды сервера в облаке с зарплатой коллектива разработчиков на стеке java?
Скорее тут нужно сравнивать стоимость коллектива разработчиков на Java и коллектива разработчиков на Rust. А так же риски, связанные с распадом подобных коллективов и простоту найма замены выбывающим бойцам.
> и трахать себе мозг Rust-ом
Вы преувеличивает сложность Rust'а. Он сложен только для начинающих, кривая обучения очень крутая в начале, а дальше она довольно пологая. То есть у Rust есть серьёзный входной барьер, но для тех, кто его прошёл (месяцок хорошо попрограммировал на нём), дальше уже проблем никаких нет. Писать на Rust не сложнее, чем на Java, а в ряде случаев даже проще (например, многопоточка).
На Rust примерно с одинаковой эффективностью можно писать широкий спектр приложений: утилиты, встраиваемые программы, десктопные приложения, бэкэнды и несколько менее эффективно фронтэнды веб-приложений. Это хороший универсальный язык программирования с очень развитой и чётко работающей модульностью, поощряющий переиспользование готового кода. Поэтому если проект начинает команда, имеющая опыт в Rust, то почему нет? То, что они эффективнее будут писать на Kotlin или Java - это миф, а вообще, они даже могут и не знать эти языки.
Мой опыт, помимо прочего - 6 лет разработки на Java и уже 6 лет на Rust.
@XX
> Писать на Rust не сложнее, чем на Java,
Если говорить про ту Java, которую я помню, то даже на C++ местами писать было сильно проще, чем на Java. Насколько я понимаю, реальный прогресс в эволюции Java как языка ускорился только в последние лет 5.
Зачем для веб-приложения нанимать команду с опытом на Rust? Тут главное - скорость разработки, быстрее выйти на рынок. А скорость работы приложения и потребление ресурсов дело десятое. Приложение, если оно вообще выстрелит, можно оптимизировать потом. Рельсы и руби тут вне конкуренции.
@OAV:
Не, почему не Ruby и не Python для меня лично понятно. Аналоги на таких языках есть и накладные расходы, которые из этого получаются, так же известны. Обойти существующие решения за счет какого-то уникального функционала можно, но сложно.
А так можно хотя бы оказаться вне конкуренции по такому критерию, как ресурсоемкость. Грубо говоря, решение на Go будет априори потреблять меньше памяти, а работать быстрее, чем на Ruby. Это вполне себе фишка.
А мне выбор раста показался оправданным. Radicle совсем не прямой аналог Gitea. В первую очередь это peer-to-peer сеть со своей децентрализованной системой идентификации (аля блокчейн) и кучей криптографии. Судя по истории, у них вначале даже протокол был свой, потом перешли на git. Web-client добавлен только через 4 года, и, скорее всего, написан на расте просто потому, что на нем же основная часть.
@Vit:
> А мне выбор раста показался оправданным.
А почему? Как-то из вашего комментария, к сожалению, не очевидно какие преимущества есть у Rust-а в сравнении с другими компилируемыми языкам (та же криптография доступна и для .NET, и для JVM, и для Go, да и сколько там криптографии нужно кроме условного SHA и TLS).
Насчет ресурсоемкости. А вы уверены, что вы получите такое число пользователей, что упретесь в ограничение языка? Это отдельная задача и смысла в преждевременной оптимизации я не вижу. RoR обеспечивает примерно 15-20 krps на одном сервере. Если не пытаться написать убийцу youtube, этого вполне хватает. С ростом нагрузки можно просто добавлять железо.
Ради интереса сравнил. Новый DELL R750 с 2 Хеon (32 ядра) и террабайтом озу, в РФ стоит 1.3 млн рублей. Это примерно заплата 3 программистов за месяц.
@OAV:
> Насчет ресурсоемкости. А вы уверены, что вы получите такое число пользователей, что упретесь в ограничение языка?
Тут работает другая логика. Вот есть, например, продукт X, который в своих системных требованиях декларирует +2GiB RAM на каждого пользователя. И есть продукт Y, который декларирует +200MiB RAM на пользователя.
Если в продуктах X и Y заинтересована маленькая контора с 10 разработчиками, то разницы нет. Если средняя, где уже 100 разработчиков, то разница начинает быть заметной. Если крупная, где от 1000 разработчиков, то разница обязательно будет очень серьезным образом оценена и принята во внимание.
Отправить комментарий