Пишем приложение на Flutter в связке с Redux

В формальной логике причина предшествует следствию, у вас наоборот. В статье нет ответа на вопрос чего ради притаскивать за уши redux туда, где он как козе баян. Какие проблемы flutter-a вы решили. Чем это лучше statefull виджетов (хуже). Учитывая, что от редакса, осознав его ущербность и сложность на ровном месте, и в джаваскрипте то бегут в mobx, всё это напоминает попытку впихнуть невпихуемое куда только можно.

Рубикон пройден: nginx

Много российских государственных сайтов работает на этом вебсервере

А кроме nginx у государственных сайтов ничего российского и нет — ни железа, ни софта. Разве что контент. ПОЧТИ ВСЕ российские государственные сайты работают на линуксе или windows на компьютерах с процессорами от Intel или AMD. Вот только отжать линукс/windows, крышевать Microsoft, Intel, AMD кишка тонка — эти продукты/бренды так или иначе под защитой законодательства ЦИВИЛИЗОВАННЫХ стран. У nginx такой защиты нет, вот и вся разница. А хитрый план с многоходовочкой что типа nginx отжимают для защиты родины — это вы для дебилов оставьте, агитпропом пришибленных.

Что значит наезд Rambler Group на Nginx и основателей и как это отразится на онлайн-индустрии

Поскольку Россия, то в офис Nginx пришел не почтальон с иском от обиженного Рамблера, а вломился спецназ, провел выемки, обыски, допросы — в общем, налицо страшная угроза национальной безопасности. Что, в общем, логично — такой куш столько лет проплывает мимо рта. Полное безобразие.

Девяностые на самом деле никуда не уходили, просто та братва, которая крышевала ларьки с сигаретами и пивом, сегодня крышует всю российскую экономику. Методы те же, просто масштаб побольше. Эти ребята ведь все равно ничего другого не умеют.

Президент Путин может рассказывать про инновации, 25 миллионов высокотехнологичных рабочих мест и про создание благоприятных условиях для бизнеса и проч. сказочки для сайтов сделаноунас.всру. На то он собственно и Сказочный Долпойоп. Для этого его туда и посадили, чтобы он нес пургу. А вот серьезные люди будут бдительно смотреть, чтобы ни крошки мимо.

Девяностые никуда не уходили, просто та братва, которая крышевала ларьки с сигаретами и пивом, сегодня крышует Рамблер и всю российскую экономику.

Rust для веб-разработчика — быстрый старт и стремительный полет

Автор, у вас эффект Даннинга Крюгера в чистом виде.

== Rust и почему от такой популярный и востребованный.

зачем здесь эта ссылка, и откуда инфа про популярность и востребованность Rust? Выдаёте свои фантазии за реальность и констатируете их как нечто самоочевидное.

== встроенные в язык «green threads» (аля корутины), но они есть уже даже в python

«green threads» в Go ничего общего не имеют с корутинами питона. Вы бы поизучали вопрос прежде, чем делать высказывания космического масштаба и космической же глупости.

== компиляция в нативный код, только непонятно, зачем (возможно, чтобы Docker работал)

Похоже, у вас проф. левель недостаточно высок для понимания. Спросите у тех. кому понятно. Вам объяснят на пальцах.

== совсем мутная ситуация с пакетным менеджером.

Любая ситуация будет мутной, если смотреть на неё через призму предрассудков и нежелания читать документацию.

Но вы пишите ещё, ваше мнение очень важно для всех нас.

Знакомьтесь, <details>

