Golang в крупных проектах возможен (back)?

ты не лучший объяснитель вещей

Так обезъян не учитель и не ставил себе такой задачи. Мне попробовали предъявить за мой фразу, я раскидал, с примером (уже на нескольких языках). Написал что гуглить (хотя это гуглится все даже без подсказок), оставил домашнее задание на выходные так сказать - бестолку.

Если собеседники не могут банально проверить то о чем идет речь, то как вообще с ними что-то обсуждать? Они просто закусили удила, поэтому не важно поймут они что-то или нет, я просто зоонаблюдаю как они сами себя обоссывают и иногда добавляю струю.

Остальные давно поняли о чем речь и перестали спорить, копнув вопрос.

Тот случай когда жаль что нельзя одновременно поставить клоуна и фейспалм.

Мы говорим о проблеме float-ов в стандарте IEEE-754. Один из двух оставшихся хомо эректусов на голубом глазу пытается подсунуть from decimal import *.

то что есть софт/библиотеки/типы которые интовыми инструкциями всё могут посчитать это и так всем понятно

этот пример ничего не доказывает, как и следующий и int

jshell> (2147483647 * 2) / 2
$21 ==> -1

jshell> 2147483647 * (2 / 2)
$22 ==> 2147483647

как впрочем и контр-примеры, очевидно не использующие float

C-style arbitrary precision calculator (version 2.15.0.6)
; (0.1 + 0.2 - 0.3) * 10**17
	0

Кроме нашего хвостатого друга - он утверждал прямо обратное.

Мы говорим о проблеме float-ов в стандарте IEEE-754.

И за 150+ постов мы пока нашли только одну проблему - ты слишком туп, чтобы понять, как они работают.

я тешил себя надеждой что вы поняли что речь о float.

