Я собственно говорил не про J2ЕЕ бутерброды... я и сам их не перевариваю.
Прежде чем говорить о том сколько памяти ест JVM нужно понимать что есть разница между тем сколько она выделяет в ОС, и сколько она действительно утилизирует... так что нужно сначала покопаться в JMX, а потом говорить что больше кушает. Да, и в утечки памяти в Java довольно привычное дело - прежде чем грешить на платформу, нужно хорошо разобраться в коде...
По поводу "Питон быстрее" могу лишь сказать что это может быть частично правдой в случае использования PyPy. Но к сожалению это пока ещё очень сырая платформа.
Собственно есть Akka которая на 100% заменяет Erlang и она входит в состав typesafe stack. Java сейчас ничем не сложнее того же РНР. Да и собственно первого тома Core Java хватает для большинства задач...
Главным приемуществом Java решений является асинхронность и многопоточность, что позволяет строить "реактивные приложния".
Производстельность обычно на много выше чем у всех интерпретируемых языков... в общем более съедобный NodeJS xD
Единственной проблемой является offheap-кэширование для борьбы с задержками при сборке мусора.
Ну у Grails камьюнити over8k.
"Всинхронность" можно не въезжать - есть модель актёров Akka "типа Erlang на Java". https://typesafe.com/
Java по сложности освоения НИЧЕМ не сложнее того же РНР.
Большинство технологий и инфраструктур более зрелые, с на много лучшей поддержкой со стороны камьюнити.
На сегодняшний день Java является лучшим решением для "реактивных" приложений. www.reactivemanifesto.org
В РНР много работы "мы заплатили - нам написали и слились, теперь мы хотим вас !" через пять минут разговора и взгляда на сорцы, "как переписывать ? мы же за это столько отдали, неужели сдесь нельзя ничего использовать ?"
80% проектов на РНР провальны... из-за небрежности заказчиков, отсутствия организации, и безответственности иссполнителей.
Впрочем в других языках / средствах ситуация не радужней...
В РНР всё печальнее как раз потому что он слишком популярен.
Проблема РНР в том что там очень много дилетантов...
Сейчас в связи с подчисткой API в РНР много фреймворков станут неактуальными. Очень много народу застыло на уровне РНР5.2 и Yii1.
Yii2 нет смысла использовать... самым прогрессивным решением остаётся Symfony2. Хотя порог вхождения оставляет желать лучшего.
Мне приходилось переучивать рельсоводов и джангистов под Grails, а также обучать молодняк... в принципе порог вхождения даже ниже чем в Yii)
Сейчас вот буду обучать 3ий курс Play Framework'у...
Согласен с @madmages, лучше подучить теорию самому, а потом сунуться в ВУЗ.
Книжек и напутствие получить очень легко...
На РНР сейчас не советую бросаться, тут сейчас очень неуютно.
Но хотя бы codecademy и coursera очень во многом могут помочь разобраться...
Не в сетевых технологиях дело...
Дело в знании шаблонов проектирования систем ассинхронной обработки событий и сетевого трафика: Disruptor, Proactor, Reactor.
Для различных типов поллинга сокетов - различные шаблоны.
Поллинг - оповещение приложения о доступности новых данных.
Количество подключений свидетельствует о том что вам нужно использовать производительнный ядерный поллер - kqueue или epoll. На пропускную способность влияют различные факторы в том числе и дизайн обработки ассинхронных событий. На практике конвеерный Disruptor с фиксированной очередью под каждый тип задач и одним продюсером/консьюмером быстрее всего.
@maxaon FMS в целом не выдерживает высоких нагрузок, может подохнуть при 5-6Гбит'ах трафика. Да и в целом бывает довольно нестабилен. На рынке експлойтов существуют не мало DoS'ов и инджектов для FMS: за последний год видел 5-6 штук, и к сожалению ситуация только усугубляется.
Собственно приложенным вами постам 3 года отроду.
1) RTMFP обходит NAT
2) Реализовать не спешат так как об опубликованном RFC просто мало кто знает - многие считают протокол закрытым
Прежде чем говорить о том сколько памяти ест JVM нужно понимать что есть разница между тем сколько она выделяет в ОС, и сколько она действительно утилизирует... так что нужно сначала покопаться в JMX, а потом говорить что больше кушает. Да, и в утечки памяти в Java довольно привычное дело - прежде чем грешить на платформу, нужно хорошо разобраться в коде...
По поводу "Питон быстрее" могу лишь сказать что это может быть частично правдой в случае использования PyPy. Но к сожалению это пока ещё очень сырая платформа.