Дочекалися!

Это какой-такой класс? Или ты о Servlet API, JAX-RS? Это просто интерфейсы, контенер нужен.

Или прямо совсем сервер в стандартную библиотеку впилили нынче?

com.sun.net, пфф, а я уже испугался. Это те люди, которые завещание пишут между обновлениями версий Java

Вот на реддите гражданин кратко отвечает в чем уникальность асинхронщины в Rust:

If a Future begins execution immediately that means it needs to immediately be placed in its final location in memory so it can be safely referenced during execution of the state machine it is compiled in to. This would require a heap allocation on Future creation as the stack isn’t a stable location. By delaying execution until you await the Future we can delay this allocation until we have the final state machine (Futures nested inside Futures as you call various async functions) and you only need one allocation. You could even potentially have zero allocations if you block your thread on execution of the Future and the executor is clever enough.

Один пул на тред? В смысле? Прямо создавать пул из нескольких тредов на каждый IO тред? Что-то я не догнал. Или ты опечатался?

s/пул/екзекутор/

Или все-таки реактор… короче, ивент-луп, который занимается разборкой очередей задач и epoll’ом. Вот он на тред должен быть один и желательно без блокировок на добавление/удаление задач.

Сорян.

Ага, я тоже сначала испугался, что чего-то не знаю.
Кстати, не нахожу что-то этого класса в исходниках OpenJDK.
Что как бы намекает.

А разве ‘com’ является частью стандарта?

В JRE есть.

Насколько я помню это часть сановской, а нынче оракловской реализации.

А в какой реализации этих классов нет?

Я езжу на квадратных колесах уже много лет. Умею заходить в них в самые крутые повороты. А теперь попробуй продай мне твои круглые! Ха!

Я утрирую конечно, но звучит почти так же.

Я знаю тебя как отличного специалиста по С++. И понимаю, что имея в руках такой универсальный инструмент, которым ты умеешь пользоваться как своими собственными пальцами, смотреть на что-то новое совсем не хочется.

Я тоже много лет писал на С++. Раст попробовал просто ради того, чтобы мозги развлечь по дороге на работу. Теперь это мой любимый язык.

Из плюсов хочеться выделить:
1. Определение времени жизни объекта. Теперь компилятор следит за отсутствием «висячих» ссылок (в том числе и в коде Junior-ов). Кроме того эти ограничения провоцируют лучше продумывать архитектуру и структуру зависимостей.
2. Ограничения по работе с объектом из разных потоков. Так же защищают от некчественного кода (а с потоками накосячить может даже очень опытный мидл)
3. Паттерн матчинг - так же помогает оформлять идеи в более понятном виде.
4. Решена проблема с вызовом методов «недоконструированных» объектов.
5. Приятная реализация ООП (не скажу, что прямо сильно лучше чем в С++, но точно проще).
6. Rust-овские макросы вполне можно использовать как замену темплейтам (но сейчас они все еще выглядят примитивно по сравнению с).

Bonus track: cargo + crates.io идеально решает все те проблемы и говнокод, который обычно живет в папочке «3party» в корне многих C++ проектов.

Есть там, конечно, и свои проблемы, куда без них.


Резюме: время, потраченное на чтение https://doc.rust-lang.org/book/ окупится с троицей, даже если ты продожишь писать на С++.

через тредпул, fcgi, uwsgi

Имеешь ввиду синхронные воркеры? Если да, то асинхрон придумали задолго до ноды.

(а с потоками накосячить может даже очень опытный мидл)

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

Хотя это мелочи по сравнению с ядром, когда тебе нужно помнить, какой же там нужно вариант спинлока дернуть для каждого конкретного случая.

одновременно защита от data-race

К сожалению нет. Имея два объекта (даже завернутых в примитивы синхронизации), дата рейс устроить можно с легкостью.

Ещё python.