если я правильно понял, он изначально говорил о float, чтобы считать процессором. ты же понимаешь, что несмотря на то, что «проблемы» такой нет - просто не используй float а считай «программно» (в SQL есть, даже в php есть, C# это вообще встроенный value type), всё же например C код считающий через какой-нибудь gmp (хотя я не сравнивал) может оказаться медленнее такового на float/double, особенно если последний векторизовался. а тут нам говорят, что тот же код якобы на самом деле мог бы считать точнее.

да и дефолтом в большинстве языков является не decimal или arbitrary precision библиотека, а float: литерал 1.5 - в большинстве языков это float. вроде в lua вообще все нумерические литералы это float (и еще в каком-то языке так же сделано)

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

По существу моего примера вам возразить нечего ведь я наглядно показал проблему float-ов в стандарте которые на текущем уровне развития оборудования уже заметно так улучшив добавив проверок в граничных диапазонах. Причем - эта проблема известна с момента принятия первой версии стандарта и не была исправлена на тот момент из-за недостаточной скорости работы ALU. Такой баланс скорость-точность вычислений на тот момент считался оправданным, в наше время - уже нет.

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

Обезъян желает вам эволюционировать. Обнял, покружил, поставил на место.

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

Проблема в том что далеко не всегда можно делать подобный вынос для float-ов. И ни один язык программирования не дает такой возможности из коробки в каком-нибудь авторежиме. И я практически не встречал в коде программ ручной контроль который вы описали, это исчезающе малые примеры на фоне всего кода. Думаю, тут вы со мной согласитесь.

Я привел максимально наглядный и известный пример. Можно привести еще бесконечное количество подобных. Думал, что начав гуглить (0.1+0.2-0.3) люди сразу найдут о чем речь и успокоятся, но нет, позориться - так до конца.

Им теперь только пароль выкладывать после такого.

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

я например тупой и сам не смогу за пределами совсем простого «вынеси за скобки» как в том примере. то есть если там и можно вероятность проблемы снизить, то я могу надеяться только что gcc/jvm за меня это сделает (и что не сделает наоборот). но оно не сможет, потому что даже видя «формулу» не знает, что там будет в рантайме.

у меня был код на C где разница типа 0 / 5.5511 повлияла бы по крайней мере на визуальный результат (возможно та программа работает неправильно, но конкретно в ней ничего критичного). причем программа считала два часа на питоне и после переноса функции в С стала считать 30 секунд, то есть decimal/gmp там «не канает». от любой дополнительной точности float (за небольшую цену) в той программе я бы точно не отказался

Вы в очередной раз проигнорировали ключевой момент:

разумеется, мы все ожидаем, что ты говоришь о числах в формате IEEE 754, а не распечатке в ASCII хрен пойми откуда взятых десятичных дробей

Пожалуйста, продемонстрируйте над какими величинами в формате IEEE 754 производятся вычисления в этих выражениях, а затем покажите почему вы считаете эти две последовательности вычислений тождественными.

кажется я понял, что бы призван продемонстрировать тот пример

Я рад что вы поняли, но мне казалось что вы поняли это сразу или практически сразу, судя по вашим ответам.

у меня был код на C

у меня тоже, в том числе и тот который через CUDA работает на видеокартах и где порядки, бывает, доходят до 2^256 со всякими реализациями BIG NUMBERS. При таких расчетах появление значений «около нуля» интервал (0,1) приводит к лавинообразному накоплению ошибки. Приходится стараться разделять примерно как вы описали, но это не всегда возможно. Если тема вам интересна, могу предложить ознакомиться с вот этим.

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

Я с вами закончил. Перечитывайте тему сначала до полного просветления.

если я правильно понял, он изначально говорил о float, чтобы считать процессором.

Это не существенно.

(0.1 + 0.2 - 0.3)
Обезьян пытается объяснить что в нормальном стандарте ответом был бы ноль.

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

Проблема в непонимании простейшей школьной математики, уже всё сказано раз два.

При преобразовании любой "обычной" по одному основанию дроби в дробь по другому основанию, будет вероятность получения бесконечной дроби. И тут "точность" расчётов (про которую тут распинается наш хвостатый друг) не имеет вообще никакого значения. Сколько бы битов ты не насыпал, в конечном итоге дробь придётся округлить на последнем знаке. Соответственно гарантировать, что расчёты в дробях по одному основанию дадут идентичные результаты после конвертации в дроби с другим основанием в принципе нельзя. Ни основания дробей, ни размерность чисел значения не имеют.

Именно это происходит с конвертацией десятичного 0.1 в дробь по основанию 2.

После конвертации с округлением это уже никакой не мусор, а совершенно законное точное число, которое приближённо равно исходному числу, и дальнейшие операции с ним идут по обычным образом.

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

сам не смогу за пределами совсем простого «вынеси за скобки» как в том примере.

Вынос за скобки и прочие алгебраические преобразования вообще тут не при чём. Алгебраическими преобразованиями можно вообще много чего сделать, но это (пока) не задача арифмометра.

(0.1 + 0.2 - 0.3)

Обезьян пытается объяснить что в нормальном стандарте ответом был бы ноль.

Не надо извращать мои слова.

Обезъян пытался объяснить что давно пора добавить доп проверки которые проверяют появление слишком отличающейся разрядности (вверх, вида 10^17 или вниз, в ситуации наоборот) в ряду операндов около нуля и преобразует выражение замедляя! таким образом накопление ошибки.

Для замедления накопления ошибки в 2008м году добавили FMA (fused multiply-add) и обозвали обновленный стандарт: IEEE754-2008 Это позволило снизить накопление ошибки. В будущем стандарте будут еще подобные улучшения и проверки.

Ну прочитайте хоть про FMA, ну нельзя быть такой бестолочью. Ай все, нафиг.

Вы так резво сыпете демагогическими уловками, что приходится уже отгадывать, какой же из выдвинутых вами тезисов вы сейчас пытаетесь отстоять:

• вы знаете некие «баги» в стандарте IEEE-754

• эти «баги», мешающие получению достаточной точности арифметических вычислений, никаким ЯП не победить

Пока что ничего убедительного представлено не было.

Обезьян пытается объяснить что в нормальном стандарте ответом был бы ноль.

Не надо извращать мои слова.

Чувак - это литерально цитата тебя буква в букву.

давно пора добавить доп проверки

Нет, не пора. Потому что тогда воспроизводимость арифметики полетит к чёрту. Загугли, зачем в жаве ключевое слово strictfp.

которые проверяют появление слишком отличающейся разрядности

И каков будет численный критерий «слишком»? На глазок? Примерно так почувствовать?

Не высокая точность операций между находящимися на разных по порядку концах представимого спектра чисел будет проблемой в любой размерности системах с плавающей точкой - это арифметическое свойство самой системы. Совершенно не понятно, с какого хрена вот прям именно сейчас её ВНЕЗАПНО надо почему-то "решать".

и преобразует выражение

А разложение суммы квадратов еще, случайно, делать не надо?

Ну и да, ловко ты переобуваешься с тезиса на тезис по ходу пьесы.

он не берет планку достигнутую десятилетие до него и ничего не упрощает

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

это если даже не говорить о сломаном дизайне обработки ошибок

Ложь.

Дизайн обработки ошибок был сломан в C++. Жизнь стала лучше в Java, хотя основная проблема осталась: control flow разделён на две части, дисциплина обработки ошибок сведена к бюрократии.

Го исправил обработку ошибок. Конечно, даже она может быть улучшена системой типов как в Rust, но без этого никто не страдает.

откуда утверждения о том, что подходы и концепты для конкарренси в нем superior тем что были в языках для простых людей до голанга?

Опыт разработчиков языка. В Plan 9 было тяжело писать многопоточный код на тредах, поэтому начали завозить CSP.

Не перепутайте «для простых людей» с «простые треды».

Если вы имеете ввиду async/await, то хотя это лучше pthreads, у них есть своя доля проблем: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Tldr: “Compared to goroutines, channels, and select, async/await is easier and smaller for language implementers to build or to retrofit into existing platforms. But it pushes some of the complexity back on the programmer, often resulting in what Bob Nystrom has famously called ‘colored functions’.”

В любом случае, нужно что-то лучше стиля pthreads.

что они вообще лучше работают на практике и их дизайн удачен?

Это проверенная модель, так что новые исследования не критичны, хотя никто не против. Кстати, такие исследования существуют:

https://songlh.github.io/paper/go-study.pdf

grep ‘Shared memory vs. message passing’

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

что reasoning относительно них проще и они будут приводить к меньшему числу некорректных программ?

Личный опыт. Некоторые вещи только так и можно установить и это абсолютно нормально.

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

На реализацию было пофиг. Ну мы, конечно, постараемся сделать всё возможное, но пусть полное решение завезёт кто-нибудь другой попозже. That’s life.

они придумали модель памяти которая проще для восприятия и чем джавовская и смогли сами ее соблюсти?

Что не так с моделью памяти? https://go.dev/ref/mem

[«Go создал Гугл для себя»] это маркетинговая болтовня не более

…

голанг вообще не создавался чтобы быть хорошим языком или даже чтобы на нем писать код

Ну а эту болтовню как назвать, «объективным непротиворечивым фактом» или «обязательным диалектическим выводом»?

не было такой разнарядки сверху «нам бы хорошо новый язык для себя создать»

Вы можете опровергнуть тезисы этой статьи? https://go.dev/talks/2012/splash.article

В разделе “Pain points” перечислены pain points. Они действительно существовали в Гугле? Ну я, конечно, не уверен на 100%, но никто из гугла, вроде бы, не утверждает обратное. Эти проблемы были исправлены Гошкой? Многие — да.

голанг всего лишь наполнитель этой внутригугловской политической конкуренции

Даже если так, что в этом плохого? Вы коммунист и желаете взорвать Манхэттен?

gcc -fanalyzer

Недавно общался с разрабом, он работал в Яндексе, Ozon. В целом неплохо отзывался о Go, пишет в основном на нем. Рассказывал про фишку что можно Go запустить и без сборщика мусора. Это может быть полезно, если ваше приложение живет какое-то определенное количество часов каждый день (биржа какая-нибудь) и память за это время вся не успевает забиться. Работать сервис будет быстрее, потому что такты ЦПУ не будут тратиться на сборщик мусора. Но в большинстве случаев наверное это трэш)

