X
Не всегда/везде эта безопасность нужна. Я напомню, что дискуссия началась с Akka для .net
Точно ведь
Size: a a a
2021 February 08
AN
Можно пример?
Любая типизация ломается об
Code.eval_string()AN
в эрлаге решили, что значит она не нужна)
LL
Типа в этом и прелесть
А вот к
elixir, ты можешь взять и прикрутить себе статическую типизацию (и практически все её себе прикручивают)А вот к
akka ты никак не сможешь отказаться от кооперативной многозадачности. Придётся как-то валидировать что код когда-нибудь закончится и отдаст управление (а это проблема остановки, если что)Aß
Aß
А где про это можно почитать, кстати?
Types and Programming Languages, B. C. Pierce
X
Типа в этом и прелесть
А вот к
elixir, ты можешь взять и прикрутить себе статическую типизацию (и практически все её себе прикручивают)А вот к
akka ты никак не сможешь отказаться от кооперативной многозадачности. Придётся как-то валидировать что код когда-нибудь закончится и отдаст управление (а это проблема остановки, если что)А в эликсире вытесняющая многозадачность?
LL
А в эликсире вытесняющая многозадачность?
Угу, там система редукций
Типа один актор может выполнить около 4000 редукций без прерывания
Можно сказать, что редукция это один вызов функции (не считая всяких линейных функций типа
Типа один актор может выполнить около 4000 редукций без прерывания
Можно сказать, что редукция это один вызов функции (не считая всяких линейных функций типа
:lists.reverse)X
Понял
((
Типа в этом и прелесть
А вот к
elixir, ты можешь взять и прикрутить себе статическую типизацию (и практически все её себе прикручивают)А вот к
akka ты никак не сможешь отказаться от кооперативной многозадачности. Придётся как-то валидировать что код когда-нибудь закончится и отдаст управление (а это проблема остановки, если что)а покажи что ты имеешь ввиду под "прикрутить себе статическую типизацию (и практически все её себе прикручивают)"
V
А где про это можно почитать, кстати?
можно начать с дискуссий про unsafe в расте.
тезисно: "статически типизированные программы" - это подмножество, полностью находящееся в множестве "рабочие программы".
тезисно: "статически типизированные программы" - это подмножество, полностью находящееся в множестве "рабочие программы".
IK
а покажи что ты имеешь ввиду под "прикрутить себе статическую типизацию (и практически все её себе прикручивают)"
он говорит о dialyzer
LL
а покажи что ты имеешь ввиду под "прикрутить себе статическую типизацию (и практически все её себе прикручивают)"
Диалайзер, например. Есть ещё другие, более точные решения. Я могу попытаться вспомнить, если сильно интересно
AN
последнее время тенденция наоборот отходить от статической типизации, и использовать ее только там, где явно указано.
Gradualizer например пилят по такому принципу. Ибо в BEAM, не считая hot code reloading есть еще сообщения, которые можно отправить кому угодно в рантайме. Ты никогда корректно не получшь тип входящего сообщения в compile-time, только паттерн матчинг спасает. Т.к. в рантайме можно отправить что угодно кому угодно, хоть из iex, хоть из другой ноды со старой версией софта и работающей с другим типом сообщенийLL
последнее время тенденция наоборот отходить от статической типизации, и использовать ее только там, где явно указано.
Gradualizer например пилят по такому принципу. Ибо в BEAM, не считая hot code reloading есть еще сообщения, которые можно отправить кому угодно в рантайме. Ты никогда корректно не получшь тип входящего сообщения в compile-time, только паттерн матчинг спасает. Т.к. в рантайме можно отправить что угодно кому угодно, хоть из iex, хоть из другой ноды со старой версией софта и работающей с другим типом сообщенийТакой себе аргумент, потому что сообщения неправильного типа можно просто отбрасывать, реализуя тайп-чекинг в рантайме
Понятное дело, что это будет жутко медленно работать, но всё-таки
Понятное дело, что это будет жутко медленно работать, но всё-таки
AN
Такой себе аргумент, потому что сообщения неправильного типа можно просто отбрасывать, реализуя тайп-чекинг в рантайме
Понятное дело, что это будет жутко медленно работать, но всё-таки
Понятное дело, что это будет жутко медленно работать, но всё-таки
тайп-чекинг в рантайме это не статическая типизация)
Aß
последнее время тенденция наоборот отходить от статической типизации, и использовать ее только там, где явно указано.
Gradualizer например пилят по такому принципу. Ибо в BEAM, не считая hot code reloading есть еще сообщения, которые можно отправить кому угодно в рантайме. Ты никогда корректно не получшь тип входящего сообщения в compile-time, только паттерн матчинг спасает. Т.к. в рантайме можно отправить что угодно кому угодно, хоть из iex, хоть из другой ноды со старой версией софта и работающей с другим типом сообщенийтут есть два пути, можно закодировать все возможные сообщения в пиде и запретить отправку некорректных сообщений процессу
LL
тайп-чекинг в рантайме это не статическая типизация)
Ну, любая программа имеет
IO и проверяет данные на входе на соответствие нужному типу и всё такоеAß
а можно разрешить паттерн матчинг по типам, который у наc и так есть
LL
A ß
а можно разрешить паттерн матчинг по типам, который у наc и так есть
По типам матчинга вроде нет, есть адовая смесь матчинга по коллекциям и гардов