Олег Фатеев признается в подзамочном посте, что становится фанатом Golang. Свою любовь он объясняет горутинами и быстрой сборкой. В следующем же посте он не совсем справедливо утверждает, что в РФ не пишут новые языки программирования (формально контрипримером тут Kotlin, но в главном-то он прав), и в камментах к этому посту Игорь Щекалев выражает сомнение в необходимости создания новых языков сейчас. Контрпримером тут я сразу же привел Swift и Golang, ведь "раз звезды зажигают, это кому нибудь нужно", на что Игорь возразил следующим образом:
[Golang] мне показался унылой смесью Erlang (из которого целиком тянута концепция каналов и все связанное с ней) с С#, откуда взято все остальное. Единственные плюсы (для кого-то) - компактный рантайм и портабильность.
Не могу согласиться с Игорем.
Языки создавать нужно, потому что сильно изменяется класс задач, и доступная техника. Навскидку, я выделю такие области применения, для которых требуются новые языки:
- Языки, компилирующие в JS. Например, Dart, Elm, Flow, TypeScript (см. полный список).
- Компиляторы в байт-код популярных (и не очень) VM - JVM и Beam (Elixir). Просто порой VM получается лучше, чем изначальный язык. Тут всегда упоминают LLVM.
- Высокоуровневые компилируемые языки со встроенным управлением ресурсами и параллельностью (Golang, Rust, Swift). Автоматическое управление, потому что ну пора бы уже. А параллельность, потому что везде несколько ядер. Тут интересно вспомнить грандиозный прокол Хavier Leroy в оценке доступности многоядерных систем, из-за чего Ocaml (в т.ч. и из-за чего) сполз в пучину безвестности, составив компанию блестящим теоретикам от программирования, разрабатывающим Haskell (язык, в основном используемый для разработки языка Haskell).
Наверняка есть и еще перспективные ниши (IoT, роботы, новое железо?), но я не припомню сходу.
И раз заговорили о Golang, то cкажу, что он абсолютно отличается от Erlang. Дело не в компиляции/интерпретации, а в базовой модели предоставляемой программисту, взятой за основу.
При реализации языков и фреймворков для параллелизма выбирают одну из двух моделей - Actor Model или Communicating Sequential Processes. Они дуальны друг к другу, и по ряду причин, нельзя реализовать сразу обе.
В целом, любая модель реализует следующее - в системе параллельно и независимо друг от друга исполняется несколько объектов (потоки, lwt, процессы, goroutines, и т.п.). Некоторые из них иногда обмениваются данным по каналам связи. А вот дальше начинаются различия.
Actor Model, это система, в которой объекты исполнения имеют идентификаторы, а вот каналы скрыты от разработчика. Ее еще называют "почтовая система", т.к. примерно так работает почта. Я, чтобы послать письмо, пишу на нем идентификатор получателя (адрес и имя), бросаю в ящик и иду заниматься своими делами. Маршрутизацией письма занимается внешняя служба (Почта России), и все происходит асинхронно. Типичные примеры, это email, Erlang/elixir, приложения, обменивающиеся сигналами.
CSP, это система с безымянными объектами, но с именованными каналами. Ее можно назвать "телефонной системой", т.к. для звонка нам нужно знать номер канала (телефон), а вот кто снимет трубку - нам неизвестно. Система синхронная - мы сами набираем номер, общаемся не отвлекаясь на другие дела ни с той, ни с другой стороны, кладем трубку сами, и сами же обрабатываем ситуацию "недозвона" (перезваниваем позже, не звоним больше, или звоним куда-то еще). Внешней службы не нужно - работали бы лишь каналы. Система получается синхронная. Из известных примеров, это Golang, программы, соединенные пайпами.
При проектировании языка или фреймворка, реализующего Actor Model, придется писать очень непростой и постоянно работающий супервизор и маршрутизатор сообщений. Опять же, т.к. синхронизация внешняя, то легче реализовать в готовом фреймворке Real-Time или near Real-Time систему. Легко расправиться с зависшим клиентом ("let it fail" в Erlang) - у них есть имена. Однако, есть и проблема. Т.к. синхронизация внешняя, то очень непросто в систему впихнуть вызов FFI. Если просто вызвать некую стороннюю функцию в объекте исполнения, то вызов может не уложиться в минимальный квант исполнения, выделенный этому процессу. Это, в свою очередь может вызвать лавинообразно нарастающую проблему, известную эрланг-разработчикам, как "Scheduler Collapse". Частично эту проблему удалось решить, но, но, но...
А вот с CSP все совершенно иначе. Супервизор и маршрутизатор будут чрезвычайно просты, т.к. система считай, что самосинхронизируется (просты, конечно, в смысле простоты на уровне разработки языка или сложного фреймворка). Та же goroutine, это такой хитро замаскированный mutex, т.е. один из базовых объектов синхронизации. В систему чрезвычайно легко добавить вызов FFI. К сожалению, есть и обратная сторона. Если заблокируется объект исполнения (например на блокирующем системном вызове), то убить его не получится - у разработчика просто нет его идентификатора, а из канала он ничего не читает. В случае golang предусмотрена специальная процедура - во-1 там горутины крайне легкие (4 килобайта, если не ошибаюсь), а во-2, если одна из них заблокирует системный поток, то планировщик эвакуирует все горутины на соседние потоки. ...Пока и их не заблокирует.
Получается, и Erlang, и Golang, это абсолютно разные языки, и компилируемой реализации Erlang с богатством библиотек из Golang, до сих пор так и нет. Ждем.
имхо, сейчас только начали реализовать языки для многозадачности\параллельности. Будущее за массовыми вычислениями, число ядер на душу стремительно выросло и всю эту вычислительную мощь надо как то использовать и не сойти при этом с ума.
ps: Забыл ещё добавить про языки для Data Mining.