Для HelloWorld Assembler лучший язык

Если кодер желает сохранить в памяти что-то, только он и может решить когда это может быть удалено

Так он может. Меняет threshold-LRU-manager на свой и явно указывает что и когда.

Для веба правильнее всего было бы не просто убивать продолжения когда кончилась память, а скидывать их при этом в базу данных. Вот интересно, в каком языке продолжения/фьючи/кактамононазывается, генерируемые системой (а то можно и руками их писать в любом ЯП) в принципе могут быть сериализованы? Обычно же это некие приватные для рантайма структуры, которые даже склонировать не возможно, не говоря уж о сериализации.

https://docs.racket-lang.org/web-server/stateless.html

Но я считаю, что это идеологически неверно. Если есть место под БД для продолжений, то лучше его же отдать под своп и работать как с памятью. А то будут потом SMS с того света приходить (очередь сообщений не почистили перед тем, как включить сервер из ремонта).

отдать под своп и работать как с памятью

И как это масштабируется? Что-то я сомневаюсь, что можно настроить своп в облаке. Кроме того не помешали бы инструменты доступа к такому свопу, как раз чтоб можно было скриптами чистить очереди. Базу данных навязывает сама идеология http. У сервера в принципе нет никакой возможности узнать заинтересован ли клиент в продолжении диалога, так как закрытие TCP соединения вовсе не означает закрытие сессии. Было бы хорошо жить в мире без http, но где живем там живем.

И как это масштабируется? Что-то я сомневаюсь, что можно настроить своп в облаке.

Почему? Я на HyperV делал.

И, как бы, а зачем? Распределение сессий (продолжений) по узлам работает тривиально.Желание смигрировать текущую сессию на другой узел… а зачем? И если очень надо (например, замена железа и очень высокая доступность), весь узел запускай в виртуалке и мигрируй.

У сервера в принципе нет никакой возможности узнать заинтересован ли клиент в продолжении диалога, так как закрытие TCP соединения вовсе не означает закрытие сессии.

Сессия в Racket живёт по-умолчанию 4 часа от последнего действия пользователя. Если клиент 4 часа не отвечает, то, скорее всего, ему уже не надо.

Базу данных навязывает сама идеология http.

Это исключительно потому, что в других языках нет удобного восстановления состояний. Впрочем SESSIONID и memcached даже в PHP сделали. И базу данных «навязывает» очень странно. То-то Web постоянно колеблется между SQL/NoSQL/файлы.

Всё равно, что считать, что мотоцикл плохо масштабируем (а вдруг понадобится перевезти 20 тонн, 18-колесным мотоциклом будет неудобно управлять с таким рулём) и что ступенчатую коробку передач навязывает сама идеология двигателя внутреннего сгорания.

В оригинале предполагалось, что никакого состояния на сервере нет. Клиенты приходят, качают/заливают контент, максимум выполняют вычисления. Но http быстро начали использовать не по назначению устраивая из него подобие десктопного гуя, а потом и сервисы ввели. Понятное дело неудобно такое кодить без состояния. Но перейти на rpc протоколы народ не желает. Наверно потому что ранее они себя плохо показали, да и от современных веет васянством. Надо бы собраться вместе, дописать например тот же capnproto и забыть о http как о страшном сне. Впрочем продвинутый народ уже давно свалил на вебсокеты, где проблема сессий по идее тоже не горит.

Но перейти на rpc протоколы народ не желает. … забыть о http как о страшном сне

Есть SOAP, есть XML-RPC. Они прекрасно себя чувствуют поверх HTTP.

Надо бы собраться вместе, дописать например тот же capnproto

А что будет браузер делать с capnproto? А если речь идёт про своего клиента для своего сервера, так никто не мешает использовать что угодно на базе TCP/UDP. Хоть тот же capnproto (он таки работает).

Racket хорош тем, что совсем не перегружает браузер. Вся эта прелесть не использует JavaScript, не требует навороченных фронтендов. Состояние полностью описывается гиперссылкой. То есть для запуска web-приложения достаточно NetSurf’а (а если в приложении нет графики, то и lynx’а). При этом функциональность практически ничем не уступает локальному приложению.

