Я, правда, не сайт писал, но по своему опыту могу сказать, что поддержка приложений на Clojure - это ад. Масштабирование - наоборот.

Можно подробнее про поддержку?

Ах, да. Писал где-то год назад сайт на CL с использованием RESTAS. Можешь скастовать archimag (хотя, я уже сам) и узнать всё из первых, как говорится, рук.

А почему Вас этот вопрос тоже интересует? Просто хочу знать контекст.

на чем будет проще в дальнейшем поддерживать и масштабировать сайт

Можно и на Common Lisp. Только тогда приготовься к допилу библиотек — заведи ГитХаб. Польза будет всем. ;-)

Интересует кложа, поэтому и спрашиваю.

Clijure это java и дял сайта достаточно тяжелая штука. И само по себе предполагает уже сопричастность к жабовскому стеку. Если же тfкой сопричастности нет, то стоит задуматся а нафига тебе оно.

просто, промолчу.

комментарий от naryl

Можно подробнее про поддержку?

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

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

Одинаково. Единственоое что web-серверы под CL нативные, достаточные легкие но с потенциальными граблями в силу относительной немногочисленности использующих. CLojure в осном использует глобально-надежно-тяжелую явовскую инфрструктуру.

Пхпшники в треде, все в машину тюринга!

ТС, бери кложу, не слушай тех, кто говорит, что тяжело. Зато готовых библиотек более, чем достаточно. А возьмешь лисп, вместе писания сайта будешь пилить чужие библиотеки уровня студенческих поделок, да еще и без документации.

А возьмешь лисп, вместе писания сайта будешь пилить чужие библиотеки уровня студенческих поделок, да еще и без документации.

Кто-то же должен этим заниматься, не? ;-)

Ну, раз уж на то пошло, то это не очередной «что опенсорсного попилить»-тред))

Спасибо cdshines и antares0 и всем остальным, мне очень важна надежность пусть и немного в ущерб производительности, поэтому выбран Clojure. Тем более на русском есть актуальная книга по языку «Программирование в Clojure». Программирование в Clojure)

пусть и немного в ущерб

По памяти я бы на немного не надеялся

Haskell VS Common Lisp VS OCaml VS Scheme VS Scala VS Clojure

Помогите пожалуйста определиться, интересует на чем будет проще в дальнейшем поддерживать и масштабировать сайт, а так же доступность готовых плюшек для web, дабы не писать все с нуля. Спасибо.

Сырость решений для твоей задачи что на CL, что на Clojure приблизительно одинакова. Но важна производная. Clojure сейчас в большом интересе, и с каждым днем появлется все больше интересных и полезных штук.Одна возможность написания серверной и клиентской части на едином языке (Clojure и ClojureScript) много чего стоит.

С точки зрения сложности исправления багов Clojure сильно проигрывает. Куча неявных приведений типов, полное отсутствие проверки типов, даже опциональной как в CL, кастрированный отладчик в nrepl в сравнении со slime, ексепшоны вместо сигналов. Стабильность фреймворков и библиотек зависит от того используешь ты джавовские (очень высокая), или свои (очень низкая). Большинство разработчиков на Clojure особо о совместимости версий не парятся.

Короче, я бы посоветовал Clojure только если тебе знакома инфраструктура java и захотелось ей воспользоваться через призму скобок.

Пистон

На Clojure, ибо к ней прилагаются все батарейки Джавы (да, они закидают шапками аналоги для CL)

готовых плюшек для web

PHP

Clojure.
Common Lisp мертв, хоть и неплох.

А возьмешь лисп, вместе писания сайта будешь пилить чужие библиотеки уровня студенческих поделок, да еще и без документации.

Слабый аргумент, учитывая, что сейчас все разрабатывается на фреймворках. А фреймворк это каркас приложений + (максимум) безопасность и несколько удобных встроенных фич с визуализацией заполнения через админку. Кроме как использовать готовую jvm и какие-то специфические (для разработки вебни стремиться к нулю) либы - нахер все эти жабьи библиотеки не нужны, копаться в таком калле.

Зато у clojure есть и плюсы (и минусы одновременно) - это так не свойственный лиспам захардкоженный _синтаксис_, при этом все еще нормальная юзабельность макросов и искоробочный STM с ленивостью и чистотой. Объективно - это сейчас самый продакшн-рэди лисп за последние 30 лет: есть среды, инструменты разработки, стремительно растущее комьюнити, (относительно) вменяемый (хоть и зашитый) синтаксис, хорошая дока, ынтерпрайз платформа.

ибо к ней прилагаются все батарейки Джавы

Ничего нужного в этих батарейках не обнаружено.

готовых плюшек для web

PHP

Там никаких плюшек нет. До сих пор ни одного нормального фреймворка, сообщество одни дебилы.

полное отсутствие проверки типов, даже опциональной как в CL

Для опциональной проверки типов есть теги

рельсы, питон, асп дотнет.

У франца в allegro cl должен быть стек технологий для этого дела, но только он дорогущий. Ведь сам веб-сервер - обычно только вершина айсберга, хотя это зависит от твоей задачи.

Для сайта тяжелая? Лол, а ты знаешь, что быстрее уже только Си, и то не на много? И что на java переделывают сайты со всяких пыхов, что бы сэкономить на железе?

Тяжелую, это какую? Jetty, на котором gmail работает? Что то я не видел, что бы из closure работали с jboss и прочей тяжелой требухой.

Jetty, на котором gmail работает?

Дрова откуда?

сообщество одни дебилы

не оттуда ли и ты вырвался, дружок?

PHP
сообщество одни дебилы

так их! красава

аргументация уровня лора

Выкинь всё это, возьми Perl + Catalyst.

Для сайта тяжелая?

