Добрый день! Большое спасибо за статью! Удачи Вашему фрэймворку! Не могли бы Вы уточнить несколько моментов:
1. Реализованный Вами подход, как я понимаю, отличается от Coroutine TS C++. Почему Вы не использовали разработки Lewiss Baker (follycoro) (потому что к моменту начала разработки Userver их ещё не было, или по какой-либо другой причине)? Планируете ли Вы в будущем дрейфовать в сторону стандарта (в смысле в части корутин) (или, наоборот, считаете, что стандарт должен дрейфовать в Вашу сторону ?).
2. Есть ли где-то более или менее подробное описание Вашего подхода к корутинам? Вынесены ли Ваши корутины в отдельную библиотеку (независимую от userver).
3. Есть ли где-то описание Вашего планировщика корутин? Вы использовали подходы, сходные с подходами Дмитрия Вьюкова (Go), или разработали что-то своё?
4. Не думали ли Вы над следующим вопросом: асинхронный сервер – это реально круто, статусно, но для большей раскрутки и востребованности проекта может имеет смысл попиариться и с точки зрения возможности делать асинхронные запросы к web-серверам (по типу pythonовского aiohttp) – чтобы привлечь на свою сторону пользователей, который запросы пишут, но которым не требуется сам web-сервер.
Всем доброго дня! Большое спасибо за статью и обсуждение! Но вообще вместо: «в общем случае RAII из C++ не позволяет делать то, что можно делать через with» корректнее сказать, что область применения with шире, чем RAII. Ваш пример про трансакцию не очень уместно рассматривать в контексте RAII – трансакция не является ресурсом (вот соединение да, ресурс).
А автору статьи действительно стоит указать, что with позволяет изящно реализовать идиому RAII (в C++ ресурс освобождается в деструкторе, в Python из-за сборщика мусора аналогичным способом действовать не получится, но спасает блок finally, который «прячется» в with?) .
И наверно не стоит так часто использовать термин «синтаксический сахар». Всё-таки with – это нечто большее, поскольку влияет на стиль мышления программиста, побуждая думать в логике контекста, что приводит к таким красивым обобщениям, как trio (и, соответственно, вдохновленный trio TaskGroup из asynсio).
Добрый день! По поводу примера 1 из раздела 5 - как то у Вас сложно получилось 😊. Вот так проще будет😊:
А по поводу: «Для данного примера нет алгоритмов, которые смогли бы решить данную задачу» - ну почему же, вполне можно😊:
Ну и соответственно для рэнжей решение можно написать гораздо проще😊:
Добрый день! Большое спасибо за статью! Удачи Вашему фрэймворку! Не могли бы Вы уточнить несколько моментов:
1. Реализованный Вами подход, как я понимаю, отличается от Coroutine TS C++. Почему Вы не использовали разработки Lewiss Baker (follycoro) (потому что к моменту начала разработки Userver их ещё не было, или по какой-либо другой причине)? Планируете ли Вы в будущем дрейфовать в сторону стандарта (в смысле в части корутин) (или, наоборот, считаете, что стандарт должен дрейфовать в Вашу сторону ?).
2. Есть ли где-то более или менее подробное описание Вашего подхода к корутинам? Вынесены ли Ваши корутины в отдельную библиотеку (независимую от userver).
3. Есть ли где-то описание Вашего планировщика корутин? Вы использовали подходы, сходные с подходами Дмитрия Вьюкова (Go), или разработали что-то своё?
4. Не думали ли Вы над следующим вопросом: асинхронный сервер – это реально круто, статусно, но для большей раскрутки и востребованности проекта может имеет смысл попиариться и с точки зрения возможности делать асинхронные запросы к web-серверам (по типу pythonовского aiohttp) – чтобы привлечь на свою сторону пользователей, который запросы пишут, но которым не требуется сам web-сервер.
Всем доброго дня! Большое спасибо за статью и обсуждение! Но вообще вместо: «в общем случае RAII из C++ не позволяет делать то, что можно делать через
with» корректнее сказать, что область применения with шире, чем RAII. Ваш пример про трансакцию не очень уместно рассматривать в контексте RAII – трансакция не является ресурсом (вот соединение да, ресурс).
А автору статьи действительно стоит указать, что with позволяет изящно реализовать идиому RAII (в C++ ресурс освобождается в деструкторе, в Python из-за сборщика мусора аналогичным способом действовать не получится, но спасает блок finally, который «прячется» в with?) .
И наверно не стоит так часто использовать термин «синтаксический сахар». Всё-таки with – это нечто большее, поскольку влияет на стиль мышления программиста, побуждая думать в логике контекста, что приводит к таким красивым обобщениям, как trio (и, соответственно, вдохновленный trio TaskGroup из asynсio).
Доброе утро! Огромное спасибо! Когда набивал заметку на Хабре, накосячил с отступами :) Поправил
Большое спасибо за замечания и за ссылку на ресурс! С форматированием – исправлюсь?
Делая подзапрос на агрегацию, я исходил из того, что лучше сократить объём информации, которая джойнится. Я не прав?
И ещё, подскажите, плиз, почему rigth join – плохой тон?