Racket хорош

Да я как бэ и не против. Просто без js сейчас нет смысла писать, почти не осталось сайтов, которые без него работают. А с ним, если интерактив, то вебсокет вывозит

Просто без js сейчас нет смысла писать, почти не осталось сайтов, которые без него работают.

Не уловил логическую цепочку. Или это в смысле «нет смысла носить нормальные штаны, все ходят даже зимой с голыми щиколотками»?

С js есть несколько проблем:

• Разнообразие браузеров. Приходится писать на самой старой версии JS из возможных у предполагаемых пользователей.
• Нагрузка на канал. «Двести метров джаваскрипта грузит текста триста байт». Кроме того из-за HTTPS эти двести метров даже на прокси не кэшируются.
• Безопасность. Если внутрисессионные объекты начинают работать у клиента, то большая часть бизнес-логики также уходит туда. А значит у клиента появляется возможность эту самую логику легко увидеть и даже поменять.

Ну и ограниченность самого JS также «слегка» мешает. Половины библиотек нет, сишные использовать нельзя, вроде даже финализаторов нету.

С js есть несколько проблем:

1. Не проблема, так как всегда приходится писать для самой старой версии браузера, даже если мы пишем без js, то нужно учитывать поддержку браузером CSS3 и HTML5 элементов и форм.

2. Js фреймворки наоборот экономят канал. Так как мы загружаем лишь один раз html документ, и дальше лишь подгружаем необходимые данные через fetch для обновления страницы, а не целиком заного страницы html. Конечно бывают одностраничные сайты с каким-нибудь огромным фреймворком, но это лишь непродуманность конкретного сайта. При изучении любого js фреймворка экономия канала будет одним из преимуществ в сравнении с классическим подходом.

https://svelte.dev/ топовый фреймворк с минимальным размером страниц.

3. Согласен, тут есть небольшая проблема…

Не проблема, так как всегда приходится писать для самой старой версии браузера, даже если мы пишем без js, то нужно учитывать поддержку браузером CSS3 и HTML5 элементов и форм.

Можно писать под NoJS/CSS2/HTML4 и сайт будет работать с всем вплоть до NetSurf’а.

Так как мы загружаем лишь один раз html документ, и дальше лишь подгружаем необходимые данные через fetch для обновления страницы, а не целиком заного страницы html.

В тэге <A> для этого ещё в HTML 3.2 придумали атрибут target. Опять же, если страница занимает 20 килобайтов (три страницы текста), то её можно и целиком перезагружать, это немного.

https://svelte.dev/ топовый фреймворк с минимальным размером страниц.

Этот сайт на одну страничку с несколькими примерами кода скачал 6,5 мегабайтов. Это в полтора раза больше, чем «Война и Мир»!

Приходится писать на самой старой версии JS

Все узают транспайлеры из es6 или typescript

Нагрузка на канал.

У всех анлим с норм скоростью

у клиента появляется возможность эту самую логику легко увидеть и даже поменять

Углифаеры, транспайлеры, не ставящие задачи генерить красивый JS или можно уйти в бинарный васм.

и сайт будет работать с всем вплоть до NetSurf’а

Для особых ценителей следует отдавать особую версию сайта со статической ссылкой на скачивание фаерфокса. У меня даже желание когда-то было написать свой браузер и тоже делать так, но уже для всех других браузеров

если страница занимает 20 килобайтов (три страницы текста), то её можно и целиком перезагружать, это немного.

Что за глупости ты пишешь, серьезно.

Намного эффективнее гонять некешируемые, на каждый чих генерируемые, иксемели и джейсоны, парсить их крутыми парсерами, и динамически рисовать следующую страницу в одностраничном приложении.

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

А в гипертексте все хорошо, потому что это просто текст … с картинками … двигающимися … со звуком … на каждое действие и бездейстие пользователя … можно еще фоткаться. Чего бояться просто текста?!

