Опыт строительства инфраструктурных объектов во внеземных условиях вполне имеет смысл. Как минимум - обкатать будущие проекты на Марсе, если человечество дотянет до его колонизации, конечно.
Я читал вашу статью и понял что вы хотели донести, но как лично я вижу это: Есть Клири (надеюсь правильная транслитерация) и есть, допустим, Metanit. Первый говорит что асинхронность не создает потоки вообще никогда (хотя на самом деле, если прокликать его сайт, то можно наткнуться и на await Task.Run() в частных случаях), а второй говорит полностью обратное. И тут есть момент: лучше человеку вбить в голову что асинхронность != потоки, чем вбить обратное. Объясню на примере: я сам учебный план строил по Metanit, просто я разбавлял его поверхностность конкретикой с msdn и пр., и я помню, что асинхронность у него идет сразу после TPL. Таким образом, учитывая, что его статьи написаны для начинающих, и написаны слишком уж коротко, получается такой вопрос: а зачем оно надо, когда задачу можно решать синхронно-мультипоточно. Если же человеку сказать обратное, то у него как минимум возникнет вопрос "а как тогда это работает", и дальше он уже сам нагуглит и про контексты и про configureAwait и про UI/ASP потоки. Конечно, лучше всего написать простыню текста, объясняющего все азы async/await, но это работа для Майкрософт (хотя, надо признать, их async/await написан вполне человеческим языком, да и половина статей там за авторством Клири).
Асинхронные методы выполняются в отдельных потоках
Не буду говорить за все остальное, но async/await блок провальный. Буквально с первой же фразы - асинхронность, это чуть ли не противоположность многопоточности, кроме пары исключений.
Пока я писал ответ на этот пост, решил сделать свой с ссылками на материалы для изучения. И я даже знаю корень проблемы - Metanit. Сайт прекрасный, Евгений молодец, но без связки с MSDN это тикающая бомба. И в теме асинхронности она взорвалась, отсюда и вышеприведенная цитата, и Thread.Sleep() в примерах кода. Без негатива, но лучше незнание, чем лжеучение.
Дайте этому Глебу Воронцову уже скачать WeChat. Ситуация напоминает поговорку "когда ты молоток..", только в данном случае все вокруг кажется гвоздями в гроб площадки, по крайней мере дезигна.
Да, но есть одна мудрость: если нужно сделать Task.Run(), значит код не требует async/await. Т.е. если у нас операция CPU-bound и нам нужно распараллелить работу - async/await здесь не потребуется.
ConfigureAwait обычно используется в рамках оптимизации, когда мы точно уверены, что продолжение async не потребует, например, получать доступ к UI потоку для UI приложений соответственно, т.е. когда захват контекста и размещение в нем континьюации, идущей после await - бессмысленная операция. В таком случае не захватывать контекст выйдет дешевле. Ну и да, континьюацию подхватит поток из пула потоков при false.
Есть хорошая статья, говорящая об асихнронности/синхронном параллелизме. Если вкратце: "хороший" async код практически никогда не запускает никаких потоков. Асинхронность идет до уровня, например, I/O, где она тоже имеется, единственные потоки, которые могут быть задействованы, это использующиеся для уведомления что I/O операция завершилась, но они полностью подкапотные. Но тут еще важно понимать SynchronizationContext, в консольных приложениях продолжение, идущее за await, запросто может выдернуть поток из пула потоков, вернее это сделает планировщик задач, который без контекста синхронизации и использует пул потоков.
сократится потребность в специалистах уровня Junior из-за автоматизации шаблонных и несложных задач. Пример из жизни уже на подходе — успешные попытки автоматизировать написание unit-тестов;
Читал статью до этого тейка. Насколько я понимаю, в этой вселенной господина "я на сцене в кожаной куртке" старшие разработчики будут выглядеть как то так:
Удобно, не надо никаких компиляторов, можно сразу в бинарник писать ритм сердцебиения.
Других идей, каким образом на рынке должны появляться специалисты, у меня нет.
Структуры-record'сы не помечены readonly, так что иммутабельны здесь только классы. Но мне вот стало интересно на что использование record'сов влияет под капотом.
Млять кто эти названия придумывает... Они или настолько увлечены разработкой, что нет минуты выслушать идеи по названиям, или им настолько насрать
Да я тоже купился поначалу. И поймал себя на мысли, что лет 5 назад не воспринял бы всерьез.
Пожалуй, я сегодня постараюсь не заходить на сей сайт..
Тьфу ты
А потом ещё и аббревиатуру можно придумать чтоб по классике "росвросгосспрос", красота
О, а вы тоже вчера на Ютуб через ТВ зашли?
Опыт строительства инфраструктурных объектов во внеземных условиях вполне имеет смысл. Как минимум - обкатать будущие проекты на Марсе, если человечество дотянет до его колонизации, конечно.
Отвлекся от работы на эту статью...
Не совсем понял про SQL Server & Xamarin
Я читал вашу статью и понял что вы хотели донести, но как лично я вижу это:
Есть Клири (надеюсь правильная транслитерация) и есть, допустим, Metanit. Первый говорит что асинхронность не создает потоки вообще никогда (хотя на самом деле, если прокликать его сайт, то можно наткнуться и на await Task.Run() в частных случаях), а второй говорит полностью обратное.
И тут есть момент: лучше человеку вбить в голову что асинхронность != потоки, чем вбить обратное. Объясню на примере: я сам учебный план строил по Metanit, просто я разбавлял его поверхностность конкретикой с msdn и пр., и я помню, что асинхронность у него идет сразу после TPL. Таким образом, учитывая, что его статьи написаны для начинающих, и написаны слишком уж коротко, получается такой вопрос: а зачем оно надо, когда задачу можно решать синхронно-мультипоточно. Если же человеку сказать обратное, то у него как минимум возникнет вопрос "а как тогда это работает", и дальше он уже сам нагуглит и про контексты и про configureAwait и про UI/ASP потоки.
Конечно, лучше всего написать простыню текста, объясняющего все азы async/await, но это работа для Майкрософт (хотя, надо признать, их async/await написан вполне человеческим языком, да и половина статей там за авторством Клири).
Окинув взглядом этот пост еще раз я понял - бездушная копипаста. Это даже не GPT, сурс.
Не буду говорить за все остальное, но async/await блок провальный. Буквально с первой же фразы - асинхронность, это чуть ли не противоположность многопоточности, кроме пары исключений.
Пока я писал ответ на этот пост, решил сделать свой с ссылками на материалы для изучения.
И я даже знаю корень проблемы - Metanit. Сайт прекрасный, Евгений молодец, но без связки с MSDN это тикающая бомба. И в теме асинхронности она взорвалась, отсюда и вышеприведенная цитата, и Thread.Sleep() в примерах кода. Без негатива, но лучше незнание, чем лжеучение.
Дайте этому Глебу Воронцову уже скачать WeChat. Ситуация напоминает поговорку "когда ты молоток..", только в данном случае все вокруг кажется гвоздями в гроб площадки, по крайней мере дезигна.
Да, но есть одна мудрость: если нужно сделать Task.Run(), значит код не требует async/await. Т.е. если у нас операция CPU-bound и нам нужно распараллелить работу - async/await здесь не потребуется.
ConfigureAwait обычно используется в рамках оптимизации, когда мы точно уверены, что продолжение async не потребует, например, получать доступ к UI потоку для UI приложений соответственно, т.е. когда захват контекста и размещение в нем континьюации, идущей после await - бессмысленная операция. В таком случае не захватывать контекст выйдет дешевле. Ну и да, континьюацию подхватит поток из пула потоков при false.
Есть хорошая статья, говорящая об асихнронности/синхронном параллелизме.
Если вкратце: "хороший" async код
практическиникогда не запускает никаких потоков. Асинхронность идет до уровня, например, I/O, где она тоже имеется, единственные потоки, которые могут быть задействованы, это использующиеся для уведомления что I/O операция завершилась, но они полностью подкапотные.Но тут еще важно понимать SynchronizationContext, в консольных приложениях продолжение, идущее за await, запросто может выдернуть поток из пула потоков, вернее это сделает планировщик задач, который без контекста синхронизации и использует пул потоков.
Читал статью до этого тейка. Насколько я понимаю, в этой вселенной господина "я на сцене в кожаной куртке" старшие разработчики будут выглядеть как то так:
Удобно, не надо никаких компиляторов, можно сразу в бинарник писать ритм сердцебиения.
Других идей, каким образом на рынке должны появляться специалисты, у меня нет.
Хабровчане, сознавайтесь
Придумайте шутку про испанца, зашедшего в бар, и дайте имя главному герою. Вряд ли это будет "Вадим" :)
В целом можно открыть имена баскетболистов любой лиги США, и там уже выйдет топ.
Пророк в кожаной куртке
Структуры-record'сы не помечены readonly, так что иммутабельны здесь только классы. Но мне вот стало интересно на что использование record'сов влияет под капотом.