С осени прошлого года в поле зрения попадает уже третья попытка создать новый язык программирования, предназначенный для компиляции в нативный код. Первым был Zimbu от Брама Мулинара (разработчика ViM-а), затем Go от Google, а вот теперь Rust от Mozilla (спасибо ув.тов.Курилке за наводку).
Пока познакомиться с Rust-ом не удалось. Мельком глянул на Language FAQ и бегло ознакомился с основными чертами языка в 65-страничной спецификации языка. И, честно говоря, не уверен в том, что руки дойдут до более тщательного его изучения – разве что после его официального релиза (хотя бы в виде стабильной Beta-версии или Release Candidate).
Как водится, язык мультипарадигменный. Со сборкой мусора, с элементами функционального программирования (включая алгебраические типы и паттерн-матчинг), с каким-то подобием ОО и пр., даже с возможностью писать собственные плагины для компилятора и тем самым расширять синтаксис языка. По современной традиции в язык встроена поддержка агентного программирования и каналов для обмена данными между параллельно работающими сущностями (тасками).
Из описания языка меня зацепило вот что – в Rust нет конструкции catch. Т.е. если кто-то внутри таска выбросил сигнал (я так понял, что это аналог исключения), то все – весь таск убивается. А другие таски могут разве что определить, что он умер.
Неоднозначное, на мой взгляд, решение. Ведь это означает, что какие-то операции (тот же ввод-вывод) нужно будет делать на кодах возврата. Открыли файл – проверили код возврата, записали N байт, опять проверили. Не нравится мне это. Впрочем, есть шансы, что я чего-то недопонял.
Да, еще одна мысль меня терзает. Вот в Go сделали каналы. В Rust сделали. А я думаю, что такие вещи на уровне универсального языка – не есть правильно и хорошо. Каналы и агенты должны реализовываться библиотеками. Тогда можно будет создавать разнообразные инструменты, как универсальные, так и заточенные под конкретную прикладную область. Скажем есть в ACE свой механизм Reactor-ов и Proactor-ов, а в Boost-е есть asio. А у нас в SObjectizer есть агенты, которые прячут сам факт использования Reactor-ов от программиста. А есть еще и libevent. Можно выбирать.
Конечно, свобода выбора имеет и недостатки. Но вот взглянем на Erlang – там механизм взаимодействия процессов является частью языка. Ну и? Где текстовые редакторы, написанные на Erlang? Где какой-нибудь grep на Erlang-е? Правильно, не под то Erlang со своими процессами заточен. Вот так и Go с Rust-ом можно заточить по какой-нибудь определенный server side и ничего на них больше не напишешь. В отличии от C++ или Java.
Так что не торкнул меня сам факт наличия Rust-а. Ну разрабатывают его, ну и пусть разрабатывают. Будем посмотреть.
4 комментария:
Думается мне, erlang не популярен в обычном софтостроении тем, что заточен немного не для того. Там много мест, где просто возникает ступор (по крайней мере у меня). Например элементарно запустить программу. Это вам не питончик, где скормил py файл интерпретатору, он хоп и запустился. Нееет, в erlang без гугления и вдумчивого чтения мануалов даже программу не запустить. И так там везде. Вот надо элементарно дату/время распарсить, так нет такой фичи в стандартной либе. Про странность библиотеки io я вообще молчу. И вот так вот постепенно создается ощущение, что erlang создан киборгами для киборгов и людские программы на нем лучше не писать...
Ну, вот здесь вот человек описывает совсем другие впечатления: http://www.slideshare.net/j2a/ss-4625844
Хотя, на мой взгляд, по читабельности у Perl-а выиграет любой нормальный язык. Было бы интересно сравнивать не Perl+C с Erlang, а какой-нибудь Python+Java с Erlang-ом.
Имхо, Erlang создавался для вполне конкретных вещей. То, что его сейчас пытаются успешно применять в Web-е -- это показатель гораздо большего запаса прочности у языка, чем можно было предполагать. Но все равно Erlang будет, я думаю, нишевым языком.
Вот в Go сделали каналы. В Rust сделали. А я думаю, что такие вещи на уровне универсального языка – не есть правильно и хорошо. Каналы и агенты должны реализовываться библиотеками.
однозначно да
Если не ошибаюсь (а статье про Rust это вроде подтверждают) в go есть убийственный момент -- хотя каналы полиморфны, язык не позволяет создавать самим что-то аналогично полиморфное -- и после этого его кто-то серьезно воспринимает??? я в шоке.
и критика других языков в pdf-презенташке Go на 80% нечестна -- он не показал, как это же делается у него (или почему у него не нужно)
______________________
насчет той задачки с собеседования: я много писал, но так видимо и не довел свою мысль: меня интересует разбор и критика именно проектного решения, а не его конкретной реализации, (а реализацию как раз и лень делать); но при наличии багов критика именно проектного решения будет затруднена, так что видимо мне придется баги все же выгрести;
чтоб меня вдохновить, можно выложить куда-нить архивчик с тестами :-)
Если доделают очень неплохой язык может получится. По моему гораздо симпатичней двух предыдущих. Да и ниша ближе к C++ и D.
Отправить комментарий