как мне перестать искать ошибки после каждой правки и начать писать код
Вот только статическая типизация тут поможет хорошо, если процентов на пять. Много хайпа, очень много бойлерплейта, мало настоящей практической пользы, насколько я могу судить, исходя из личного опыта (и опыта команды).
Передатчик обычно не наш, а если и наш — это вообще не его дело. «Я вот вам поставляю продукты бесперебойно, вы уж там сами как-нибудь со своим складом разберитесь.»
У нас очень много такого типа задач, и это всегда решается тем, что мы принимаем все, чтобы не возникало пробок вне нашего контроля, а потом разгребаем всеми доступными потоками. Иногда приходится даунскейлиться на менее тщательную обработку, и т. п. Просто «потоками» и «асинхронностью» bask pressure не решается чуть более, чем никак.
Основная опасность в том, что мы в итоге получаем zero fault tolerance.
Вот я отладил, выотладил и переотладил свой код, содержащий yield. А Вася его неаккуратно использовал, и теперь внутри yield закрывается открытый мной ресурс. В результате мой (я умею в защитное программирование :) finally блок пытается его закрыть еще раз и voilà.
в Го неизменяемые объекты вообще признаны неидеоматичными, и как-то с этим они живут
Довольно странно приводить Го как пример удачной архитектуры для асинхронных вычислений. Одной корпоративной многозадачности достаточно, чтобы никогда с ним не связываться.
В однопоточном синхронном коде back pressure работает просто по построению.
Мы, наверное, разные вещи называем back pressure. Представьте себе сокет, синхронный, в который льется больше, чем приемник может обработать (не вычитать, а именно обработать). Рано или поздно передатчик захлебнется и отвалится. Чтобы этого не произошло, изобретают механизмы противодействия.
Вы, и комментаторы выше, хором твердите про то, что мы бесплатно получаем back pressure. Я не очень понимаю, каким именно образом, если честно. Иными словами, что случится, если на восьмиядерной машине придет запрос инвертировать девять деревьев? Flux разрулит?
Спору нет, это все гораздо разумнее, чем синхронно долбиться в стену, но чтобы сдерживать back pressure нужен, как минимум, отдельный поток/процесс, просто от переписывания все в реактивненьком стиле чуда не произойдет.
Или я чего-то не понимаю? (Я просто джаву/шарп в последний раз нюхал лет 15 назад и подотстал, но мне действительно интересно).
И при этом Шолле — ученый с мировым именем, пожалуй, второй после Хинтона в глубинном обучении, создатель одной из самых самой широко используемой библиотеки, principal (а может, и distinguished) engineer в Google, и просто умнейший мужик.
При их внедрении (в которое я, повторяю в третий раз, не верю в ближайшие 50 лет в Испании, тут, слава атеизму, в этом плане правительство вменяемое) — я или куплю какую-нибудь тойо-тутундру, или вертолет, или уеду жить на малообитаемый остров.
Написать малюсенькое ядрышко на С, а там IDE его сама допишет.
We call it bootstrapping.
Угу. Что ярко иллюстрируется такими примерами, как LISP, FORTRAN, COBOL, PHP, JS, Scala...
Я вот не использую IDE вовсе, например. Кроме того, если уж IDE такая умная, то, может быть, пусть она сама и код пишет?
И эрлангу это удалось.
В статье, в комментариях выше моего, в моем комментарии, начинающем этот тред.
Просто любопытно: а зачем вам в этой схеме Гугл? Просто ради адреса? Так Гугл прекрасно умеет в переадресацию.
yield resourceВ таком утрированном виде это выглядит как «сам дурак, не нужно ресурсы отдавать», а в реальном мире это иногда необходимо, да и не столь прозрачно.
Кхм. Это не мы решили, это бизнес решил.
Поэтому я и говорю, что реативненькое программирование проблему back pressure не решает.
Вот только статическая типизация тут поможет хорошо, если процентов на пять. Много хайпа, очень много бойлерплейта, мало настоящей практической пользы, насколько я могу судить, исходя из личного опыта (и опыта команды).
И да, у нас проекты не только на десять строчек.
Я не понял вопрос. Что именно — как?
Если вызывающий код позволяет вызываемому навредить ему — дело швах.
Передатчик обычно не наш, а если и наш — это вообще не его дело. «Я вот вам поставляю продукты бесперебойно, вы уж там сами как-нибудь со своим складом разберитесь.»
У нас очень много такого типа задач, и это всегда решается тем, что мы принимаем все, чтобы не возникало пробок вне нашего контроля, а потом разгребаем всеми доступными потоками. Иногда приходится даунскейлиться на менее тщательную обработку, и т. п. Просто «потоками» и «асинхронностью» bask pressure не решается чуть более, чем никак.
Ну я в конец треда просто привык реплики добавлять :)
Если честно, я не верю в удачную архитектуру с concurrency + mutability. Что-то одно, вместе они не работают.
Основная опасность в том, что мы в итоге получаем zero fault tolerance.
Вот я отладил, выотладил и переотладил свой код, содержащий
yield. А Вася его неаккуратно использовал, и теперь внутриyieldзакрывается открытый мной ресурс. В результате мой (я умею в защитное программирование :)finallyблок пытается его закрыть еще раз и voilà.Довольно странно приводить Го как пример удачной архитектуры для асинхронных вычислений. Одной корпоративной многозадачности достаточно, чтобы никогда с ним не связываться.
Мы, наверное, разные вещи называем back pressure. Представьте себе сокет, синхронный, в который льется больше, чем приемник может обработать (не вычитать, а именно обработать). Рано или поздно передатчик захлебнется и отвалится. Чтобы этого не произошло, изобретают механизмы противодействия.
Вы, и комментаторы выше, хором твердите про то, что мы бесплатно получаем back pressure. Я не очень понимаю, каким именно образом, если честно. Иными словами, что случится, если на восьмиядерной машине придет запрос инвертировать девять деревьев?
Fluxразрулит?Спору нет, это все гораздо разумнее, чем синхронно долбиться в стену, но чтобы сдерживать back pressure нужен, как минимум, отдельный поток/процесс, просто от переписывания все в реактивненьком стиле чуда не произойдет.
Или я чего-то не понимаю? (Я просто джаву/шарп в последний раз нюхал лет 15 назад и подотстал, но мне действительно интересно).
А что Kotlin? Это даже не новый язык, а новый синтаксис для неспособных в Скалу.
При всем уважении, Coq — это некая сублимация известного, а Idris — не знает ни одной проверки боем до сих пор.
Agda уж тогда.
И при этом Шолле — ученый с мировым именем, пожалуй, второй после Хинтона в глубинном обучении, создатель
одной из самыхсамой широко используемой библиотеки, principal (а может, и distinguished) engineer в Google, и просто умнейший мужик.А вы — никто.
Ха ха
При их внедрении (в которое я, повторяю в третий раз, не верю в ближайшие 50 лет в Испании, тут, слава атеизму, в этом плане правительство вменяемое) — я или куплю какую-нибудь тойо-тутундру, или вертолет, или уеду жить на малообитаемый остров.
Из нихонги́ же.
Пожалуйста https://habr.com/ru/post/481846/