LINUX.ORG.RU

Сайт на Clojure или Common Lisp?

 , , ,


0

6

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

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

naryl ★★★★★
()
Последнее исправление: naryl (всего исправлений: 1)

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

naryl ★★★★★
()

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

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

gensym ★★
()
Ответ на: комментарий от naryl

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

SAA ★★★
()

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

antares0 ★★★★
()
Ответ на: комментарий от SAA

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

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

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

elf80lvl
() автор топика
Ответ на: комментарий от elf80lvl

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

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

antares0 ★★★★
()
Ответ на: комментарий от umren

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

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

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

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

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

gensym ★★
()
Ответ на: комментарий от gensym

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

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

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

elf80lvl
() автор топика
Ответ на: комментарий от elf80lvl

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

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

antares0 ★★★★
()
Последнее исправление: antares0 (всего исправлений: 1)

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

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

unlog1c ★★★
()
Ответ на: комментарий от elf80lvl

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

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

naryl ★★★★★
()

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

yoghurt ★★★★★
()

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

alienclaster ★★★
()
Ответ на: комментарий от cdshines

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

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

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

alienclaster ★★★
()
Последнее исправление: alienclaster (всего исправлений: 1)
Ответ на: комментарий от yoghurt

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

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

alienclaster ★★★
()
Ответ на: комментарий от naryl

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

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

feofan ★★★★★
()

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

ymn ★★★★★
()

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

dave ★★★★★
()
Ответ на: комментарий от antares0

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

dizza ★★★★★
()
Ответ на: комментарий от antares0

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

dizza ★★★★★
()
Ответ на: комментарий от dizza

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

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

anonymous
()
Ответ на: комментарий от alienclaster

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

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

rikardoac
()
Ответ на: комментарий от alienclaster

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

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

umren ★★★★★
()

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

yaspol
()
Ответ на: комментарий от dizza

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

По памяти

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

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

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

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

antares0 ★★★★
()
Ответ на: комментарий от dizza

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

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

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

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

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

antares0 ★★★★
()
Ответ на: комментарий от alienclaster

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

cdshines ★★★★★
()
Ответ на: комментарий от rikardoac

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

antares0 ★★★★
()
Ответ на: комментарий от antares0

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

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

dizza ★★★★★
()
Ответ на: комментарий от antares0

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

dizza ★★★★★
()
Ответ на: комментарий от dizza

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

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

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

antares0 ★★★★
()
Ответ на: комментарий от dizza

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

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

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

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

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

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

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

antares0 ★★★★
()
Ответ на: комментарий от dizza

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

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

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

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

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

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

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

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

umren ★★★★★
()
Ответ на: комментарий от antares0

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

dizza ★★★★★
()
Ответ на: комментарий от umren

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

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

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

dizza ★★★★★
()

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

q0tw4 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.