Видимо, вы имеете в виду дословный перевод алгоритмов, основанных на массивах, на функциональные языки. Но это ложная задача, для неизменяемых структур есть свои алгоритмы. А там где надо (например в БД записать или пользователю результат отдать), там сайд-эффекты управляемо возможны штатными средствами стандартной библиотеки.
человек понимает сразу как работает эта шайтан машина, что куда положить и т.д.
Ага, только это иллюзия понимания… Потом человек попадает на сайд-эффект и "весело" проводит неделю за отладкой в полном непонимании как работает эта шайтан машина.
Я ничего не отрицал, потому что изначально не понимаю, чем описание последовательности действий (процедурное программирование) проще, чем описание конвейера?.. Понятно только, что ООП (описание объектов и их взаимодействия) уже точно сложнее.
Тем не менее, всё производство давно уже конвейерное. И если вы хотите стабильный код, вам всё равно придётся отказываться от "последовательности действий" и эмулировать конвейер в императиве, наворачивая кучу паттернов. Просто это неудобно по сравнению с ФП, где всё из коробки под это заточено.
Я за ним слежу, и даже есть один проект в продакшене. Но по динамике развития, складывается ощущение, что там один Жозе его развивает (это видно по статискике github).
Хм, так вы посмотрите статистику за 2018-й год. На долю Жозе приходится примерно половина коммитов, но как минимум ещё 9 человек активно участвовали.
Но в целом, смотреть динамику развития Elixir по компилятору не очень правильно. Основное развитие идёт в тулинге и в сопутствующих библиотеках. Например, из свеженького Phoenix LiveView
Функциональный подход — «запишите формулу или постройте примитивную математическую модель происходящего»
Совсем нет. Функциональный подход — "опишите конвейер преобразований".
Соответственно, каждый этап самостоятелен и не лезет в детали реализации других этапов, а просто принимает входные данные и выдаёт свой результат.
Только людей с математическим складом ума сильно меньше.
Эм, хоть это никак не относится к выбору подходов, но я как-то не верю в существование программистов с другим складом ума.
Это, кстати, заблуждение — думать что между сайтами-визитками и хайлоадом ничего нет по середине. В моём понимании, большинство — это куча разнообразных проектов с многомиллионными бюджетами, но при этом не предполагающих особых нагрузок. Если посмотреть правде в глаза, то даже средне нагруженных проекты от силы 1% от веб-приложений наберётся (сайты-визитки я в расчёт даже не беру)
Я бы сформулировал, что если не предполагается нагрузка выше 10 rps в среднем за сутки, и хотя бы 50 rps в пиковые часы, то даже смотреть в сторону Go — совершенно нецелесообразно. Понятно, что запросы сильно разные бывают и цифры ориентировочные, но порядок примерно такой.
Ну, кстати, да. Про Node.js забыл.
А что касается массовости, массам и Go не нужен, потому что для большинства проектов вообще пофиг отвечает у тебя сервер за 100 ms или за 30 ms.
Слишком сильно зависит от бэкграунда, поэтому я бы сказал, что сравнить в общем случае невозможно. Кому-то быстрее Go получится освоить, кому-то — C#.
Я больше про то, что все эти "за 1 день" — не более, чем маркетинговый булшит.
Что-то начать писать можно на 1-й день на любом языке (особенно если у вас уже есть пяток ЯП в арсенале), но это не значит, что он освоен.
Потому что Go отъедает рынок у python, php, ruby и пр, где нет единого бинарника.
Это фантазии любителей Go. Python, PHP, Ruby и так для HighLoad не часто использовались. А писать, к примеру, какую-нибудь админку (внутренний проект) с развесистой бизнес-логикой для 1000 юзеров в месяц на Go — это надо сильно упороться.
Go играет на поле Scala, Elixir, Haskell, Rust, C-расширения. Причём первые 3 дают более приятные возможности для программирования.
Потому что иногда приходится возится с бинарником напрямую, и когда это один файл — это удобно.
Зачем с ним возиться напрямую? Вы по FTP что-ли деплоите, как в старые ламповые времена?
Вы ж сами написали: "Простой язык — обратная сторона бедности синтаксиса — возможность освоить язык за 1 день. Даже не за 1 день, а за 1 присест."
Что, мягко говоря, вообще не правда. Go — весьма сложный для освоения язык, потому что граблей по нему разбросано неимоверное количество. Даже статьи с подборками писали, типа 50 Shades of Go. Часть граблей имеет какое-то более-менее разумное объяснение, а часть — WAT чистой воды. Но в любом случае, освоить его быстро не получится, т.к. опереться на предыдущий опыт с другими языками не получится.
jsonb — это во-первых как раз потеря производительности на ровном месте, потому что при размер json больше пары килобайт мне быстрее будет сжимать и обрабатывать json на стороне приложения.
Причём тут сжимать? Это полноценный document-storage без необходимости затаскивать в проект к-н Mongo без крайней необходимости. Плюс с возможностью использовать эти поля в условиях на выборки.
но по-моему сейчас все БД поддерживают gis
Зато не все ORM поддерживают )))
полнотекстовый поиск — отстой в постгресе, с кучей ограничений
Вы показываете низкую квалификацию такими утверждениями. Любое решение имеет свои trade-offs, и полно случаев когда поисковых возможностей PG более чем достаточно, а затаскивать Solr, Sphinx или Elastic в проект — нецелесообразно.
Стандарт стандартом, но во-первых полнота его поддержки отличается в разных СУБД, а во-вторых разные СУБД добавляют разные возможности для оптимизации различных запросов.
А в вашем случае, вам остаётся небольшое подмножество стандарта, которое поддерживается более-менее одинаково основными игроками рынка СУБД, в итоге вы делаете запросы неоптимально и с кучей ненужных костылей. Для простых проектов, конечно, без разницы, а для нетривиальных — это потеря производительности и удобства разработки на ровном месте.
Например, как можно использовать PostgreSQL, но при этом не использовать jsonb, PostGIS, CTE, полнотекстовый поиск, оконные функции, индексы по функциям и т.д.? Я уж молчу про партиционирование и прочие тонкости работы с большими БД.
Среди коллег тоже могут быть друзья, почему бы нет?
Мне кажется, что вы сильно завышаете процент. Или сильно завышаете требования к сеньору.
Да не, реально много людей, которые не знают совсем уж элементарных вещей, не тянут даже на мидла, но при этом пробуются на сеньорские позиции. Возможно у вас просто HR-отдел есть, который первичную фильтрацию осуществляет.
Видимо, вы имеете в виду дословный перевод алгоритмов, основанных на массивах, на функциональные языки. Но это ложная задача, для неизменяемых структур есть свои алгоритмы. А там где надо (например в БД записать или пользователю результат отдать), там сайд-эффекты управляемо возможны штатными средствами стандартной библиотеки.
А вдруг затык в том, что Вы непонятно объясняете функциональщину? xD
В шарпе слабенький паттерн-матчинг, но хоть какой-то добавили — уже плюс, тут спору нет.
Ага, только это иллюзия понимания… Потом человек попадает на сайд-эффект и "весело" проводит неделю за отладкой в полном непонимании как работает эта шайтан машина.
Я ничего не отрицал, потому что изначально не понимаю, чем описание последовательности действий (процедурное программирование) проще, чем описание конвейера?.. Понятно только, что ООП (описание объектов и их взаимодействия) уже точно сложнее.
Тем не менее, всё производство давно уже конвейерное. И если вы хотите стабильный код, вам всё равно придётся отказываться от "последовательности действий" и эмулировать конвейер в императиве, наворачивая кучу паттернов. Просто это неудобно по сравнению с ФП, где всё из коробки под это заточено.
Возможно. Но тот сегмент, который я выше упомянул, это как раз зачастую автоматизация бизнес-процессов с очень развесистой логикой.
Модель асинхронности Go мне, кстати, не нравится, в Erlang/Elixir гораздо интереснее и, на мой взгляд, удобнее.
Хм, так вы посмотрите статистику за 2018-й год. На долю Жозе приходится примерно половина коммитов, но как минимум ещё 9 человек активно участвовали.
Но в целом, смотреть динамику развития Elixir по компилятору не очень правильно. Основное развитие идёт в тулинге и в сопутствующих библиотеках. Например, из свеженького Phoenix LiveView
Совсем нет. Функциональный подход — "опишите конвейер преобразований".
Соответственно, каждый этап самостоятелен и не лезет в детали реализации других этапов, а просто принимает входные данные и выдаёт свой результат.
Эм, хоть это никак не относится к выбору подходов, но я как-то не верю в существование программистов с другим складом ума.
Это, кстати, заблуждение — думать что между сайтами-визитками и хайлоадом ничего нет по середине. В моём понимании, большинство — это куча разнообразных проектов с многомиллионными бюджетами, но при этом не предполагающих особых нагрузок. Если посмотреть правде в глаза, то даже средне нагруженных проекты от силы 1% от веб-приложений наберётся (сайты-визитки я в расчёт даже не беру)
Я бы сформулировал, что если не предполагается нагрузка выше 10 rps в среднем за сутки, и хотя бы 50 rps в пиковые часы, то даже смотреть в сторону Go — совершенно нецелесообразно. Понятно, что запросы сильно разные бывают и цифры ориентировочные, но порядок примерно такой.
Ну, кстати, да. Про Node.js забыл.
А что касается массовости, массам и Go не нужен, потому что для большинства проектов вообще пофиг отвечает у тебя сервер за 100 ms или за 30 ms.
Слишком сильно зависит от бэкграунда, поэтому я бы сказал, что сравнить в общем случае невозможно. Кому-то быстрее Go получится освоить, кому-то — C#.
Я больше про то, что все эти "за 1 день" — не более, чем маркетинговый булшит.
Что-то начать писать можно на 1-й день на любом языке (особенно если у вас уже есть пяток ЯП в арсенале), но это не значит, что он освоен.
Это фантазии любителей Go. Python, PHP, Ruby и так для HighLoad не часто использовались. А писать, к примеру, какую-нибудь админку (внутренний проект) с развесистой бизнес-логикой для 1000 юзеров в месяц на Go — это надо сильно упороться.
Go играет на поле Scala, Elixir, Haskell, Rust, C-расширения. Причём первые 3 дают более приятные возможности для программирования.
Зачем с ним возиться напрямую? Вы по FTP что-ли деплоите, как в старые ламповые времена?
Вы ж сами написали: "Простой язык — обратная сторона бедности синтаксиса — возможность освоить язык за 1 день. Даже не за 1 день, а за 1 присест."
Что, мягко говоря, вообще не правда. Go — весьма сложный для освоения язык, потому что граблей по нему разбросано неимоверное количество. Даже статьи с подборками писали, типа 50 Shades of Go. Часть граблей имеет какое-то более-менее разумное объяснение, а часть — WAT чистой воды. Но в любом случае, освоить его быстро не получится, т.к. опереться на предыдущий опыт с другими языками не получится.
Причём тут сжимать? Это полноценный document-storage без необходимости затаскивать в проект к-н Mongo без крайней необходимости. Плюс с возможностью использовать эти поля в условиях на выборки.
Зато не все ORM поддерживают )))
Вы показываете низкую квалификацию такими утверждениями. Любое решение имеет свои trade-offs, и полно случаев когда поисковых возможностей PG более чем достаточно, а затаскивать Solr, Sphinx или Elastic в проект — нецелесообразно.
Ну, это говорит о том, что Вы и стандарт плохо знаете, потому что они даже там есть, но детали реализации в разных СУБД отличаются. Для чего используются? Много для чего: https://postgrespro.ru/docs/postgresql/10/tutorial-window
90% проектов и даже больше — это тупой CRUD, но это ни разу не повод хотеть заниматься такими проектами.
Что такое "обычное web приложение"? Не хотите поработать над необычным? )))
Возьмите free-тариф на Heroku, для небольшого хобби-проекта вполне норм.
Стандарт стандартом, но во-первых полнота его поддержки отличается в разных СУБД, а во-вторых разные СУБД добавляют разные возможности для оптимизации различных запросов.
А в вашем случае, вам остаётся небольшое подмножество стандарта, которое поддерживается более-менее одинаково основными игроками рынка СУБД, в итоге вы делаете запросы неоптимально и с кучей ненужных костылей. Для простых проектов, конечно, без разницы, а для нетривиальных — это потеря производительности и удобства разработки на ровном месте.
Например, как можно использовать PostgreSQL, но при этом не использовать jsonb, PostGIS, CTE, полнотекстовый поиск, оконные функции, индексы по функциям и т.д.? Я уж молчу про партиционирование и прочие тонкости работы с большими БД.
Ok, убивают программисты, которые не знают SQL и строят запросы через ORM, как через чёрный ящик.
Нет, это либо тривиальные проекты, либо банальная глупость — пользоваться маленьким подмножеством фич конкретной БД.
Среди коллег тоже могут быть друзья, почему бы нет?
Да не, реально много людей, которые не знают совсем уж элементарных вещей, не тянут даже на мидла, но при этом пробуются на сеньорские позиции. Возможно у вас просто HR-отдел есть, который первичную фильтрацию осуществляет.