ecto тоже можно

я бы query object сделал

+1

А есть варик halt всякие проверки в changeset?

слушай, ты много раз писал конструкцию "есть варик"

что это такое?

вариант

у нас так в калхозе говорят

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

Чуваки, где лучше хранить кастомные запросы к дб - в контроллере, в функциях репозитория или в модели? и как

В контексе же. Скоро 1.3 выйдет и там не будет моделей совсем.

Можно ли эликсир скомпилить в бинарник???

Я забыл как называется то что вместо моделей?

схемы, наверное

Можно ли эликсир скомпилить в бинарник???

http://stackoverflow.com/questions/24500994/elixir-or-hex-portable-package-format

можно, но без установленного эрланга работать не будет

http://langintro.com/cljsbook/

снимай портки, власть сменилась

кто-нибудь юзал - http://www.ponylang.org/

?

я вбрасывал как-то.. любителей не нашлось

уже одно название доверия не внушает

да пофиг на название, главное чтобы работал как лошадка

розовая. маааленькая.

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

на джаваскрипт

на джаваскрипт

не, когда смотрю на js мне нравится тайпскрипт и f#

не, когда смотрю на js мне нравится тайпскрипт и f#

посмотри на голанг

хмхм

посмотри на голанг

это работает.

посмотри на голанг

Но я больше про какий-нидь хау ту

Кстати, сегодня на CodeFest был ( https://2017.codefest.ru/ ), на первом дне. Там часа полтора общались с девелопером из Касперского. У них там ЕМНИП аж пять Haskell-девелоперов в команде, пилят кусок ОС.

Но я больше про какий-нидь хау ту

от такого бы я и сам не отказался ;)

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

И, что интересно, в кулуарах уже успели обсудить Dart, Elm, Haskell. BEAM-based языки пока не обсуждались

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

в раст чатике то самое же

Ж))

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

erlang

erlang

))) Не, сначала в моСк, а потом в эрланг )))

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

попробуй написать на с++ tcp/ip сервер с использованием epoll/kqueue. поэкспериментируй между одним процессом, тридами на каждое соединение, смешанную технику. вот когда уже дойдешь до самостоятельной необходимости реализации зеленых процессов, возвращайся. я тебе расскажу про 10-е правило гринспена.

да, еще горячее обновление кода забыли))

хороший и емкий аргумент против упоротых адептов статической типизации

да. в некоторых языках этого не будет. вообще. совсем. никогда.

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

вообще все это из ерланга.

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

еще обязательно надо попробовать напрямую поработать с epoll, потом попробуй освоить какой-нибудь boost.asio, libevent, livev, libuv

ну. я сначала попал в ерланг. по своей воле

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

особенно новый вид мышления

все в мире есть процессы

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

ну то есть, ряд задач, которые благодаря эрлангу, я наконец-то смог решить

а зачем тогда юные неокрепшие умы на хабре от эликсира/эрланга отворачиваешь?

кстати. там в статье по поводу серверов http go vs elixir. появился каммент, где человек написал сервачек вообще на TCL! и получилось быстрее. вероятнее и быстрее Go. как я понял, он из разработчиков TCL. он вообще высказал мнение, что компилируемый язык вовсе не обязательно даст больший RPS. вот так

еще обязательно надо попробовать напрямую поработать с epoll, потом попробуй освоить какой-нибудь boost.asio, libevent, livev, libuv

это еще зачем?

а зачем тогда юные неокрепшие умы на хабре от эликсира/эрланга отворачиваешь?

ну. цели такой не было. но я вообще стараюсь быть объективным, на сколько это возможно. тупо по цифрам так уж вышло :(

это про статью и тесты?

там на хабре

это еще зачем?

был вопрос о том, куда смотреть, чтобы эликсир понравился

там на хабре

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

чтобы понравился эликсир надо сначала осознать вообще ерланг.

кстати

http://erlangonxen.org/ - пару лет назад Макс Сохацкий пиарил

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

ну. цели такой не было. но я вообще стараюсь быть объективным, на сколько это возможно. тупо по цифрам так уж вышло :(

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

http://erlangonxen.org/ - пару лет назад Макс Сохацкий пиарил

да да. есть такая тема. я вот вообще как-то считаю, что ерланг вм - это полноценная самодостаточная ОС.

ERROR: S client not available

вообще главное архитектура - если архитектура гавно то байтодрочерство не спасает

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

боюсь ядно настолько большое и сложное

что не появится быстро и тем более надежно

там же монолит дикий

универсальный

зелёные потоки линуксу не нужны, он же потоками на уровне ядра рулит

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

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

видишь, как я понял ты юзаешь ковбой

но ковбой априори поделка под определенную задачу

хоршо бы написать свою тестовую реализацю веб сервера

на отдельном порту

да. и правильно попробовать не только ковбой. а стандарный ерланговый http. потом есть еще как минимум yaws.

статическая типизация по определению быстрее чем динамическая потому что там меньше проверок (они во время компиляции проходят)

да можно просто порт открыть и самому реализовать простенький сервак

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

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

да можно просто порт открыть и самому реализовать простенький сервак

вот в планах статья. реализация есть. надо просто старые коды поглядеть.

фи. на си. я знаю целую контору, которая бекенд пишет на си

я планирую, что они сдохнут всетаки. через несколько лет

хороший и емкий аргумент против упоротых адептов статической типизации

Это часто и не нужно

более того, это часто и не используют

по поводу статической типизации очень люблю приводить слова Алана Кея - И вскоре Алан стал поддерживать идею того, что динамические языки это будущее разработки ПО (pdf). В частности, ему важна легкость изменения: Позднее связывание позволяет с меньшими усилиями встраивать в проект идеи, которые возникли позже в процессе разработки (по сравнению с системами с более ранним связыванием вроде C, C++, Java, и пр.)

кому интересно

советую почитать

https://habrahabr.ru/company/hexlet/blog/303754/

И потенциал для изменений на ходу и более быстрых итераций: Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений. Даже крупные изменения должны быть поэтапными и занимать не больше доли секунды. который отсутствует в статически-типизированных языках: Если вы используете языки с ранним связыванием, как это делает большинство, то вы запираете себя в рамки того, что уже написали. Переформулировать с легкостью уже не получится.

по поводу статической типизации очень люблю приводить слова Алана Кея - И вскоре Алан стал поддерживать идею того, что динамические языки это будущее разработки ПО (pdf). В частности, ему важна легкость изменения: Позднее связывание позволяет с меньшими усилиями встраивать в проект идеи, которые возникли позже в процессе разработки (по сравнению с системами с более ранним связыванием вроде C, C++, Java, и пр.)

Да. Это звучит логично

Но я все же за опционально динамическую типизацию.

никто не мешает на эликсире написать nif функцию на нативном быстром СИ