@majioa шизофрению никто не отменял

@majioa шизофрению никто не отменял

фантазирование с силлогизмами тоже)

вброшу еще сюда, пожалуй

Названы go, jvm-языки, C/C++. Но забыли упомянуть elixir :)

эликсир это не конкурент, а синтаксический сахарок

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

и не только авторы

мне не нравится даже сама идея считать его отдельным языком

потому что это формирует неправильный подход

результаты которого мы видим зачастую в эликсировом комьюнити

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

и нести вот такое мышление в массы безголовых хипстеров, набегающих на запах эликсира в комьюнити

еще бы в головы elixir core team это вдолбить

А мне кажется они всё правильно делают. Если Elixir комьюнити будет считать себя тем же Erlang'ом с сахаром, то развитие языка сильно замедлится. Erlang хорош в очень узком спектре задач, которые от него никуда не денутся. Elixir сейчас явно получает вектор развития в зависимости от "набегающих хипстеров". И пусть.

угу, и все останется как есть. у жрланга библиотек и комьюнити нет, в эликсире и то, и то - ruby-like говно

даже не так, "библиотек, комьюнити и кадров"

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

ну вот старпером меня еще не называли

Эрланг мертв в хипстерском смысле

А то что мертво в хипстерском смысле сегодня - вообще мертво

Потому что никто не носит программы на дискетах и не учит прогать по книжкам

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

А если я не умею одновременно писать на эликсире, попивать смузи, потягивать вейп и катиться на моноколесе, то я эрланг-старпёр?

Для того чтобы быть хипстером достаточно просто хайпить

какая разница, VM одна

Чё там, scala сахар для Явы?

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

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

настоящий хипстер :)

Вот такого примерно

Чё там, scala сахар для Явы?

и кложа - сахар для явы

Он сказал что то типа סיסו את ירושלים

И уехал в закат

на яве

Он сказал что то типа סיסו את ירושלים

опять скала в чате

опять скала в чате

Присмотрись, это Elm

на элме Just יסו את ירושלים

должен признать, выделить это - это достижение

Да, сложновато

Букву пропустил)

?

Букву пропустил)

не получилось почему то((

сахар для байткода jvm)

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

на элме Just יסו את ירושלים

выделяйте с конца

все сахар для бинарного кода

занудству людей нет предела)

фантазирование с силлогизмами тоже)

к чему это, ну да ладно, всякое бывает)

Уважаемые знатоки. Есть вполне стандартная функция для апдейта сущности в базе: def update(%Entity{} = entity, attrs) do entity |> Entity.changeset(attrs) |> Repo.update! end В сгенерированных фениксом тестах пары ключ-значение attrs и updated_entity сравниваются по очереди, в несколько ассертов, но я хочу сравнить их всех охапкой и простое сравнивание attrs и updated_entity тут не работает. Есть ли функция которая позволяет проверить наличие ключей-значений одной map в другой? Т.е. что бы можно было так: test "", %{entity: entity} do update(entity, @update_attrs) updated_entity = get_entity!(entity.id) assert has_key_values?(updated_entity, @update_attrs) end вместо того что бы сравнивать по очереди значения ключей updated_entity и attrs (как это сделано в генерированных тестах феникса)

т.е. понятное дело что можно ее реализовать самому, но вдруг она уже есть в стандартной библиотеке или в ex_unit? :)

на яве

на JAWA 350 )

к чему это, ну да ладно, всякое бывает)

ровно к томуже, что и о шизофрении, ну да ладно, всяко бывает)))

ровно к томуже, что и о шизофрении, ну да ладно, всяко бывает)))

кто ты, чудо расчудесное, згинь нечистая) "тому же" пишется раздельно((

Ассерт паттерн матчинг ест, не только сравнение

Т.е. в правой части твоя проверяемая мапа, а в левой паттерн со всеми необходимыми ключами

@Echoes93 такое подойдёт?

(RuntimeError) cannot use Logger, the :logger application is not running

о_О

require Logger

require Logger

Рили?

Ващет это произошло в приложении в котором логи непрерывно пару недель

в mix.ex extra applications логер указан?

Такое происходит, когда сам логгет падает

ну я вот везде, где нужен логгер ставлю require. и все норм

в mix.ex extra applications логер указан?

ессно

а без реквайр он и не заработает вовсе

а так очевидно да, логгер приуныл, прикольно

а эт, кастомные логи в приложухе или как?

ну то, что через логгер пишется в своём коде, да

https://github.com/elixir-lang/elixir/blob/756a7ab84499e3245cb9746073496aeff3f9b36d/lib/logger/lib/logger/app.ex

припал немношк, с кем не бывает

это да, просто я кастомизировал себе логгер, и когда ошибка происходила при форматировании - он падал

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

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

Тоже бывало такое что логер падал, logger_file_backend не использовался

очевидно, что данная проблема никак не связана с require Logger.

https://github.com/devonestes/fast-elixir#retrieving-state-from-ets-tables-vs-gen-servers-code

как-то обсуждали стейт генсервера и ets

как-то не верится про 30 раз

как-то не верится про 30 раз

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

а вот, например, оттуда Map Lookup vs. Pattern Matching Lookup стоило бы проверить на масштабируемость

на, скажем, миллионе элементов

@nwalker - У тебя pattern match с миллионом элементов - скорее всего не скомпилируется просто.

я ж и говорю - проверить надо

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

мне всегда не нравилось в ets что результат lookup это массив. как-то казалось, что из state в генсервере элементы извлекаются проще и логичнее