LINUX.ORG.RU

Платформы выбора тред

 , , , ,


1

5

Нужно выбрать платформу для написания сервиса по управлению ip-камерами.

Предполагается, что эта фигня будет самостоятельно ставиться людьми (нужен удобный деплой).

Нужно:

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

Взял бы сразу Rails, ибо удобная и развитая платформа. Но у Ruby (и Rails в частности) очень серьёзные проблемы с памятью, один свежий инстанс приложения занимает где-то 80 Мб, а в процессе работы отжирается где-то до 200-300. Соответственно нужно караулить и рестартовать. Сложно и неудобно.

Erlang/Cowboy — всё отлично с потреблением ресурсов, с развёртыванием, вроде библиотек более-менее. Однако, как мне кажется, неудобен для такого проекта. Нам нужно очень много всяких мелочей, всякой логики и кастомизации, хотелок.

Возможно Rails обернуть в докер-контейнер, и весь цирк-деплой делать внутри, но мне эта идея как-то не по-душе.

Смотрю на связку Python/Flask: вроде и платформа более-менее развитая, и вроде как с потреблением получше.

У JVM-based языков те же проблемы с памятью что и у Rails, подскажите? Я имею ввиду всякие скалы и clojure.

★★

Последнее исправление: CYB3R (всего исправлений: 2)

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

Ахрененные требования. И какого уровня по-твоему будут советы?

loz ★★★★★
()
Ответ на: комментарий от vladimir-vg

Штуки вроде ActiveRecord и SQLAlchemy нужны.

Юзаю алхимию, питон, эрланг. Все живы.

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

Нормальные IDE (не нужно писать в блокноте).

Точнее только с IDE и можно писать на них.

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

Проблема не в языке кмк.

Проблема еще как в языке. Макросы говно, свои типы данных создавать нельзя, чего-нибудь аналогичного объектной системе нет ни в каком виде. Все орм которые я видел это костыли поверх parse transform.

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

Оно на макросах целиком и полностью.

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

недостаток логики можно компенсировать специфичными языками (python, java, php) главным образом через порты + прикладные протоколы.

Это чуть ли не единственный способ. И опять же в итоге все упирается в негибкие эрланговые структуры данных.

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

Это чуть ли не единственный способ. И опять же в итоге все упирается в негибкие эрланговые структуры данных.

erlang, конечно далеко не мёд, но где-то обстоят дела получше?

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

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

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

Ну, в любом другом динамическом языке от луа до лиспов.

Кроме лиспа в общем довольно разные категории. Вообще дело вкуса и компетенции. Эрланг, это вотчина неосиляторов. Хотя в ситуации ТС-а без специфичных библиотек, напрягает их возможное отсутствие, тогда как в других популярных языках (наверное питон, java, c++) наверняка есть.

По-моему везде есть возможность создавать свои типы, в том числе в рантайме.

да, везде, «пользовательские»

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

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

да, везде, «пользовательские»

Главное чтобы не тегированные кортежи)

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

Главное чтобы не тегированные кортежи)

Расскажи зачем нужны пользовательские типы, и почему жизнь с теггированными кортежами невыносима.

Мне нравится подход Erlang — всё plain data, никаких абстракций над данными (типов, классов или ещё чего).

Мне чому-то норм. Может я что-то упускаю?

vladimir-vg ★★
() автор топика
Ответ на: комментарий от vladimir-vg

Может я что-то упускаю?

Потому что их схавает любая функция принимающая кортеж, потому что данные нельзя наследовать, потому что при добавлении/удалении поля (а у тебя эрланг, hot-code upgrade и все такое) нужно перекомпилить все модули рекорд использующие (а если голый кортеж так вобще переписать). Ты не можешь получать доступ к полю по имени известному в рантайме, не можешь итерировать по именам, ну то есть в рантайме их вобще нет. Это дает невероятные «преимущества» когда нужна более-менее автоматическая сериализация твоих кортежей. В частности это приводит к тому что орм такой какой он есть сейчас, что все json либы могут работать только с проплистами, а не твоими собственными данными и многим другим проблемам.

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

Когда тебе нужна либа X и она есть в языке A, B и C какая разница что в языке A еще 100500 каких-то либ которые тебе не нужны в этом проекте?

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

Когда тебе нужна либа X и она есть в языке A, B и C какая разница что в языке

