Стиль статьи очень походит на таковой в курсовых работах.
Бросаются в глаза такие вещи, как: 1) утверждения, выходящие за пределы темы (концовка статьи, заключение); 2) голословные утверждения. Например, Вы утверждаете, что интерфейсы Go лучше таковых в других языках, но ничего не пишете, о том, а каково оно у них, да и о каких языках речь-то? Примеры хороши, но они не доказывают, что интерфейсы Go лучше, так как сравнить их не с чем. 3) наличие спорных утверждений, например, об IDE. Это отдельная тема для обсуждения.
Вероятно, что все эти вещи и повлияли на то, что статью заминусовали.
Но ведь публицистика на то и нужна, чтобы доносить проблематику до широкой аудитории и инициировать обсуждение её. А какие ещё книги на тему проблем больших данных Вы можете назвать?
Прежде чем утверждать, что это политика или психоз, разберитесь поглубже в проблеме. На эту тему можно прочитать в книге "Убийственные большие данные" (2016-2018, Кэти О'Нил).
1) Я так понимаю, что ClojureScript Вы не рассматриваете?
2) И ещё, может стоило написать книгу (может будущую) в стиле Cookbook? Раньше такой формат был распространён, и лично мне нравился, но в последние лет десять что-то не встречается (поправьте, если ошибаюсь).
Не стану высказывать здесь своё мнение. Все знают, что в Erlang динамическая типизация. Но вот (к сожалению не вспомнил, где об этом прочитал), Джо Арстронг, автор Erlang, как-то посетовал, что жалеет, что в Erlang изначально не предусмотрели статическую типизацию, и что был проект по её внедрению в него, но когда он был готов на 95%, оказалось, что оставшиеся 5% реализовать невозможно.
Эх, были времена. Тоже двадцать лет назад купил свой первый компьютер и стал экспериментировать с различными ОС. И тогда точно также Linux покорил своей открытостью, настраиваемостью и документированностью. Рабочий стол KDE и Gnome были гораздо привлекательней чем у тогдашней Windows 98. Первым активно используемым Linux был Mandrake. Пробовал также RedHat, Debian. Какое-то время использовал Slackware. Году в 2005 попробовал Ubuntu и остался на ней по сей день. В параллели ставил также FreeBSD, DragonFlyBSD, NetBSD. Особо нравилась NetBSD.
По мне этот код сложен и в чтении, и в написании. Хотелось бы для подобного рода задач иметь инструмент более простой. Поэтому и отправился на поиски такового. :)
(В Node.js встроенный request не Promise-фицирован, что дополнительно доставляет.)
Наверное есть смысл посмотреть на Go. Просто сейчас уже поизучал Python, а Erlang в процессе. Можно даже на примере такой задачки сделать сравнение нескольких языков. :)
404 скриптом отлавливать не проблема, но бывают другие ситуации, когда нужно повторить попытку, например, когда сервер на время блокирует приём подключений от этого скрипта (если их сразу много к одному серверу) или просто не может сразу много принять запросов.
Для сравнения подходов сформулирую простую задачку: дан длинный список URL, нужно по всем ним пройтись и загрузить данные. При этом 1) это должно быть эффективно; 2) в случае сбоев загрузки, повторять попытки до достижения успеха. Знаю, как такое делать на Node.js, скрипт получается сложный и для разработки, и для чтения, но работает хорошо. Соответственно: насколько просто решить такую задачку на Go, Python, Erlang, (write here what you want)?
Несколько лет использовал Node.js. В последнее время выбираю альтернативы: Python, Erlang (Go как-то не по душе). В том числе и по тем же причинам, что описаны в статье.
Мой совет новичку: чтобы узнать, что изучать, нужно не подобные статейки читать, а найти специалиста в области, которой заинтересовался, и расспросить его, что да как. Ещё лучше взять у него несколько уроков. Если специалиста найти не удалось, то пойти в онлайн-магазин книжек и приобрести пару книг по теме для ознакомления с интересующей темой.
Автор не обладает всей полнотой информации: П.3 в плюсах и П.2 в минусах (там где о языках программирования и технологиях) не соответствуют российской действительности. Стандарты на высшее образование никак не регламентируют, что конкретно должно быть в учебных планах и рабочих программах дисциплин.
Стиль статьи очень походит на таковой в курсовых работах.
Бросаются в глаза такие вещи, как: 1) утверждения, выходящие за пределы темы (концовка статьи, заключение); 2) голословные утверждения. Например, Вы утверждаете, что интерфейсы Go лучше таковых в других языках, но ничего не пишете, о том, а каково оно у них, да и о каких языках речь-то? Примеры хороши, но они не доказывают, что интерфейсы Go лучше, так как сравнить их не с чем. 3) наличие спорных утверждений, например, об IDE. Это отдельная тема для обсуждения.
Вероятно, что все эти вещи и повлияли на то, что статью заминусовали.
Этот текст — курсовая работа студента?
Но ведь публицистика на то и нужна, чтобы доносить проблематику до широкой аудитории и инициировать обсуждение её. А какие ещё книги на тему проблем больших данных Вы можете назвать?
Прежде чем утверждать, что это политика или психоз, разберитесь поглубже в проблеме. На эту тему можно прочитать в книге "Убийственные большие данные" (2016-2018, Кэти О'Нил).
Ясно. Спасибо!
1) Я так понимаю, что ClojureScript Вы не рассматриваете?
2) И ещё, может стоило написать книгу (может будущую) в стиле Cookbook? Раньше такой формат был распространён, и лично мне нравился, но в последние лет десять что-то не встречается (поправьте, если ошибаюсь).
Что скажете насчёт Deno (новая среда исполнения с поддержкой TypeScript от самого создателя Node.js.)? Как раз на днях вышла версия 1.0.
Не стану высказывать здесь своё мнение. Все знают, что в Erlang динамическая типизация. Но вот (к сожалению не вспомнил, где об этом прочитал), Джо Арстронг, автор Erlang, как-то посетовал, что жалеет, что в Erlang изначально не предусмотрели статическую типизацию, и что был проект по её внедрению в него, но когда он был готов на 95%, оказалось, что оставшиеся 5% реализовать невозможно.
Нашёл другое интервью с Армстронгом https://www.infoq.com/interviews/Erlang-Joe-Armstrong/, где он ратует за статическую типизацию и признаётся в любви к Haskell.
Смотрю у
axiosесть дополнениеretry. Это хорошо.1) request — функция из стандартного модуля https: https://nodejs.org/dist/latest-v12.x/docs/api/https.html
2) util.promisify — не знал, честно говоря; ну это прекрасно, раз можно Promise-фицировать стандартными средствами. https://nodejs.org/dist/latest-v12.x/docs/api/util.html#util_util_promisify_original
Да, есть. Я использовал
request-promise-native. Но хотелось бы, чтобы Promise-фикация была из коробки.Эх, были времена. Тоже двадцать лет назад купил свой первый компьютер и стал экспериментировать с различными ОС. И тогда точно также Linux покорил своей открытостью, настраиваемостью и документированностью. Рабочий стол KDE и Gnome были гораздо привлекательней чем у тогдашней Windows 98. Первым активно используемым Linux был Mandrake. Пробовал также RedHat, Debian. Какое-то время использовал Slackware. Году в 2005 попробовал Ubuntu и остался на ней по сей день. В параллели ставил также FreeBSD, DragonFlyBSD, NetBSD. Особо нравилась NetBSD.
По мне этот код сложен и в чтении, и в написании. Хотелось бы для подобного рода задач иметь инструмент более простой. Поэтому и отправился на поиски такового. :)
(В Node.js встроенный request не Promise-фицирован, что дополнительно доставляет.)
Наверное есть смысл посмотреть на Go. Просто сейчас уже поизучал Python, а Erlang в процессе. Можно даже на примере такой задачки сделать сравнение нескольких языков. :)
404 скриптом отлавливать не проблема, но бывают другие ситуации, когда нужно повторить попытку, например, когда сервер на время блокирует приём подключений от этого скрипта (если их сразу много к одному серверу) или просто не может сразу много принять запросов.
Для сравнения подходов сформулирую простую задачку: дан длинный список URL, нужно по всем ним пройтись и загрузить данные. При этом 1) это должно быть эффективно; 2) в случае сбоев загрузки, повторять попытки до достижения успеха. Знаю, как такое делать на Node.js, скрипт получается сложный и для разработки, и для чтения, но работает хорошо. Соответственно: насколько просто решить такую задачку на Go, Python, Erlang, (write here what you want)?
Несколько лет использовал Node.js. В последнее время выбираю альтернативы: Python, Erlang (Go как-то не по душе). В том числе и по тем же причинам, что описаны в статье.
Нет, с Dgraph ещё не разбирался.
Мой совет новичку: чтобы узнать, что изучать, нужно не подобные статейки читать, а найти специалиста в области, которой заинтересовался, и расспросить его, что да как. Ещё лучше взять у него несколько уроков. Если специалиста найти не удалось, то пойти в онлайн-магазин книжек и приобрести пару книг по теме для ознакомления с интересующей темой.
Автор не обладает всей полнотой информации: П.3 в плюсах и П.2 в минусах (там где о языках программирования и технологиях) не соответствуют российской действительности. Стандарты на высшее образование никак не регламентируют, что конкретно должно быть в учебных планах и рабочих программах дисциплин.