AP
А! Имеется в виду "без React"?
Size: a a a
2017 October 26
NK
имеется в виду без JS
NK
😌
AP
ClJS не пытается быть самостоятельным языком. Это hosted язык, как и Clojure - оба испольуют преимущества платформы, в т.ч. и через interop
NK
ну
AP
Вот переделать с React на preact имело бы смысл, т.к. вся работа со стейтом всё равно на cljs пишется, а от реакта используется только VDOM
NK
видимо такого нету
AP
А ещё авторы Quiecsent, Reagent, Om не пытаются уйти от React во многом потому, что для оного уже есть куча компонент и прочих библиотек
NK
хороший аргумент
MP
И сравнивать сообщество Эльма и Го вполне правомочно: и там и тут куча народу, который еле-еле разбирается в теме, уже но устал от предыдущего языка (Python/Ruby в случае Го и JS в случае Elm), и которому продали идею "тут у нас ничего знать не надо, у нас всё просто, все сложные решения за вас уже приняли". И "пипл хавает". Но коль скоро пиар кампания была довольно агрессивной - буквально на каждом шагу кричат "у нас всё просто, а тем у кого сложно - плохо" - неудивительно, что любая критика воспринимается в штыки.
Меж тем любой, кто до Elm осилил хотя бы SML, или ту же Scala - но именно осилил, а не прикоснулся - понимает ограничения Elm, которые действительно мешают писать что-то достаточно сложное эффективно. И проблема тут в том, что нет инструментов повышения уровня абстракции, а ведь это главный рычаг для управления сложностью! Отобрать его - всё равно что крылья подрезать! И все, кто увидел Эльм после нормальных языков в его нише, считают Эльм объективно бедным языком. Это факт
Меж тем любой, кто до Elm осилил хотя бы SML, или ту же Scala - но именно осилил, а не прикоснулся - понимает ограничения Elm, которые действительно мешают писать что-то достаточно сложное эффективно. И проблема тут в том, что нет инструментов повышения уровня абстракции, а ведь это главный рычаг для управления сложностью! Отобрать его - всё равно что крылья подрезать! И все, кто увидел Эльм после нормальных языков в его нише, считают Эльм объективно бедным языком. Это факт
Ну я пришел в Elm из Haskell и Scala, js и dom практически не зная, на html дедал только статику и шаблоны, которые потом отдавал верстальщикам. Да, классов типов очень не хватает. В HKT особой потребности пока не испытывал, но хотел бы иметь под рукой, как парашют, если вдруг понадобится. Не хватает макросов, например для генерации сборщика/разборщика json. Жаль что убрали сигналы, они были красивые. Но все эти недостататки для меня компенсируются развитой инфраструктурой и возможностью удобно писать UI не зная js. Пытаюсь смотреть на PureScript, но у меня сложилось впечатление, что от js и dom он не спасает. Правда, появилось желание попробовать его на серверной строне.
AP
PureScript - не спасает. На серверной стороне я бы использовать не стал, т.к. Node - не самый хороший рантайм, мягко говоря, а PyErl и Pure11ещё не готовы
AP
Elm избавляет от современного фронтендо-тулчейна и это огромный плюс! Я лично поэтому и возвращаюсь к Эльму периодически - тут хотя бы webpack настраивать не нужно :) Только вот тенденция в сторону "нативных модулей", интеграции с вебпаком и проч. заставляет думать, что и времена спокойной работы с elm-packages без npm/bower/gulp/whatever проходят
MP
PureScript - не спасает. На серверной стороне я бы использовать не стал, т.к. Node - не самый хороший рантайм, мягко говоря, а PyErl и Pure11ещё не готовы
Мой опыт показывает, что на AWS Lambda лучшее решение - это node. Пока я использую Scala, но время обработки запроса иногда подскакивает до 20 секунд, при среднем 0.5 секунд. Для node эти неожиданные задержки сокращаются до 6 секунд. Питон и F# занимают промежуточное место.
AP
В данном конкретном случае скорость раскочегаривания рантайма может иметь значение, согласен. Но в остальном Node - никак не самый быстрый и надёжный вариант.
AP
Scala работает поверх JVM c JIT, а JIT надо прогревать, чтобы получить максимальную производительность. Так что всё, что работает на JVM, будет плохо себя показывать в ситуации, когда нужно быстро поднять программу, что-то сделать, и быстро же программу потушить.
ZK
Я думаю проблема больше в Scala, нежели в JIT. Чтобы что-то базовое на ней сделать, нужно 100500 классов загрузить сначала
AP
Часто можно подтюнить параметры запуска JVM так, что запускаться будет быстро. Но работать будет медленнее.
AP
И да, Scala очень много сущностей генерирует, всё это раскочегарить тяжко.
AP
Clojure тоже много классов генерит и поэтому меееедленно старутет. Зато потом работает быстро.
AP
Из за всего этого, кстати, не летят всякие Scala Script и lein-run. На них удобно писать скрипты для ОС, но скорость запуска убвает всё желание