Что это значит запустить без сборщика? Бинарник с ключом или собрать без сборщика?

Наверное речь идёт о вызове debug.SetGCPercent(-1) в коде.

но чем [отсутствие синкронайзед блоков и методов] лучше в сравнении с prior art в лице банальной джавы, сишарпа?

Тем, что reentrant locks не нужны.

https://groups.google.com/g/golang-nuts/c/XqW1qcuZgKg/m/Ui3nQkeLV80J

почему в языке якобы хорошо приспособленном для конкурентного программирования, лок отпускается вручную?

Автоматический механизм отпускания лока присутствует (аналог try-finally), на усмотрение программиста.

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

кто отпустит блокировку если вызов appendIfNotExists привет к панике … ?

finally

наверное этот голанг как-то [гарантирует панику из appendIfNotExists() как невозможную в принципе]

Нет

но я бы не сказал, что это «читабельный и понятный» язык.

Паника - исключительный случай, гражданин второго сорта, поэтому обычный код освобождён от бюрократии, связанной с ней. То есть эта вещь наоборот способствует «читабельности».

блокировку автор отпустил сразу же после вызова … потому, что

Чтобы правильно, учитывая риск возникновения паники, отпустить блокировку, нужно делать так:

func() {
	ln.mu.Lock()
	defer ln.mu.Unlock()
	ln.channels = appendIfNotExists(ln.channels, channels...)
}()

