Разыскивается информация по лучшим практикам, подводным камням и т.п. для back-end разработки на Elixir. В принципе, гуглить я умею и восторженных отзывов о том, как всё стало после использования Elixir уже нашел... но а что там плохо? Где и когда все разваливается? Какие практики лучше себя зарекомендовали что бы не развалилось? Поделитесь информацией, пожалуйста
Re: Elixir, подводные камни, лучшие практики и т.п.
Здравствуйте, kaa.python, Вы писали:
KP>Разыскивается информация по лучшим практикам, подводным камням и т.п. для back-end разработки на Elixir. В принципе, гуглить я умею и восторженных отзывов о том, как всё стало после использования Elixir уже нашел... но а что там плохо? Где и когда все разваливается? Какие практики лучше себя зарекомендовали что бы не развалилось? Поделитесь информацией, пожалуйста
Поскольку Elixir — это сахарок для Erlang VM, то и проблемы там, скорее всего, такие же как у Erlang. Читать, например: https://www.erlang-in-anger.com/
Re: Elixir, подводные камни, лучшие практики и т.п.
Здравствуйте, kaa.python, Вы писали:
KP>Разыскивается информация по лучшим практикам, подводным камням и т.п. для back-end разработки на Elixir. В принципе, гуглить я умею и восторженных отзывов о том, как всё стало после использования Elixir уже нашел... но а что там плохо? Где и когда все разваливается? Какие практики лучше себя зарекомендовали что бы не развалилось? Поделитесь информацией, пожалуйста
Сам не использовал, но видел проект с которым непросто работать. На мой взгляд основные проблемы были в том, что в нем пытались использовать что-то похожее на ООП, с кучей состояний пробрасываемых по стеку вызова. То есть в первую очередь желательно смотреть паттерны разработки для функциональных языков, особенности иммутабельных объектов.
Re[2]: Elixir, подводные камни, лучшие практики и т.п.
Здравствуйте, Ziaw, Вы писали:
Z>Сам не использовал, но видел проект с которым непросто работать. На мой взгляд основные проблемы были в том, что в нем пытались использовать что-то похожее на ООП, с кучей состояний пробрасываемых по стеку вызова. То есть в первую очередь желательно смотреть паттерны разработки для функциональных языков, особенности иммутабельных объектов.
Ну да, логично, если пытаться запихнуть ООП в ФП то закономерно выйдет лажа... или OCaml, но тут талант нужен