Для меня большая. Количество либ это достаточно ёмкий показатель. Например в erlang до сих пор нет нормального драйвера mysql, pgsql, кормят завтраками типа odbc или портами и байками: «чё там делать возьми и запили на сокетах»...

A еще 100500 каких-то либ которые тебе не нужны в этом проекте?

да это вообще монохромно

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

Количество либ это достаточно ёмкий показатель

Показатель чего?

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

Потому что их схавает любая функция принимающая кортеж

Ну и хорошо, всем понятный интерфейс.

потому что данные нельзя наследовать

Наследовать данные? Не совсем понятно что имеется ввиду.

потому что при добавлении/удалении поля (а у тебя эрланг, hot-code upgrade и все такое) нужно перекомпилить все модули рекорд использующие (а если голый кортеж так вобще переписать)

Согласен. Лечится написанием геттеров и сеттеров.

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

Вообще в э-ге появились maps, они позволяют и доступ по имени известному в рантайме, и итерирование.

Что касается records, то если уж мне действительно необходим такой финт ушами, то можно накостылить функцию (щитай getter/setter).

когда нужна более-менее автоматическая сериализация твоих кортежей

согласен, тут уже без maps никуда.

vladimir-vg ★★
() автор топика
Ответ на: комментарий от vladimir-vg

Ну и хорошо, всем понятный интерфейс.

С какой-то стороны хорошо, но вот иногда хочется чтобы is_tuple возвращало false на твои собственные данные.

Наследовать данные? Не совсем понятно что имеется ввиду.

Ну это типа у тебя есть юзеры - у них определенные данные, а потом еще появляются вдруг какие-то, например, юзеры из социальных сетей и у них те же данные что и у юзеров, но и еще пачка собственных данных. Понятно что это можно решить просто создав новую структуру, включив одну структуру в другую, или все время расширять юзера и проверять его тип. Но у всех этих подходов есть очевидные минусы перед тем чтобы указать что юзер из соцсети это расширение типа юзер данными A, B, C.

Лечится написанием геттеров и сеттеров.

Это вобще по-моему автоматически должно генерироваться. Но когда надо обновить/получить, кучу полей сразу опять же неудобно.

Вообще в э-ге появились maps

Опять же, НЕ ПРОШЛО И 25 ЛЕТ. Осталось подождать пока в продакшен попадет 17 эрланг и критичные либы перепишут с их использованием.

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

указать что юзер из соцсети это расширение типа юзер данными A, B, C.

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

НЕ ПРОШЛО И 25 ЛЕТ.

справедливое замечание.

vladimir-vg ★★
() автор топика

Clojure норм, JVM не стоит бояться. Она прекрасно тюнится из коробки.

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

Языки с GC требуют от 2-х до 4-х раз больше памяти

Не требуют, но используют если возможно. Если уж говорить о преимуществе крестов, то оно в том, что можно выделять память на стеке.

Языки с VM (да еще и без JIT/HotSpot) работают в несколько раз медленнее

Для ввода-вывода это значения не имеет.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Не требуют, но используют если возможно.

Ох, это, конечно, злобный офтопик, то все-таки очень интересно. А если не возможно, то что делают языки с GC?

eao197 ★★★★★
()
Ответ на: комментарий от no-such-file

Запускают GC, чтобы освободить память. Очевидно же.

Ну и? Если вам хотя бы это очевидно, то сделайте уже следующий логический шаг. Что будет, если GC будет запускаться слишком часто?

eao197 ★★★★★
()

Пиши на Си и не ипи себе и людям мозги.

anonymous
()
Ответ на: Ruby is dead от entefeed

знатно ты в лужу пёрнул

объясни чем питон живее руби и почему нельзя взять руби/ноду, м? Наверное потому что ты кроме питона ничего не знаешь, поэтому его и пираишь. (против питона ничего не имею)

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

Со стороны действительно кажется что руби-рельсы мертвы, но это просто потому что хипсторы которые три года назад очень им радовались повзрослели и стали крутыми погроммиздами B-) На деле руби сейчас везде, просто о нём не кричат, просто юзают.

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

в целом да. Хайп вокруг рубей подстих и вместо него просто спокойная планомерная работа. Это фактически дефолт №2 после PHP для нового вебсайта сегодня.

Но мы для задачи, с которой начался топик, выбрали питон.

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