Комментарии 25
А каковы прогнозы развития этого проекта? Сможет ли он конкурировать с популярными сейчас облачными проектами, такими как Windows Azure?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
ну про сырую и глючную это вы зря :) scala уже давно не такая.
ну не знаю, в последней стабильной 2.7 немеряно утечек памяти в actors, даже банальный List.equals может вылететь со Stack Overflow Exception, в HashMap вообще ужас что творится.
окей, в 2.8 всё это будет исправлено, но сама 2.8 настолько сырая, настолько значительно меняется, что использовать её невозможно. по масштабам изменений тянет больше на 3.0 чем на 2.8. боюсь с 2.7 она будет не совместима, вплоть до того что код, который компилировался на 2.7 не будет компилироваться на 2.8.
окей, в 2.8 всё это будет исправлено, но сама 2.8 настолько сырая, настолько значительно меняется, что использовать её невозможно. по масштабам изменений тянет больше на 3.0 чем на 2.8. боюсь с 2.7 она будет не совместима, вплоть до того что код, который компилировался на 2.7 не будет компилироваться на 2.8.
А яву зачем пихать?
Если уж мужик сказал, что нужно создавать новый язык программирования, то для чего завязываться на старый язык и парадигму. Ведь как раз их-то и хотели поменять?
Вообще, есть мнение, что для распределенных систем больше подходят не императивные, а функциональные языки. И Erlang здесь как нельзя кстати с его парадигмой «все есть процесс». Именно это и есть тот желанный подход «не от данных, а от вычислений». В эрланге нет «данных» — т.е. переменных как они обычно понимаются, есть только «вычисления» — процессы. Раз нет данных, то не требуются локи, семафоры и прочая интерпроцессная синхронизация.
Если уж мужик сказал, что нужно создавать новый язык программирования, то для чего завязываться на старый язык и парадигму. Ведь как раз их-то и хотели поменять?
Вообще, есть мнение, что для распределенных систем больше подходят не императивные, а функциональные языки. И Erlang здесь как нельзя кстати с его парадигмой «все есть процесс». Именно это и есть тот желанный подход «не от данных, а от вычислений». В эрланге нет «данных» — т.е. переменных как они обычно понимаются, есть только «вычисления» — процессы. Раз нет данных, то не требуются локи, семафоры и прочая интерпроцессная синхронизация.
НЛО прилетело и опубликовало эту надпись здесь
Соглашусь.
Впрочем, яву можно хорошо использовать как маркетинговый инструмент — смотрите, тут все на старой доброй яве, которую вы давно используете. У нее есть хороший кредит доверия в корпоративной среде, это может много значит и помочь войти на рынок. Но все равно, после реализации затей от этой jvm останется процентов 10, все остальное придется переписать. Ява вещь хорошая, но это совсем другая парадигма. И эту разницу в парадигмах так просто не спишешь.
Впрочем, яву можно хорошо использовать как маркетинговый инструмент — смотрите, тут все на старой доброй яве, которую вы давно используете. У нее есть хороший кредит доверия в корпоративной среде, это может много значит и помочь войти на рынок. Но все равно, после реализации затей от этой jvm останется процентов 10, все остальное придется переписать. Ява вещь хорошая, но это совсем другая парадигма. И эту разницу в парадигмах так просто не спишешь.
А в эрланговские программы распределяются только за счёт прозрачной отправки сообщений? А то у этого чувака распределяются не данные, не сервера, а сами вычисления, путём посылки continuations на те сервера, на которых размещены данные.
И ещё, насколько я понял из текста по ссылке, scala ему нужна была только как язык написания виртуальной машины для swarm, причём scala он выбрал, т.к. ему хотелось её изучить… Т.е. пересылаются continuations не для jvm, а для написанной им виртуальной машины.
И ещё, насколько я понял из текста по ссылке, scala ему нужна была только как язык написания виртуальной машины для swarm, причём scala он выбрал, т.к. ему хотелось её изучить… Т.е. пересылаются continuations не для jvm, а для написанной им виртуальной машины.
НЛО прилетело и опубликовало эту надпись здесь
В общем, да только отправкой сообщений, но на базе этого есть прозрачные удалённые вызовы функций.
Так же есть pool, что отдаёт стандартной библиотеке все домыслы на предмет распределения загрузки. То есть для программиста выглядит так, создаётся пул узлов, а дальше spawn (создать поток) заменяем на pspawn, и поток будет запущен на наиболее не загруженном узле.
Так же есть pool, что отдаёт стандартной библиотеке все домыслы на предмет распределения загрузки. То есть для программиста выглядит так, создаётся пул узлов, а дальше spawn (создать поток) заменяем на pspawn, и поток будет запущен на наиболее не загруженном узле.
Яву может быть потому что это одна из лучших (если не лучшая) по настоящему кроссплатформенных виртуальных маших?
Автор говорит что ему нужны были распределенные continuations. Да и вообще это прототип, я так понимаю.
НЛО прилетело и опубликовало эту надпись здесь
ну видимо автор не нашел готовой библиотеки для erlang'а которая удовлетворила бы все его требования.
ПС про то что в какомто языке все это проблема и это в принципе невозможно никто и не говорит
ПС про то что в какомто языке все это проблема и это в принципе невозможно никто и не говорит
НЛО прилетело и опубликовало эту надпись здесь
Я на самом деле согласен что на эрланге это смотрелось бы идеологически правильнее. И вообще платформа мне очень интересна, но не получается ее нигде применить :(
А с библиотеками в яве действительно лучше, и это очень сильно сдерживающий миграцию фактор. В том числе и для математики куча библиотек. Точнее так: для всего что популярно в корпоративной разработке есть библиотеки :)
А про этот swarm посмотрим еще что в результате выйдет. Может и для эрланга будет.
А с библиотеками в яве действительно лучше, и это очень сильно сдерживающий миграцию фактор. В том числе и для математики куча библиотек. Точнее так: для всего что популярно в корпоративной разработке есть библиотеки :)
А про этот swarm посмотрим еще что в результате выйдет. Может и для эрланга будет.
НЛО прилетело и опубликовало эту надпись здесь
Я думаю должно быть хуже, но это ведь фиг измеришь. Библиотеки есть, очень разные. Производительность, конечно, ниже, но не настолько чтобы это мешало.
Ну и из опыта скажу что больше всего затрат уходит не на конкретный алгоритм (математический или нет, не суть важно), а на общую компоновку системы, удобную архитектуру, поиск багов и отладку, разбирательство в старом коде, модификацию его под новые условия и т.д.
Ну и из опыта скажу что больше всего затрат уходит не на конкретный алгоритм (математический или нет, не суть важно), а на общую компоновку системы, удобную архитектуру, поиск багов и отладку, разбирательство в старом коде, модификацию его под новые условия и т.д.
В вычислениях помимо красивого распараллеливания еще и скорость выполнения важна. Swarm может интересно что-то предложить в этом плане?!
над проблемой распараллеливания не то, что облачных вычислений, но и сильно связанных систем, бьются уже десятилетия, не верится, что новым языком это можно исправить.
8 килобайт путсячного кода на github и 35 минут презентации. FAIL!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Swarm: язык распределённых вычислений в облаке