Спасибо Вам, добрый человек, очень помогло! Я до сих пор очень многое из описанного делал по колхозному с помощью бустрапа((

Ящик для хранения данных в go-приложениях

Из текста я так и не понял зачем нужно писать (и уж тем более использовать) ещё один kv сторадж на Go вместо того, чтобы использовать готовые, в которых есть весь упомянутый функционал плюс ещё очень много из того, что не упомянуто, и апи более логичный и чистый. Например, индексы, язык запросов, оптимизации. Cui prodest?

Работа с ошибками в Go 1.13

Есть библиотеки для ошибок на много лучше — github.com/ansel1/merry

Речь идёт о том, чтобы включать стектрейс в любую ошибку, созданную функциями errors.New и fmt.Error.

Как создать свое первое веб-приложение с помощью Go

Да, я по ошибке написал не туда.

Не могли бы вы показать пример искомой либы на другом языке? Если фронтендщик всё разверстал и нужно только правильно приготовить XML, то вроде проблем с Go не должно быть (если я правильно понял о чём речь)

Как создать свое первое веб-приложение с помощью Go

От jsp и asp/asp.net принципиально отличается тем, что не динамический html, а генератор кода на Go. Нет движка сервлетов с магическими диррективами. На quicktemplate вы пишете обычные Go функции и методы, создающие строки текста по определённым правилам.

Не соглашусь с Вами. Для xslt не требуется какой-то специальной поддержки. Можно использовать стандартные шаблоны Go, производящие xslt с динамическим связыванием. Можно создавать XSLT с помощью quicktemplate.

Как создать свое первое веб-приложение с помощью Go

omg шаблоны в Go — это такой дичайший отстой, что их даже врагам народа да террористам на дальних подступах не гуманно впаривать. Не дебажатся, не декомпозируются, не типизируются, вообще ни как не проверяются. Использовать их в серьёзном продакшене — чистое безумие. Используйте github.com/valyala/quicktemplate будет вам счастье

В остальном материал статьи — очередное бессмысленное перетирание из пустого в порожнее о том, как написать хелуворлд на Го, информационной контент которого укладывается в пол экрана оф. доков по пакету net/http

Работа с ошибками в Go 1.13

В чём это противоречит тому, что я написал, и с чего вы взяли что я не читал документацию?

Работа с ошибками в Go 1.13

Каким образом умение поиска по коду поможет найти место возникновения ошибки во внешней библиотеке?

захват фрейма не самая дешевая операция

прикрепить к ошибке несколько байт дебаг-символов — дорогая операция?? с чего вы это взяли? Где бенчмарки?

развертка стека операция по определению недешевая.

совершенно наплевать на развёртку стека. она происходит один раз на самом верху в момент логгирования ошибки

Работа с ошибками в Go 1.13

Не надо путать божий дар с яичницей. При чём тут паника и логи если речь идёт об ошибках? Ошибки в сторонних либах в месте их возникновения нельзя ни залоггировать ни превратить в панику. Стектрейс — единственный способ точно установить где именно возникла ошибка. Стектрейс есть в любом уважающем себя рантайме в исключениях. Тот факт, что по умолчанию в любой ошибке, созданной с помощью fmt.Errorf и errors.New, нет стектрейса — это грёбаный стыд и феерический косяк разработчиков голанга. Один из самых дебильных способов сэкономить на спичках и сломать ноги в темноте

Работа с ошибками в Go 1.13

всё это можно. Но. В someFunc:

errors.Is(fmt.Errorf("%w %w", err1, err2), err1) == err2 //true
errors.Is(fmt.Errorf("%w %w", err1, err2), err1) == err1 //false

Работа с ошибками в Go 1.13

Опять фэйл. Где стектрейс? Где множественное наследование ошибок? Всё ещё использую merry

Многопоточность в .NET: когда не хватает производительности

Я склонен с Вами согласится. Пожалуй, в данном вопросе правы вы, а я ошибался. Любой из потоков ОС, используемых рантаймом Го, может в какой-то момент времени отвечать за выполнение кода одной из горутин. Предполагаю, что потоки ОС из рантайма Го, выполняющие горутины, используют общую память, поэтому переключений контекста ядра/пользователя не требуется. Трудно сказать без нагрузочных тестов, насколько это критично в плане различий с производительностью с C#.

Многопоточность в .NET: когда не хватает производительности

Ничего. Эта исходный код этой функция сгенерирован из прототипов системных вызовов.

Многопоточность в .NET: когда не хватает производительности

Я не думаю, что syscall.Gettid является корректным и переносимым способом определения нативного потока горутины. А почему вы думаете иначе? откуда такая информация?

Многопоточность в .NET: когда не хватает производительности

Нет, затем текущий поток начинает выполнять следующую таску в очереди на выполнение. Никакого «другого потока» в этой схеме нет.

А, ну значит вы просто не в курсе как это работает.

Task.Run(async () =>
            {
                for (var i = 0; i<10; i++)
                {
                    Console.Write("{0} ", Thread.CurrentThread.ManagedThreadId);
                    await Task.Delay(1);                    
                }
            });
            Console.ReadKey();
            // 3 4 4 3 4 3 4 4 4 3

Как вы можете видеть, context switch есть даже в самом примитивном сценарии.

При переключении потоков восстанавливаются настройки MMU и восстанавливается содержимое регистров процессора.

В реальной жизни при блокировках этого достаточно для lock convoy при той нагрузке, которую программа на Go даже не заметит

в dotnet таска переключается в момент вызова «системных» функций, await и вызова SemaphoreSlim.WaitAsync и аналогов

Так ведь не таска в C# переключается, а поток операционной системы переключается. А в Go поток ОС никуда не переключается, он выполняет свои горутины.

dotnet имеет одну очередь из которой много потоков выбирают задачи

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

Причем я думаю, что go на самом деле так не делает. Потому что тогда бесконечный цикл в горутине «вырубит» все, что должны выполнятся в этом потоке.

Безусловно вырубит. Нет, это не повод уродовать рантайм бессмысленными переключениями между потоками ОС. Те, кто пишет бесконечные циклы, учитывают эту особенность. И, кстати, на практике написать такой бесконечный цикл практически невозможно. Мой пример искусственный, на практике будет инструкция a=12, и компилятор такой код не пропустит

И тут стоит вернутся к вопросу — а чем go лучше dotnet в плане выполнения goroutine/task

Я вам в каждом комментарии отвечаю на этот вопрос. Тем лучше, что в Go нет хлама в многопоточном коде, при этом многопоточный код на Go более надёжный и эффективный. Но вы всё игнорируете и продолжаете своё «не вижу» «не понимаю»

Было бы интересно услышать более развернутый комментарий на тему того, что семафор гонки не предотвращает, а мьютекс предотвращает.

Зачем развёрнутые комментарии на очевидное? Это следует из определения семафора и определения гонки данных.