Похоже, Microsoft кропеет над новым языком программирования для паралельных вычислений под названием Axum. Неизвестно еще, уйдет ли когда-либо в продакшн, но шансы вроде есть. На первый взгляд (disclaimer: я не сильный специалист в паралельном программировании) выглядит интересно, посмотрим, будет ли выхлоп.
Презентацию (требуется Silverlight) можно глянуть здесь, почитать немного здесь.
Краткое описание языка:
“It’s a language that builds upon the architecture of the web and the principles of isolation, agents, and message-passing to increase application safety, responsiveness, scalability and developer productivity. Other advanced concepts we are exploring are data flow networks, asynchronous methods, and type annotations for taming side-effects. We currently have a working prototype with basic Visual Studio integration and a few demonstrations of working code.”
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
Здравствуйте, Gaperton, Вы писали:
G>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
... << RSDN@Home 1.2.0 alpha 4 rev. 1184 on Windows Vista 6.1.7000.0>>
Здравствуйте, AndrewVK, Вы писали:
G>>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
AVK>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
Ну что ж, тем лучше для него. Приятнее [мне] было бы, правда, если бы оно влилось в F#.
G>>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
AVK>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
Думаю, что тогда он Эрлангу не конкурент.
Если разворачивать, то 1) сравнения с образцом не будет, 2) громоздкий синтаксис, 3) внутри будет ООП, а не что-нибудь функциональное.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
AVK>>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
T>Думаю, что тогда он Эрлангу не конкурент.
T>Если разворачивать, то 1) сравнения с образцом не будет, 2) громоздкий синтаксис, 3) внутри будет ООП, а не что-нибудь функциональное.
С# уверенно движется в "функциональном" направлении, насколько я слышал.
Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю. А если их делать на основе файберов, то их на 32-х битной архитектуре много не создашь, ибо адресное пространство под стек резервируется с запасом и обязано быть непрерывным. Так, что несколько тысяч файберов быстро сожрут адресное пространство. Известная проблема нативных "зеленых потоков".
Короче, чтоб все было приятно в плане количества потоков (сотня тысяч — штатная ситуация) — нужно либо 64 бита, либо серьезная модификация рантайма. А лучше и то и другое.
Здравствуйте, Gaperton, Вы писали:
G>Короче, чтоб все было приятно в плане количества потоков (сотня тысяч — штатная ситуация) — нужно либо 64 бита, либо серьезная модификация рантайма. А лучше и то и другое.
такое кол-во легких потоков нужно в эрланге т.к. там нет объектов, а в axure actor это скорее gen_server только пока(может сделают) без горячей замены и прочей радостей OTP.
Я бы тоже предпочел это увидеть в F#, а не в отдельном DSL, тем более F# пока CTP, и можно вводить новые фишки не оглядываясь назад.
Здравствуйте, Gaperton, Вы писали:
G>С# уверенно движется в "функциональном" направлении, насколько я слышал.
Настолько, насколько это не встречает противодействия Хейлсберга.
G>Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю.
API есть, реализации нету. Не забывай, что речь идет о C# 5, который бог знает когда будет.
G> А если их делать на основе файберов, то их на 32-х битной архитектуре много не создашь, ибо адресное пространство под стек резервируется с запасом
Лишний повод перейти на х64. Инфраструктура готова, дело лишь за потребностями.
G>Короче, чтоб все было приятно в плане количества потоков (сотня тысяч — штатная ситуация) — нужно либо 64 бита, либо серьезная модификация рантайма. А лучше и то и другое.
Или технология навроде итераторов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1216 on Windows Vista 6.1.7100.0>>
AVK>>>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком. T>>Думаю, что тогда он Эрлангу не конкурент. T>>Если разворачивать, то 1) сравнения с образцом не будет, 2) громоздкий синтаксис, 3) внутри будет ООП, а не что-нибудь функциональное. G>С# уверенно движется в "функциональном" направлении, насколько я слышал.
G>Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю.
Да, забыл про потоки.
Тогда можно смело думать, что этот Axum не более, чем маркетинговый ход. Тот самый fire, чтобы у других не было motion.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Тогда можно смело думать, что этот Axum не более, чем маркетинговый ход.
Насколько сейчас можно судить, Axum даже не маркетинговый ход. Это исследовательский проект в рамках MS. Ребята просто пытаются воплотить модель актеров в своем .NET-овском языке.
Собственно, о том, что это такое, можно ознакомиться в руководстве по Axum и в его спецификации.
А для того, чтобы конкурировать с Erlang-ом, не обязательно тупо копировать решения Erlang-а (поддержку сотен тысяч независимых процессов).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю. А если их делать на основе файберов, то их на 32-х битной архитектуре много не создашь, ибо адресное пространство под стек резервируется с запасом и обязано быть непрерывным. Так, что несколько тысяч файберов быстро сожрут адресное пространство. Известная проблема нативных "зеленых потоков".
Либа CCR реализует подобие легких потоков через итераторы. Только многословно сильно получается.
Axum делает практически тоже самое, создает из линейного кода State Machine с состоянием в хипе.
T>>Тогда можно смело думать, что этот Axum не более, чем маркетинговый ход. AVK>Да при чем тут маркетинг? Это MSR, это просто исследования, что можно сделать.
Всё, что попадает во вне MSR через PR, становится маркетингом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
E>>А для того, чтобы конкурировать с Erlang-ом, не обязательно тупо копировать решения Erlang-а (поддержку сотен тысяч независимых процессов).
T>А что надо делать?
Да практически так же, как и поступают разработчики Axum и не только его (можно, наверное, с десяток агентных фреймворков насчитать, в основном для JVM, но есть и для Python, Ruby, C++): оформлять агентов в виде объектов. Подробнее я на эту тему уже писал