На данный момент я кажется окончательно вывел для себя правила по выбору языка для той или иной задачи. До этого многие годы писал на C++, C, Python, Java и Objective-C. Перепробовал кучу экзотических языков, таких как OCaml, Erlang, Scala, Lisp, Clojure. Так как я не занимаюсь разработкой UI, Web-сайтов или мобильных приложений, все мои соображения актуальны исключительно для разработки системных приложений, сетевых приложений и бизнес логики. Кроме того, все что я пишу в этой заметке относится к командной разработке приложений в рамках относительно крупной компании, и будет не актуально для команд из 1-2 разработчиков или “домашних” проектов.

Само же правило по выбору оказалось предельно простым: если в силу объективных причин задачу нельзя решить на Python, то необходимо оценить возможность использования Java, но если по объективным причинам не подходит и Java, то необходимо брать C++. Да, именно эти языки и именно в такой последовательности. И да, никакой экзотики типа OCaml, Erlang, Scala, Lisp или даже Rust.

Экзотика

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

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

С учетом совокупности перечисленных факторов, я бы не стал брать никаких не мэйнстрим языков в продакшн среднестатистической компании без какой-то крайне сильной необходимости.

Python

Очень простой язык программирования с отличной стандартной библиотекой и внушительной коллекцией сторонних библиотек на все случае жизни. По большому счету, на Python можно написать все что угодно до тех пор, пока нет жестких требований по памяти, скорости или ограничений на поставки кода в составе продукта. Особенно стоит отметить любовь научного сообщества к этому языку, что привело к появлению SciPy, NumPy, Pandas, NLTK и т.п. библиотек, сопоставимых аналогов которым с большой вероятностью не окажется во многих других языках программирования. При всем богатстве библиотек, управление ими посредству pip очень просто и интуитивно понятно.

Основная реализация языка не позволяет писать многопоточные приложений, что и плюс и минус одновременно, т.к. в любом случае, как правильно писать многопоточные приложения подавляющее большинство программистов не представляет. А тут, нет возможности – нет проблемы, а асинхронные приложения на Python писать совсем не сложно при использовании asyncore и Twisted.

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

Java

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

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

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

Надо признать, что в случае с Java вопрос памяти и производительности довольно философский. С одной стороны на синтетических тестах скорость между тестами на Java и C++ будет различаться в 1.5-2 раза, в реальном приложении разрыв с большой вероятностью будет существенно выше. Но тут сразу стоит вспомнить шутки со стеками вызовов Java со вложенностью в сотню функций и любовью Java разработчиков к абстракциям, фабрикам и моделям. Те же прошивки для принтеров написанные на Java с активным использованием Spring отлично работают на слабых MIPS-ах с 500Мб памяти “на всё”.

C++

Что удивительно, язык программирования кормящий меня уже почти 15 лет я поставил в самый конец списка. К сожалению, на это есть достаточно веские причины, такие как крайне высокие требования к разработчиком, отсутствие систем управления библиотеками аналогичным pip, Maven, высокий порог вхождения новичков и т.п. Безусловно, пункт про требования к разработчиком довольно спорен, но с учетом всеобщего акцента на управляемые среды количество разработчиков понимающих принципы работы с памятью, устройство процессора и другие низкоуровневые вещи стремительно сокращается.

При этом C++ не является панацеей в написании высокопроизводительных приложений. Если сильно увлечься архитектурными вопросами, например начитавшись Александреску на ночь, то можно с легкостью получить приложение, которое по скорости не превосходит “заархитектуренную” Java, при этом собирающееся на порядок медленнее, без сопутствующей инфраструктуры Java и радостей управляемой среды.

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

Честно говоря, в голову практически не приходят причины почему нужно начинать решать новую задачу на C++ за исключением достаточно редких случаев когда миллисекунды или +-100 мегабайт памяти имеют значение. Во всех же остальных случаях лучше взять что-то (Java, Python) более простое в разработке и поддержке.

Маленькие команды и собственные проекты

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

А вот для меленькой компании или тем более для собственного любимого детища уже смело можно брать куда как более экзотические вещи, например заменить Java на Scala или Clojure, активно использовать C++ или даже Rust да и вообще ни в чем себе не отказывать.