Ну я больше говорю о порваных указателях или когда просто не заметил утечки мутабельного обьекта в другой поток. А так все сводится к тому, что считать data race. «Я написал много поточный код и он не делает то что я хочу - data race»

окупится с троицей

Йопт!

Хз, скачал OpenJDK 13, есть там этот класс. Видимо плохо ищешь. Туточки оно. Между прочим в модуле под названием jdk.httpserver, звучит вполне официально.

Спасибо, читану обязательно. Просто фишка в том, что кресты же тоже не стоят на месте и c++20 - это опять-таки новый язык. А все языки не выучишь)

Лучше хаскель сразу учи, а то этот раст какой-то не пацанский, закорючек всё ещё недостаточно.

Книжку с голубым слоном уже читал, спасибо)

Пока в плюсах нужно руками писать сериализации, ни о каких «примитивных по сравнению с темплейтами» макросах и речи быть не может. Ни говоря уже о вещах вроде автоматической конвертации AoS -> SoA, генерации парсеров с адекватным синтаксисом и других edsl.

Темплейты нормально выглядит только как дженерики. Заменить нормальные макросы, вроде rust-овых процедурных, defmacro из лиспов, template haskell они не могут. Или получится крайне сложная реализация абсолютно элементарных вещей (я вкурсе про сериализацию на hana, спириты и прочее).

Кстати да, один из жирных плюсов Rust по сравнению с остальными C-like это встроенная поддержка конвертации твоего любимого формата серилизации в тип. Просто пишешь адаптер к serde и готово.

кресты же тоже не стоят на месте и c++20 - это опять-таки новый язык

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

Пока в плюсах нужно руками писать сериализации

В плюсах это боль, да. Но это ведь только одно из возможных применений для макросов.

Плюс это не заменяет тот факт, что синтаксиси макросов в Расте сейчас, мягко скажем, не самый читабельный.

закорючек всё ещё недостаточно

Их там совсем мало стало, согласен. Сейчас вообще выглядит как типичный С++ код.

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

На самом деле, даже если в Сишку добавить поддержку макросов + интроспекцию получится язык с бОльшими возможностями чем плюсы.

https://github.com/ptal/oak/blob/master/doc/src/full-calc-grammar.md

https://github.com/ludat/hado-rs

https://github.com/mattgathu/cute

Можно писать специфичные под задачу маленькие языки.

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

Там два вида макросов, я подозреваю тот о котором ты говоришь это macro_rules!, у них свой синтаксис и их можно юзать для всяких простых трансформаций. Есть еще procedural macro, они выглядят как обычный rust и там ты уже что хочешь делаешь с потоком токенов.

https://github.com/dtolnay/proc-macro-workshop

Так ты новый язык пишешь, а макросами старый расширяешь.

Я про оба.

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

procedural macro - то еще удовольствие, ручками TokenStream'ы собирать. Или есть способ проще?

А, я думал про видимый юзеру. Ну просто давать писать конфиги на ЯП это так себе затея, на моц взгляд.

procedural macro - то еще удовольствие, ручками TokenStream’ы собирать.

Честно говоря, выбирая между этим и темплейты+препроцессор, я бы выбрал это. К тому же есть quote!.

Или есть способ проще?

Пока нет. https://github.com/rust-lang/rust/issues/39412

А потом умельцы подоспели с неожиданными применениями - сериализация опций командной строки в структуру в одну сторону, и генерация хелпа, shell completion из структуры в другую сторону.

https://docs.rs/structopt/latest/structopt/

Взялся сегодня наконец-то посмотреть внимательно на procedural macro. Там все очень даже круто!

quote! - няшка, прожевал развертку вложенных коллекций `Vec<Vec<_>>` без проблем!

Беру свои слова назад. Процедурные макросы для меня сейчас вылгядят даже лучше чем темплейты.

P.S. Хождение по всяким NestedMeta - то еще удовольствие, конечно. Но приятно, что не приходиться учить дополнительный язык для написания обобщенного кода.

