Туда кстати периодически весьма прикольно заглядывать. По разным закладкам вон меряются и длиной, и скоростью, и пропускной способностью, джедайские техники иногда всякие разные показывают, забавные (вроде half closed connection... или это в Go изначально придумали), или реализации NETMAP/UDP (и даже собственных TCP) в userspace, без похода в ядро через эти ваши дурацкие sockets API... обчитаться до заикания, и потом обратно в родной jetty/httpd/nginx/haproxy
Но надо отдать должное - чуваки на Rust ну прям сильно сильно стараются, прям как в последнюю битву еще один раз, уж очень хочется прославиться как самый самый... перспективно небесполезный язык?
Пока не приходят ребята с каким H2O и libreaсtor c С (иногда и с С++ какой lithium) наперевес и не сбрасывают их с первых мест. И так до следующей итерации.
Про пингору писать не буду. Да, молодцы, добрались до 7 класса школы. Как в техникум пойдут (и что-то скажут чего на тему Raft), можно будет еще раз на них посмотреть.
Но тогда зачем его называть C++, можно как-нибудь по-другому назвать, например C# или Rust
Так уже были попытки. D, Vala, Cyclone, C-- какой. Это все не взлетит даже по той простой причине, что просто некому допиливать VS Code и GDB/LLDB.
На самом же деле там нужно лишь немного доработать сам С++ (разрешить перегружать оператор точка и еще пару вещей), ну и заново реализовать всю библиотечную часть, и наступит счастье, никакой Rust и Swift будет не нужен.
C# не проходит кастинг по причине бельзальтернативности GC коллектора, да и там и так уже давно over 9000 базовых класов в Runtimе (40513 in 3.5SP1), их теперь остается только выбросить, жизни не хватит даже перечитать это API великолепие .
Простите, а зачем их хранить в таком непотребном виде? Весь сознательный мир давным давно перешел на UTF-8, ничего лучшего уже никогда не будет. Все остальные древние кодировки сразу на входе (на входе внешних данных) должны быть к utf-8 через какой iconv() приведены, и приложение потом внутри ничем иным оперировать не должно, и выдавать тоже - только UTF-8. Ну ок, для каких Win32 API или RPC можно наверное API врапперов написать, но там просто конвертация на лету в байтовый массив на стеке, хранить это точно не надо.
Таки да, там и правильная бухгалтерская математика для Libdfp реализована в кремнии, и вообще много прикольных вещей. Жаль только что это все в итоге будет выброшено на свалку, об обратном приходится лишь мечтать. Идиократию не победить, весь мир вон считает деньги в double и вообще не парится же (только PostgreSQL с Oracle и спасают от краха цивилизации).
Подскажите хорошую инструкцию на CMake, а то у меня как-то сложно вышло библиотеки подключать из под винды...
Простите, а зачем вы под винду до сих пор что-то пишете? Этож Legacy еще хуже какого OSF/1. Современный Linux вполне юзабелен для абсолютно всех задач, ну кроме CAD/CAM/CAE.
А если по существу - да, Windows и Clang/CMake были "подружены" даже в VS сильно неестественным браком, и реально пользоваться этим было просто невозможно лет пять назад. Весь движ в C библиотеках (да и в С++ тоже, хотя это отдельная спецолимпиада) - он уже много лет почти исключительно в POSIX средах, до Windows там долетают только жалкие остатки.
И вырывать себе волосы, пытаясь на коленках сочинять mmap() и fork()/clone() и прочие POSIX API враперы, а потом портировать еще что-то под винду - такое даже врагу не пожелаешь.
А вот под Linux там все предельно просто - просто берешь и пишешь
потому что там под капотом чёрная магия над старшими битами указателей
Идея со старшими битами так себе. Да, по факту сейчас практически все компьютеры 48 битные (адресуемость до 256 терабайт, типа их хватит всем), но это уже сегодня довольно серьезный косяк/ограничение.
Вот было бы ну очень прикольно иметь возможность обращаться к любой ноде в каком infiniband супер кластере с экзабайтом оперативки просто напрямую, без RDMA API
Хотя какие китайцы может быть и запилили уже подобное...
Потоки кстати тоже не нужны. Почти всегда заменяются асинхронным I/O, где нужно в конкурентный доступ извне, и многопроцессностью (не многотредностью), где нужно терабайты данных в каком ML пережевывать.
На текущем уровне развития IT наличие потоков в прикладном коде - это явный сигнал о кривой архитектуре и весьма слабом понимании современного оборудования (L3/NUMA и прочих когерентностей кешей).
Сомневающимся прописать срочное изучение паттерна LMAX Disruptor, потом много думать.
Есть платформы с сатурацией и без сатурации. Это когда MAX_INT + 1 дает - MAX_INT, или дает 0 на других.
Ну есть и есть, делов-то. Я помню лишь один-два алгоритма, которые прям явно используют целочисленное переполнение. Расчет sha-1, md5 и возможно что-то еще. Покрывается это тестами и прочими #ifdef.
А вот дальше есть два варианта - или код прям гарантированно валиден и никогда не приведет к переполнению, или при переполнении можно попасть на неопределенное (как минимум непротестированное) поведение. И вот тут я бы лично хотел иметь опцию - или вот прям отдельный от int/long специальный тип, который явно разрешает переполнение (типа программист знает что делает), и int/long, которые абсолютно всегда проверяются на переполнение (благо там копейки - OF/CF флаг проверять и делать jmp на секцию с abort()).
Причем переполняемому типу еще и штатную арифметику запретить, пусть через интринзики мучаются, если им сильно надо (а не наоборот, как сейчас с этими вашими __builtin_add_overflow ).
Да, для какого strncpy() внутри проверка на overflow избыточна - вот и ладушки, пусть они это явно там себе это отдельным типом, производным от size_t обозначат и потом еще и обоптимизируются по самое небалуйся на ассемблерах. Но почему остальные должны от потенциальных дыр страдать, раз они там в glibc все такие прям красивые и умные?
А вот про алиасинг и кастинг float к int не так интересно.
Java программисты говорят точно так-же. Даже утверждают, что из Java может быть и быстрее чем C++, и они лично на каких-то блогах про это читали.
Про быстрее на примерах с массивами, без GC - таки вполне может быть в отдельных случаях, особенно если сравнивать с march=x86-64 (generic) и забыть про профилирование и всякие SIMD.
Линус сказал (с плохо скрываемым ужасом в голосе), что на Расте сам не пишет и не планирует. Что фигово.
Почему фигово? Вполне себе реакция здорового человека. Что такое новое может дать Rust в ядре с технической точки зрения, кроме социокультурных моментов вроде упомянутого "привлечения новых молодых программистов для написания драйверов"?
Про безопасность можно не говорить, в данном случае не интересно (до тех пор, пока все ядро на Rust не перепишут).
Кстати, а когда на Rust хоть какое-то ядро уже напишут (или уже написали)?
Там на ЛОРе недавно мелькала новость, какие-то энтузиасты на Ada уже POSIX совместимое ядро верифицированное таки смогли написать, не прошло и 50 лет. Ада, кстати, это был вполне такой себе Rust в 80-х и немного 90-х, жаль померла правда (по тем же нетехническим причинам, что похоже и раст ожидают).
Весь софт для F-22 на Ada был написан, что показательно. Правда весь коллектив потом на пенсию внезапно вышел, а новых не смогли найти, в результате даже пришлось F-35 полностью отдельно с нуля строить, т.к. набранные с рынка C++ разработчики просто не захотели с Ada кодом разбираться.
CMake давно де-факто стандарт. Ну или automake для принципиальных дедушек - он вроде тоже умения в непосредственно make не предполагает (там могу ошибаться, сам не пользуюсь).
Полностью согласен с Бьярном, первое, о чём подумал - что на этих новых языках можно точно так же наворотить.
Там весь цимес в том, что на новых языках чтоб наворотить - нужно приложить усилия. Т.е. проявить прямо злонамеренное целеустремленное упорство.
А чтоб на С++ нужно наоборот - почти всегда прилагать усилия, чтоб НЕ наворотить. Т.е. нужно проявить упорство, опыт, знание и прочее чутье, чтоб реализовать что-то доброе вечное, из лучших побуждений. А вот нечаянно наворотить, отстрелить себе что-то (особенно в чужом коде) - это, увы, поведение практически по дефолту.
В этом плане американских законодателей можно только поддержать. Сначала нужно привести С++ к нормальному поведению по-умолчанию (и кстати вообще убрать неопределенные поведения), а потом уже рекомендовать везде и всегда использовать.
Проблема в том, что у С/С++ самая лучшая инструментальная инфраструктура (бэкэнд, оптимизирующий компилятор, LTO, DCD, LLVM и вот это вот все). Все остальные находятся на уровне если не детсада, то строительного техникума и курят в сторонке. Альтернативы ей нет и не предвидится.
Но фронтэнд, который для человеков, он не просто эстетически ужасен, он какой-то просто человеконенавистнечиский. Простые вещи делаются до предела странными, сложными и многословными конструкциями, это никак не способствует чтению и верификации кода. И делается почти всегда не как у всех, что особенно печально.
Про то, что изначально все базовые примитивы принципиально сделаны не так как у Swift, Kotlin, Java и пр. наследников С++ это понятно (типа кто там первый был и мог подумать как на самом деле надо было), но что мешало уже сделать потом нормально? Зачем тянуть в века это замшелое и посредственное говно мамонта под названием библиотека SGI STL, зачем-то называя ее стандартом? Она даже хешмапы делает плохо, есть более быстрые и удобные. И почему именно эту библиотеку в стандарты двинули, почему нельзя взять любую другую, которая хотя бы строки и контейнеры будет делать в стиле Java (к примеру), и в camelStyle нотации имен? Сколько можно этими подчеркиваниями мучаться?
100500 способов 32 битное целое называть - это вообще зачем? Почему нельзя один раз всем сказать, что со следующего стандарта int это всегда знаковое 32 битное целое и успокойтесь там уже со своим PDP-11, сидите в своем музее на на старом стандарте, вас никто не трогает.
И кому реально так сильно впилась эта обратная совместимость, все равно же без флагов --std= в реальной жизни не обойтись? Хочется писать в духе С++98, ну и отлично - вот вам песочница и отдельные .deb/.rpm со "стандартными" библиотеками, не плачьте.
А вот небезопасные штуки доступа к памяти можно было вполне запретить по дефолту, в равной степени как и принудительную верификацию диапазонов и прочих выходов за границ обязать делать - это все вполне можно было через опцию флажками компилятора привинтить, да и стандартную библиотеку давно пора переписать с нуля, начиная с спецификаций интерфейсов, тут никакой Америки нет. Кому прям очень надо там для какого CRC32 алгоритма - старый стандарт или unsafe флаги в помощь.
Но мир видимо решил проявить упорство в своем безумии и все надежды возложить на весьма странных парней из Rust (как минимум странных своими чумовыми названиями - все эти трейты, крейты, опять не похожий на всех синтаксис), дескать они уж точно знают как надо. Наивность веры в Rust просто невероятно поражает, учитывая, что им пока не удалось ничего более внятного, чем несколько относительно неплохих библиотек для веб микросервисов написать и сильно ограниченно их популяризовать (и то, даже на C++ есть библиотеки и побыстрее, и в целом покруче).
Альтернатива где? Не на Swift же переходить? Хотя поневоле задумаешься, они там уже и на UTF-8 догадались переползти, и даже начали макросы применять, не пройдет и 30 лет как совсем взрослыми станут.
фильтры и гриды - это весь твой уровень? там htmx справится.
PWA так вообще смешно :)
По теме совсем нечего сказать? Это печально (с).
Кстати, а упомянутые "фреймы" это вообще что? Это так по-молодежному frameworks уже стало принято называть? Типа как "собес" это оказывается собеседование, а вовсе не то место, где СНИЛСы выдают?
Ок, тебя попросили привести пример действительно сложных интерфейсов. В результате мы услышали про клики на свечах на SVG графиках, и увидели невнятную попытку самоутверждения демонстрацией чувства превосходства в финале.
Это вообще не спортивно. А можно было и про хитрые LOV с диалогами поиска, и про настраиваемые/сохраняемые фильтры в каких pivot или обычных гридах поговорить, для начала. И про offline mode в PWA, чтоб уж точно HTMX на лопатки положить.
Впрочем это наверное уже middle уровень, джуниорам такое не поручают? Ну и ладно, как нибудь в другой раз.
SSE/Websockets лично я не занимался, да, чятики пилил другой человек. Ну в чем там сложность-то? sectet's hash можно послать каким угодно способом, да хоть как часть пользовательских данных. В чем откровение-то?
Клики на свечу? Да, такое я тоже не делал. Дальше что?
Загуглить "Add onclick event to SVG element" и найти готовый снипет может ребенок лет семи наверное. И потом еще штук 30 снипетов на выбор, какой больше глазу приятнее будет.
Тоже мне ловля на живца, смешно. Это все задачи уровня pre-junior. Решаются правым мизинцем и половинкой гипоталамуса (и ChatGPT вполне справится), там больших ресурсов и не требуется.
Как обычно, это как? Как Htmx авторизовывает sse/websocket/ соединение? (По тз показываем графики только авторизованным клиентам и сессионная кука может стать не валидной, забаненной, как обработать на htmx такие случаи?).
Зачем? auth_token куки шлет браузер. Можно и без кукисов, в HTMX есть возможность дописывать произвольные request headers, но зачем усложнять?
Про невалидную куку не совсем понятно. Как обрабатывать на HTMX ошибки от сервера? Да как угодно, можно заново редиректить на страницу авторизации (сервер инициирует редирект клиента), или на стороне браузера можно перехватывать какие 403/404. Можно и так и так, как угодно. Там вообще нет никаких ограничений и навязываемых подходов, только новые дополнительные к HTML5/CSS3/JS6 фичи, которые можно использовать, можно не использовать (правда автор странно любит и поддерживает даже и IE11, но шутки по этому поводу оставим, у него видимо это личное).
Дальше что происходит? От sse/ws приходят только json? Чей код апдейтит графики и свечи? Ваша писанина как-то при входящем data вызывает bar.update()? или htmx умеет апдейтить графики автоматически ?
В смысле умеет? HTMX штатно сам умеет по клику или какому еще событию получить от сервера HTML код, встроить его куда сервер скажет, при случае вызвать указанный сервером JS или и вовсе сделать какой redirect/page reload. А что сверху - всегда можно ловко донавернуть самому в нужных местах разными способами, плюс расширения всякие готовые.
Там нет ничего военного - всякими разными подходами можно отработать действия пользователя и выслать на сервер request, куда записать тоже что угодно, и получить от сервера ответ - по дефолту один кусок HTML и target element id (но можно и много кусков, и много target), скрипты потом обработчиками вызывать, события получать/заново слать, и т.д. и т.п. Там нет ограничений, в отличие от. Полная свобода. Там только одно ограничение - нет обязательности в React/Vue/Angular и любого иного натужного OpinionWare в зависимостях.
Только htmx.min.js и браузер с его базовым функционалом, этого уже достаточно для полноценного SPA. А дальше можно самому развивать и декорировать куда захочется.
получится ему навесить свои хендлеры на чужие html элементы постоянно меняющиеся, обновляющиеся?
Элементарно. Один из способов - регистрируются custom events, на них вешаются обработчики. Сервер шлет этот самый event, обработчики делают что им там нужно, получив нужные данные через event параметры. И это лишь один из способов.
Может стоит документацию почитать и примеры поизучать? Они там очень прикольные, читаются легко, задорно и весело, в отличие от React/Vue/Angular тягомотины. Первая глава и эссе особенно заставляют прям задуматься о безумии этого вашего корпоративного софтостроения и не только.
Так есть же известный биорекатор для писькомерства.
https://www.techempower.com/benchmarks/
Туда кстати периодически весьма прикольно заглядывать. По разным закладкам вон меряются и длиной, и скоростью, и пропускной способностью, джедайские техники иногда всякие разные показывают, забавные (вроде half closed connection... или это в Go изначально придумали), или реализации NETMAP/UDP (и даже собственных TCP) в userspace, без похода в ядро через эти ваши дурацкие sockets API... обчитаться до заикания, и потом обратно в родной jetty/httpd/nginx/haproxy
Но надо отдать должное - чуваки на Rust ну прям сильно сильно стараются, прям как в последнюю битву еще один раз, уж очень хочется прославиться как самый самый... перспективно небесполезный язык?
Пока не приходят ребята с каким H2O и libreaсtor c С (иногда и с С++ какой lithium) наперевес и не сбрасывают их с первых мест. И так до следующей итерации.
Про пингору писать не буду. Да, молодцы, добрались до 7 класса школы. Как в техникум пойдут (и что-то скажут чего на тему Raft), можно будет еще раз на них посмотреть.
Так уже были попытки. D, Vala, Cyclone, C-- какой. Это все не взлетит даже по той простой причине, что просто некому допиливать VS Code и GDB/LLDB.
На самом же деле там нужно лишь немного доработать сам С++ (разрешить перегружать оператор точка и еще пару вещей), ну и заново реализовать всю библиотечную часть, и наступит счастье, никакой Rust и Swift будет не нужен.
C# не проходит кастинг по причине бельзальтернативности GC коллектора, да и там и так уже давно over 9000 базовых класов в Runtimе (40513 in 3.5SP1), их теперь остается только выбросить, жизни не хватит даже перечитать это API великолепие .
В UTF-16 ничего православного нет. Это ошибка природы, историческое недоразумение.
Простите, а зачем их хранить в таком непотребном виде? Весь сознательный мир давным давно перешел на UTF-8, ничего лучшего уже никогда не будет. Все остальные древние кодировки сразу на входе (на входе внешних данных) должны быть к utf-8 через какой iconv() приведены, и приложение потом внутри ничем иным оперировать не должно, и выдавать тоже - только UTF-8. Ну ок, для каких Win32 API или RPC можно наверное API врапперов написать, но там просто конвертация на лету в байтовый массив на стеке, хранить это точно не надо.
Таки да, там и правильная бухгалтерская математика для Libdfp реализована в кремнии, и вообще много прикольных вещей. Жаль только что это все в итоге будет выброшено на свалку, об обратном приходится лишь мечтать. Идиократию не победить, весь мир вон считает деньги в double и вообще не парится же (только PostgreSQL с Oracle и спасают от краха цивилизации).
Простите, а зачем вы под винду до сих пор что-то пишете? Этож Legacy еще хуже какого OSF/1. Современный Linux вполне юзабелен для абсолютно всех задач, ну кроме CAD/CAM/CAE.
А если по существу - да, Windows и Clang/CMake были "подружены" даже в VS сильно неестественным браком, и реально пользоваться этим было просто невозможно лет пять назад. Весь движ в C библиотеках (да и в С++ тоже, хотя это отдельная спецолимпиада) - он уже много лет почти исключительно в POSIX средах, до Windows там долетают только жалкие остатки.
И вырывать себе волосы, пытаясь на коленках сочинять mmap() и fork()/clone() и прочие POSIX API враперы, а потом портировать еще что-то под винду - такое даже врагу не пожелаешь.
А вот под Linux там все предельно просто - просто берешь и пишешь
даже FindLibrary() уже и не почти нужны совсем.
Идея со старшими битами так себе. Да, по факту сейчас практически все компьютеры 48 битные (адресуемость до 256 терабайт, типа их хватит всем), но это уже сегодня довольно серьезный косяк/ограничение.
Вот было бы ну очень прикольно иметь возможность обращаться к любой ноде в каком infiniband супер кластере с экзабайтом оперативки просто напрямую, без RDMA API
Хотя какие китайцы может быть и запилили уже подобное...
Потоки кстати тоже не нужны. Почти всегда заменяются асинхронным I/O, где нужно в конкурентный доступ извне, и многопроцессностью (не многотредностью), где нужно терабайты данных в каком ML пережевывать.
На текущем уровне развития IT наличие потоков в прикладном коде - это явный сигнал о кривой архитектуре и весьма слабом понимании современного оборудования (L3/NUMA и прочих когерентностей кешей).
Сомневающимся прописать срочное изучение паттерна LMAX Disruptor, потом много думать.
Ну есть и есть, делов-то. Я помню лишь один-два алгоритма, которые прям явно используют целочисленное переполнение. Расчет sha-1, md5 и возможно что-то еще. Покрывается это тестами и прочими #ifdef.
А вот дальше есть два варианта - или код прям гарантированно валиден и никогда не приведет к переполнению, или при переполнении можно попасть на неопределенное (как минимум непротестированное) поведение. И вот тут я бы лично хотел иметь опцию - или вот прям отдельный от int/long специальный тип, который явно разрешает переполнение (типа программист знает что делает), и int/long, которые абсолютно всегда проверяются на переполнение (благо там копейки - OF/CF флаг проверять и делать jmp на секцию с abort()).
Причем переполняемому типу еще и штатную арифметику запретить, пусть через интринзики мучаются, если им сильно надо (а не наоборот, как сейчас с этими вашими __builtin_add_overflow ).
Да, для какого strncpy() внутри проверка на overflow избыточна - вот и ладушки, пусть они это явно там себе это отдельным типом, производным от size_t обозначат и потом еще и обоптимизируются по самое небалуйся на ассемблерах. Но почему остальные должны от потенциальных дыр страдать, раз они там в glibc все такие прям красивые и умные?
А вот про алиасинг и кастинг float к int не так интересно.
Java программисты говорят точно так-же. Даже утверждают, что из Java может быть и быстрее чем C++, и они лично на каких-то блогах про это читали.
Про быстрее на примерах с массивами, без GC - таки вполне может быть в отдельных случаях, особенно если сравнивать с march=x86-64 (generic) и забыть про профилирование и всякие SIMD.
Почему фигово? Вполне себе реакция здорового человека. Что такое новое может дать Rust в ядре с технической точки зрения, кроме социокультурных моментов вроде упомянутого "привлечения новых молодых программистов для написания драйверов"?
Про безопасность можно не говорить, в данном случае не интересно (до тех пор, пока все ядро на Rust не перепишут).
Кстати, а когда на Rust хоть какое-то ядро уже напишут (или уже написали)?
Там на ЛОРе недавно мелькала новость, какие-то энтузиасты на Ada уже POSIX совместимое ядро верифицированное таки смогли написать, не прошло и 50 лет. Ада, кстати, это был вполне такой себе Rust в 80-х и немного 90-х, жаль померла правда (по тем же нетехническим причинам, что похоже и раст ожидают).
Весь софт для F-22 на Ada был написан, что показательно. Правда весь коллектив потом на пенсию внезапно вышел, а новых не смогли найти, в результате даже пришлось F-35 полностью отдельно с нуля строить, т.к. набранные с рынка C++ разработчики просто не захотели с Ada кодом разбираться.
Простите, но зачем в 21-м веке знать про make?
CMake давно де-факто стандарт. Ну или automake для принципиальных дедушек - он вроде тоже умения в непосредственно make не предполагает (там могу ошибаться, сам не пользуюсь).
Модули в С++ уже есть, и CMake их поддерживает (уже год как). И работают весьма неплохо.
Они правда довольно хреново совместимы с STL, но это как раз еще один повод чтоб задуматься о ее аннигиляции.
Там весь цимес в том, что на новых языках чтоб наворотить - нужно приложить усилия. Т.е. проявить прямо злонамеренное целеустремленное упорство.
А чтоб на С++ нужно наоборот - почти всегда прилагать усилия, чтоб НЕ наворотить. Т.е. нужно проявить упорство, опыт, знание и прочее чутье, чтоб реализовать что-то доброе вечное, из лучших побуждений. А вот нечаянно наворотить, отстрелить себе что-то (особенно в чужом коде) - это, увы, поведение практически по дефолту.
В этом плане американских законодателей можно только поддержать. Сначала нужно привести С++ к нормальному поведению по-умолчанию (и кстати вообще убрать неопределенные поведения), а потом уже рекомендовать везде и всегда использовать.
Никогда не спорьте с дураками, они стащат вас на свой уровень и задавят опытом!
— Марк Твен, 371 цитата
И таки сейчас набегут же еще и Твена минусовать, эти суровые рыцари смузи и ванильного латте. Жаль только что нельзя посмотреть список минусующих.
Проблема в том, что у С/С++ самая лучшая инструментальная инфраструктура (бэкэнд, оптимизирующий компилятор, LTO, DCD, LLVM и вот это вот все). Все остальные находятся на уровне если не детсада, то строительного техникума и курят в сторонке. Альтернативы ей нет и не предвидится.
Но фронтэнд, который для человеков, он не просто эстетически ужасен, он какой-то просто человеконенавистнечиский. Простые вещи делаются до предела странными, сложными и многословными конструкциями, это никак не способствует чтению и верификации кода. И делается почти всегда не как у всех, что особенно печально.
Про то, что изначально все базовые примитивы принципиально сделаны не так как у Swift, Kotlin, Java и пр. наследников С++ это понятно (типа кто там первый был и мог подумать как на самом деле надо было), но что мешало уже сделать потом нормально? Зачем тянуть в века это замшелое и посредственное говно мамонта под названием библиотека SGI STL, зачем-то называя ее стандартом? Она даже хешмапы делает плохо, есть более быстрые и удобные. И почему именно эту библиотеку в стандарты двинули, почему нельзя взять любую другую, которая хотя бы строки и контейнеры будет делать в стиле Java (к примеру), и в camelStyle нотации имен? Сколько можно этими подчеркиваниями мучаться?
100500 способов 32 битное целое называть - это вообще зачем? Почему нельзя один раз всем сказать, что со следующего стандарта int это всегда знаковое 32 битное целое и успокойтесь там уже со своим PDP-11, сидите в своем музее на на старом стандарте, вас никто не трогает.
И кому реально так сильно впилась эта обратная совместимость, все равно же без флагов --std= в реальной жизни не обойтись? Хочется писать в духе С++98, ну и отлично - вот вам песочница и отдельные .deb/.rpm со "стандартными" библиотеками, не плачьте.
А вот небезопасные штуки доступа к памяти можно было вполне запретить по дефолту, в равной степени как и принудительную верификацию диапазонов и прочих выходов за границ обязать делать - это все вполне можно было через опцию флажками компилятора привинтить, да и стандартную библиотеку давно пора переписать с нуля, начиная с спецификаций интерфейсов, тут никакой Америки нет. Кому прям очень надо там для какого CRC32 алгоритма - старый стандарт или unsafe флаги в помощь.
Но мир видимо решил проявить упорство в своем безумии и все надежды возложить на весьма странных парней из Rust (как минимум странных своими чумовыми названиями - все эти трейты, крейты, опять не похожий на всех синтаксис), дескать они уж точно знают как надо. Наивность веры в Rust просто невероятно поражает, учитывая, что им пока не удалось ничего более внятного, чем несколько относительно неплохих библиотек для веб микросервисов написать и сильно ограниченно их популяризовать (и то, даже на C++ есть библиотеки и побыстрее, и в целом покруче).
Альтернатива где? Не на Swift же переходить? Хотя поневоле задумаешься, они там уже и на UTF-8 догадались переползти, и даже начали макросы применять, не пройдет и 30 лет как совсем взрослыми станут.
По теме совсем нечего сказать? Это печально (с).
Кстати, а упомянутые "фреймы" это вообще что? Это так по-молодежному frameworks уже стало принято называть? Типа как "собес" это оказывается собеседование, а вовсе не то место, где СНИЛСы выдают?
Ок, тебя попросили привести пример действительно сложных интерфейсов. В результате мы услышали про клики на свечах на SVG графиках, и увидели невнятную попытку самоутверждения демонстрацией чувства превосходства в финале.
Это вообще не спортивно. А можно было и про хитрые LOV с диалогами поиска, и про настраиваемые/сохраняемые фильтры в каких pivot или обычных гридах поговорить, для начала. И про offline mode в PWA, чтоб уж точно HTMX на лопатки положить.
Впрочем это наверное уже middle уровень, джуниорам такое не поручают? Ну и ладно, как нибудь в другой раз.
SSE/Websockets лично я не занимался, да, чятики пилил другой человек. Ну в чем там сложность-то? sectet's hash можно послать каким угодно способом, да хоть как часть пользовательских данных. В чем откровение-то?
Клики на свечу? Да, такое я тоже не делал. Дальше что?
Загуглить "Add onclick event to SVG element" и найти готовый снипет может ребенок лет семи наверное. И потом еще штук 30 снипетов на выбор, какой больше глазу приятнее будет.
Тоже мне ловля на живца, смешно. Это все задачи уровня pre-junior. Решаются правым мизинцем и половинкой гипоталамуса (и ChatGPT вполне справится), там больших ресурсов и не требуется.
Зачем? auth_token куки шлет браузер. Можно и без кукисов, в HTMX есть возможность дописывать произвольные request headers, но зачем усложнять?
Про невалидную куку не совсем понятно. Как обрабатывать на HTMX ошибки от сервера? Да как угодно, можно заново редиректить на страницу авторизации (сервер инициирует редирект клиента), или на стороне браузера можно перехватывать какие 403/404. Можно и так и так, как угодно. Там вообще нет никаких ограничений и навязываемых подходов, только новые дополнительные к HTML5/CSS3/JS6 фичи, которые можно использовать, можно не использовать (правда автор странно любит и поддерживает даже и IE11, но шутки по этому поводу оставим, у него видимо это личное).
В смысле умеет? HTMX штатно сам умеет по клику или какому еще событию получить от сервера HTML код, встроить его куда сервер скажет, при случае вызвать указанный сервером JS или и вовсе сделать какой redirect/page reload. А что сверху - всегда можно ловко донавернуть самому в нужных местах разными способами, плюс расширения всякие готовые.
Там нет ничего военного - всякими разными подходами можно отработать действия пользователя и выслать на сервер request, куда записать тоже что угодно, и получить от сервера ответ - по дефолту один кусок HTML и target element id (но можно и много кусков, и много target), скрипты потом обработчиками вызывать, события получать/заново слать, и т.д. и т.п. Там нет ограничений, в отличие от. Полная свобода. Там только одно ограничение - нет обязательности в React/Vue/Angular и любого иного натужного OpinionWare в зависимостях.
Только htmx.min.js и браузер с его базовым функционалом, этого уже достаточно для полноценного SPA. А дальше можно самому развивать и декорировать куда захочется.
Элементарно. Один из способов - регистрируются custom events, на них вешаются обработчики. Сервер шлет этот самый event, обработчики делают что им там нужно, получив нужные данные через event параметры. И это лишь один из способов.
Может стоит документацию почитать и примеры поизучать? Они там очень прикольные, читаются легко, задорно и весело, в отличие от React/Vue/Angular тягомотины. Первая глава и эссе особенно заставляют прям задуматься о безумии этого вашего корпоративного софтостроения и не только.