LINUX.ORG.RU

Язык+фреймворк с минимальным оверхедом для веба


0

6

Хочу странного. «Для души», практически свои хотелки не обосную.

Язык обязательно статически типизированный. Должен работать со скоростью порядка Java. C, C++, D, Rust и всё такое.

Асинхронная обработка запросов. Полностью. В node.js это близко к идеалу. Любой I/O должен переключать управление на следующий запрос. И всё это с минимальным оверхедом, чтобы могли лежать миллионы коннектов без значимого проседания, пока процессора и памяти хватает. Естественно коннект не должен занимать много памяти. Экстрима в десятки байтов не надо, но и сотни килобайтов тоже.

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

Нормальный развитый REST-фреймворк. Каких то особых требований нет, он просто должен работать и обеспечивать более-менее удобный интерфейс. Естественно полностью асинхронный.

Очень хочется мегабыстрого шаблонизатора. Который будет работать не в разы медленней, чем выплёвывание в сокет текста и подставленных значений переменных.

Общее потребление памяти должно быть вменяемым после старта. 10 мегабайтов это вменяемо. 500 мегабайтов это не вменяемо.

Что я пока видел.

Node.js. Первый минус - динамический JS. Второй минус - однопоточность. Но асинхронность сделана идеально, синхронный вызов найти надо постараться.

Java: практически нигде нет нормальной асинхронности, модель «поток на запрос» доминирует. Драйверы JDBC все синхронные. Что-то такое есть в Play, но это скала с её десятками и сотнями мегабайтов потребления оперативной памяти.

Go: есть интересный фреймворк revel. Но я пока не понимаю модель многопоточности в Go, какие у неё затраты. Как я понимаю, накладных расходов куда больше, чем в случае node.js.

Rust. Сама идея этого языка мне нравится, но нет нормальных библиотек. Какое то teepee вроде пилят, но хз когда допилят. И опять же не совсем понимаю модели многопоточности и накладных расходов.

В идеале я бы хотел видеть Java (не Scala!). Поверх Netty должна быть написана полностью асинхронная (это важно!) прослойка, которая даёт удобный способ работы с асинхронным API, посредством Promises. Учитывая, что в Java 8 все эти лямбды должны достаточно неплохо оптимизировать, работать оно должно шустро. Плюс надо написать асинхронный драйвер к постгресу на Java. Но такого нигде нет и вряд ли будет :( Даже думал запилить, но вряд ли потяну, сложная штука, нужен реально башковитый чувак, чтобы такое сделать как положено.

Собственно хотелось бы узнать, может я чего упускаю? И, если кто хорошо понимает потроха Go и/или Rust, может популярно объяснит, какие накладные расходы там идут в случае «зелёных» потоков, как система отнесётся к миллиону спящих на I/O задач.

Возможно есть какой-то фреймворк для C? Какое-нибудь расширение nginx-а? Хотя асинхронное программирование на C это, наверное, тот ещё изврат.

★★★★★

Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

какие(кая) задачи(а) плохо реализуемо интерфейсом, которая хорошо реализуема шаблонами в Golang(буть шаблоны в го)?

ps. ошибки не старые добрые , а возвратом «синтетических» структур с немедленым «патернмэтчингом» и дефер в нутри что бы из любой точки можно было бы ошибкануть и не иметь лока/лика нужного ресурса.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

какие(кая) задачи(а) плохо реализуемо интерфейсом, которая хорошо реализуема шаблонами в Golang(буть шаблоны в го)?

Любая структура данных без шаблонов требует множества бессмысленных кастов. Банальный связный список, например. Или функция max(a, b).

ps. ошибки не старые добрые , а возвратом «синтетических» структур с немедленым «патернмэтчингом» и дефер в нутри что бы из любой точки можно было бы ошибкануть и не иметь лока/лика нужного ресурса.

Во-первых в Go я не видел паттерн матчинга. Во-вторых проблема локов-ликов нужного ресурса тривиально решается с помощью defer.

Legioner ★★★★★
() автор топика
Ответ на: комментарий от Legioner

1. пример? «нормативное» решение предполагает наличие общего интерфейса тогда кастов не будет ведь?

2. слишком метафоричен сорри. подразумевал возможность возврата составного набора без необходимости заводить тип(уменьшение бюрократии) облегчает использование классических состояний об ошибках наряду(в сопутствии) с обычными возвращаемыми данными , про дефер я и сказал что облегчает _гарантирует.

т.е по 2. зачем нужны в голэнг исключения? какой юзкейс?

qulinxao ★★☆
()
Ответ на: комментарий от Legioner

к первому:

Шаблоны планировались, главным образом, для статической типизации

контейнеров

т.е закрепление интерфейса к конкретной реализации.

а для каких действительно задач(цено) ДЕЙСТВИТЕЛЬНО ценно наличии таковой специализации?

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Я не очень понимаю вопроса. Есть понятие структуры данных. У неё есть какие-то внутренние детали реализации и она хранит значения определённого типа. Например связный список - у каждого узла есть указатель на следующий узел, а также каждый узел хранит значение определённого типа. При этом сам тип по сути совершенно не важен, все операции работают одинаково вне зависимости от этого типа.

Структуры данных применяются во всех задачах. Вообще в любой. Даже в Hello World-е есть строка, а это уже структура данных.

Legioner ★★★★★
() автор топика
Ответ на: комментарий от Legioner

немножно отмотаем:

Любая структура данных без шаблонов требует множества бессмысленных кастов

это слишком общее утверждение что-бы быть верным всегда.

вопрос когда интерфейсного утиного в голанг не достаточно и желательно инстанцирование(специализации) в компайлтайме путём шаблонов(будь они в голэнг)?

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Когда я хочу сделать универсальную структуру данных. Связный список, который способен хранить любой тип. int, float, MyStruct, string. Положить её в библиотеку и использовать где хочу.

Legioner ★★★★★
() автор топика
Последнее исправление: Legioner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.