Все узают транспайлеры из es6 или typescript

И всё становится ещё в несколько раз тормознее.

У всех анлим с норм скоростью

Кроме канала ещё и оперативку сильно грузит. А её не совсем анлим. И процессор.

Углифаеры, транспайлеры, не ставящие задачи генерить красивый JS или можно уйти в бинарный васм.

Всё равно приложение приходит к клиенту и там запускается. А если оно целиком на сервере, а у клиента только представление данных, то безопасность намного выше.

Для особых ценителей следует отдавать особую версию сайта со статической ссылкой на скачивание фаерфокса.

Это уже сделали. Только для Хрома. Назвали «Электрон». Теперь снова ресурсов компьютера не хватает на запуск дюжины приложений одновременно.

Это уже сделали.

Я имел ввиду сделать электрон ровно наоборот. Вместо того чтоб скачивать браузер в виде десктопного аппа предлагаю скачать десктоп апп, работающий в качестве браузера и показывающий единственный мой сайт. Ну реально почему бы не верстать на «мой еще ненаписанный гуи тулкит» сайт нативно. Это же как быстро работать будет и мороки с совместимостью никакой (опенжл-ес везде работает, ЯП кроскомпилятся).

И всё становится ещё в несколько раз тормознее.

Типаскрипт довольно прозрачно компилится. Reasonml, говорят, вообще быстрее работает, чем рукописный js. А если транспилер не ок, есть https://prepack.io/

Типаскрипт довольно прозрачно компилится.

Посмотри, во что превращается yield, если целевая платформа ES3.

https://prepack.io/ смотрел? Думаю как выберется время попробовать его в связке с PureScript, одним из самых жирных компиляторов. Впрочем транспилеры из существующих ЯП в js (за исключением BuckleScript) обычно тянут с собой такой дикий рантайм (причем порой зависающий наглухо), что не уверен что там препак поможет, но надо проверять.

https://prepack.io/ смотрел?

Это штука полезная для говнокода и древних браузеров. Но проблему отсутствия быстрых примитивов и эффективной компиляции в старых версиях JS это не решает.

десктоп апп, работающий в качестве браузера и показывающий единственный мой сайт.

Это называется «клиент» в клиент-серверной технологии. Только HTML не нужен, картинки и прочую мультимедию «сайта» сделать частью «браузера» и для каждой ОС сделать «браузер», использующий графические средства этой ОС,

Просто сейчас народ за унификацию всея и, так как html широко распространён, логичнее всего узать его. А я болею NIH настолько, что готов пойти против системы. Хотя тут скорее даже не NIH, а лисп-мышление, которое говорит «лучше всего задаче подходит тулза, разработанная конкретно под нее» и «монолит может быть гораздо умнее, чем слабо связанный набор аля лебедь, рак и щука».

Я из этих соображений https://github.com/Kalimehtar/hive-client и https://github.com/Kalimehtar/hive-server сделал.

Racket хорош

Не удивительно: нет такой дряни, чтобы не нашёлся желающий её похвалить.

тем, что совсем не перегружает браузер. Вся эта прелесть не использует JavaScript, не требует навороченных фронтендов

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

Название темы тоже содержит необоснованную похвалу. Assembler - не лучший язык для Helloworld, поскольку имеет лишь ограниченные возможности для работы с текстом.

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

Судя по количеству скачиваний дистрибутива, наличию свыше 3 тысяч звёзд на github’е у самого ракета и кучи проектов на нём, очевидно, что утверждение «ракетом никто не пользуется» не меньшее преувеличение, чем «ракет лучший язык для Web».

Assembler - не лучший язык для Helloworld, поскольку имеет лишь ограниченные возможности для работы с текстом

Смотря как определять слово «лучший». Если как «дающий наибыстрейший код», то вполне обоснованную.

Assembler - … имеет лишь ограниченные возможности для работы с текстом

ЩИТО??? Какую операцию надо текстом невозможно сделать на ассемблере?