Иерархия языков веб-программирования

Когда я думаю о языках программирования, используемых для Интернета, я склонен автоматически группировать их в один из нескольких «уровней», иерархию языков. Здесь я расскажу о том, что куда идет и почему.

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

Я упоминаю об этом главным образом потому, что люди очень ценят эти вещи. Говоря об этом, это также не просто «языки» в самом строгом смысле, поскольку включает в себя такие навыки, как HTML.

Ярусы

Основополагающая технология

Это базовое ожидание веб-разработчика, самое начальное знание. Примерами могут быть CSS, HTML и очень простой JavaScript. Это не значит, что эти вещи бесценны, и даже не сказать, что они не сложны. Если подумать, это, по сути, все причудливые другие языки, на которые в конечном итоге выводятся данные. Но как начинающий разработчик это не те вещи, которые вы начали бы изучать. Это то, что вы уже должны знать. Шансы получить должность профессионального джуниора без хотя бы некоторого знакомства с этими инструментами исчезающе малы.

Основные языки

Это языки базового уровня. Они являются критически важными частями мира разработки. Эти языки сегодня составляют подавляющее большинство технологических стеков в Интернете.

В эту категорию входят все обычные основы разработки: .NET, PHP, Python, Ruby/Rails, NodeJS, Java. Во внешнем интерфейсе, вероятно, было бы разумно добавить «современный JavaScript» и такие фреймворки, как React.

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

Дополнительные языки

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

Примерами дополнительных языков являются Elixir, Go, Rust, Kotlin или Scala. С большей нерешительностью я бы поставил Elm для интерфейса.

Эти языки имеют ряд ключевых сходств. Они без исключения обладают чрезвычайно высокой производительностью, часто в 10 раз выше, чем у основных языков — по крайней мере, в тестах. Кроме того, все, кроме одного (Go), являются языками функционального программирования, что делает их совершенно другим мышлением для программирования. Они очень дисциплинированы, часто ставя обработку ошибок, надежность и тестируемость задолго до блестящих функций. или опыт разработки.

Языки домена

Есть ряд других языков, которые могут время от времени появляться, потому что они используются в определенной сфере бизнеса. Примерами являются Solidity или Vyper для разработки блокчейна или R для статистического анализа.

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

Что все это значит?

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

Второстепенные языки могут быть вредны для бизнеса

Этим языкам, как правило, крайне не хватает инструментов, поддержки IDE, репозиториев с глубокими знаниями и т. д. В них еще больше не хватает персонала. Попытка нанять талантливых разработчиков для работы над проектами, написанными даже на распространенных языках, может оказаться сложной задачей, переход на менее распространенные и малоизвестные языки резко сокращает пул разработчиков. И по мере сокращения кадрового резерва затраты растут. Возврат инвестиций может быть очень грубым.

Дополнительные языки могут быть плохими для разработчиков

Может показаться приятным плавать в этом меньшем бассейне, но факт остается фактом: вы не получите прибыльной работы, если на самом деле есть рабочие места. Поиск Golang в моем городе показывает только пять ролей. Поиск по Elixir показал только одно совпадение — и это было ложное срабатывание на марку кофе.

Для сравнения, в PHP и Python указано более 70 ролей, а в Node. В списке было около 140 для .NET. Кстати, исторически PHP и .NET были ближе, чем Python, а Python ниже, поэтому я удивлен, увидев такую ​​разницу.

Различия в производительности могут быть незначительными

Даже учитывая огромные (часто на порядок) преимущества в производительности для этих мощных дополнительных языков, реальная разница может быть не так уж велика. Фактическая производительность приложения не помогает таким вещам, как медленные запросы к базе данных или постоянный доступ к IO, и обычно это более важный фактор, чем язык. Там, где само приложение является узким местом, производительность обычно можно повысить с меньшими затратами за счет большего количества оборудования или базового кэширования. Переписывание приложения на другом языке редко является хорошим выбором, и в лучшем случае кандидатом на переписывание может быть конкретное узкое место.

Тематические исследования не являются репрезентативными

Существует бесчисленное множество примеров перехода крупных компаний с основного на дополнительный язык. Популярным является то, что Twitter начинался как приложение Ruby on Rails, и в итоге его пришлось переписать сначала на Java, а затем на Scala. Вывод часто заключается в том, что Rails по своей природе слишком медленный, и вам лучше начать с более быстрой платформы, такой как Scala. Во-первых, это редукционизм, многое в Твиттере по-прежнему RoR, но, в частности, сам вывод ошибочен. Ваше приложение — это не Twitter. Готов поспорить, что ваше приложение не имеет почти таких же требований к производительности, как Twitter. И даже если это в конечном итоге произойдет, давайте будем честными: Rails был достаточно хорош, чтобы позволить им стать Twitter. Позаботьтесь о запуске, прежде чем беспокоиться о масштабировании.

Эти категории не являются фиксированными или жесткими

Это то, как я вижу вещи, и это не обязательно работает одинаково со всеми языками. Как конкретное полуисключение, Go/Golang, вероятно, теперь является более точным гибридом Core-Secondary. Компании нередко переходят на Go с PHP. Даже место, где я недавно работал в качестве пользовательского магазина PHP, теперь работает на 100%, хотя, если опыт является ориентиром, я готов поспорить на деньги, что это по плохим причинам. Jetbrains делает для этого специальную IDE. Через несколько лет недостатки Go вполне могут быть смягчены. Включая как пул вакансий для разработчиков, так и пул разработчиков для вакансий.

Какой здесь вывод?

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

Если вы хорошо зарекомендовавший себя разработчик, использующий что-то вроде PHP или Ruby, возможно, пришло время взглянуть на другие варианты и добавить еще одну струну в свой лук? Большинство языков имеют общие «апгрейды», которые люди регулярно используют. Магазины PHP и Python обычно переходят на Go. Разработчики Ruby/Rails часто используют Elixir.

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