c++20 - это опять-таки новый язык

Шо, опять? Сравнительно недавно новым языком был C++11.

прожевал развертку вложенных коллекций Vec<Vec<_>> без проблем

А ide что-нибудь внятного может почерпнуть из синтаксиса твоей свертки?

Это просто чувак из комикса https://funnyjunk.com/funny_pictures/3182045/Learn+c+in+21+days/

Я помню нажрался как-то с другом, он тогда учился в финансовой академии на факультете 21 века (серьезно, так факультет называется). И у него был их официальный учебник «c++ за 21 день». Я этот учебник у него отобрал и выкинул в помойку.

Да даже c++17 уже наркомания, почитай хотя бы, что они сделали с {}

Эээй. Ты что такое творишь? Я щас полицию позову. Ты же должен защищать плюсы и опускать руст

Ну, учебник про c++ за 21 день - это ересь

В руби и пхп их считай что нет. Питонячий asyncio имеет уродливый дизайн – писать что-то относительно большое – боль. Смешно сравнивать с жсными промисами

Ты асинхрон без гор сахара не воспринимаешь? В том же JS ещё совсем недавно никаких эвейтов и промисов не было.

Питонячий asyncio имеет уродливый дизайн

Смешно сравнивать с жсными промисами

Сам постоянно это говорю. Но не смотря на это, вещь вполне юзабельная. Пул процессов из коробки есть, например.

Ты асинхрон без гор сахара не воспринимаешь? В том же JS ещё совсем недавно никаких эвейтов и промисов не было

Транспилеры давно умели транспилить async во что-нибудь. До async конечно не воспринимаю асинхрон. Тем-более на сервере. Даже цепочки из голых js-промисов нечитабельны в сколь-нибудь больших количествах

Сам постоянно это говорю. Но не смотря на это, вещь вполне юзабельная

Может быть. У меня оставила ужасное впечатление. Может плохо разобрался

Не, это, безусловно, — говнище. Но если не задумываться об этом и просто писать код, то выходит очень даже нормально. Работает себе на уровне магии, ну и хрен с ним.

Пул процессов из коробки есть, например

Чем отличается от этого? https://nodejs.org/dist/latest-v13.x/docs/api/worker_threads.html

До async конечно не воспринимаю асинхрон

Тем-более на сервере

На сях за долго до этого всего асинхрон писали, до сих пор пишут, и ничего. А питоне так ещё с незапамятных времён были удобные обвязки типа asyncore, всякие гринлеты и монструозный twisted. async/await нужны только чтобы снять нагрузку с ограниченной по размеру кодерской черепушки.

Тем, что в питоне этим кто-то пользуется. Ну оно на уровне футур всё таки. Передал и оно просто выполняется, никаких танцев в присядку.

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

Я просто писал интеграцию девайса для Home Assistant. И это было неприятно. У них там свое API поверх asyncio. Приходилось углубляться и обвешиваться костылями. Было совершенно непонятно, когда что вызывается, где последовательно, а где параллельно. Пишешь await в await через await, а оно все-равно в параллель к моему ttyUSB0 стучится..

Еще эта дурацкая тенденция у питонистов – использование библиотеки через расширение ее базового класса. Вкупе с async очень запутывает. Наверное у них это от безысходности, т.к. многострочных лямбд и нет. И какие-то непонятки с аналогом Function.bind() Приходится пердолиться через наследование

Еще эта дурацкая тенденция у питонистов – использование библиотеки через расширение ее базового класса. Вкупе с async очень запутывает. Наверное у них это от безысходности, т.к. многострочных лямбд и нет. И какие-то непонятки с аналогом Function.bind() Приходится пердолиться через наследование

Тут ты не прав, именно эти грязные джаваскриптные костыли существуют от безысходности, а никак не наоборот.

Может быть и так

закорючек всё ещё недостаточно

Ты не прав, их ровно чуть-чуть меньше, чем слишком много.