Давайте представим нереалистичный сценарий, где вы выбираете язык программирования для проекта, который в перспективе станет очень большим. Допустим, это будет набор сервисов в монорепозитории, над которыми работает более 100 человек. Чтобы сделать этот сценарий ещё менее реалистичным, предположим, что вы игнорируете типичные ограничения, например, не учитываете, сможете ли использовать сборщик мусора, и впишется ли поставленная задача в конкретный стек технологий.
Пусть это будет мысленный эксперимент. Подыграйте мне. Если вы читали мою прошлую статью (англ.), то должны правильно предположить, что я бы предпочёл экспрессивный язык, ориентированный на профессионалов. Так и есть. Но в гибком языке программирования есть серьёзная проблема с масштабированием – слишком много стилей оформления кода и способов его написания. В итоге просто не обойтись без руководств по стилю, которые помогут сориентироваться в правильной реализации.
Какое подмножество C++ или Kotlin вы используете? Что вы предпочтёте: project.toml или requirements.txt? Теперь у вашего языка есть возможность поэтапной типизации с помощью аннотаций типов. Хотите ей воспользоваться? Как вы реализуете конкурентность: с помощью многопоточности, Tokio или std::async?
Чем более экспрессивный язык, тем сложнее всё становится. И здесь на сцену выходит Go. И речь не только о gofmt, но и о его стандартной библиотеке и согласованности. В Kotlin вам приходится гадать, что лучше использовать для ошибок: исключения или объекты Result? В случае же Go вам всё ясно – ищем err. Да, это многословно, но зато предсказуемо.
Экспрессивные языки прекрасны, но часто создают путаницу. Вы можете использовать богатый и комплексный язык, поддерживающий миллион способов реализации одного и того же. Именно это я хочу вам показать. Как же сохранить всю эту мощь, но уменьшить беспорядок? Как избежать возникновения 500 поддиалектов? Но прежде, чем переходить к решениям, обсудим Scala.Читать полностью »