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

Тогда я не совсем понимаю, о чём речь. Иногда приходится писать на js. На js можно написать плохо (на самом деле на любом языке можно написать плохо, просто на js легче). Интероп эльма проверяет, что плохо написанный внешний код не повлияет на базовые предположения рантайма и ошибка не накопится. То есть внутри эльма всё останется предсказуемо на каждой конкретной итерации.

Альтернатива: раз js может что-то сломать, то и в нашем языке мы стараться минимизировать потери не будем. Как по мне, в таком случае будешь точно так же как и в js постоянно сидеть на пороховой бочке.

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

Есть, если ты правильно указал путь к elm-make

у меня на этот счёт ни каких иллюзий нет. js как он есть со всеми его ужасами - true backend для компилятора elm.  Как то наивно ожидать от него 100%ных гарантий.  Впрочем, я вижу у нас действительн какое-то взаимонедопнимание. Предлагаю вернуться к этому разговору позже с бОльшей конкретикой. Я как нибудь напишу здесь код и псведо код на elm, тогда может будет более понятно о чём я выше говорил

Вот это разговор! Давай так. Тем более, что интероп - одна из основных тем этого чата)

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

Добрый день, коллеги. У нас в компании скоро может понадобиться фронт-энд разработчик на новый проект, написать админку для одного сервиса. Работать будет в паре с двумя scala-разрабами на бэкенде. Появилась идея создать вакансию Elm-разработчика, попробовать его в реальном проекте и сделать выводы, насколько этот опыт применим для других наших приложений. Как считаете, имеет смысл или язык сыроват пока? Scala.js пока не рассматриваем

Да, это тема

Для админки однозначно пробуйте. Я бы только предложил сразу попробовать решить несколько задач из разных областей: общение с сервером, сложные ui компоненты, рендеринг больших списков. Так на раннем этапе сможете понять ограничения и преимущества языка.

Тут еще конечно вопрос найдется ли сам разработчик)

Здравствуйте! Знание elm конечно в плюс любому frontend-разработчику и продакшен код на нём имееет право на жизнь. Но я бы не рискнул писать приложение на одном лишь elm, это всё же маргинальный ЯП, для энтерпрайза имхо требуется технологии с бОльшей поддержкой вендоров. Самый жизнеспособный, как мне кажется, стек технологий - TypeScript + react + mobx, и маленькие модули на elm  в виде react компонент, вызываемых изTypeScript

Для F# есть более зрелое решение - Websharper Ui Next, интегрированное с прекрасным ajax фреймворком.

Почему же нет. Кстати на хабре есть вакансия elm

Спасибо за ответ! Ну хотелось конечно именно писать целиком чтобы получить все плюшки, отсутствие рантайм ошибок, таймтревел, патерн матчинг. Сейчас как раз используем везде TS с ангуляром, реактом и мобиксом.

И не понятно какие именно части приложения писать на elm

Есть достаточно много материалов о встраивании elm приложений как отдельных компонентов. Можно провести эксперимент и небольшую часть написать на нём

нашел только такую на ХХ https://hh.ru/vacancy/22740892

опыт elm разработки 2 года)