LINUX.ORG.RU

Промисы: библиотеки vs встроенные в язык конструкции

 


0

2

Какие фичи дает нативная поддержка async-await в языке, в сравнении с библиотеками промисов?

Язык любой какой хочется (знаете)

Является ли [в вашем случае] наличие встроенных в язык подобных конструкций сильным аргументом за использование этого языка?

Стали ли вы геморроиться с добавлением подобных фич препроцессором или чем-то таким, и на какие жертвы пошли? (н-р CoffeeScript -> Iced Coffee Script, добавили конструкцию ценой нечитаемого после компиляции кода)

★★★★☆

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

arturpub ★★
()
Ответ на: комментарий от arturpub

В кложуре не было нативной и ничего, припилили сбоку.

unlog1c ★★★
()

По-моему async-await прилепливают к языку тогда, когда нет общего решения, которым является специальный синтаксический сахарок для монад. Да, опять эти монады! Куда же без них?

В F# есть такой достаточно мощный и гибкий сахарок, и async строится целиком средствами самого языка. А вот в Scala нет адекватного встроенного сахарка для монад, там кто во что горазд, а поэтому там как-то все не очень, то макросы какие-то для async, то мудренный синтаксис, то еще чего. И если честно, то я немного разочарован тем, что в питоне ввели частное решение только для async, а не общее - для всех монад сразу.

Есть, конечно, другие пути, но они для языков уровнем пониже, типа тех же Си++. Там, где нет полноценной сборки мусора, а потому абстракции, скажем, не достаточно мощные.

dave ★★★★★
()

Правда, поговаривают, что async-await в C# будет по-быстрее монадического async из F#. Ну, может быть, что-то и есть в их способе реализации. Может быть, не все решения должны быть похожи друг на друга.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)

Еще до кучи добавлю. Async есть в Haskell, но сделан он там как-то хитро (через STM). Все вроде бы ничего, но когда стали рассматривать асинхронные исключения, например, связанные с отменой асинхронных вычислений, то столько граблей сразу вылезло. Это привело к тому, что многопоточные примитивы стали совсем не примитивами, и лишь STM более-менее чисто и просто смотрится. Короче, жертв оказалось много) Здорово подправили рантайм хаскеля. И все из-за асинхронных исключений.

Тема сложная, в общем.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от dave

А вот в Scala нет адекватного встроенного сахарка для монад, там кто во что горазд, а поэтому там как-то все не очень, то макросы какие-то для async, то мудренный синтаксис, то еще чего.

Ты бредишь

anonymous
()
Ответ на: комментарий от anonymous

Дражайший аноним, покажи мне тогда, как можно записать while, for (цикл который), try-catch и try-finally внутри монадического выражения через сахарок. Не кабы как, а на том же уровне, как в F#. Если не знаешь по вычислительные выражения F#, то вопрос снимается сразу за бессмысленностью. В качестве подсказки скажу, что что-то похожее будет через плагин продолжений Scala, но у него есть свои родовые травмы.

dave ★★★★★
()
Ответ на: комментарий от dave

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

anonymous
()
Ответ на: комментарий от dave

Ну и да, это сразу и ответ на вопрос опа - полноценный asyтc-await без нативной поддержки реализовать принципиально невозможно. Будут получаться только кривые костыли.

anonymous
()
Ответ на: комментарий от anonymous

Вот поэтому в Scalа и нет «полноценного» сахарка для монад. Подает надежды макрос effectful, но что-то он совсем не развивается. Кстати, создатель этого макроса был вдохновлен Scala Async.

А для Haskell простительно иметь такой простой сахар по той причине, что там почти все определяется через комбинаторы, а им как бы пофигу на этот сахар. Да даже на уровне такого простого сахара в Haskell сделано много лучше и в разы удобнее, чем то что мы видим в Scala в виде for-comprenehsion. For-comprension, вообще, больше о коллекциях, чем о вычислениях, о чем и печаль.

dave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.