Мне не нравится цитировать самого себя, но:
«Я не уверен, что стоит писать на языке, автор которого считает, что вызывать сторонние программы в компайл-тайме — норма.»
Ну, будем честны — erlang компилируется в байткод, который и вправду интерпретируется. Ни JIT, ни AOT нет.
Впрочем, все знают — erlang выбирают не за raw performance.
> В Go простота этого процесса доведена до предела и занимает секунды: одна команда «go get url-проекта» и одна строчка «import url-проекта» в коде.
Ага. А потом, внезапно, приходит понимание, что pin to master — не лучший способ управления зависимостями, и приходится «прикручивать библиотеки». То есть, фактически, go в этом плане ничего не решает — он просто откладывает решение проблемы.
Если говорить по теме — даже просто отказавшись от го в пользу эрланга, они бы решили проблему stop-the-world gc и сильно облегчили бы себе жизнь в плане работы с памятью.
JSX это очень чистый синтаксический сахар без своей семантики. Он транслируется в JS один-в-один, предельно прямолинейно, костыли и медсестры предоставляются JS.
почему бы просто не взять полноценный язык шаблонов?
Потому что он не нужен.
Он все равно скомпилируется все в тот же JS, но при этом у него будет довольно ущербная семантика с костылями и медсестрами.
Это дополнительные усилия, дополнительные абстракции и дополнительное время на обучение. Зачем?
О, раз вы в теме — а как в Обероне принято разруливать совместимость структур при перезагрузке модуля?
Поясняю — вот есть Эрланг, с тем же самым hot code reload. В новой версии модуля поменялась некая внутренняя структура, функции скмпилированы в рассчете на нее, а в памяти осталась висеть структура предыдущей версии. После перезагрузки вызов функции из новой версии модуля предсказуемо вызовет ошибку. Есть некоторые пути для миграции формата стейта, чтобы избежать этого, но они не сказать, что сильно удобны.
Так вот, как с этим в Обероне?
Я вообще на эрланге пишу и не имею за плечами ни одного заметного проекта на С. Не надо приписывать мне чужих слов и смыслов, порожденных чужими комплексами.
Проблемы были разве что по SSH через putty, но там со всем были проблемы.
«Я не уверен, что стоит писать на языке, автор которого считает, что вызывать сторонние программы в компайл-тайме — норма.»
Впрочем, все знают — erlang выбирают не за raw performance.
Ага. А потом, внезапно, приходит понимание, что pin to master — не лучший способ управления зависимостями, и приходится «прикручивать библиотеки». То есть, фактически, go в этом плане ничего не решает — он просто откладывает решение проблемы.
Если говорить по теме — даже просто отказавшись от го в пользу эрланга, они бы решили проблему stop-the-world gc и сильно облегчили бы себе жизнь в плане работы с памятью.
Потому что он не нужен.
Он все равно скомпилируется все в тот же JS, но при этом у него будет довольно ущербная семантика с костылями и медсестрами.
Это дополнительные усилия, дополнительные абстракции и дополнительное время на обучение. Зачем?
Поясняю — вот есть Эрланг, с тем же самым hot code reload. В новой версии модуля поменялась некая внутренняя структура, функции скмпилированы в рассчете на нее, а в памяти осталась висеть структура предыдущей версии. После перезагрузки вызов функции из новой версии модуля предсказуемо вызовет ошибку. Есть некоторые пути для миграции формата стейта, чтобы избежать этого, но они не сказать, что сильно удобны.
Так вот, как с этим в Обероне?
«си не пробовал, не мужЫк» было сказано не мной — habrahabr.ru/post/258391/#comment_8428597, не надо передергивать.
Я вообще на эрланге пишу и не имею за плечами ни одного заметного проекта на С. Не надо приписывать мне чужих слов и смыслов, порожденных чужими комплексами.
А этих фриков, сбежавших с ЛОРа, наверное, даже за людей не стоит считать.