LINUX.ORG.RU

Почему Go это плохо, и он вам, на самом деле, не нужен.

 ,


7

15

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

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

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

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

Из гугла же идет маразматическая система управления зависимостями Го, которая заточена на монорепы.

Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?

А тут надо понимать, как внутри устроены огромные корпорации типа гугла.

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

Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.

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

Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.

Сложность программных систем возникает из-за их размера. И Go эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много вещей, даже если каждая отдельная вещь - очень простая. Количество RAM в голове ограничено.

В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, Go будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.

★★
Ответ на: комментарий от vinvlad

Общее у них - это использование асинхронного ввода-вывода.

Т.е. когда я пишу на C++ с использованием асинхронного ввода-вывода, то у меня типа как в Go? O_o

Вот тут и подоспела гошечка, где программисту предоставляется более «гуманный» инструмент для программирования таких же шустрых приложений.

А что, есть аналог nginx на Go, который сравним с nginx по производительности?

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

Окей, а теперь давай про Java, треды которой тоже зеленее некуда.

Не - не буду)) Для каждого класса задач - свой инструмент. Java/.Net не пересекаются с Golang по своему назначению. Ну а поскольку вы этого явно не осознаете, то и разговаривать не имеет смысла - пустая трата времени…

vinvlad ★★
()

Мне плевать, на сколько удобен и лоялен ЯП, кто и зачем его придумал, если он решает мои задачи.

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

Не - не буду)) Для каждого класса задач - свой инструмент. Java/.Net не пересекаются с Golang по своему назначению.

Почему не пересекаются? И на том и на другом пишут в основном серверный софт. А .net ещё пишут гуй под венду и даже игрульки (Unity3d).

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

А что, есть аналог nginx на Go, который сравним с nginx по производительности?

Да, на Go можно писать сетевые сервера, близкие к nginx по производительности - там же внутри весь сетевой ввод-вывод асинхронный.

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

А что, есть аналог nginx на Go, который сравним с nginx по производительности?

Да, на Go можно писать сетевые сервера, близкие к nginx по производительности - там же внутри весь сетевой ввод-вывод асинхронный.

Тогда почему не написали? Единственный сервер на Go, который я знаю, это Caddy, и он раза в два-три медленее nginx.

https://github.com/centminmod/centminmod-caddy-v2#caddy-vs-centmin-mod-nginx-http2-https-benchmarks

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

Единственный сервер на Go, который я знаю, это Caddy …

А ты сравнивай не с Nginх, а с каким-нибудь стареньким Apachе, где еще не было модулей с асинхронным вводом-выводом)

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

Единственный сервер на Go, который я знаю, это Caddy …

А ты сравнивай не с Nginх, а с каким-нибудь стареньким Apachе, где еще не было модулей с асинхронным вводом-выводом)

Так это ты сравниваешь:

Да, на Go можно писать сетевые сервера, близкие к nginx по производительности - там же внутри весь сетевой ввод-вывод асинхронный.

лол

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

Ну хорошо - переформулирую ответ другим образом: на Golang можно писать сетевые сервера, существенно более близкие к производительности Nginx, чем классические сервера на обычных OS-овских тредах )) Так устроит?)

vinvlad ★★
()

Хотел добавить «своих пять копеек» к ОП. Когда Ритчи создавал язык программирования С, он его создавал для решения научных задач, на прямую или косвенно связанных с реальным физическим миром. К тому же, базовая логика основалась на математиме и сухом анализе. В каким условиях он творил? Независимый, ученый в научной лаборатории, который фактически ни с чем не связан, главная задача была - простота и лаконичность. А сейчас что творится, в каких условиях находятся условные «создатели языка go»?! У них совершенно нет никакой творческой свободы, их «пайка» как ее наличие, так и размер на прямую завязана на иерархической структуре, где они выступают лишь только «исполнителями», проще говоря самая обыкновенная обслуга и они играют музыку, которую хотят услышать бенефициары иерархии, не больше и меньше.

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

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