Довольно коряво, к сожалению. Поэтому он и написал так, как получилось.

Я лично был бы не против оставить как есть, учитывая то, что используется маленькая и простая функция как appendIfNotExists, где паниковать почти нечему.

нужны SA

sync.Mutex, sync.RWMutex

у голанга вместо модели памяти документ, суть которого сводиться к «ничему»… . пусть будет всё через гонку

Вот этот документ: https://go.dev/ref/mem

Мне сравнить не с чем, джавовскую модель памяти не читал, но мне интересно из чего в этом документе можно вывести «пусть будет всё через гонку».

авторы которого сделали говно и предпочитают не признавать ошибки

Если бы знали процессы, через которые проходит разработка языка, то данное утверждение было бы сложнее сделать. Почти все пользователи языка буквально признают, что все принятые в языке решения имеют свой набор компромиссов. То, что сам язык не догматичен, транслируется самими разработками языка. Небольшой пример: https://research.swtch.com/dogma.

Подробнее про процессы внесения изменений в язык: https://research.swtch.com/proposals

Но факт в том что не из ООП берутся идеи, это ООП просто сборник того что уже было. Но кое-кто сделал финт ушами, взять кучку готовых практик, собрать их вместе и сказать что они специально придуманы, все неразрывно связаны и так задумано назвать это по своему, а потом показывать пальцем на всех где есть что угодно похожее и говорить, «а вот смотрите, а вот тут они позаимствовали наши ООП идеи и подходы»

Е, бать, ты знаток истории CS. Попробуй перед тем как отвечать, изучать вопрос.

это в питоне. в го они не нужны ибо подобная вещь делается через лямбду. да и невозможны питоновские декораторы в го из-за строгой типизации.

Всё, чего в Го нет, по совпадению, не нужно. Прямо удивительно.

kubernetes - это достаточно крупный проект? Или, может, это не достаточно back?

Эту хрень и на баше можно было написать.

Если мне нравится способ обработки ошибок в го, то…

То ничего слаще репы ты не едал.

Идея такая: набираем узбеков за доширак, даем им в лапы пхп (сабж сгодится), они корябают бездарный говнокод без всякого ревью и тестирования

У меня знакомый узбек за натягивание тем на wp берёт 8 тысяч долларов в месяц. СНГшные гоферы будут дешевле: долларов 200-400 можно найти.

Whatever string db:"whatever"

При этом вся хрень, заключённая в `…` разбирается в рантайме твоим импровизированным интерпретатором. Безопасность, мощь и сила! Но декораторы, конечно, «не нужны, ведь есть лямбды».

