Долгое время Elixir был (да и сейчас есть, пожалуй) эдакий RoR на стероидах. Как бы и Руби, но поверх BEAM, так что много вкусняшек из коробки. Да, я в курсе про всякие WhatsApp, но на общем фоне они погоды не делают.
И тут проскакивает новость, что автор Эликсира Жозе Валим решил запилить некое чудо под названием Project Nx и создает некую Machine Learning Working Group и всецело себя посвящает этой задаче. В принципе, если посмотреть на другие его творения, типа Phonix, Ecto ну и конечно же сам Elixir, что-то интересное безусловно будет создано.
Но это всё вступление, картина крупным планом. А вот что меня интересует, так это будет ли какой-то потенциально интересный выхлоп для ML сообщества в замене того же однопоточного Python на миллион-поточный-и-всё-летает Elixir? Расчеты всяко же будут на GPU, со всякими TensorFlow и PyTourch, но тогда вроде всё и так есть и ничего нового не надо? Или всё же идея хорошая?
Здравствуйте, kaa.python, Вы писали:
KP>Но это всё вступление, картина крупным планом. А вот что меня интересует, так это будет ли какой-то потенциально интересный выхлоп для ML сообщества в замене того же однопоточного Python на миллион-поточный-и-всё-летает Elixir? Расчеты всяко же будут на GPU, со всякими TensorFlow и PyTourch, но тогда вроде всё и так есть и ничего нового не надо? Или всё же идея хорошая?
Если он этим занялся значит кто-0то за это платит. Мне вот интересно, какой бизнес будет строить инфраструктуру вокруг BEAM + ML? Неужели в телеком это проникает, но вопрос тогда в каком виде?
Здравствуйте, kaa.python, Вы писали:
KP>Но это всё вступление, картина крупным планом. А вот что меня интересует, так это будет ли какой-то потенциально интересный выхлоп для ML сообщества в замене того же однопоточного Python на миллион-поточный-и-всё-летает Elixir? Расчеты всяко же будут на GPU, со всякими TensorFlow и PyTourch, но тогда вроде всё и так есть и ничего нового не надо? Или всё же идея хорошая?
В ML есть такой неприятный момент, что оно, зараза, проникает повсюду. Значит питон и расчёты в облаках становятся лишь стадией прототипирования. Нужен "язык для проадакшена". Теоретически — С/С++. Практически — а где ты столько годных плюсовиков найдёщь? Поэтому яблочники что-то пытаются на своём Сфифте изобразить, где-то в финансах, слышал, Юленьку мучают, а эти вот решили веб-маргинальщиной развлечься. Всё хорошо. Больше попыток — больше щансов на пресловутое перерастание качества в количество.
Здравствуйте, Kernan, Вы писали:
K>Если он этим занялся значит кто-0то за это платит. Мне вот интересно, какой бизнес будет строить инфраструктуру вокруг BEAM + ML? Неужели в телеком это проникает, но вопрос тогда в каком виде?
Может как El Camino Real предполагает — более простой способ запуска уже натренированных моделей в продакшн? Звучит разумно, особенно с учетом того, на сколько просто вести разработку на Elixir.
То есть это точно не для телекома, т.к. Elixir не для телекома, а для веб-приложений в первую очередь, просто на базе BEAM с OPT.
Здравствуйте, El Camino Real, Вы писали:
ECR>В ML есть такой неприятный момент, что оно, зараза, проникает повсюду. Значит питон и расчёты в облаках становятся лишь стадией прототипирования. Нужен "язык для проадакшена". Теоретически — С/С++. Практически — а где ты столько годных плюсовиков найдёщь? Поэтому яблочники что-то пытаются на своём Сфифте изобразить, где-то в финансах, слышал, Юленьку мучают, а эти вот решили веб-маргинальщиной развлечься. Всё хорошо. Больше попыток — больше щансов на пресловутое перерастание качества в количество.
Ну т.е. просто еще одни биндинги к основным системам машинного обучения для запуска моделей в проде? Да, такой вариант звучит разумно, принимая во внимание то, что BEAM приложения довольно легко масштабируются из коробки, чего про C++ приложения не скажешь
KP>Ну т.е. просто еще одни биндинги к основным системам машинного обучения для запуска моделей в проде?
Угадал.
Вступай в EEF ML WG, ее как раз сегодня одобрили на board meeting. Будешь founding member, требуется всего ничего, 5 часов в месяц работать над какими-нибудь связанными с этим всем проблемами.
Здравствуйте, El Camino Real, Вы писали:
ECR>В ML есть такой неприятный момент, что оно, зараза, проникает повсюду. Значит питон и расчёты в облаках становятся лишь стадией прототипирования. Нужен "язык для проадакшена". Теоретически — С/С++. Практически — а где ты столько годных плюсовиков найдёщь? Поэтому яблочники что-то пытаются на своём Сфифте изобразить
И не только яблочники. Гугл на базе swift хотел сделать новый TF, но обломился. Ниша для такого языка по прежнему свободна.
Здравствуйте, Nuzhny, Вы писали:
N>И не только яблочники. Гугл на базе swift хотел сделать новый TF, но обломился. Ниша для такого языка по прежнему свободна.
Здравствуйте, kaa.python, Вы писали:
KP>А что пошло не так?
Вроде бы создатель Chris Lattner ушёл из Гугла. Но, думаю, что это эхо причины, а не она сама.
С другой стороны, все его наработки включаются в основной репозиторий языка, так что работа была проделана не напрасно.
Здравствуйте, johny5, Вы писали:
N>>Ниша для такого языка по прежнему свободна. J>Может Julia стала таким языком?
Ещё точно не стала и непонятно станет ли в будущем. Как бы данные у неё есть для этого для тех, кто переходит с Матлаба. Но с другой стороны, индексация с 1 может сломать мозг программистам.
Здравствуйте, kaa.python, Вы писали:
KP>А вот что меня интересует, так это будет ли какой-то потенциально интересный выхлоп для ML сообщества в замене того же однопоточного Python на миллион-поточный-и-всё-летает Elixir? Расчеты всяко же будут на GPU, со всякими TensorFlow и PyTourch, но тогда вроде всё и так есть и ничего нового не надо? Или всё же идея хорошая?
Чем оно будет лучше Julia?
Чем хуже? скоростью и экосистемой.
Здравствуйте, Nuzhny, Вы писали:
N>Но с другой стороны, индексация с 1 может сломать мозг программистам.
+1
Проблема на ровном месте. Идиотизм уровня "в DOS будут другие слэши".
Здравствуйте, novitk, Вы писали:
N>Чем оно будет лучше Julia?
Если я правильно понял СкайДанса, то оно немного про другое получается (к сожалению). На Юлии ты можешь (качество "моженья" не трогаем) прототип, обвязки к существующим вычислительным ядрам и даже своё собственное вычислительное ядро замутить. А тут получается как бы назвать-то... ML middleware что ли. На первый взгляд, похоже на Dask. Там numpy массивы заменили на свою супер-масштабируемую реализацию, а здесь библиотеку тензоров Nx сделали. И всё это теоретически должно опираться на масштабируемость и простоту развёртыванию присущие Elixir. Теоретически
Здравствуйте, kaa.python, Вы писали:
KP>Но это всё вступление, картина крупным планом. А вот что меня интересует, так это будет ли какой-то потенциально интересный выхлоп для ML сообщества в замене того же однопоточного Python на миллион-поточный-и-всё-летает Elixir? Расчеты всяко же будут на GPU, со всякими TensorFlow и PyTourch, но тогда вроде всё и так есть и ничего нового не надо? Или всё же идея хорошая?
Поезд ушёл.
Для экспериментов PyTorch рулит. Для production'а он тоже рулит, так TorchScript компилируется в С++. Так что натренированную и отлаженную модель можно одним движением пальца ноги превратить в автономный бинарик, для развёртывания хоть на iPhone'ах. Особенно учитывая, что PyTorch можно конвертировать в модели для CoreML.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kaa.python, Вы писали:
C>Для экспериментов PyTorch рулит. Для production'а он тоже рулит, так TorchScript компилируется в С++. Так что натренированную и отлаженную модель можно одним движением пальца ноги превратить в автономный бинарик, для развёртывания хоть на iPhone'ах. Особенно учитывая, что PyTorch можно конвертировать в модели для CoreML.
Не знаю. Если у нас инференс на nvidia, то переписываем на C++ и TensorRT. Если на x86, то переписываем на C++ и OpenVINO. Все быстрее PyTorch. Кажется, что обучение и продакшен пока в одном инструменте полноценно не совмещаются.
Здравствуйте, Cyberax, Вы писали:
C>Для экспериментов PyTorch рулит. Для production'а он тоже рулит, так TorchScript компилируется в С++. Так что натренированную и отлаженную модель можно одним движением пальца ноги превратить в автономный бинарик, для развёртывания хоть на iPhone'ах. Особенно учитывая, что PyTorch можно конвертировать в модели для CoreML.
т.е. ты тренируешь модель на Python и тебе даже не надо притрагиваться к Плюсам? Звучит интересно, а насколько оно по скорости адекватно работает?
Всё же если говорить решение на базе BEAM, то там будет доступ к OTP что дает довольно неожиданные возможности для распределённых вычислений. Ни Python ни C++ такого нет и иметь не будут.
Здравствуйте, SkyDance, Вы писали:
SD>Вступай в EEF ML WG, ее как раз сегодня одобрили на board meeting. Будешь founding member, требуется всего ничего, 5 часов в месяц работать над какими-нибудь связанными с этим всем проблемами.
Звучит потенциально интересно. А где можно детали узнать?
Здравствуйте, Nuzhny, Вы писали:
N>Не знаю. Если у нас инференс на nvidia, то переписываем на C++ и TensorRT. Если на x86, то переписываем на C++ и OpenVINO. Все быстрее PyTorch. Кажется, что обучение и продакшен пока в одном инструменте полноценно не совмещаются.
Вообще да. У нас тоже PyTorch для обучения, а потом уже мы на плюсы переносим. Но сейчас уже пошли SoC с ML-модулями способными напрямую выполнять натренированную модель с минимальными затратами электричества, что вообще круто для встраиваемых систем.
Здравствуйте, kaa.python, Вы писали:
KP>Вообще да. У нас тоже PyTorch для обучения, а потом уже мы на плюсы переносим. Но сейчас уже пошли SoC с ML-модулями способными напрямую выполнять натренированную модель с минимальными затратами электричества, что вообще круто для встраиваемых систем.
Все так, но дорого. Для встраиваемых конечная цель — запускать на дешёвом арме и чтоб оно само себя дообучало по ходу пьесы. И пока не видел хорошего решения.
Здравствуйте, El Camino Real, Вы писали:
ECR>В ML есть такой неприятный момент, что оно, зараза, проникает повсюду. Значит питон и расчёты в облаках становятся лишь стадией прототипирования. Нужен "язык для проадакшена". Теоретически — С/С++. Практически — а где ты столько годных плюсовиков найдёшь?
Программистов на C++ уж всяко легче найти, чем на какой-нибудь экзотике.
Здравствуйте, El Camino Real, Вы писали:
ECR>Все так, но дорого. Для встраиваемых конечная цель — запускать на дешёвом арме и чтоб оно само себя дообучало по ходу пьесы. И пока не видел хорошего решения.
Сам себя обучать — это пока фантастика. В лучшем случае как в Тестле: отправлять данные на сервер, где будет идти контролируемое пополнение датасета, дообучение и обновление моделей на устройствах.
Здравствуйте, kaa.python, Вы писали:
KP>т.е. ты тренируешь модель на Python и тебе даже не надо притрагиваться к Плюсам? Звучит интересно, а насколько оно по скорости адекватно работает?
Да, все модели на TorchScript. Который, кстати, JIT-компилируется при необходимости. Обучение идёт или на AWS-инстансах, или на своём небольшом кластере из 50 видеокарт.
KP>Всё же если говорить решение на базе BEAM, то там будет доступ к OTP что дает довольно неожиданные возможности для распределённых вычислений. Ни Python ни C++ такого нет и иметь не будут.
Ну так а смысл? Для тренировки нейронок ничего распределённого не нужно. А запускать будут, один фиг, или на устройствах пользователя (iOS, Android — никакого BEAM), или на серверах (где тоже таки нужна скорость).
Лет 5 назад ещё можно было что-то сделать, а сейчас ниша уже прочно занята.
Здравствуйте, Cyberax, Вы писали:
C>Ну так а смысл? Для тренировки нейронок ничего распределённого не нужно.
Так вот это я и хочу понять. Однозначно не глупые люди зачем-то же решили запилить Nx. Просто что бы было я не исключаю, но как-то это грустно звучит.
C>Лет 5 назад ещё можно было что-то сделать, а сейчас ниша уже прочно занята.
А почему 5 лет назад такая штука была бы полезна?
Я, наверное, глупые вопросы задаю, просто мои познания в машинном обучении ограниченны курсом Энга
Здравствуйте, El Camino Real, Вы писали:
ECR>Все так, но дорого. Для встраиваемых конечная цель — запускать на дешёвом арме и чтоб оно само себя дообучало по ходу пьесы. И пока не видел хорошего решения.
Зависит от задачи. Для тех же AV есть интересные решения от компаний типа Ambarella. ASIL-D решений я не видел, но ASIL-B есть.
Хосе хочет эту WG возглавить, и использовать бюджет EEF для различных работ. Это означает conflict of interest с его нынешней позицией (board member), поэтому он и уходит с нее (как раз перед выборами, кстати, которые уже через неделю откроются). В этом году, кстати, я в списке на перевыборы, и в определенном роде это решение Хосе мне на руку, больше шансов остаться в board.
Здравствуйте, kaa.python, Вы писали:
C>>Ну так а смысл? Для тренировки нейронок ничего распределённого не нужно. KP>Так вот это я и хочу понять. Однозначно не глупые люди зачем-то же решили запилить Nx. Просто что бы было я не исключаю, но как-то это грустно звучит.
Видимо, чтобы хоть как-то поймать уезжающий поезд. Сам язык уже практически однозначно сдулся, так как его использование не нарастает.
C>>Лет 5 назад ещё можно было что-то сделать, а сейчас ниша уже прочно занята. KP>А почему 5 лет назад такая штука была бы полезна?
Потому, что тогда ещё не было развитой питоновской инфраструктуры. Сам по себе ведь Питон для ML не сильно важен как язык, важны инструменты вокруг него (включая и всякие OpenCV, NumPy, и т.п.)
KP>Я, наверное, глупые вопросы задаю, просто мои познания в машинном обучении ограниченны курсом Энга
А хороший пример, кстати. Курс от товарища Нья делается в Jupyter, что сейчас практически является однозначным требованием для ML-инструментов.
KP>Переобучить программиста на любом языке в программиста на Elixir — это 1-2 месяца.
Синтаксис, да.
Но даже очень сообразительный разработчик с хорошим опытом на императивных языках потратит не менее года (а чаще два) на то, чтобы начать писать более-менее идиоматично на Erlang/Elixir/LFE. И то только при условии что его будет менторить еще более опытный товарищ, включая diff reviews.
Уж слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution — на освоение всего этого требуется время и много усилий.
Здравствуйте, SkyDance, Вы писали:
SD>Но даже очень сообразительный разработчик с хорошим опытом на императивных языках потратит не менее года (а чаще два) на то, чтобы начать писать более-менее идиоматично на Erlang/Elixir/LFE. И то только при условии что его будет менторить еще более опытный товарищ, включая diff reviews.
SD>Уж слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution — на освоение всего этого требуется время и много усилий.
В каких именно целях?
Если просто из любопытства, то, наверное, я бы просто рекомендовал начать с какой-нибудь литературы. Например, с книги "Learn you some Erlang", написанную Фредом Хебертом, веселым канадцем.
Другой вариант, сделать что-то работающее, какую-нибудь классику вроде чата. Или поднять свой ejabberd сервер (это с чего whatsapp начинался).
Хотелось бы в общих чертах понять, что Вы имели ввиду, когда писали "писать более-менее идиоматично на Erlang/Elixir/LFE" и "слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution".
Я так понимаю, что при разработке distributed систем каждый раз возникают типовые задачи.
И в Erlang выработаны подходы/инструменты для их решения.
Хотелось бы понять, что это за подходы, их +/- и почему они такие.
PS Что-то типа книжек, в которых авторы технологий с нуля объясняют, какие задачи идеи у них были на старте, что сработало, а что нет, что и почему они сделали в итоге.
SL>Хотелось бы в общих чертах понять, что Вы имели ввиду, когда писали "писать более-менее идиоматично на Erlang/Elixir/LFE" и "слишком много надо шаблонов сорвать. Мало того, что функциональный (но не совсем) подход, так еще и shared (nothing), и к concurrency совсем другое отношение, и (полу)прозрачный distribution".
У разработчика с опытом в других языках есть багаж знаний, который делает освоение функциональных (и тем более распределенных) языков сложным.
Могу, пожалуй, порекомендовать лекцию Роберта Вирдинга, там есть немного по теме.
SL>Я так понимаю, что при разработке distributed систем каждый раз возникают типовые задачи.
После 20 лет в индустрии любые задачи кажутся типовыми. И это ведет к типовым же решениям. Которые, внезапно, оказываются сразу же устаревшими на 20 лет. Потом история делает новый виток, и рождается еще один подход, который, разумеется, повторяет предыдущие, но со своими особенностями. За справкой можно пройти к войнам между "ServiceLocator" и "DependencyInjecton"
SL>И в Erlang выработаны подходы/инструменты для их решения. SL>Хотелось бы понять, что это за подходы, их +/- и почему они такие.
Ага! За этим можно обратиться к Бьярну Декеру, и его выступлениям на конференциях, про историю Ericsson Labs, как Эрланг получился таким, какой он есть.
SL>PS Что-то типа книжек, в которых авторы технологий с нуля объясняют, какие задачи идеи у них были на старте, что сработало, а что нет, что и почему они сделали в итоге.
Да, как раз что нужно. Можно начать с исторической справки. Забавно, что ровно через 10 минут начинается второй день конференции CodeBEAM America (увы, virtual), где Бьярн будет повторять это выступление. Ибо, видимо, все еще актуально.
Здравствуйте, kaa.python, Вы писали:
KP>Долгое время Elixir был (да и сейчас есть, пожалуй) эдакий RoR на стероидах. Как бы и Руби, но поверх BEAM, так что много вкусняшек из коробки. Да, я в курсе про всякие WhatsApp, но на общем фоне они погоды не делают.
А какая связь с Руби и МЛ? Я понимаю Elixir это развитие Элранга. Он конечно похож чем-то МЛ, так как тоже ФП. Но как-то это все натянуто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А какая связь с Руби и МЛ? Я понимаю Elixir это развитие Элранга. Он конечно похож чем-то МЛ, так как тоже ФП. Но как-то это все натянуто.
У Руби никакой, и у Эликсира никакой. А вот что в случае с Руби, что в случае с Эликсиром чуть ли не единственный заметный сценарий использования — написание CRUD. Ну и писал Эликсир автор РоР, так что они крайне похожи.
KP>У Руби никакой, и у Эликсира никакой. А вот что в случае с Руби, что в случае с Эликсиром чуть ли не единственный заметный сценарий использования — написание CRUD. Ну и писал Эликсир автор РоР, так что они крайне похожи.
Ты что-то перепутал. Хосе не писал ruby on rails. Хосе сначала увлекся РоР, а потом познакомился с BEAM, и очень ему эта виртуальная машина понравилась. Но т.е. РоР ему тоже очень нравился, он смог сделать Руби на BEAM. Не просто сделать, а еще и с финансированием под это — что втройне сложная задача!
На Elixir CRUD, конечно, удобно, но это отнюдь не единственная задача, под которую он годен. Еще есть много всяких data processing pipelines, всякие там distributed systems, ну а теперь, с развитием beam/erlang/..., и вовсе можно на planetary scale applications замахиваться.
Здравствуйте, SkyDance, Вы писали:
SD>Ты что-то перепутал. Хосе не писал ruby on rails. Хосе сначала увлекся РоР, а потом познакомился с BEAM, и очень ему эта виртуальная машина понравилась. Но т.е. РоР ему тоже очень нравился, он смог сделать Руби на BEAM. Не просто сделать, а еще и с финансированием под это — что втройне сложная задача!
José Valim is co-founder of Plataformatec, creator of the Elixir programming language and member of the Ruby on Rails Core Team.
SD>На Elixir CRUD, конечно, удобно, но это отнюдь не единственная задача, под которую он годен.
Это единственная задача на данный момент где он хоть как-то заметен. Что такое современный Elixir? Это Phoenix + Ecto и... и всё
SD> Еще есть много всяких data processing pipelines, всякие там distributed systems, ну а теперь, с развитием beam/erlang/..., и вовсе можно на planetary scale applications замахиваться.
Много что можно, даже на C++ такое написать можно, и что интересно писали и пишут. А еще можно Scala с Akka взять и будет тебе фактически тот же Elixir, разве что пошустрее работающий, но статически типизированный. Planetary scale applications на динамически типизированном языке, пусть и с ништяками типа сопоставления с образцом это идея сильно на любителя. Я знаю что ты как раз в компании таких любителей, но то, что мало кто еще использует таким образом BEAM (в планетарном масштабе) говорит о плохом масштабировании с точки зрения человеческих ресусов (сам-то BEAM шикарно масштабируется).
Тоесть я за BEAM и Elixir, очень хорошие инструменты, но на данный момент они слабо подходят для старта чего-то кроме CRUD в коммерческой разработке. Что бы не быть голословным, я поработал немного в компании фанатов Elixir-а и заметил интересную особенность. Как только ты хоть на шаг отходишь от CRUD, у тебя появляется гора других языков. Надо прикрутить NLP — привет микросервисы на Python. Надо добавить интеграцию с ClickHouse — привет микросервисы на Go. И так всё время!
José Valim is co-founder of Plataformatec, creator of the Elixir programming language and member of the Ruby on Rails Core Team.
Между "автором РоР" (Дэвид) и контрибутором есть большая разница А то так и меня можно было бы автором эрланга назвать, да?
KP>Тоесть я за BEAM и Elixir, очень хорошие инструменты, но на данный момент они слабо подходят для старта чего-то кроме CRUD в коммерческой разработке. Что бы не быть голословным, я поработал немного в компании фанатов Elixir-а и заметил интересную особенность. Как только ты хоть на шаг отходишь от CRUD, у тебя появляется гора других языков. Надо прикрутить NLP — привет микросервисы на Python. Надо добавить интеграцию с ClickHouse — привет микросервисы на Go. И так всё время!
Так это же твой выбор — "прикрутить". Посмотри на того же Jose Valim, он ведь тоже мог бы "прикрутить pytorch" (и да, прикрутил).
Но есть и другой подход. Реализовать на родном языке, Erlang/Elixir/..., а то и вовсе изобрести.
Мы о разных вещах говорим просто. Я о фундаментальных. Ты — о прикладных.
Здравствуйте, VladD2, Вы писали:
VD>А какая связь с Руби и МЛ? Я понимаю Elixir это развитие Элранга. Он конечно похож чем-то МЛ, так как тоже ФП. Но как-то это все натянуто.
МЛ это машин лёрнинг, а не ML как язык.
Здравствуйте, SkyDance, Вы писали:
SD>Так это же твой выбор — "прикрутить". Посмотри на того же Jose Valim, он ведь тоже мог бы "прикрутить pytorch" (и да, прикрутил). SD>Но есть и другой подход. Реализовать на родном языке, Erlang/Elixir/..., а то и вовсе изобрести.
Это выбор обусловленный необходимостью разрабатывать коммерческий продукт. По большому счету, то что ты пишешь можно применить практически к любому языку, даже к тому же C++. Там тоже можно что угодно взять да прикрутить. А на практике, в коммерческой разработке, приходится исходить из того что уже прикручено. А к Elixir полноценно прикручен исключительно CRUD, ну и само собой OTP доставшийся по наследству.
SD>Мы о разных вещах говорим просто. Я о фундаментальных. Ты — о прикладных.
Фундаментально на JS можно написать эмулятор компьютера, и даже кто-то написал. Но на практике эта идея так себе.
KP>Это выбор обусловленный необходимостью разрабатывать коммерческий продукт. По большому счету, то что ты пишешь можно применить практически к любому языку, даже к тому же C++. Там тоже можно что угодно взять да прикрутить.
Ага, помню-помню. Важно не то, какого качества продукт, а то, что оно запахло раньше других.
Странно, что народ так возмущается копроэкономикой.
Здравствуйте, Kernan, Вы писали:
K>МЛ это машин лёрнинг, а не ML как язык.
Так не надо использовать устоявшиеся названия. Тем более, что МЛ — это официальное имя зыка.
А какое на фиг машинное обучение может быть на медленных интерпретируемых языках? Народ вон видюхи задействует и мега-процессоры с морем ядер. Там любое вычисление на счету и оптимизируете. Эрланг здесь не по назначению получается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Так не надо использовать устоявшиеся названия. Тем более, что МЛ — это официальное имя зыка.
Влад, у меня есть подозрение, что то, что ML — это язык, знают куда меньше разработчиков чем про то, что ML — это machine learning.
VD>А какое на фиг машинное обучение может быть на медленных интерпретируемых языках? Народ вон видюхи задействует и мега-процессоры с морем ядер. Там любое вычисление на счету и оптимизируете. Эрланг здесь не по назначению получается.
Модель учат, тестируют и т.д. на Python, который еще медленнее Erlang-а. Тут скорее про удобные биндинги к плюсовым библиотекам.
VD>А какое на фиг машинное обучение может быть на медленных интерпретируемых языках? Народ вон видюхи задействует и мега-процессоры с морем ядер. Там любое вычисление на счету и оптимизируете. Эрланг здесь не по назначению получается.
Erlang может точно так же задействовать "мега-процессоры и видяхи". Да уже и не совсем интерпретируемый, ибо реализован JIT (точнее, AoT, — изначально шли к JIT, но выяснилось, что иногда лучше как проще, чем как круче, и весь эрланг, однако, как раз про это).
Здравствуйте, VladD2, Вы писали:
VD>Так не надо использовать устоявшиеся названия. Тем более, что МЛ — это официальное имя зыка.
Мужик, ты застрял в 2000, всё же поменялось давно и не один раз. VD>А какое на фиг машинное обучение может быть на медленных интерпретируемых языках?
Ну вот мы и увидим что нам предложит Жозе Валим.
Здравствуйте, SkyDance, Вы писали:
SD>Erlang может точно так же задействовать "мега-процессоры и видяхи". Да уже и не совсем интерпретируемый, ибо реализован JIT (точнее, AoT, — изначально шли к JIT, но выяснилось, что иногда лучше как проще, чем как круче, и весь эрланг, однако, как раз про это).
Эрланг принципиально не оптимизируем. Ну как скрипт для склеивания, конечно проканает. Но идея бредовая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kaa.python, Вы писали:
KP>Влад, у меня есть подозрение, что то, что ML — это язык, знают куда меньше разработчиков чем про то, что ML — это machine learning.
А ты демал, что на сайт домохозяек зашел?
KP>Модель учат, тестируют и т.д. на Python, который еще медленнее Erlang-а. Тут скорее про удобные биндинги к плюсовым библиотекам.
Не ну учить и на китайском можно, но писать придется на чем то более подходящем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
KP>>Модель учат, тестируют и т.д. на Python, который еще медленнее Erlang-а. Тут скорее про удобные биндинги к плюсовым библиотекам. VD>Не ну учить и на китайском можно, но писать придется на чем то более подходящем.
Писать что? Сейчас пишут пайплайн обучения практически все на Питоне, что-то другое — доли процента. Инференс уже часто на другом (и это другое С++), но кажется, что Питон и тут один из лидеров на серверах: обучили модельку, соптимизировали, может сконвертировали в, например, TensorRT, завернули в докер и поставили. На мобилках — да, там Питона будет меньше.
Так что в текущей реальности ты не прав.
N>Писать что? Сейчас пишут пайплайн обучения практически все на Питоне, что-то другое — доли процента. Инференс уже часто на другом (и это другое С++)
Именно это и будет с Erlang/Elixir/Nx: C++ bindings для инференса будут запускаться из BEAM. По крайней мере такова задумка. Так что Nerves получит второе дыхание, Peer уже радостно потирает руки
Здравствуйте, SkyDance, Вы писали:
SD>Именно это и будет с Erlang/Elixir/Nx: C++ bindings для инференса будут запускаться из BEAM. По крайней мере такова задумка. Так что Nerves получит второе дыхание, Peer уже радостно потирает руки
Но для этого уже есть Python в купе с NumPy, Pandas, Matplot и еще кучей библиотек и, конечно же, Jupyter. Чего такого есть в Elixir чего нет в экосистеме Python? Вернее как, всего вышеперечисленного нет, так за счет чего ожидается откусывание куска пирога?
KP>Но для этого уже есть Python в купе с NumPy, Pandas, Matplot и еще кучей библиотек и, конечно же, Jupyter. Чего такого есть в Elixir чего нет в экосистеме Python? Вернее как, всего вышеперечисленного нет, так за счет чего ожидается откусывание куска пирога?
Есть Phoenix всякие там, вкупе со всей телеметрией, а также BEAM — concurrency, distribution, fault tolerance.
Вопрос лишь в том, хватит ли сил научить людей пользоваться всем этим. Это основная сложность. Вот если б в школе преподавать все эти вещи (не обязательно на эрланге/эликсире), было бы куда лучше.
Здравствуйте, SkyDance, Вы писали:
SD>Erlang может точно так же задействовать "мега-процессоры и видяхи".
Эрланг — не может. С Эрланга — можно. Но сразу встает вопрос, а на фиг он там уперся, если сами вычисления производятся не на нем и не с его помощью.
SD>Да уже и не совсем интерпретируемый, ибо реализован JIT (точнее, AoT, — изначально шли к JIT, но выяснилось, что иногда лучше как проще, чем как круче, и весь эрланг, однако, как раз про это).
Это принципиально скрптовый язык. Он не может быть быстрым в числодробильных целях. Ну, и опять таки повторюсь, если переносить вычисления на видюхи, все свойства хост-языка вообще рояли не играют. Скорее будет важно насколько язык позволяет разные выкрутасы позволяющие упросить написание и выполнение этих самых алгоритмов на видюхах. У меня начальник на дотнете этим делом занимается, например. Участвует в пенесометриях где очень разные языки используются. И вроде как в топы выбиваются.
Эрланг же интересен своей рантайм-средой позволяющей распределять вычисления и делать отказоустойчивые решения. К подходам принятым в машин-лернинге это как-то не очень близко.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kernan, Вы писали:
K>Мужик, ты застрял в 2000, всё же поменялось давно и не один раз.
С падения Римской империи прошло до нашей эры. Но термины придуманные в то время живут до сих пор и не меняются.
K>Ну вот мы и увидим что нам предложит Жозе Валим.
Не думаю, что увидим. Но хуже не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuzhny, Вы писали:
N>Писать что? Сейчас пишут пайплайн обучения практически все на Питоне, что-то другое — доли процента.
Это в твоем воображении. А в реальности много на чем делают. У меня начальник на Шарпе пишет. Причем и код что на видюхе это считает, тоже.
N>Инференс уже часто на другом (и это другое С++), но кажется, что Питон и тут один из лидеров на серверах: обучили модельку, соптимизировали, может сконвертировали в, например, TensorRT, завернули в докер и поставили. На мобилках — да, там Питона будет меньше.
Да запускалка она какой угодно может быть. Вопрос в том на чем и как написаны сами вычислительные алгоритмы. Ну, и в самих алгоритмах, конечно.
N>Так что в текущей реальности ты не прав.
Да, конечно. Один ты прав.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это в твоем воображении. А в реальности много на чем делают. У меня начальник на Шарпе пишет. Причем и код что на видюхе это считает, тоже.
Интересно. А код во что потом транслируется? Это C# поверх LLVM? Или NVPTX?
VD>Да запускалка она какой угодно может быть. Вопрос в том на чем и как написаны сами вычислительные алгоритмы. Ну, и в самих алгоритмах, конечно.
Пока тут вариантов практически и нет: С, С++, CUDA. Далее уже идут всякие ПЛИС, TPU и другие нейроускорители, для них я даже не знаю на чём пишут.
VD>А ты ник прочесть не можешь? Лучше бы разобрался в причинах или спросил у тех кто разбирался.
Окей, спрашиваю про причины.
Про "кто разбирался" тоже интересно. А то ведь заявление ну очень сильное: "VD>Эрланг принципиально не оптимизируем."
Он настолько не оптимизируем, что свежий RC1 работает в среднем на 40% быстрее предыдуших версий. Для некоторых случаев вообще в 2-3 раза ускорение (как раз для вычислительных ворклоадов).
PS: ты б тоже разобрался, кто здесь кто. А то ведь, внезапно, здесь есть люди, не по наслышке знакомые даже с темными закоулками Эрланга и его виртуальной машины.
Здравствуйте, SkyDance, Вы писали:
SD>Он настолько не оптимизируем, что свежий RC1 работает в среднем на 40% быстрее предыдуших версий. Для некоторых случаев вообще в 2-3 раза ускорение (как раз для вычислительных ворклоадов).
Не так давно было выступление с какой-то конференции, где рассказывали об интеграции LLVM с BEAM для оптимизации кода. Там что-то типа 100% ускорения получалось относительно предыдущих версий. Ты об этом?
KP>Не так давно было выступление с какой-то конференции, где рассказывали об интеграции LLVM с BEAM для оптимизации кода. Там что-то типа 100% ускорения получалось относительно предыдущих версий. Ты об этом?
LLVM оказался тупиковой веткой. Но в целом да, JIT (точнее, AoT), простой, но очень действенный.
Здравствуйте, SkyDance, Вы писали:
SD>Окей, спрашиваю про причины.
Причина в организации самого языка. Идея атомов и структурных объектов, основанных на них, не очень дружит с оптимизациями. Далее числа расширяемой длинны. Очень удобно для программиста (особенно для не профессионального), но просто драматически сказывается на производительности. Все тоже самое, например, у Лиспа. Есть типа оптимизирующие компиляторы последнего, но они и рядом не стояли с оптимизирующими компиляторами С++. Связанные списки хороши с точки зрения абстракции, но хреновы на практике, так как приводят к непоследовательному хранению элементов и, как следствие, более частым промахам в кэше. Создание оптимизирующего компилятора вообще очень дорогая задача. И делать его для не подходящего для этого языка никто не будет. Ну, разве что гики, у которых просто не хватит бабла для разработки подобного масштаба. Даже МС для своего дотнета пока что не создал ничего похожего на оптимизирующие компиляторы С++, хотя у него потенциал есть.
SD>Про "кто разбирался" тоже интересно. А то ведь заявление ну очень сильное: "VD>Эрланг принципиально не оптимизируем."
Прикинь есть люди, которые занимаются разработкой ЯП и могут прикинуть возможности по оптимизации тех или иных языков в соответствии со своим опытом.
SD>Он настолько не оптимизируем, что свежий RC1 работает в среднем на 40% быстрее предыдуших версий. Для некоторых случаев вообще в 2-3 раза ускорение (как раз для вычислительных ворклоадов).
Среднее отставание интерпретируемых языков от компилируемых обычно составляет 10 раз. Есть некоторые задачи на которых интерпретаторы могут померяться с компиляторами, но как только речь заходит о сложных вычислительных задачах с неопределенным алгоритмами они по любому начинают сливать. Это закон. А уж меряться с оптимизирующими компиляторами в которые вложили миллионы баксов просто смешно. Ну, а во фразу "в среднем на 40%" можно вложить много чего. Скажем улучшили в Эрлаге переключение контекста, вот и тебе и рост производительности в параллельных задачах. Но попробуй померяться в скорости парсинга с профессиональным рукописным кодом на С++.
SD>PS: ты б тоже разобрался, кто здесь кто. А то ведь, внезапно, здесь есть люди, не по наслышке знакомые даже с темными закоулками Эрланга и его виртуальной машины.
Я давно вышел из возраста когда меряются пиписками. Виртуальная машина пока что еще ни разу не порвали оптимизирующие компиляторов в принципе. Вот это я знаю точно. В теории правильно спроектированная ВМ, заранее рассчитанная на оптимизации это сделать может. Но на практике прецедентов пока что не было. Все косячат, а потом безуспешно борются со своими косяками. И самое смешное, что с переносимостью с допотопным С тоже никто поспорить пока что не может. Хотя в теории...
Эрланг точно не разрабатывался как основа для числодробильных вычислений. У него были совсем другие архитектурные замыслы. Высокий параллелизм. Отказоустойчивость. Функциональный язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Эрланг точно не разрабатывался как основа для числодробильных вычислений.
Так он и не используется как числодробилка. В данном топике обсуждают удобную (ну, наверное) обёртку для вычислительных ядер на CPU (какой-то OAT/JIT сделали, уверен, ты прав и по качеству он уступит С++, но какая разница? кому всерьёз надо "тяжелое" ML на ЦПУ?) / GPU (здесь у нас банально мостик к LibTorch, соотвественно туда и претензии к производительности) / TPU (через Google XLA, т.е. TensorFlow, опять же бэкенд не мой, я просто функцию позвал). Смысл такой, что сейчас в домене машинного обучения, как минимум на inference, даже супер-оптимизированный компилятор с треском проиграет специалированному железу. И смысл тогда убиваться над компилятором, если можно сфокусироваться на масштабируемости, поддерживаемости, расширяемости и прочих прелестях фронт-энда к железякам?
Здравствуйте, El Camino Real, Вы писали:
ECR>Здравствуйте, VladD2, Вы писали:
VD>>Эрланг точно не разрабатывался как основа для числодробильных вычислений. ECR>Так он и не используется как числодробилка. В данном топике обсуждают удобную (ну, наверное) обёртку для вычислительных ядер на CPU (какой-то OAT/JIT сделали, уверен, ты прав и по качеству он уступит С++, но какая разница? кому всерьёз надо "тяжелое" ML на ЦПУ?) / GPU (здесь у нас банально мостик к LibTorch, соотвественно туда и претензии к производительности) / TPU (через Google XLA, т.е. TensorFlow, опять же бэкенд не мой, я просто функцию позвал). Смысл такой, что сейчас в домене машинного обучения, как минимум на inference, даже супер-оптимизированный компилятор с треском проиграет специалированному железу. И смысл тогда убиваться над компилятором, если можно сфокусироваться на масштабируемости, поддерживаемости, расширяемости и прочих прелестях фронт-энда к железякам?
Но это уже всё есть и крайне удачно реализовано в Python. А ведь еще есть R и Julia. Ну а пока создается ощущение, что будет еще одно решение для фанатов, типа Phoenix-а, которое со скрипом заработает пока от основного и единственного сценария использования ни на шаг.
KP>Но это уже всё есть и крайне удачно реализовано в Python.
Про Python написано выше. Про интерпретаторы и принципиальную невозможность оптимизации. Тормознее языков я еще не встречал. При всех вваленных в питон средствах, он умудряется быть намного медленнее Эрланга, и совсем кошмарным, если надо параллелизм.
SD>Про Python написано выше. Про интерпретаторы и принципиальную невозможность оптимизации. Тормознее языков я еще не встречал. При всех вваленных в питон средствах, он умудряется быть намного медленнее Эрланга, и совсем кошмарным, если надо параллелизм.
А мне вот такой вопрос интересен.
Я не настоящий программист на Python. Но вот уже больше десяти лет так точно раз в полгода прихожу в Python чтобы потратить в нем с неделю и написать какую-то небольшую необходимую тулзу для меня. Как правило или статистическую обработку или какую-то билд тулзу (ну там, бинарник собрать из разных компонентов, и тому подобное).
Обычно я на С все пишу, местами ассемблер да шеловские скрипты. Раньше вместо С был C++, но уже лет 7 ни строчки на C++ не написал.
Так вот, первый день обычно немного ломает и медленно на Python, потому как за полгода подзабываю. К концу недели ловлю себя на мысли как быстро и легко я накидываю логику, на С это просто невозможно. В-общем радует меня скорость разработки.
А потом через какое-то время я возвращаюсь к тому же коду, читаю его и понимаю что ну говнокод же. Написал быстро. А читать хреново (причем на С такого нет). Так у меня вопрос: это поотому что я не умею на Python писать, или потому что сам язык располагает на хуяк-хуяк и готово и я этим радостно пользуюсь вместо того чтобы вдумчиво и хорошо все написать?
Здравствуйте, gardener, Вы писали:
G>А потом через какое-то время я возвращаюсь к тому же коду, читаю его и понимаю что ну говнокод же. Написал быстро. А читать хреново (причем на С такого нет). Так у меня вопрос: это поотому что я не умею на Python писать, или потому что сам язык располагает на хуяк-хуяк и готово и я этим радостно пользуюсь вместо того чтобы вдумчиво и хорошо все написать?
Большинство такие проблемы всё же с Си испытывают
По сути вопроса, т.к. на Питоне я очень много пишу. Судя по твоему описанию, "быстро и редко", у тебя качество кода на Питоне сильно страдает. Нормальный, даже не высококлассный, через год легко читается и развивается. Но надо не забывать про динамическую типизацию, если разрастётся сильно, может быть больно, но тут на помощь возможность указания типов приходит.
KP>По сути вопроса, т.к. на Питоне я очень много пишу. Судя по твоему описанию, "быстро и редко", у тебя качество кода на Питоне сильно страдает. Нормальный, даже не высококлассный, через год легко читается и развивается. Но надо не забывать про динамическую типизацию, если разрастётся сильно, может быть больно, но тут на помощь возможность указания типов приходит.
Здравствуйте, gardener, Вы писали:
G>Ясно. Ну что ж, будем считать что дело во мне.
Питон простой, если есть желание и немного самодисциплины (чтобы расставлять типы когда это не обязательно), то будет легко поддерживаемый и читаемый код.
KP>Питон простой, если есть желание и немного самодисциплины (чтобы расставлять типы когда это не обязательно), то будет легко поддерживаемый и читаемый код.
Ну потому я его и использую что простой и на нем можно быстро нафигачить что мне надо
Но все что я на нем делаю это одноразовые и небольшие вещи. Как-то инвестировать время в него смысла мне нет особого.
Попробую следующий раз с типами, спасибо, скорее всего будет существенно лучше.
Здравствуйте, gardener, Вы писали:
G>Ну потому я его и использую что простой и на нем можно быстро нафигачить что мне надо G>Но все что я на нем делаю это одноразовые и небольшие вещи. Как-то инвестировать время в него смысла мне нет особого. G>Попробую следующий раз с типами, спасибо, скорее всего будет существенно лучше.
Я бы посоветовал один раз инвестировать немного времени в сам язык. Для C/C++ разработчика много усилий не понадобится, а в памяти детали по Питону освежаются за пару часов написания кода даже после того как пол года не трогал язык.
Так же советую даже на небольшом проекте прогонять flake8 и black, хорошо очень на читабельности сказывается и детские ошибки отлавливает.
Ну и последнее, наверное, если с языком работаешь редко, то PyCharm позволяет сильно упростить работу.
Здравствуйте, gardener, Вы писали:
G>А потом через какое-то время я возвращаюсь к тому же коду, читаю его и понимаю что ну говнокод же. Написал быстро. А читать хреново (причем на С такого нет). Так у меня вопрос: это поотому что я не умею на Python писать, или потому что сам язык располагает на хуяк-хуяк и готово и я этим радостно пользуюсь вместо того чтобы вдумчиво и хорошо все написать?
Как ни крути ЯП действительно отличаются в первую очередь синтаксисом.
Он, синтаксис определяет скорость разработки.
есть еще два фактора влияющие на выбор:
перформас и кол-во готовых библиотек.
надо полагать что си это последние два.
питон это 1 и 3.
Я работаю на сишарпе и для фана (скрипты и пр.) фшарп. Также был впечатлен лиспом.
Но как заметил Влад2 здесь ужасный перфоманс, причем лисп стартует шустрее сишарпа.
Сам сишарп пытюатся сделать быстрым давая все более низкоуровневый доступ в новых версиях.
Но сам старт даже приветмир занимает приличное время и тут проявляется убожество любой ВМ.
А на днях тыкал раст и ди. аналогичный код и ди и раст примерно одинаково отработали.
Но раст концептуально сложнее, хоть и упал в рантайме с ошибкой переполнения.
В ди проверка по умолчанию была отключена, так что он выдал неверный результат. после исправления int на long (i32 на i64) все сработало приблизительно одинаково.
При этом Ди это почти питон. Причем для меня он даже проще чем питон. А раст в противовес ди обладает большим кол-вом хороших актуальных библиотек.
У ди правда еще одно приемушество. Он генерирует си-совместимые библиотеки.
А логику конечно приятно писать на яп типа фшарп. Но это(ВМ) всегда будет уступать в перфомансе. конечно.
И да, постоянно переключение с ЯП на ЯП не гуд, т.к. в голове от этого каша.
G> Так у меня вопрос: это поотому что я не умею на Python писать, или потому что сам язык располагает на хуяк-хуяк и готово и я этим радостно пользуюсь вместо того чтобы вдумчиво и хорошо все написать?
Имея под рукой гигантскую кодовую базу на Питоне, смею отметить, что язык действительно располагает к быстрому прототипированию.
Чтобы данную тенденцию прибить в зародыше, в большинстве известных мне мест репозитории с питонами обложены по самое не могу lint'ерами, test coverage bot'ами, validator'ами, formatter'ами и прочими инструментами, направленными на затруднение "хуяк-хуяка". Разумеется, этот инструментарий возникает не сразу, а в процессе разрастания кодовой базы.
Могу лишь заверить, что есть и еще более злобные языки для такой работы. Например, Perl, — как по мне так он вообще write only language.
KP>Так же советую даже на небольшом проекте прогонять flake8 и black, хорошо очень на читабельности сказывается и детские ошибки отлавливает. KP>Ну и последнее, наверное, если с языком работаешь редко, то PyCharm позволяет сильно упростить работу.
Кхехе, вот-вот. ЧТД.
Сам язык — просто, легко, удобно, ррраз, и готово.
"Залезть на верблюда? Да, конечно! Да, бесплатно!"
Скрытый текст
Турист, уже на верблюде: "О, класс, окей, хочу слезть" — "А вот это уже не бесплатно, с вас 10 баксов".
Здравствуйте, SkyDance, Вы писали:
SD>Кхехе, вот-вот. ЧТД. SD>Сам язык — просто, легко, удобно, ррраз, и готово.
Ну да, для Elixir-а и без mix format сразу хорошо форматированный код выходит, ну и никому не нужный credo там какие-то наркоманы сделали
Может ты еще не осознал, но форматер и статический анализатор вообще в любом языке нужны, так как всего помнить не возможно, даже если язык крайне простой
Здравствуйте, gardener, Вы писали:
G>Так у меня вопрос: это поотому что я не умею на Python писать, или потому что сам язык располагает на хуяк-хуяк и готово и я этим радостно пользуюсь вместо того чтобы вдумчиво и хорошо все написать?
И то, и другое. Работая в подобном режиме уже который (большая часть задач: прототип на питоне, продуктизация на С, периодически с плюсами), заметил, что ничего страшного не происходит. Если выясняется, что scratchpad121.py сильно дублирует scratchpad63.py, то можно аккуратно перенести функционал в отдельный модуль. Реально же много кода получается write only: написал, не сработало, забыл. В своё оправдание, могу сказать, что раньше со связкой Matlab+Perl было ещё грязнее.
Б>Это я к тому, что кучу проблем в питоне уже решили с помощью (удобных) библиотек.
Вне всякого сомнения. Sunk cost, он такой, — если уже вложено ВОООООТ СТОЛЬКО в питон, дешевле kick the can down the road, чем заново учиться и осваивать более продуктивные методы разработки.
Похоже что обучение людей — самая сложная и дорогая задача, с которой только приходится сталкиваться (не только в разработке, а вообще). "Вырастить специалиста" — чертовски сложно, долго и дорого. Создавать "удобные библиотеки" в конечном счете дешевле.
Собственно, поэтому большие компании столько вкладывают в обучение, включая школы, университеты и т.п.. Научить людей пользоваться, скажем, MS Office, — все равно что продать много-много копий оного.
Здравствуйте, SkyDance, Вы писали:
SD>Вне всякого сомнения. Sunk cost, он такой, — если уже вложено ВОООООТ СТОЛЬКО в питон, дешевле kick the can down the road, чем заново учиться и осваивать более продуктивные методы разработки.
Моя мысль была не в том, что в питон много вложено. Мысль была про то, что предлагаемые тобой методы и технологии не являются более продуктивными по сравнению с "питон + библиотеки". По факту, в текущем состоянии они даже уменьшают продуктивность, пока в них не реализованы нормальные инструменты.
SD>Похоже что обучение людей — самая сложная и дорогая задача, с которой только приходится сталкиваться (не только в разработке, а вообще). "Вырастить специалиста" — чертовски сложно, долго и дорого. Создавать "удобные библиотеки" в конечном счете дешевле.
В данном случае дело не обучении. Большинство программистов вполне могут освоить эти новые технологии (кто-то быстрее, кто-то медленнее). Просто сейчас это никому не надо, т.к. переход на новую технологию не окупится.
Поэтому будут пионеры, которые работают с новой технологией только ради интереса, они доведут технологию до удобоваримого состояния, потом уже подтянутся остальные.
Здравствуйте, kaa.python, Вы писали:
KP>Но это всё вступление, картина крупным планом. А вот что меня интересует, так это будет ли какой-то потенциально интересный выхлоп для ML сообщества в замене того же однопоточного Python на миллион-поточный-и-всё-летает Elixir? Расчеты всяко же будут на GPU, со всякими TensorFlow и PyTourch, но тогда вроде всё и так есть и ничего нового не надо? Или всё же идея хорошая?
Не совсем понятно, как предполагается перетащить питонщиков на этот эликсир. Питонщики в разы дешевле чем функционалисты, и их на порядка два больше и продолжает прибывать.
Здравствуйте, kaa.python, Вы писали:
KP>Но это всё вступление, картина крупным планом. А вот что меня интересует, так это будет ли какой-то потенциально интересный выхлоп для ML сообщества в замене того же однопоточного Python
А Python в ML разве не просто тупо обертка над высокопроизводительным бинарным кодом, написанным на языках типа С++? И этот код умеет утилизировать ядра CPU и GPU?