Ну хорошо - переформулирую ответ другим образом: на Golang можно писать сетевые сервера, существенно более близкие к производительности Nginx, чем классические сервера на обычных OS-овских тредах )) Так устроит?)

Близкие – это в несколько раз медленнее. Да, так можно, конечно, но Golang тут не уникален. То же можно делать на любом другом говноязычке, если это не пердон.

Смари, вот тут у чувака Kestrel уделал Caddy:

https://edi.wang/post/2021/2/3/aspnet-core-50-throughput-test-in-kestrel-iis-nginx-and-caddy

Правда, у него Kestrel уделал и nginx, так что яхз можно ли верить его бенчу, но это означает что у Kestrel производительность как минимум на уровне с Caddy.

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

Когда Ритчи создавал язык программирования С, он его создавал для решения научных задач, на прямую или косвенно связанных с реальным физическим миром.

Из какой жопы ты этот бред вынул?

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

Этой лабораторией владели AT&T – один из жирных монополистов того времени.

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

Рассматривал, не подошел. А, вообще, посмотриваю на Kotlin Native

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

Т.е. когда я пишу на C++ с использованием асинхронного ввода-вывода, то у меня типа как в Go? O_o

Если ты создаешь структуры-таски с неким каллбеком по поступающим из async io API сигналам, обрабатываешь таски в одном или нескольких реальных тредах OS, вызывая каллбек каждого на некоторый квант времени и сохраняя состояние таска и ендпоинт исполнения в каллбеке для последующего вызова, то внутри каллбеков у тебя будет все как в Go (и все как в плюсовых короутинах). Но вся машинерия с тасками, каллбеками и async io у тебя будет переизобретением гошного рантайма.

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

Писали и много, и быстрого и медленного. Го для сетевых задач ооочень хорошо вписывается.

ergo ★★★
()

Изначально язык хотели назвать «Гой», но решили, что тогда гойский скот обидится и откажется от предназначенного для него языка.

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

Близкие – это в несколько раз медленнее…

В несколько раз медленнее написали конкретные программисты конкретную программульку. Это вовсе не характеризует однозначно возможности языка, который они использовали. Может дело в самих «программистах»…) На C тоже можно отчебучить медленно работающую программу. Так что, не будем погружаться в демагогию.

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

Близкие – это в несколько раз медленнее…

В несколько раз медленнее написали конкретные программисты конкретную программульку. Это вовсе не характеризует однозначно возможности языка, который они использовали. Может дело в самих «программистах»…) На C тоже можно отчебучить медленно работающую программу. Так что, не будем погружаться в демагогию.

Нет никакой демагогии. Есть факт, что производительность кода на голанге не является чем-то из ряда вон выходящим в сравнении с аналогичными языками, как например C#/.net.

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

Есть факт, что производительность кода на голанге не является чем-то из ряда вон выходящим в сравнении с аналогичными языками, как например C#/.net.

А я разве утверждал что-либо противоположное? Просто Java и C# - это достаточно «тяжеловесные» платформы программирования, ориентированные больше на энтерпрайз. В качестве критериев выбора языка фигурирует не только скорость работы приложения - есть и другие нюансы.

vinvlad ★★
()

а давай мыслить позитивно

и следующей темой обсуждения будет «почему сишечка это хорошо и она вам, на самом деле (позарез) нужна»

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

вызывая каллбек каждого на некоторый квант времени и сохраняя состояние таска и ендпоинт исполнения в каллбеке для последующего вызова, то внутри каллбеков у тебя будет все как в Go (и все как в плюсовых короутинах).

Не-а. Если у меня решение будет на чистых callback-ах никуда не упрятанных или вообще на голом цикле вокруг poll-а, то ничего общего с Go не будет.

Но вся машинерия с тасками, каллбеками и async io у тебя будет переизобретением гошного рантайма.