По памяти

Лол, а ты знаешь, что быстрее уже только Си, и то не на много?

В синтетике и розовых мечтах лоровских аналитиков.

на java переделывают сайты со всяких пыхов, что бы сэкономить на железе?

Что с таким же успехом может говорить об убогости конкретных php-шников или что ты просто слышал звон.

Тяжелую, это какую?

Tomcat. GWT который где-то внутри ClojureScript.

Jetty, на котором gmail работает?

В Google могут работать хоть на технологиях с альфы Центавра, обычным смертным это все равно не поможет.

И не сказать что бы сами жабщики этот Jetty повально использовали. Зато привести его в пример, докинуть непроверяемой фигни и наклеить ярлычок с магической буквой G ...

Со вторым абзацем согласен, а с первым не совсем, потому что фреймворки на то и фреймворки. Если ты пишешь хоть сколько-нибудь специфичный сервис, рано или поздно придется гуглить, есть ли $подставить_имя библиотека, а в случае с clojure шансы повыше.

GWT который где-то внутри ClojureScript

покажи мне это место, где в clojurescript используется gwt

Грешен. Нигде. ППочему то вспомнился вместо Google Closure

По памяти расскажу такую штуку: писал я как то веб-сервис с нагрузкой в 1000 запросов в секунду. Хип выставлен был в 128 мегабайт. Это жрет? Тезис «Ява жрет память» был актуален лет 10 назад, когда памяти всего могло быть 128 мегов. С тех пор Ява же жрать больше не стала.

Про пехапе: как ты код не вылизывай, но такой же вылизанный код на более быстрой реализации будет требовать меньше железа. При чем в разы. Я лично учавствовал в проекте, где чуваки вылизывали код на питоне, в итоге уже и в асинхронность влезли и в си что то вынесли. Но сука аппликуха все равно кучу серваков требовала. Профайлинг показал, что все уже стало упираться в скорость базовых операций питона. Вот тогда уже начали смотреть на Яву, на PyPy и так далее.

GWT действительно хрень. Jetty очень популярен в хайлоаде. Ну и собственно о чем и речь, ручные обезьянки пихают везде аппсерверы с gwt, а потом оказывается Ява тормозит. Там где нужна скорость, Ява отличный помошник. Что там индусы за оглобли на Яве используют не имеет значения.

веб-сервис с нагрузкой в 1000 запросов в секунду. Хип выставлен был в 128 мегабайт. Это жрет?

Без детального анализа это ниочем.

У меня был сервер на sbcl на 48 мб. VPS-е. И это тоже ниочем.

ручные обезьянки пихают везде аппсерверы с gwt, а потом оказывается Ява тормозит.

Что там индусы за оглобли на Яве используют не имеет значения.

Соседние сообщения.

не слушай тех, кто говорит, что тяжело. Зато готовых библиотек более, чем достаточно.

ибо к ней прилагаются все батарейки Джавы (да, они закидают шапками аналоги для CL)

Яву тянут в прект аргументируя батарейками. Потом начинаем выяснять какие батрейки писаны не индусами. Потом пишем почти все сами.

Это вот то что я имел ввиду когда говорил что явовский стек «тяжелый».

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

Мне проще/быстрее и дешевле (для бизнеса) решать 90% задач интерпритируемым языком, а для 10% задач где он будет не эффективным(это нужно осознать) - выбрать другую технологию, чем писать все 100% на яве, с убийственным блоатом.

Я лично учавствовал в проекте, где чуваки вылизывали код на питоне, в итоге уже и в асинхронность влезли и в си что то вынесли

чуваки думали что питон может все, на деле это просто еще один интерпретируемый яп, который плохо работает в случае где нужен серьезный сoncurrency

Про пехапе: как ты код не вылизывай, но такой же вылизанный код на более быстрой реализации будет требовать меньше железа

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

Но сука аппликуха все равно кучу серваков требовала

тут надо взвешивать плюсы и минусы отдельной реализации
вариант 1: у нас много «рабочих» ресурсов которые готовы переписать критическую часть приложения и поддерживать ее
вариант 2: лишних рук нет, все загружены под завязку, покупаем серверы (это в итоге дешевле для бизнеса)

Кстати, я не отношусь к тем, кто выбирает яву потому, что там много батареек. Годных батареек там не много, так же как и в том же питоне. JVM я люблю именно как платформу. За то, что получается безопасный код со скоростью близкой к нейтиву и отличной поддерживаемостю, переносимостью и управляемостью.

Я говорю про конкретную задачу - хайлоад проект. Для не хайлоада я предпочитаю питон. Про яву я вообще написал в контексте старой байки «java тормозит».

вариант 1: у нас много «рабочих» ресурсов которые готовы переписать критическую часть приложения и поддерживать ее

Вот этот вариант и был использован.

аргументация уровня лора

И что же я аргументировал? :)

на emacs-lisp же

Elnode - event driven web development in Emacs Lisp

Хотел я кложу поучить для андроида после того как неосилил скомпилить туда racket, но 15 секунд ждать пока появится надпись hello world на новейшем мощном планшете - бред. Насколько я смог выяснить проблема в том что сама система кложи грузится с сорцов вместе с документацией. Ну оно то исправимо, но всеравно складывается впечатление что кложа - студенческая поделка с плохо продуманной оптимизацией при компиляции. Брали бы пример с ракета, который умеет значительно ускорять код засунутый в модуля (модуль гарантирует неизменность топ-определений извне чи както так), может быть типизирован с выводом типов и при этом его jit догадается проанбоксить все элементарные типы. Не уверен что на jvm адекватно реализовывать такое в принципе. Так что пусть уж лучше будет раскручена и обатареена какая-то лисповая vm, оно того стоит.