Им норм, они принюхались; для них Goвно не пахнет.

вы смогли прочитать и даже немного понять логику кода на го абсолютно не зная его :).

Всё верно. А ведь всё благодаря гениальной прагматичности и супер простоте ЯП. Где ещё есть конструкции if, while, а в качестве названий идентификаторов используются слова на английском!

Представляю переписку разработчиков Гошки.

— Расс, ты знаешь как сделать статические интерфейсыдженерики?

— Нет. И не знаю зачем они нужны.

— Ну ладно, тогда делай как попало.

Буквально так и было.

Дизайн обработки ошибок был сломан в C++. Жизнь стала лучше в Java, хотя основная проблема осталась

на эту тему есть пост про вред исключений и ооп https://250bpm.com/blog:4/

бред. код на любом языке, написанный математиком, не читаем

Факт. Написание хорошего кода доступно только людям не знакомым с математикой. Ещё увлечение алгоритмами, говорят, до хорошего не доводит. Напишут свои сортировки, а потом ходют и всю кодовую базу портют. Поэтому, код писать должны только доставщики и только на Гоу, - я так считаю.

и где ты свой пызурек применишь? stl в 93 вроде появился, а вот до этого все эти сортировки нужно было реализовывать самому… в скриптовых же языках всп это часть языка. если пхпшника кто-то попросит сортировку пузырьком реализовать, то он посмотрит на него как на дегенерата. это не имеет смысла. никакого. разумнее спросить про знакомство с каким-то фреймворком… математики же страдают манией величия, поэтому критику не воспринимают, стандартам не следуют… они все считают вторичным кроме своей математики, забывая, что та даже не наука, так как не отвечает критерию воспроизводимости - это прочно язык для описания количественных характеристик мира

Так я и говорю, ты совершенно прав. Алгоритмы не нужны; да и нет других кроме сортировки пузырьком. Те, что нужны уже давно реализовали и включили в PHPGo. Учить пограммиста заумностям вроде математики и CS – только портить. Многие знания – многие печали. Писать код можно только с незамутнённым разумом. Как завещал Иисус: «удобнее верблюду пройти сквозь игольные уши, нежели математику войти в Айти» (от Матфея 19:24).

В математике нет заумности. Она к логике отношение имеет лишь опосредованное. А шарп я хз зачем ты приплел. Верблюду войти в айтишника еще сложнее… И, да, в Go как в яваскрипте многое встроенное. В нем не нужны алгоритмы, которые учат в институтах, там на графах все кончается, которые тож нах нужны. Как и паттерны. Нужно лишь «логическое мышление», которое никак не выразишь в каких-то попугаях. Самые умные - это не айтишники на самом деле. Они как раз не умнее кладовщиков в большинстве своем. Самые умные - это менеджеры, наемные руководители компаний, подразделений и тп. А математики - они ничем не лучше лингвистов каких и филологов, которые максимум могут быть учителями, потому как получали не практические знания, а изучали язык (математика тоже язык и ничего более).

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

Golang — это язык, на замену C++, написанный для команд инженеров Google. Так как в Google бешеный конкурс, этот язык подразумевает, что пользователь — это не новичок, а уже сформировавшийся разработчик, знающий не один язык и свободно жонглирующий понятиями из ООП, Архитектуры ОС, Системного Дизайна, и Компьютерных Сетей. Специально под такого сотрудника собрали новый язык выбрав самые востербованные решение из популярных языков.

Встречал мнение, что этот язык плохо для этого подходит.

Golang хейтят, потому что на одном синтаксисе далеко не уехать: нужно разбираться в идиомах языка. Там с места в карьер начинается использование интерфейсов и Мiddleware для чтения/записи в файл и для создания HTTP-сервера.

Это не язык для новичков.

Отсутствие привычного ООП мешает его юзать?

Смотря кому. Тем, кто разбирается в теории ООП, только помогает. Тем, кто считает, что ООП — это однозначно Наследование/Инкапсуляция/Полиморфизм — мешает.