Такое переизобретение произойдет разве что если я попытаюсь сделать систему stackfull coroutines (т.е. повторю какой-нибудь условный boost.fiber или userver).

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

чем классические сервера на обычных OS-овских тредах

На обычных OS-овских тредах можно писать по модели thread per connection или thread per CPU core. И высокие накладные расходы, даже при правильно растущих руках, присущи старой модели thread per connection, а не thread per CPU core. Тем более, что устареть она успела еще в прошлом веке, ведь, емнип, проблема c10k была сформулирована в самом конце 90-х годов.

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

Просто Java и C# - это достаточно «тяжеловесные» платформы программирования

Что это значит? В чём заключается их тяжеловесность?

ориентированные больше на энтерпрайз.

В чём эта ориентация заключается и почему C# используют широко для компьютерных игр (Unity3d)?

Java и Golang – это буквально один и тот же сегмент рынка языков. А именно, язык для команды обезьян, которые будут копать отсюда и до обеда. Единственная разница – у жабы виртуальная машина вместо компиляции в нативный код, но это вообще ничего не значит, потому что всё равно все деплоят через сраный докер.

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

Вы не прочитали всю нить моих постов, поэтому прицепились к одному из них. «Thread per CPU core» - как в Nginx - невозможно использовать оптимально без асинхронного вывода. Считайте, что я критиковал сервера, написанные в модели «thread per connection».

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

Считайте, что я критиковал сервера, написанные в модели «thread per connection».

Мне доводилось видеть сервер, написанный по модели thread per connection, внутри которого I/O делался на неблокирующихся сокетах и с использованием select для определения моментов готовности к чтению/записи. Т.е., грубо говоря, асинхронный ввод-вывод.

Так что из ваших слов проистекает только то общее между nginx и Go, что в них асинхронный ввод-вывод асинхронный.

Не более того.

Ну так и между вами и курицей то общее, что есть по две ноги у каждого.

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

Если у тебя даже и есть компания

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

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

… и почему C# используют широко для компьютерных игр (Unity3d)?

Разве можно валить в одну кучу сетевые микросервисы к компьютерные игры? Это задачи совершенно разного класса. Нравится вам Java & C# - да ради бога…

vinvlad ★★
()

Чет много догадок и домыслов. Разработка Го почти из первых дней открыта, авторы много раз объясняли свою мотивацию. Если в нем не искать то, что туда не закладывали то получается нормальный язык (конечно, со своими недостатками). А разрабатывался он как простая и безопасная замена С++, ближе к простоте С. Пайк сам неоднократно говорил, что они были удивлены, что его растаскали по всем нишам.

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

Разве можно валить в одну кучу сетевые микросервисы к компьютерные игры? Это задачи совершенно разного класса. Нравится вам Java & C# - да ради бога…

это был намёк в сторону godot и опровержение «тяжеловесности» (что это вообще значит?) C#.

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

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

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

Интересный пост.

У google проблем на порядки больше и go много упростил разработку и сопровождения кроссплатформенных приложений.

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

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от eao197

Так что из ваших слов проистекает только то общее между nginx и Go, что в них асинхронный ввод-вывод асинхронный.

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

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

Вы занимаетесь демагогией

Вы сюда часом не с RSDN-а пришли? Это манера тамошних Windows/.NET/C#/Nemerle пропагандонов: чуть что обвинять собеседника в демагогии. Фу таким быть.

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

Я вам прозрачно намекаю на то, что нахождение общего между Go и nginx только на основе того факта, что и там, и там, в итоге, все упирается в асинхронный I/O, несостоятельно.

Ключевой момент в Go – это горутины, которые суть stackful coroutines. А раз это корутины, шедулингом которых занимается не ОС (и, следовательно ОС не может отдать CPU другой короутине, пока текущая заснула на блокирующей операции), то этот самый шедулинг были вынуждены запилить в рантайме Go. И отсюда уже и использование асинхронного I/O (ибо не будь его, короутины бы блокировали лежащие под ними реальные треды ОС при чтении/записи).

