Здравствуйте, sourcerer, Вы писали:

S>Что же до экзотики, то LINQ тоже был когда-то экзотикой.

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

Здравствуйте, sourcerer, Вы писали:

S>В последнее время ("внезапно", ага ) заметил четкую тенденцию к миграции в строну функциональных возможностей (на примере C#) — достаточно посмотреть на литературу от того же Manning ("Functional Concurrency in .NET", "Rx.NET in Action"). В связи с этим стал смотреть вокруг — чего в мире творится, и обнаружил очень интересную связку Elixir/Erlang/Phoenix, которые, (лишь по отзывам, конечно, — сам пока судить не могу: только книжку по Эликсиру и примеры в ней осилил — в индустриальной разработке не использовал), позволяют использовать многопоточность без танцев с бубном, и писать распределенные системы (альтернатива фреймворку Akka.NET), без нагромождения инфраструктурных частей. Но они не ОО, a функциональщина. Это назревает хайп или серьезная конкурентная заявка?

Elixir — хороший язык программирования. Однозначно лучше многих подобных (динамических языков с элементами ФП), с удачной макро-системой и менеджером пакетов. Erlang OTP — не самый плохой рантайм, с неплохим планировщиком задач и сборщиком мусора.

Но ни Erlang, ни Elixir, ни тем более Phoenix — не позволят сами по себе сильно облегчить разработку распределенных систем. Так как основная сложность там далеко не в языке программирования или фреймворке. В лучшем случае хороший фреймворк только упростит отладку такой системы, но это примерно такое же облегчение как чистилище вместо ада.

P.S. В промышленной разработке распределенных систем фреймворк Microsoft Orleans сейчас считается cutting edge. Но он значительно более низко-уровневый чем Akka.

Из исследовательских систем были интересные разработки типа Bloom и Lasp. Но пока дальше исследовательских прототипов они не пошли. На подобных "языках" потенциально можно "писать распределенные системы без нагромождений", но требуется глубокое переформатирование разума.

Здравствуйте, sourcerer, Вы писали:

S>В последнее время ("внезапно", ага ) заметил четкую тенденцию к миграции в строну функциональных возможностей

Плохо у вас с аналитикой, товарищ студент! Если на АвтоВАЗе стали крепить лыжи к багажнику, это как называется? "Тенденция в сторону снегокатания"? Вот-вот. Это ВСЕГО ЛИШЬ дополнение, расширение языка опциональными плюшками. С чего вы это решили, что C# становится функциональным-то??

S> Это назревает хайп или серьезная конкурентная заявка?

Хайп.

В последнее время ("внезапно", ага ) заметил четкую тенденцию к миграции в строну функциональных возможностей (на примере C#) — достаточно посмотреть на литературу от того же Manning ("Functional Concurrency in .NET", "Rx.NET in Action"). В связи с этим стал смотреть вокруг — чего в мире творится, и обнаружил очень интересную связку Elixir/Erlang/Phoenix, которые, (лишь по отзывам, конечно, — сам пока судить не могу: только книжку по Эликсиру и примеры в ней осилил — в индустриальной разработке не использовал), позволяют использовать многопоточность без танцев с бубном, и писать распределенные системы (альтернатива фреймворку Akka.NET), без нагромождения инфраструктурных частей. Но они не ОО, a функциональщина. Это назревает хайп или серьезная конкурентная заявка?

Здравствуйте, sourcerer, Вы писали:
S> В последнее время ("внезапно", ага )
S> Это назревает хайп или серьезная конкурентная заявка?
По-моему уже несколько раз успело умереть функциональное. Я думаю как из-за производительности, так и самой экзотики поделий.

Здравствуйте, Alex_ex_123, Вы писали:

A__>По-моему уже несколько раз успело умереть функциональное. Я думаю как из-за производительности, так и самой экзотики поделий.
Есть такой проект Nerves, где вся embedded функциональность реализована на Elixir — значит производительности хватает вполне. Что же до экзотики, то LINQ тоже был когда-то экзотикой.

Здравствуйте, sourcerer, Вы писали:

S>В последнее время ("внезапно", ага ) заметил четкую тенденцию к миграции в строну функциональных возможностей (на примере C#) — достаточно посмотреть на литературу от того же Manning ("Functional Concurrency in .NET", "Rx.NET in Action"). В связи с этим стал смотреть вокруг — чего в мире творится, и обнаружил очень интересную связку Elixir/Erlang/Phoenix, которые, (лишь по отзывам, конечно, — сам пока судить не могу: только книжку по Эликсиру и примеры в ней осилил — в индустриальной разработке не использовал), позволяют использовать многопоточность без танцев с бубном, и писать распределенные системы (альтернатива фреймворку Akka.NET), без нагромождения инфраструктурных частей. Но они не ОО, a функциональщина. Это назревает хайп или серьезная конкурентная заявка?

вообще, хайп уже очень давно. и даже успел пойти на спад в окрестности erlang'а
проблема в том, что рантайм имеет ограничения на масштабируемость. когда-то это не мешало, но сейчас на топовых по нагрузке проектах это не позволяет серьёзно масштабироваться вширь.
авторы что-то обещали исправить на этот счёт, но пока результатов нет. последний релиз-кандидат не содержит таких правок, насколько я понял.
плюс нет jit-компиляции, что сильно бьёт по производительности.

а хайп сейчас идёт вокруг clojure.

Здравствуйте, sourcerer, Вы писали:
S>Есть такой проект Nerves, где вся embedded функциональность реализована на Elixir — значит производительности хватает вполне.
Да дело не в "кое-где производительности хватает вполне", а в том что производительность всегда будет ниже чем в С. А сложность освоения высокая. В чем профит — не понятен. Ну если только перед пацанами пальцы гнуть.
S>Что же до экзотики, то LINQ тоже был когда-то экзотикой.
Он попал в удачное время и место(корпорация). Когда образовалась критическая масса велосипедов, которые он ограниченно заменил. Какие велосипеды фукционально можно заменить? Сделать новые велосипеды, довести уровень велосипедостроения дo абсурда.

Здравствуйте, Alex_ex_123, Вы писали:

A__>Да дело не в "кое-где производительности хватает вполне", а в том что производительность всегда будет ниже чем в С. А сложность освоения высокая. В чем профит — не понятен. Ну если только перед пацанами пальцы гнуть.
Профит в том, что современная функциональная хрень позволяет очень легко и просто работать с асинхронными событиями. Ты асинхронные события можешь комбинировать, фильтровать, группировать и т.д. Если ты будешь делать это так же, как раньше, то есть на каллбеках, то ты умрешь на более менее сложной логике, у тебя код будет совершенно неподдерживаемым. В функциональном стиле это все будет очень сильно походить на обычный синхронный код, но под капотом все асинхронно. В идеале во многих случаех конечно хотелось бы писать именно синхронный код. Тогда вообще можно прекрасно обойтись без функциональщины. Ну максимум будут всякие async await. Если этого достаточно и это можно сделать — так нужно сделать, ибо так проще. Но во многих случаях так просто сделать невозможно. Может потребоваться функционал фильтрации событий по промежуткам времени, например. И уже функционала async await не хватит. Для многих задач более предпочтительна будет именно функциональная парадигма, которая прекрасно ложится на концепцию потоков — снова функционала async await не хватит.

И ни хрена там сложность освоения не высокая. Если знаком с операциями map, flatMap, each, groupBy и т.д — ты уже прекрасно понимаешь все концепции, хоть и изначально это на синхронный код распространяется. Если же ты ни черта не понимаешь что такое map в функциональном стиле, значит нужно поднимать свою квалификацию.

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

Здравствуйте, neFormal, Вы писали:


F>а хайп сейчас идёт вокруг clojure.

clojure уже офиц-но или почти оф-но объявлен умирающим.

Здравствуйте, mizuchi, Вы писали:

F>>а хайп сейчас идёт вокруг clojure.
M>clojure уже офиц-но или почти оф-но объявлен умирающим.

кто его так и за что?

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, mizuchi, Вы писали:

F>>>а хайп сейчас идёт вокруг clojure.
M>>clojure уже офиц-но или почти оф-но объявлен умирающим.

F>кто его так и за что?
netcraft

Здравствуйте, mizuchi, Вы писали:

F>>>>а хайп сейчас идёт вокруг clojure.
M>>>clojure уже офиц-но или почти оф-но объявлен умирающим.
F>>кто его так и за что?
M>netcraft

ясно, понятно.
объявляю netcraft умирающим.

Здравствуйте, sourcerer, Вы писали:


S>Есть такой проект Nerves, где вся embedded функциональность реализована на Elixir — значит производительности хватает вполне.
Про "всю embedded функциональность" — это как минимум преувеличение. Большая часть работы с железом на C, обернутом в Elixir. Elixir в данном случае является типичным языком-клеем, как Python, Lua и тому подобные.

К тому же Nerves — это embedded linux, то есть устройства обычно значительно более мощные, чем типичные микроконтроллеры. На таких устройствах нередко гигагертцевые процессоры и сотни мегабайт ОЗУ. Так что производительности рантайма почти любого языка программирования будет хватать, даже какого-нибудь Ruby.

Здравствуйте, Vermicious Knid, Вы писали:

VK>Nerves — это embedded linux, то есть устройства обычно значительно более мощные, чем типичные микроконтроллеры. На таких устройствах нередко гигагертцевые процессоры и сотни мегабайт ОЗУ. Так что производительности рантайма почти любого языка программирования будет хватать, даже какого-нибудь Ruby.

Список поддерживаемых проектом Nerves платформ

Здравствуйте, Vermicious Knid, Вы писали:

VK>Но ни Erlang, ни Elixir, ни тем более Phoenix — не позволят сами по себе сильно облегчить разработку распределенных систем. Так как основная сложность там далеко не в языке программирования или фреймворке. В лучшем случае хороший фреймворк только упростит отладку такой системы, но это примерно такое же облегчение как чистилище вместо ада.

раскрой тему. что же там на самом деле?
просто именно разработку они облегчают. потому что рантайм — это уже совсем другое дело.

Здравствуйте, sourcerer, Вы писали:

VK>Nerves — это embedded linux
S>Список поддерживаемых проектом Nerves платформ
Я на этой странице был. Что нового я там должен был увидеть? На ней черным по белому написано, что построено на Buildroot:

If you’re trying to support a new Target, there may be quite a bit more work involved, depending on how mature the support for that hardware is in the Buildroot community. If you’re not familiar with Buildroot, you should learn about that first, using the excellent training materials on their website.

Buildroot — это набор скриптов для сборки Линукса. То есть поддержка всех перечисленных платформ построена на базе Линукса.

Линукс почти всегда подразумевает достаточно мощное железо. Каждую железку мне лень проверять, но Raspberry Pi, BeagleBone Black — это очень мощные машины. У Linkit Smart 7688, скорее всего одной из самых слабых железок в списке, 580 Mhz CPU и 128 Mb RAM. Сейчас посмотрел спецификации Lego EV3 — 300 MHz, 64 MB RAM. Довольно слабо, но все равно намного серьезнее, чем типичный микроконтроллер.

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Alex_ex_123, Вы писали:

A__>>Да дело не в "кое-где производительности хватает вполне", а в том что производительность всегда будет ниже чем в С. А сложность освоения высокая. В чем профит — не понятен. Ну если только перед пацанами пальцы гнуть.
E>Профит в том, что современная функциональная хрень позволяет очень легко и просто работать с асинхронными событиями. Ты асинхронные события можешь комбинировать, фильтровать, группировать и т.д. Если ты будешь делать это так же, как раньше, то есть на каллбеках, то ты умрешь на более менее сложной логике, у тебя код будет совершенно неподдерживаемым. В функциональном стиле это все будет очень сильно походить на обычный синхронный код, но под капотом все асинхронно. В идеале во многих случаех конечно хотелось бы писать именно синхронный код. Тогда вообще можно прекрасно обойтись без функциональщины. Ну максимум будут всякие async await. Если этого достаточно и это можно сделать — так нужно сделать, ибо так проще. Но во многих случаях так просто сделать невозможно. Может потребоваться функционал фильтрации событий по промежуткам времени, например. И уже функционала async await не хватит. Для многих задач более предпочтительна будет именно функциональная парадигма, которая прекрасно ложится на концепцию потоков — снова функционала async await не хватит.

E>И ни хрена там сложность освоения не высокая. Если знаком с операциями map, flatMap, each, groupBy и т.д — ты уже прекрасно понимаешь все концепции, хоть и изначально это на синхронный код распространяется. Если же ты ни черта не понимаешь что такое map в функциональном стиле, значит нужно поднимать свою квалификацию.

Async/await без promis-а не работоспособен.