В конце треда о рецензиях на книги Столярова я много писал о Golang. Там подробно развернуты вопросы ООП и Golang.

В математике нет заумности. Она к логике отношение имеет лишь опосредованное. А шарп я хз зачем ты приплел. Верблюду войти в айтишника еще сложнее… И, да, в Go как в яваскрипте многое встроенное. В нем не нужны алгоритмы, которые учат в институтах, там на графах все кончается, которые тож нах нужны. Родился на улице Герцена, в гастрономе номер двадцать два. Известный экономист, по призванию своему — библиотекарь. В народе — колхозник. В магазине — продавец. В экономике, так сказать, необходим. Это, так сказать, система… э-э-э… в составе ста двадцати единиц. Фотографируете Мурманский полуостров и получаете «Те-ле-фун-кен». И бухгалтер работает по другой линии — по линии библиотекаря. Потому что не воздух будет, академик будет! Ну вот можно сфотографировать Мурманский полуостров. Можно стать воздушным асом. Можно стать воздушной планетой. И будешь уверен, что эту планету примут по учебнику.

Если эту шизофазию высрала не сеть маркова, то остаётся только призвать санитаров.

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

Опять в треде идет классический мотив «алгоритмы не нужны». Нужны алгоритмы, не нужны алгоритмы — без навыка решения и объяснения алгоритмических задач вас не возьмут ни в Yandex, ни в Ozon. Это факт.

Golang — это язык, на замену C++, написанный для команд инженеров Google. Так как в Google бешеный конкурс, этот язык подразумевает, что пользователь — это не новичок, а уже сформировавшийся разработчик, знающий не один язык и свободно жонглирующий понятиями из ООП, Архитектуры ОС, Системного Дизайна, и Компьютерных Сетей. Значит, на пользу физике пойдёт одна планета. Величина, оторванная в область дипломатии, даёт свои колебания на всю дипломатию. А Илья Муромец даёт колебания только на семью на свою. Спичка в библиотеке работает. В кинохронику ходят и зажигают в кинохронике большой лист. В библиотеке маленький лист разжигают. Огонь… э-э-э… будет вырабатываться гораздо легче, чем учебник крепкий. А крепкий учебник будет весомее, чем гастроном на улице Герцена. А на улице Герцена будет расщеплённый учебник. Тогда учебник будет проходить через улицу Герцена, через гастроном номер двадцать два, и замещаться там по формуле экономического единства. Вот в магазине двадцать два она может расщепиться, экономика! На экономистов, на диспетчеров, на продавцов, на культуру торговли…

Ну вот, ещё один.

Я рад, что у тебя бомбит.

А они мне нужны? Туда и без них берут. Если есть знакомые, кто там работает, то тебя возьмут. Я про яндексы. А ozon - это говно. В нем как раз на go пишут и спрашивают алгоритмдристику, чтобы потом про нее забыть и не вспоминать никогда (она реально не нужна).

Ещё скажи, что я тебе завидую.

Википедия говорит, что у тебя либо шизофрения, либо тяжёлое слабоумие:

Помимо параноидной формы шизофрении [шизофазия] … может возникать при тяжёлом слабоумии

Ты чушь пишешь.

Конкретизируйте, где я пишу чушь.

• Вы считаете что Golang написали не в Google и не для замены С++?
• Вы считаете что запись и чтение в файл произсходит без использования интерфейсов пакета io в Golang?
• Вы считаете что патерн Middleware не используется в написание HTTP сервера в Golang?

Все это легко проверяемые факты.

Вы считаете что Golang написали …не для замены С++?

А богомерзкой Java с лицензионными правами на которую были проблемы такие, что одна питерская организация, ныне мимикрирующая под чешскую, разработала для Google на всякий случай Kotlin.

Вы считаете что запись и чтение в файл произсходит без использования интерфейсов пакета io в Golang?

В Go интерфейсы — это не тоже самое, что в других языках.

Вы считаете что патерн Middleware не исползьутеся в написание HTTP сервера?

В Go говно на каллбеках как в JavaScript. Это не Java, Мартин сосет жопу с его бесполезной макулатурой.