Но, сюрпрайз, сюрпрайз, в nginx ничего подобного нет. Там рукопашная работа с системными вызовами ОС.

По сути, Go - это более практичная замена NodeJS

NodeJS мне не интересен. Но вы умудрились найти общее между Go и nginx. И выглядит это так, как будто вы не понимаете сути происходящего.

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

Я вам прозрачно намекаю на то, что нахождение общего между Go и nginx только на основе того факта, что и там, и там, в итоге, все упирается в асинхронный I/O, несостоятельно.

Вы как-то по своему понимаете прочитанное) Ранее я просто дал «намек» на то, что в Go заюзана та же фича - асинхронный ввод-вывод - что и в Nginx и NodeJS. И заюзана она для эффективного использования процессора. Просто в Go это чисто внутренняя фича и вам не нужно возится со всякими callback-ами и прочими сложностями непосредственной работы с асинхронным вводом-выводом. Ничего другого общего между Nginx и Go я и не собирался находить!) Я не утверждал, что Golang === Nginx )))

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

Вы как-то по своему понимаете прочитанное)

Позволю себе напомнить с чего все началось:

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

Про green threads (aka stackful coroutines) вижу, про асинхронность не вижу.

Я не утверждал, что Golang === Nginx )))

А я и не утверждал, что вы такое утверждали.

Мои комментарии относятся к тому, что вы нашли схожесть между nginx и Go. И эта схожесть такая же, как и то, что и человек, и курица, двигается на двух ногах.

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

Про green threads (aka stackful coroutines) вижу, про асинхронность не вижу.

Дык в Golang это спрятано внутрь и предоставляется автоматом - поэтому я и не указал сразу на это явно - дал «намек» чуть позже, типа, дал возможность слегка напрячь мозги, чтобы лучше усвоилось)

вы нашли схожесть между nginx и Go…

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

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

Вот это и называется «демагогия»

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

и явно слишком прямолинейно трактуете слово «схожесть», отрывая его от контекста всего разговора

Этого контекста не возникло бы, если бы вас не заставили явно объяснить, какую именно схожесть вы нашли.

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

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

Цель вытягивания из вас информации и была именно в том, чтобы всем стало очевидно, что вы только про асинхронность ввода-вывода и все. Без вытягивания не было бы «сто раз объяснили».

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

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

Какое богатое воображение.

Рекомендую все же открыть компанию, очень помогает перестать писать херню в интернете.

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

Этого контекста не возникло бы, если бы вас не заставили явно объяснить, какую именно схожесть вы нашли.

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

vinvlad ★★
()

Их давно пожрал рак бюрократии

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

И продукты у них весьма посредственные.

Вот взять google calendar и aCalendar (написанное небольшой студией). Казалось бы, где google и где эта контора. Однако aCalendar на порядок удобнее и интуитивнее.

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

Оно. А сами инженерные задачи вообще по большей части даже и решать не надо.

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

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

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

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

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

Go это чтобы микросервисы писать. а поскольку микросервис имеет малую сложность, то необходимости высоких абстракций ему не надо

C это операционную систему Unix писать. а поскольку операционная система имеет малую сложность, то необходимости высоких абстракций ему не надо

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

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

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

C это операционную систему Unix писать.

а что сложного в ОС? это набор довольно простых компонент. к тому ж тогда размер ОЗУ был в сотни килобайт, и ничего сложного туда положить было невозможно.

у pdp-11 на которой запустили первый unix был кажется 18 битный адрес. то есть размер памяти 256 кб. какая тут сложность?

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

прежде чем обсирать какой-то язык

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

Вас с курицей сравнивал. Это было. И, видимо, не зря.

Но вот ничего плохого в адрес Go или еще чего-то не говорил.

Так что цинк в студию, плиз.

eao197 ★★★★★
()
Ограничение на отправку комментариев: