1. Само собой, но тем не менее.
2. meh
3. В том, что топик о том, что мы сравниваем инфраструктуру и экосистемы руби\рельсов и того же elixir\phoуnix. Конечно всегда можно ответить в духе "ну возьми, да сделай". Только к изначальному вопросу это никак не относится и вы зачем-то пытаетесь постоянно уйти в эту степь.
Я вообще эликсиром не пользуюсь, так что мне всего хватает. Мы не об этом говорим.
Alexey Poimtsev: Вы из принципа не читаете исходный комментарий? Давайте я помогу:
> Ecto *новый* скоро там будет, а ни с чем кроме Psql вроде не работает
За это время в Ecto 2 добавили поддержку MySql еще, да. Но даже список того, с чем работает старый Ecto - достаточно короткий, по сути несколько самых популярных СУБД. (4 штучки, если SQLite вычеркнуть)
webus: + ко всему RoR или Django это уже сформировавшаяся база пакетов, практик и так далее. Не многие захотят от этого отказываться пока не увидят аналогичной среды обитания в Phoenix
webus: не работаю с фронтэндом, не ведаю особо. Пока беглым взглядом - Ecto новый скоро там будет, а ни с чем кроме Psql вроде не работает. Опять же - Elixir это функциональный ЯП, не думаю, что люди прям сразу будут на это перепрыгивать, если вообще будут. Для многих проще прикрутить webpack к рельсам, нежели функциональщина.
Так что процесс будет точно не очень быстрым. Кому очень нужны возможности Elixir - конечно пойдут, кому нет - те нет.
beduin01: Я и не говорю, что там это сложно. Я говорю о том, что приводить в качестве примера работу с преобразованием данных - достаточно странно, с учетом того, что Go главным образом заточен на реализацию высокоэффективных задач сетевого взаимодействия с высоким уровнем отказоустойчивости, если выражаться казенным языком.
Во-вторых, автор вопроса про работу с данными вообще ничего не писал, так причем тут она?
beduin01: В Excel такое тоже будет одной строкой. О чем пример? Go написан для других задач от слова совсем, само собой в каких-то других задачах его использование будет выглядеть странным костылем. Если в вашей работе подобная обработка данных - каждодневный процесс, то не нужно представлять это как единственный тип задач для всех, ну смешно же.
Расскажите лучше как там с параллелизмом, конкурентностью итд.
PS: ну и чисто не холивара для - в приложении\системе с нормальной архитектурой такие танцы с преобразованиями должны быть сведены к минимуму по умолчанию.
Raikov: Клиент сам и рассылает. Они не будут выбирать одного-двух "тех самых", а, как и описано выше, делают выборку по критериям и рассылают предложение N фрилансерам.
Очевидно - самый "простой" (условно) способ попадания в выборку - высокие рейтинги (количество, качество и соотношение показателей)
Артём Иннокентьев И то и другое - обертка над нативным Python, разница в удобстве. Можно и так и эдак, можно использовать голую urllib, как показано ниже.
taki_t: В таком случае решение обычно приходит по той причине, что был сформулирован вопрос. Попробуйте перед тем как его задавать кому-то правильно его сформулировать для себя самого. В правильной постановке вопроса - половина решения.
Про строение надо уточнить, что имеется ввиду. Разный набор полей? Если так, то скорее всего либо привести базу к нужному формату (тогда очевидно, какие-то поля будут пустыми), либо из награбленного убирать ненужное.
