Marat Amerov

stackoverflow.com/questions/715604/why-do-dynamic-...

По сути в ruby/python не нужны абстрактные классы. Во всяком случае так считали авторы языков, основываясь на идее, что в этих языках все проверки на существование методов происходят в рантайме, ну и можно в рантайме подменять методы и много чего еще творить с классами.

Вообще говоря любая сущность в конечном итоге является стркутурой/инстркуциями в памяти, т.е. "объектом". Вопрос в том можно ли получить доступ к этой сущности из runtime/compiletime/designtime/etc. К большинству таких сущностей в Ruby в рантайме можно иметь доступ как к стандартным объектам языка.

Но например к командам(скомпилированному коду программы) такой доступ получить нельзя, хотя можно по другому - с помощью чтения исходников выполняемой программы из нее самой, изменением их и компиляции с помощью eval и передачи управления новому коду.

Кстати, на заметку - контексты выполнения в функциях/блоках это тоже объекты языка (Binding)

TL;DR: Имплементация любой системы актеров автоматически является ивент лупом.

Ивентлупом обычно называются планировщики, например в виде С библиотек таких как libuv, которая используется в node.js, Julia, Rust, а также в ивентлупом называют такие библиотеки как в D, например Vibe.D. Актеры Эрланга это больше чем просто планировщик, это также еще и система обмена сообщениями.

Если вам не нужно чтобы ваши единицы планирования общались между собой, вам возможно не нужна система актеров, и можно будет быстро это написать прямо на C с использование libuv. Как только вы захотите чтобы единицы планирования общались между собой вам потребуется что-то больше чем просто цикл по стекам.

Вопрос, к сожалению, не имеет смысла, так как Эрланг предоставляет даже больше чем просто систему актеров. Вы не найдете WebSocket сервер для Erlang который не поддерживает концепцию актеров, а также не найдете WebSocket сервер для Erlang который не поддерживает концепцию event loop.

Глупо учить язык программирования, а не техники программирования (ФП, ОПП, рефакторинг, хайлоад, БД, алгоритмы, структуры данных и т.д.).

Год назад я бы сказал, что у руби нет будущего (имею 7 лет опыта в Ruby on Rails), теперь я думаю, что на следующие 3-5 лет определённо запас мощности есть. Однако, вы всё же задумайтесь о том, что бы учить методы и техники, паттерны и способы взаимодействия с людьми через ЯП, а не сам ЯП. ЯП и фреймворк легко выучить, легко так же получить опыт, если действительно заинтересоваться. Куда легче всё это понять и выучить, когда ты понимаешь технологию. Да и в конце концов, можно и самому стать архитектором фреймворка и языка - тогда уж точно получите массу опыта и станете действительно сильным программистом.

Расширяемое и производительное приложение можно разработать на любом языке, вопрос как всегда в исполнителях.

Вы рассуждаете слишком наивно: вложу в 2 раза меньше и получу то же самое. Увы, получить вы можете все что угодно от в 10 раз лучше до в 10 раз хуже, независимо от технологии.

Если речь идет об одном и том же разработчике - все равно одной технологией (PHP) он владеет лучше и возможно вам предлагают еще и оплатить свое обучение (Rails) с не прогнозируемым для вас результатом.

Если это разные разработчики, то тут нужно смотреть и сравнивать. Возможно те кто просят дешевле и делают хуже. Или, например, стандартные требования укладываются в их CMSку, а вот расширенные - ценник может вырасти в 5 раз.

В любом случае с разработчиками нужно заранее обсудить программу-максимум, уточнить во сколько она выльется по времени и средствам.

PS: почитал тут про тормознутость ruby от коллег php-шников, кратко - это миф из давнего прошлого, современному положению дел не соответствует

Дак пилите, кто вам мешает.

Простите, но сразу вспомнился Говнокод.ру