Представлен релиз языка программирования Go 1.14, который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52443
Традиционно не добавили дженериков
Не нужно как твои дженерики как и сам го.
Дженерики в 2.0 будут. Или в 1.2, не знаю, как решат.
1.2 после 1.14?
Так 1.2 > 1.14)
Аноним, ты не прав. Сравнивать надо не строковые литеры, и числовые коды.
Наверное, берегут до версии 2.0, чтобы не провоцировать взрыв сознания у фанатов.
каких дженериков?
Зачем использовать плохие практики из других языков... научитесь писать эффективный код без надуманного говна из прошлого
>научитесь писатьу вас много ошибок в слове "копипастить выполняя работу конпелятора". или, что еще хуже, генерить код.
Это необходимо крайне редко. Гораздо реже, чем кажется тому, кто пока просто не достаточно хорошо научился использовать Go.
Часто нужно. С любой базовой структурой.Вот есть у меня, допустим, некий type X struct, и linked list (container/list), содержащий элементы типа *X.
Там, где с generic-ами я бы имел нормальную типизацию и отлов несовпадения типов в compile time, в Go я имею элементы interface{}, которые приходится явно приводить к *X, и ошибку тут я словлю только в runtime.
Причем, для частных случаев (slices, channels) концепция generic-ов есть (неявно). Иначе бы было совсем плохо. Но только для частных случаев.
Если обобщенные структуры данных вам необходимы крайне редко, я не знаю, что вы там пишете.
> Вот есть у меня, допустим, некий type X struct, и linked list (container/list), содержащий элементы типа *X.
> Если обобщенные структуры данных вам необходимы крайне редко, я не знаю, что вы там пишете.Я просто делаю свой тип на базе `container/list`, который приводит тип и покрываю это unit-test-ом (чтобы в реальном runtime это ни к каким ошибкам не приводило). В общем говорю, вопрос лишь привычки работать с Go.
Да это не привычка, а костыли.
Причем авторы Go проблему прекрасно осознают, уже есть патчи для поддержки generics, их тестируют.
Я, правда, не понимаю, накой они придумали еще одну сущность (контракты) вместо расширения понятия интерфейса.
Это и привычка и костыль. Но костыль малозначимый и невредный (на дизайн приложения негативно не сказывается). Хорошо бы исправить, но и не критично. Например, лично мне важнее было бы исправить производительность ED25519, чем эти generic-и, так как это уже реально негативно сказывается на качество продукта, написанного на Go.
> Я, правда, не понимаю, накой они придумали еще одну сущность (контракты) вместо расширения понятия интерфейса.Эх. А я вот об immutable мечтаю :(
Т.е. вместо проверки типа элемента контейнера компилятором нужно самому каждый раз для каждого нового типа свои проверки лабать? Э, так мой дедушка ещё делал. В конце 70-х.
Уверен, что именно эта проблема делает Go не-usable-ным. Прям никак нельзя поделать эти обёртки, пока не сделают generic-и. Просто ужас какой-то! Как так жить-то!
говно из го вкуснее?
> код без надуманного говна из прошлогоОоооо, святая толстота. Ad hoc polymorphism это оказывается говно из прошлого.
> Ооооо, святая толстота. Ad hoc polymorphism это оказывается говно из прошлого.Примерно так. Мягко говоря не новое изобретение. В массы не пошло в основном потому что превращает код в малочитаемое месиво, в котором никто не может разобраться без поллитры. И после этого радости с того что он компактнее оказывается как-то немного.
Если бы вы хоть немного следили за языком (коль вам эти дженерики так нужны), то вы бы знали, что они будут в Go2 и Роб Пайк в рассылке даже примеры приводил.
Да что ж такое, сектанты только все методички заучили про то, что дженерики не нужны, а тут такая подстава! Что же им теперь, придумывать оправдания с точностью до наоборот?
Дженерики в Го не нужны.
doublethink, однако
Бывает. Почти как с типизацией в джаве и шарпе.. пока туда "универсальный" тип не подвезли..
Пример приведи зачем нужны дженерики в виде кода,
а то вдруг реально полезная штука.
https://medium.com/@alshdavid/an-update-on-go-and-gener...
Шаблоны удобны. Самый расхожий пример шаблонной абстракции это ограниченные по типу коллекции. Да, можно написать и без шаблонов. Но с шаблонами значительно лаконичней. Хотя доступность языка они снижают изрядно. Особенно, когда реализованы только на уровне синтаксической конструкции, как в Java-е.
Ну так и пиши на С++ тогда.
Я не знаком с Го вообще. Как же там обеспечивается типическая безопасность те же коллекций? Каждый раз нужно писать проверки типа при создании коллекции, которая может принимать только определённый тип объектов? А как решается проблема ковариантности?
СРР всё же громоздок и очень небезопасен. Шарп хорош, но есть проблемы с лицензированием и с экосистемой. Ява корява до безобразия, но имеет зрелый инструментарий и крайне развитую экосистему. Идеала, увы, пока нет.
А нужны ли они? Google молодцы: не тащат всё подряд в Go!
Пока не понятно как циклические зависимости разрешать как и во всех языках
А как во всех языках решают циклические зависимости с помощью дженериков?
Лучше крестов.
Хуже раста
Короче, где-то так, посерединке.
в общем Go короче
и еще посерединке 0_0 ?!
хм итого: где-то так ... ну такое ...
Без обоснованное утверждение
эскобар в гробу перевернулся
если вам эта мысль помогает жить, то считайте так., но прошу вас не вводите в заблуждения окружающих.
Смотря с какой точки зрения.
С точки зрения простоты для изучения - конечно. Го изучается за три дня, а кресты можно изучать всю жизнь. С точки зрения мощности языка - конечно нет.
Лучше раста
До чего ж библиотеки или куцые или костыльные. Или самому писать, или ждать, пока созреет как Питон. Обзаведётся либами, др. объектами...
Так я и постарше тебя буду, Петька
Если за 12 лет язык не обзавелся либами, то такой язык годен разве что на помойку.
Это вы пожалуй выкиньте-ка лучше на помойку свой раст с инопланетным синтаксисом. Гошка прекрасный язык, там просто все работает, все сделано для людей.
Как-то ты Раст ну совсем не в тему тут вставил. Лишь бы вставить..
Очень даже в тему. Смотри чуть выше, там гопники с растоманами мерялись.
Я бы сказал, что тролли троллили троллей. Совсем изголодались зелёные. Но если ты говоришь, что гопники с растоманами, значит так оно и есть.
Это ты ещё lisp, erlang и R ещё не видел.
> До чего ж библиотеки или куцые или костыльные.давайте примеры
Наконецто неосилятарам раста можно гордиться что о них не забывают и подкидывают новые релизы.
слушай кул-стори дорогой Аноним: автор языка Rust ушёл из Mozilla в Apple пилить Swift full-time. причина? - как он сам сказал в своём бложике (почитай кстати) из-за слишком высокой когнитивной нагрузки (т.е. Rust слишком сложный для него). за ним кстати последовало несколько участников Rust Core Team, теперь они тоже пилят Swift.так что неосиляторы Rust радуются новым релизам Swift, а не Go
релизам Go радуются все облака - Docker, k8s, Prometheus, Istio, Etcd и т.д.
релизам Rust радуются авторы утилиты из 70-х, Msft IoT Team да 7% Firefox
Да хватит уже. Такие оскорбительные вбросы очевидным образом дискредитируют Rust и всех, кому он нравится (например, меня). Полагаю, пишут здесь такое намеренно и отнюдь не в целях продвижения Rust, а скорее в обратных - выставить сторонников Rust поехавшими.
Го учиться за 2 дня, но только раст может развить вас как разработчика.
Какие же все недоразвитые были до появления Раста!
Не совсем так. В расте слишком много финтифлюшек после которых другие языки кажутся детским садиком.
Хоть и другие замудренные ЯП тоже есть. Но в основном другие имутабльные
В Расте нет ничего такого, чего не было в плюсах с его стандартными и не очень библиотеками. Вменяемое подмножество современных плюсов вообще довольно близко (не синтаксически, конечно, но семантически).
>В Расте нет ничего такого, чего не было в плюсах с его стандартными и не очень библиотеками.Навскидку: модель владения объектов, наличие гарантий компилятора(привет null-pointer exception), стерильные макросы, пакетный менеджер с репозиторием, темп развития языка
> модель владения объектовлегко реализуется средствами с++, причем на любой вкус и цвет, а не как криво прибито разработчиками раста
> наличие гарантий компилятора
наличие _ограничений_ компилятора, не позволяющих программисту писать код так, как он считает нужным (другими словами - отобрали у макаки ножик, дали пластиковую палочку)
> (привет null-pointer exception)
уже много лет как решено использованием всяких разных смарт-поинтеров (даже в стандарт внесли, давно); но макакам, конечно же, это неизвестно
> стерильные макросы
жалкое подобие системы с++ темплейтов, на которых можно хоть целый новый язык сваять
> пакетный менеджер с репозиторием
в с++ на выбор 100500 нормальных пакетных менеджеров, разной степени качественности (включая миллионы раз в год постоянно тестируемые apt, yum, kiss и т.д. и т.п.) - бери и разворачивай любой; а не обязательно пользуй это прибитое гвоздями нерасширяемое поделие
> темп развития языка
А-ХА-ХА-ХА-ХА-ХА.
Уж кто-бы сравнивал темп развития чего бы то ни было с с++, который настолько сильно разогнался, что аж подбешивает (но при этом сохраняет полную обратную совместимость, в отличие от).
--
Вывод: насыпали какого-то говна и рекламируете. Говноеды.
Плюсы уже давно стали какой-то вещью в себе.
Изначально относительно лаконичная надстройка, он со временем превратился в нечто монструозное и совершенно загаженное в плане лексики.
Это наглядный пример того, когда разрабы к существующей и работающей системе, построенной на старых идеях и подходах, просто постоянно пытаются приделывать модные шутки и система превращается в невнятную, громоздкую и отталкивающую ***.Хотя и раст - то еще *.
> модель владения объектовsmart pointers
> наличие гарантий компилятора(привет null-pointer exception)
smart pointers
> стерильные макросы
templates
> пакетный менеджер с репозиторием
conan
> темп развития языка
C++11, C++14, C++17, C++2x...
Да, в Rust все это сведено в единую стройную систему, а в C++ надо изучать хорошие практики и гораздо больше думать о том, что делаешь. При этом система-то не очень простая получилась, когнитивная нагрузка примерно одинаковая. Выстрелить себе в ногу в крестах намного проще, эт да
А больше думать в любом случае не помешает.
Посмотри на Scala, утёнок. Твой Раст это инвалидная коляска.
один из анонимов сказал:
раст для элиты, го для рабов за еду, а си для тех кому скоро на кладбище
Не знал, что в гугле за еду работают. Кормят-то хоть хорошо?
О чём вы? ... бизнесу нужно прям сегодня и прям сейчас, а лучше ещё вчера! Поэтому выбирают языки с огромной экосистемой Java, C#. А за этими языками стоят монстры Oracle и Microsoft, т.е. не умрут языки в ближайшие лет 10 ... Хотите кушать, учите то, что нужно бизнесу. Хотите романтики, учите Rust.
- Он знает что-нибудь?
- Конечно. Он из элиты.
Заходите.
Фильм "Хакеры". 1995.
>> раст для элитыдля той, видимо, что хаскель не осилила
>> го для рабов за еду
у вас в аббревиатуре "PHP" ошибка
>> си для тех кому скоро на кладбище
ну тут всё понятно - реформа образования, не иначе
хаксель нинужен
О, евангелист вылез!
Маслинку хочешь, да? Ты как комивыезжёр - упёртый и навязчивый. И тебе плевать на объективную реальность лишь бы продвинуть свой раст. Любой ценой. Тебе же за это не платят, какая выгода? Ну, кроме гноеизлияния, конечно же.Для крестов есть компиляторы под разными лицензиями и нет ограничения на написанные поделия. А для раста - всё что написано на расте автоматически подпадает под действие mpl. Хуже того - является копирайтом мозиллы. Ну, то есть ты не можешь лицензировать проект на расте иначе, чем под mpl. Если не mpl, то мозилла вправе подать в суд за такое лицензирование и будет исключительно права.
Например, так.
>ты не можешь лицензировать проект на расте иначе, чем под mplПруф?
Ты хотел сказать Хаскель, но зачем-то написал Раст.
https://tsya.ru/
Ой аж новый MacBooks захотелось с Catalina и смузи мне да так чтобы по усам текло и на футболку с не смешим мимом которую я ношу иронично.
Лучше брейнфака
Интересно, почему растаманы набегают в каждую новость именно про go, а не про, скажем, python? Языки настолько же разные, почему именно от go сзади свербит?
Да больше похоже, что это тролли обычные. Но так-то между Go и Rust сейчас напряжение, ведь у них есть пересекающиеся ниши, особенно на фоне последних событий: например, Discord отказался от Go в пользу Rust, а недавно даже Google, вследствие негативного опыта, отверг применение собственного Go в Fuchsia, в то время как Rust оказался допущен во всей кодовой базе, кроме ядра (и то ограничение на ядро лишь связано с тем, что разрабов Fuchsia беспокоит молодость языка).
>Rust оказался допущен во всей кодовой базе, кроме ядраОни же готовые ядра взяли. Смысла нет переписывать. А остальную обвязку уже сами пишут.
Тоненько. Отличный вброс.
Пересекающиеся ниши и с python-ом есть (Twisted, вот это все). Это какой-то срач ради срача. На go удобно писать небольшие инфраструктурные микросервисы, в которых gc не роляет. Он как раз хорошо заменяет всякие там python+twisted / ruby+eventmachine / nodejs - программировать так же просто (даже проще), развертывать проще простого (на выходе один бинарь), можно поручить не особо опытному разработчику. Rust для задач посерьезнее, он скорее конкурирует с C++.
Согласен, мне самому не нравятся эти срачи (но я правда не очень уверен, что ребята, которые развели здесь Go vs Rust действительно растоманы - больше похоже, что это просто повышенно зеленые персонажи).Хоть я и люблю Rust, я не считаю, что все нужно на нем писать (хотя очень многое можно и стоит) и у Go определенно есть свое место. Правда я не уверен в Go для больших проектов, по крайней мере пока не появятся фичи, обещанные для Go 2.0
про дженерики уже спрашивали?
Пара вопросов ко всем кто это читает:
1) чем для вас плох Go?
2) какой ЯП больше всего нравится?
1. Простая невыразительная система типов, относительно толстый рантайм, if err != nil. Простой язык - это здорово на небольшой кодовой базе: тула какая-нибудь, микросервис и прочее в таком духе, но на большом проекте поддерживать тонны копипасты уже такое себе удовольствие, как по мне.2. На данный момент Rust. Да, он нетривиален, поначалу кажется странным, и на нем в некотором смысле приходится учиться программировать заново (особенно, наверное, если не имел дела с функциональными языками). Но за свою кривую обучения Rust благодарно отплачивает. Трейты, афинные типы, алгербаические типы, дженерики, макросы, кложуры, итераторы, паттерн-матчинг, everything is expression, оператор проброса ошибок (вместо if err != nil), отсутствие Null как явления и еще очень много чего - все это позволяет писать надежный, плотный, обобщенный и эффективный код.
>> оператор проброса ошибокэто же полная дичь, как можно всерьёз говорить о каком-то надёжном коде, написанном на язычке, допускающим подобное
>> if err != nilесли рассматривать гошку как игрушечный вариант С, обвешанного игрушками-погремушками, то подобный вариант обработки ошибок выглядит вполне логично. для мелких тулзовин пойдёт, если человек не знает С. гошка хотя бы правильно позиционируется, в отличие от растишки, на которой апологеты "прогресса" кидаются переписывать чуть ли не ядра
Вы хоть разобрались бы, о чем речь. Под пробросом ошибок подразумевается, что вместо копипасты "if err!= nil {return err;}" на Rust можно написать что-нибудь в духе "let response = service.get_data()?;", и если из get_data вернулась ошибка Result::Err(error), то она вернется из функции, а если нет, то результат исполнения Result::Ok(response) распакуется и поместится в переменную response, а функция продолжит выполнение. Т.е. абсолютно то же, что и с Go, только тело функции не засрано бойлерплейтом. И даже более того, в Go 2.0, насколько я помню, подумывают добавить похожую фичу. К тому же, учитывая, что в Rust ошибки упакованы в алгебраический тип Result, семантика языка не даст их не проверить/не пробросить выше, и никакой линтер для этого, как в случае с Go, не нужен.Судя по всему, вы ничего не знаете про Rust, да еще и очень надменно рассуждаете о других языках и их сферах применения. Даже я не пишу о Go в такой уменьшительно-ласкательной снисходительной манере.
Из последнего, такая "троица":
* агент — демон на "голом" C (вообще-то "на голом" разве что ядра, реально в роли "фреймворков" glibc, libpthread, zlib и т.д.) — ≈2c CPU за сутки, 1.5 недели на написание/отладку. От 200к до 2М RSS (x86), в зависимости от багов glibc (внезапно, там кое-что может вообще никогда не вычищаться и это мало кого парит т.к. "не течёт же дальше"). Бинарник 28к (т.к. динамическая линковка). На самом деле, 28к для такой финтифлюшки — тоже безобразно много, но тут и 64бит и более-менее свежий GCC 7.4.1 — против компактности.* Сервер-коллектор на golang (раньше вполне мог оказаться на python, но теперь всё убивает вопрос "какой версии"). ≈20с CPU за сутки (из них половина — GC), пара дней на написание/отладку. 4…8МБ RSS (т.к. GC). Бинарник 3МБ (всё статикой, "-ldflags "-s -w" --tags static_all").
На С такое даже пытаться бы не стал, т.к. не имею бесконечного времени. А так — почти честный демон (один форк со сбросом привилегий, но без второго с отвязкой от всяких консолей/fd).* "Экспертная система" — псевдо-демон на баше. День на расписывание выходов "автомата", ещё день на зачистку багов (примерно в каждой строке). Главный баг (писать на баше) при этом сохраняется на неопределённое время. Вызываемые в процессе find/grep/etc. едят в среднем 3МБ RSS, но CPU за сутки набегает до 300с (и в дальнейшем ещё добавится некий logN от числа обрабатываемых отчётов).
Аналогичная функциональность сразу на каком-нибудь go заняла бы около недели времени т.к. изначально не было готовой концепции "как правильно". Или вот так как я сделал (из г&п) и затем переписать (опять таки +время, но можно разбить на более короткие/предсказуемые фазы и вообще переписку отдать пофессиональному кодеру).Это я всё к тому, что не "игрушечный вариант С", а каждому свои задачи. Go свою нишу нашёл, а вот от "взятия на вооружение" rust пока отпугивает текущий состав комьюнити. (Во как я политкорректно выдал). И вообще есть риск что rust повторит судьбу haskel "прикольно но".
> из них половина — GCИспользую активно Go с 2012-го года, но чтобы половина была сожрана GC -- такого ни разу не было. Хотя на старых версиях Go, и когда я ещё не умел писать на Go, GC бывало сжирал 30-40 процентов.
Можно на код глянуть? :)
> Использую активно Go с 2012-го года, но чтобы половина была сожрана GC
> -- такого ни разу не было. Хотя на старых версиях Go,
> и когда я ещё не умел писать на Go, GC бывало
> сжирал 30-40 процентов.В данном случае (сервис крутится практически вхолостую, "коту нечего делать") — вполне нормально.
* "Холостой" экземпляр в паре A-S — вообще ничего не потребляет (кроме RSS). Т.к. один тред висит на futex() пока сигнал не случится, а payload ничего не делает пока сокет пустой.> Можно на код глянуть? :)
Да пожалуйста https://github.com/ds-voix/VX-PBX/tree/master/IPADDRD
Если вам важны процессорные циклы и нагрузка на GC, то буду рад предложить PR, чтобы лёгким исправлением слегка поправить ситуацию. Актуально? :)
> Если вам важны процессорные циклы и нагрузка на GC, то буду рад
> предложить PR, чтобы лёгким исправлением слегка поправить ситуацию. Актуально? :)Просто ткните носом (любым удобным способом).
Здесь, повторюсь, оно не важно. Но это не значит, что мне не интересен принцип.
* Сейчас взял калькулятор, 20с на том хосте где крутится это ≈0.003% от местной "полезной нагрузки". Однако, это совсем другая проблема. И она (внезапно) про python.** Там же, выше по каталогу, лежат куски от flowchart-based АТС. Которая прочно застряла в b2b по причине отсутствия фронт-энда с одной стороны и интеграции с популярными CRM — с другой. Здесь возможен как fixed-price, так и выпуск ООО с долями под проект. Проблема найти заинтересованного специалиста: задача (про фронт-энд) достаточно нестандартная.
По-хорошему надо написать benchmark-тесты, найти узкие места и устранить. И обычно, когда пишут на Go, стараются в main-е держать лишь парсер флагов и запускатель когда и другого пакета. Таким образом легко становится делать тесты и разбираться почему что-то медленно работает.Если это не очень актуально (как я понял), то, конечно же, лень тратить время на это. Поэтому давайте посмотрим хотя бы быстрым взглядом поверхностно (извиняюсь за низкое качество анализа):
1. Вы каждый раз выделаете огромный буфер:
buf := make([]byte, BUF_LEN)Если убрать `go` от `serve`, то можно было бы один раз выделить этот буфер (просто вне `for`-а) и постоянно его использовать. Если `go` нужен. то можно постараться либо изменить serve (перенести функционал), чтобы ему не нужен был этот буфер, либо в крайнем случае хотя бы просто применить `sync.Pool` для переиспользования буферов. По факту в отдельной рутине (`go serve`) достаточно было оставить только ту часть, что с syscall-ами, ибо вычислительная часть занимает сильно меньше, что позволило бы сделать один статический буфер (и избежать даже `sync.Pool`).
Есть ощущение, что именно эта строчка и портит вам всю статистику.
2. Что такое `daemon`? Не вижу его в import-ах.
3.
ipv4 = append(ipv4, fmt.Sprintf("%b %s", (head>>1), ip.String()))
...
hostname = fmt.Sprintf("%s", buf[pointer+1:length-4-16])
...
report := fmt.Sprintf("addr=%s\nhost=%s\n", addr.String(), hostname)
if overhead {
report += "overhead\n"
}
... и т.п.Это всё тоже в некоторых случаях нехило давит и на CPU и на GC. Опять же, sync.Pool + strings.Builder (вместо Sprintf).
Кроме того, преобразование []byte в string делает копию (давит и на CPU и на GC). Вы могли вообще без string тут обойтись (см. bytes.Builder, вместо strings.Builder).
То есть да, Sprintf удобен, но когда пишешь именно тот кусочек кода, где действительно важна производительность, то лучше избегать его использования.
---
В целом, если вам будет действительно важно что-то прооптимизировать на Go, то я буду рад разочек помочь. Если вам важно прооптимизировать именно эту программу, то с вашей стороны я бы попросил написать unit/integration тест для той части кода, что мы хотим оптимизировать. А я со своей стороны пообещаю добиться производительности близкой к Сишной без особых костылей.
Сделать unit/integration тест очень несложно: просто превратите listen_udp в функцию, которая принимает этот `pc` извне аргументом типа net.Conn и напишите тест, который вызывает эту функцию, посылает туда хотя бы парочку разных пакетов и проверяет правильность результата.
Я добавлю benchmark тест. Сделаю `go test ./ -bench=. -cpuprofile /tmp/cpu.pprof -memprofile /tmp/mem.pprof`, глянем на реально слабые места этой программы и исправим ;)
Прошу прощения за опечатки...> запускатель когда и другого пакета.
->
> запускатель кода из другого пакета.
... и т.п. Только проснулся :)
> 1. Вы каждый раз выделаете огромный буфер:
> buf := make([]byte, BUF_LEN)Мне самому глаза мозолит, но тут по большому счёту референсный кейс: "по-быстрому обслужи пришедшее соединение и форкни то что долгое в отдельный тред". Соответственно, просто переиспользовать в такой схеме не прокатит. Но таки да, make(buf) всё портит. Не сильно заморачиваясь, есть вариант выделить "кольцо" статикой…
* Альтернативно кон. автомат и пул воркеров как в схемах с nginx (и гонять туда данные по каналам? не, лучше сообщения "возьми этот буфер"), но тут это "из пушки по воробьям".> Если убрать `go` от `serve`, то можно было бы один раз выделить
> этот буфер (просто вне `for`-а) и постоянно его использовать. Если `go`
> нужен. то можно постараться либо изменить serve (перенести функционал), чтобы ему
> не нужен был этот буфер, либо в крайнем случае хотя бы
> просто применить `sync.Pool` для переиспользования буферов. По факту в отдельной рутине
> (`go serve`) достаточно было оставить только ту часть, что с syscall-ами,
> ибо вычислительная часть занимает сильно меньше, что позволило бы сделать один
> статический буфер (и избежать даже `sync.Pool`).
> Есть ощущение, что именно эта строчка и портит вам всю статистику.Насчёт syscall's — архи-разумная мысль. Обязательно попробую в след. раз. разнести мухи/котлеты.
sync.Pool + "кольцо" буферов — ага. Тогда вообще есть вариант сразу выпустить воркеров "статикой", по одному на буфер. Дальше "семафорить" или блокировкой, или каналы "сделай"/"сделал".> 2. Что такое `daemon`? Не вижу его в import-ах.
Пакет go-daemon → "daemon".
>[оверквотинг удален]
> report := fmt.Sprintf("addr=%s\nhost=%s\n", addr.String(), hostname)
> if overhead {
> report += "overhead\n"
> }
> ... и т.п.
> Это всё тоже в некоторых случаях нехило давит и на CPU и
> на GC. Опять же, sync.Pool + strings.Builder (вместо Sprintf).
> Кроме того, преобразование []byte в string делает копию (давит и на CPU
> и на GC). Вы могли вообще без string тут обойтись (см.
> bytes.Builder, вместо strings.Builder).Да. Не слишком красиво/привычно (аналогичные "Sprintf()" есть в большинстве ЯП ), зато без дурных копий.
>[оверквотинг удален]
> программу, то с вашей стороны я бы попросил написать unit/integration тест
> для той части кода, что мы хотим оптимизировать. А я со
> своей стороны пообещаю добиться производительности близкой к Сишной без особых костылей.
> Сделать unit/integration тест очень несложно: просто превратите listen_udp в функцию,
> которая принимает этот `pc` извне аргументом типа net.Conn и напишите тест,
> который вызывает эту функцию, посылает туда хотя бы парочку разных пакетов
> и проверяет правильность результата.
> Я добавлю benchmark тест. Сделаю `go test ./ -bench=. -cpuprofile /tmp/cpu.pprof -memprofile
> /tmp/mem.pprof`, глянем на реально слабые места этой программы и исправим ;)
> https://golang.org/pkg/testing/Да, идею я понял: для бенча нужна точка куда удобно напихать данных.
Соответственно, "хороший тон" делать так "из коробки". Конкретно здесь — вынести начало обработки пакета в новую функцию (? +пенальти на вызов. Или тесты в GO умеют изображать работу net-сокетов?).
Быстро не обещаю т.к. конкретно этот код "сделал-работает-забыл". Или "на досуге потренироваться", или подвернётся что-нибудь более требовательное к качеству.
> Использую активно Go с 2012-го года, но чтобы половина была сожрана GC
> -- такого ни разу не было.А ты попробуй покодить как вон там в fuchsia - драйверок ФС, какой, чтоли. И посмотри чего будет дальше, и почему хипстеры такой languages.md, или как там его накорябали :)
> но на большом проекте поддерживать тонны копипасты уже такое себе удовольствие, как по мне.копипаста -- это обычно признак неправильного дизайна приложения. Возможно нужно было делать отдельный package реализующий что-то и задействовать его, или договориться о каких-то других интерфейсах внутри или ещё что (варианты бывают очень разные). В другом бы языке вы это просто замазали бы наследованием или ещё какой фигнёй, а тут придётся подумать и сделать правильно.
> относительно толстый рантайм
Это правда, если говорить про попытку использовать его на микроконтроллерах (хотя там есть tinygo) или прочем embedded. Но а если говорить про generic case, тогда не понятно о чём вы. Можно конкретнее (и сравнение с каким-нибудь другим языком)?
> Простая невыразительная система типов
Что это значит? Очень даже конкретная и выразительная система типов. Можно конкретнее?
> if err != nil
В смысле вы бы предпочли throw-try-catch или к чему это?
> Возможно нужно было делать отдельный package реализующий что-то и задействовать его, или договориться о каких-то других интерфейсах внутри или ещё что (варианты бывают очень разные)
>В другом бы языке вы это просто замазали бы наследованием или ещё какой фигнёй, а тут придётся подумать и сделать правильно.Все равно не хватает дженериков и интерфейсы не позволяют делиться реализацией, так что до появления Go 2.0 от копипасты до конца не получится убежать, мне кажется. В Rust, к счастью, тоже нет такой гадости как наследование (в этом и в ряде других вопросов Go и Rust идеологически дружат), но трейты (своего рода интерфейсы, но с куда более широкими возможностями) могут содержать дефолтные имплементации методов, дженерик-имплентации в том числе. Уже это снижает долю копипасты в разы.
> Можно конкретнее (и сравнение с каким-нибудь другим языком)?
Да я на самом деле с теми же C/C+ и Rust сравниваю, которые условно говлря не имеют рантайма вовсе. Так-то у Go он не такой и толстый, но просто при сравнении с Rust, который также позволяет писать безопасный по памяти код, видишь, что можно платить меньше за те же или даже большие гарантии.
> Что это значит? Очень даже конкретная и выразительная система типов. Можно конкретнее?
Недостаток дженериков, вещей вроде трейтов, прозрачных и доступных для пользовательской имплементации итераторов, алгебраических типов и т.д. - все это сильно снижает выразительность языка. В Go, в силу простоты системы типов, значительная часть фундаментальных абстракций реализлвана в виде компилятлрной магии. В Rust огромная часть семантики языка описана кодом в стандартной библиотеке, в том числе итераторы.
> В смысле вы бы предпочли throw-try-catch или к чему это
Конечно нет! Исключения - еще одна гадость, насчет которой Rust и Go дружат во мнении. Я про сочетание оператора ? и выражение match.
> интерфейсы не позволяют делиться реализациейЭто нужно реально редко. Например, часто бывает достаточно просто продумать другие интерфейсы, чтобы дублируемая реализация тупо была отдельным package-ем (который можно будет цеплять и вообще в других пакетах потом), вместо попытки её дублировать в реализации каких-то других интерфейсов.
Есть проблема с generic-ами, когда, например, пытаешься без reflect-а (ибо он медленный) сделать какую-нибудь сериализацию/десериализацию. Там ты как не дизайн и не перепродумывай интерфейсы, всё равно куча одинакового кода. Сейчас в Go обходятся кодогенерацией (что по сути даёт временный вариант generic-ов).
> трейты (своего рода интерфейсы, но с куда более широкими возможностями) могут содержать дефолтные имплементации методов,
Да, слышал хвальбы трейтов от весьма грамотных людей. Но сам использовал Rust мало, и пока не прочувствовал.
> Так-то у Go он не такой и толстый, но просто при сравнении с Rust, который также позволяет писать безопасный по памяти код, видишь, что можно платить меньше за те же или даже большие гарантии.
Говоря "толстый", что имеется в виду? Что бинарий много весит? Если да, то тут буквально недавно экспериментировал с rust и go на примере hello world, и как-то разницы не почувствовал.
По поводу "платить меньше". К сожалению, Rust отнимает больше времени программиста. И это по множеству причин:
* Сырой и нестабильный. Зачастую инструкцию по установке какого-то rust-приложения начинается с "установите unstable такой-то версии". Какие-то пакеты хотят одну версию, какие-то другую. Вроде бы хочешь сделать какую-нибудь тривиальную вещь, а тратишь весь день.
* Rust просто требует больше мозговых ресурсов (требует более сложные и глубокие мысли). В Go же мысль больше фокусируется на том, что ты хочешь сделать, а не на том, как это сделать.
* Под Rust меньше всего уже написано, чем под Go. Просто популярность у Rust ниже.
* Субъективно (лично для меня:), Go очень открытый, прозрачный и понятный. Там очень легко разобраться в любой детале (даже если она совсем internals).Я бы сам использовал Rust в качестве основого языка, если бы не ощутил насколько больше времени сжирает (в сравнении с Go) сделать одно и то же.
> Недостаток дженериков, вещей вроде трейтов, прозрачных и доступных для пользовательской имплементации итераторов, алгебраических типов и т.д. - все это сильно снижает выразительность языка.
По поводу итераторов немного не понял, чего вы хотите. По остальному согласен. Но это мелочные проблемы (и которые, вроде как, обещаются быть исправленными в будущем).
> значительная часть фундаментальных абстракций реализлвана в виде компилятлрной магии
А можно пример? Я просто тупой, и не понял :)
> Я про сочетание оператора ? и выражение match.
Это ж просто синтаксический сахар, если я не ошибаюсь. То есть это не делает программу другой, а лишь сокращает количество строк (свёртывает код в более компактную форму). Если, например, вы работаете в GoLand, то какой-нибудь трёстрочник из "if err != nil { return fmt.Errorf("sdfsdf: %w", err) }" тоже свернётся в серенький неприметненький однострочник.
В Расте очень ограниченные типы, это только после C кажется, что "вау".Рекомендую посмотреть на язык Idris, чтобы понять, что такое по-настоящему полноценная система типов.
Я знаю про Idris и у меня в планах в нем покопаться. Очевидно, что Rust уступает в типизации любому мощному функциональному языку. Но прелесть в том, как функциональные концепции прекрасно заиграли в императивном системном языке.К тому же Rust находится не только в позиции потребителя идей, на самом деле сам Idris испытал на себе влияние Rust: http://docs.idris-lang.org/en/latest/reference/uniqueness-ty...
Плюс, для Rust готовится некоторое подобие зависимых типов в виде конст дженериков.
>1) чем для вас плох Go?Го - это комбинация из NIH, агрессивного луддизма, копипасты (дженерики слишком сложны для гопников) и необразованных фанатов. Основная "фича" языка - заставить кодера придумывать очередной, не особо совместимый с другими, вариант реализации ООП на Го.
>2) какой ЯП больше всего нравится?
Разумеется плюсы - самый лучший язык в мире
плюсы гов№о, чистый С форева!
> плюсы гов№о, чистый С форева!И ты прав, но про на плюсах очень мощные и экспрессивные конструкции заворачивают. На сях так ну не то чтобы нельзя, но получится что-то странное и не факт что лучше :)
1) В первую очередь тем, что принудительно заставляют использовать синтаксис вида
хрень {
}
А я люблю
хрень
{
}
Также не люблю сборщики мусора. В остальном Go нравится.2) Помесь из Си и Си++. Раст тоже неплох, а ряд вещей в нем сделано очень хорошо, но напрягает сырость языка и не очевидные непредвиденные баги. Вот например только вчера столкнулся с тем, что программа на Rust может выпасть в осадок, если ее stdout перенаправлен по конвейеру на другую команду и произошло досрочное завершение процесса (обработка сигнала SIGPIPE). Вот пример:
$ squid_access_log_top 5 |head -3
#------------------------------------------------
# ТОП 5 для файлов:
# /var/log/squid/access.log
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:700:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
> Rust может выпасть в осадокЭто скорее всего не Rust выпал в осадок, а сама программа (на Rust) применила unwrap, что явно говорит паниковать в данном случае. Rust сказал автору принять решение как себя вести в такой ситуации, а автор принял решение: "паниковать!!". Так что не очень понятно что тут Rust сделал не так :)
> сама программа (на Rust) применила unwrap
> Rust сказал автору принять решение как себя вести в такой ситуацииНе, скорее всего он не говорил, и автор программы не принимал сознательного решения. Вывод в stdout прозводится чаще всего при помощи макроса println!, который делает unwrap молча и ни о чём не спрашивая. В документации к println! написано, что он выкинет панику, ежели с stdout что случится, но кто ж читает документацию?
Автор программы такую хрень в документации не заметил (а возможно ее там не было, когда он ее читал). Факт в том, что такое поведение программы совершенно нетипичное для программ, написанных на других языках, поэтому додуматься до того, что будет такая засада, автору было бы очень нелегко.
> Автор программы такую хрень в документации не заметил (а возможно ее там
> не было, когда он ее читал). Факт в том, что такое
> поведение программы совершенно нетипичное для программ, написанных на других языках, поэтому
> додуматься до того, что будет такая засада, автору было бы очень
> нелегко.Да, ситуация ещё осложняется тем, что println! показан в любом туториале по rust'у, но в этих туториалах, понятно, уделяется куча внимания тому, как можно быстро вывести структуру на печать, но такие особенности println!, как способность прибить процесс -- нет. Но люди заканчивают с туториалом, в иллюзиях о том, что они его освоили.
Эти люди и про го также думаю ща за 2 дня выучу. А потом гавнокодят и плються на яп что он кривой и косой.
> Факт в том, что такое поведение программы совершенно нетипичное для программ, написанных на других языках, поэтомуУгу - просто будет делаться какая-то рандомная *рень
python -c "print(open('foo','r').read())"|h
zsh: command not found: h
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipepython2.7 -c "print(open('foo','r').read())"|h
zsh: command not found: h
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
или иногда сегфолтится:
https://forum.mongoose-os.com/discussion/114/segfault-with-b...
но зато никаких паник …
Что мне в Golang нравится это двойной возврат и отложенный запуск.
Что мне не нравится это постоянные {} и отсутствие полной поддержки структур данных.
Go очень специализирован, шаг в сторону и его возможностей не хватает.Любимого языка нет. Надо язык выбирать под задачу, а не задачу подгонять под язык.
С слишком нискоуровневый, С++ многословный, Python - интепритируемый, Golang - ограниченный, asm не портируемый, java завязан на ООП и java машину.
Есть универсальный вариант. Python+c/c+++asm. Придётся разбавлять ассемблером, конечно, но иначе не бывает. Не очень часто. А ты думал, в сказку попал?
> Есть универсальный вариант. Python+c/c+++asm. Придётся разбавлять ассемблером, конечно,
> но иначе не бывает. Не очень часто.Используя гибриды мы меняем одни недостатки на другие. Получаем дополнительные проблемы на стыке языков. Плюсы + asm, теряем портабельность, и получаем острые проблемы на стыки(Тем острее, чем абстрактние код). Теряем в инструментах, усложняется система сборки.
Python+c отдельная тема. Тут все от решения и пропорций зависит.
Универсальностью тут даже не пахнет.
> А ты думал, в сказку попал?
Да. Доки, интернет, форумы, компиляторы на выбор, GNU и еще куча всего. Это действительно сказка.
У меня программный комплекс написан на Qt, go, Python и Bash. Хотя последнего почти не осталось и надо бы избавится совсем. При этом каждый язык на своем месте и его выбор был обоснован.А раньше выбор был: либо Basic который тормозит, либо asm на котором писать замучаешься. Слава богу, что этот период в моей жизни быстро прошел.
Верцуны в серебряные пули вообще забавные ребята. Как максимум получается какой-нибудь питон, который вроде бы и может почти все. Но счастья не наступает - потому что он все может одинаково гуняво, так что почти любой кейс можно зело улучшить, переписав на чем-нибудь другом. Чем в последнее время все и занимаются :)
>1) чем для вас плох Go?Как некий си-подобный питон для rest-серверов и тулзов он неплох. В первую очередь тем что он компилируемый, в отличии от питона. Во вторую очередь тем что он прост для "начинающих гуглеров" и сишников (pure c). Он не призван хватать звёзды с неба, так как создавался для иных целей.
P.S: единственный минус только в том, что он создавался под сильным влиянием Роба Пайка с его тараканами в голове.
Я бы не сказал, что он прост
На мой взгляд, это миф
Си как бы полная аналогия - простой по синтаксису, но совсем не простой для понимания
Под простотой я подразумевал именно малое количество абстракций и их простота в целом (по крайней мере в видимой части).
> но совсем не простой для пониманияЧтобы понять си, надо понять как работают компьютеры. И тогда все просто, логично и даже прострелить себя пятку надо еще основательно постараться. А если прогать как типичный питонист - "не хочу учиться, хочу жениться!" - да так в принципе на любом ЯП программа будет УГ. Си, по счастью, отфильтровывает таких экспонатов будучи неудобным и чреватым для такого подхода.
про недостатки написали, особенно в 1 ответе. а нравится D-lang.
> чем для вас плох Go?Дык а чем он может заинтересовать? Что макакам от кодинга в нем легко разобраться? А таких становиться все больше, в том числе и среди комментаторов здесь..
2) Лисп
У ГО есть как минимум один +, нет классов.
>У ГО есть как минимум один +, нет классовУра! У<это "пробел" Унылого Говна тут нет>Го нет ООП!
Открою тебе глаза на истину: "Все лучшие программы в мире написаны без ООП - Linux, Apache, Windows, Office и т.д."
Все худшие программы, а это enterprise-приложения и т.д., созданы с использованием ООП безмозглыми апологетами секты ООП головного мозга. Зато "быстро, модно, молодежно", что привело к увеличению вычислительных мощностей и глобальному потеплению.
Ты видел код MS Office?
Тыкалка пальцем в розетку, я видел код Office и тот Office работал шустро, И код Oracle тоже видел, он тоже на C.
Это в Linux и Apache то нет ООП? Смешно
> Это в Linux и Apache то нет ООП? СмешноНу покажи ООП в ядре линукса? Желательно сразу Торвальдсу, интересно почитать каменты :)
Это смотря что понимать под ООП.
Если понимать ООП так, как описал Алан Кей, то, во-первых, в Linux и Apache оно есть, а во-вторых, это не имеет никакого отношения к тому "ООП головного мозга", критика которого абсолютно справедлива.
И, кстати, настоящее ООП - это то же самое, что Unix Way.
ну не все. UT написан с ООП, VS 6.0 написана на MFC. И всё это работало и работает весьма хорошо.
В go есть ООП. Нет наследования, но оно и не является необходимостью.
Наследование в го есть. Оно не нужно, но есть. Абстрактные типы могут наследоваться.
lol no generics
Расскажите лучше про новую систему модулей
Которая вместо GOPATH
Настолько новую, что появилась в позапрошлом релизе, а в прошлом включена по умолчанию?
Собаки лают, а караван идёт. Почти все крупнейшие мастерские софта, как в РФ так и у буржуев, пилят масштабные проекты на Go. Именно на Go, не на Java, C++ и прочих. Чуваки инсайдеры (если они тут водятся) подтвердят. В таких проектах 99.9999% сложности-это бизнес логика, данные, сеть и вообще куча всего, что не имеет отношения к используемому ЯП. Go хорош тем, что ко всей это куче головных болей не добавляются "прелести" таких геморройных ЯП, как C++, например. Go-ЯП для инженеров софта.
Крупнейшие мастерские софта, инсайдеры. Такого тупого наброса я давно не видел. Как там мистер бонд поживает? Он все ещё прлграммирует на Ada или обновил себе компьютер
Ну я инсайдер из РФ-овской мастерской софта, с названием, оканчивающемся на ру. Пилим бигдата платформу на golang-е. Что дальше кукарекнешь, школьник?
Работаю в гаражном стартапе в области энергетики. Не то, что гошечку пользую -- WebAssembly на стороне клиента активно практикую. Доволен вполне.
А клиент - доволен?
> А клиент - доволен?Как слон. Картинка плавная, подгрузка даже на мобилке мгновенная, отзывчивость интерфейса, исходный код недоступен -- безопасность пассивно повышена.
На Го ничего масштабного не напишешь.
> На Го ничего масштабного не напишешь.Кубернетис, докер, миниДНС, Дропбокс и Гугель смотрят на тебя с удивлением.
Дурашка, как ты сейчас свою "бизнес-логику" будешь без обобщений (шаблонов) лепить? В Го из абстракций коллекций только массивы и есть. Причём, массивы корявые. Го это такой "наш ответ Свифту".
Go - недоязык, игнорирующий 50 лет опыта ЯП и распиаренный гуглом. Нужно смотреть в сторону нормальых языков.Например: https://crystal-lang.org/
Go - недоязык, игнорирующий 50 лет опыта ЯП и распиаренный гуглом. Нужно смотреть в сторону нормальых языков.
Например: https://docs.microsoft.com/ru-ru/dotnet/csharp/
Фу, бяка на виртуальной машине, да ещё и проприетарная, да ещё и виндоус-онли (Mono не предлагать).
> Фу, бяка на виртуальной машине, да ещё и проприетарная, да ещё и виндоус-онли (Mono не предлагать).Я профессионал в Руби, в т.ч. в его внутренностях, которые понимают человек 10 отсилы. Я теперь программирую чтобы обеспечить себя семизначными суммами в долларах, и я програмирую на Джаваскрипт. Делаю это и плююсь.
Поймите меня правильно.
Я тебя разочарую, у состав ruby core team нет русскоговорящих
Так он как-то не очень "русскоговорит".
В Руби кор тим нет не только русскоговорящих, но и вообще во внутренностях языка понимает только Койчи Сасада.
Да и на кой ляд в них кому-то что-то понимать.
А я английскую королеву чих-пых.
> Фу, бяка на виртуальной машине, да ещё и проприетарная, да ещё и виндоус-онли (Mono не предлагать).и как там в 2013? сколько у вас доллар стоит?
Я не поклонник C# и .Net Framework, но укажу для объективности, что уже давно существует .Net.Core (уже версия 3.1), работающий как Windows так и под Linux. Также пилят PowerShell.Core, который основан на .Net.Core и будет работать и там и там. И даже Ms Sql Server 2017, 2019 работают под Linux (но еще не весь функционал по сравнению с вариантом под Windows).
Первая доза бесплатно. Знаем, плавали, спасибо, не надо. Уж лучше гошечка.
Там есть проблемы с лицензированием до сих пор. МС Сиквел и даром не нужен, а вот Кор понравился.
От Майкрософта нам ничего не нужно.
> Go - недоязык, игнорирующий 50 лет опыта ЯП и распиаренный гуглом.Гугл нанял стадо питонмакак, теперь вот не знают куда их девать таких красивых. В последнее время на вот это переучивают, так они по крайней мере сервисы компании окучивают за копье, и все же не так непотребно как на питоне - в го основные факапы и юзкейсы гугеля все же учтены.
> Go - недоязык, игнорирующий 50 лет опыта ЯП и распиаренный гуглом. Нужно
> смотреть в сторону нормальых языков.То-то гугель такой бедный и тупой. Они же ничего не умеют и не знают. А кубернетис твой аналог просто убил. Будем знать.
А исключения так и не добавили, гады
Исключения это харам. Они... сложные.
> Исключения это харам. Они... сложные.Создатели Rust тоже так говорили, но под давлением реальности - ввели в язык постфиксный оператор ?, что по использованию практически аналогично throws.
> А исключения так и не добавили, гадыИсключения не имеют право на существование. Правильно сделали.
Наброшу-ка! Мнение чела который ел устриц.
https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild.../
Да уж... Педантизм и отвага. И столько энергии слить в критику? Не знаю кому-как, а на меня статья подействовала наоборот -- Go выглядит как адекватный и простой инструмент, а придирки автора -- удивляют. Типа он показывает хорошие вещи, как что-то плохое.Да и Plan9, Bell Labs -- упоминаются так, как буд-то это что-то плохое. ) Куда катится мир?
Пора применить go в своем проекте. ;)
Мотивы похожи на те, которые заявлялись перед выкатом Явы. Этакое простое СРР для всех. Без усложнений и без возможности выстрелить себе в ногу. Что же имеем сейчас? Компостную кучу с приведениями: тут тебе и обобщения без обобщений, и ламбы без ламбд, и пакеты без пакетов, и потоки без потоков. Го тем же путём двинул.
Чувак, ну какие хорошие вещи? Если заявленный универсальным интерфейс для работы с файлами... универсальным не является, то какой уж тут "адекватный и простой инструмент"?
Сначал думал было написать развернуто, а потом понял, что если человек не понимает, к чему приводит универсальность возведенная в абсолют, и что значит слово "адекватный", то и я не объясню. Вернее, мои доводы не будут услышаны.Так что, похоже, разным людям -- разное чувство прекрасного и разные инструменты. Я всего лишь написал о своем восприятии (якобы, критикующей Go) статьи. Мне там все понравилось. Вероятно -- мой язык. Буду изучать глубже (пока только пару утилит на нём).
Речь не про абсолют, а про то, что целый ряд библиотек завязаны на конкретные реализации и в условиях других реализаций просто молча не работают. Поэтому назвать такой инструмент универсальным -- сложно. Го не универсальный инструмент, а язык для Гугла, т.е. язык, применяемый прежде всего в Linux-среде. Меня это не смущает, но и универальным такое не назовёшь.
Я честно, даже не знаю что тебе сказать. Я не знаю, кто такой автор этого блога, но кроме максимализма и пафоса я там не вижу ничего.Ну, например, где он задвигает о том, что пути к файлам в go - это строки. И это -- плохо! Потом пример кода приводит. Даже я, человек написавший на Go всего-ничего, понимаю, что там написан бред. Вернее, я не понял вообще что он там хотел доказать.
Выводит e.Name() говорит, что смотрите - проклятый Go искажает пути (silently)! Ну преобразуй в byte и выводи свой массив! Будет типа оригинальные данные. (Я не поленился и проверил этот пример). И я даже молчу про саму ситуацию, высосанную из пальца. Но при этом - пафоса то! "Lie!"(с) Ну или как там, в начале статьи. Ну и весь текст такой.
Короче, пусть эксперт занимается чем хочет, а для меня это лишний повод поизучать go. Классный язык, особенно для тех, кто вырос на C.
> работают. Поэтому назвать такой инструмент универсальным -- сложно. Го не универсальный
> инструмент, а язык для Гугла, т.е. язык, применяемый прежде всего в
> Linux-среде. Меня это не смущает, но и универальным такое не назовёшь.Вопрос в том, когда остановиться. На мой взгляд, "эмуляция" posix при работе с ФС не худший вариант унификации.
Собственно, GoВНО-язык и создавался для таких говнарей, как ты - с интеллектом устрицы и отчаянным желанием что-то напрограммастить. У нормального разработчика языки подобные Го вызывают отторжение.
Какой-то очередной Котлин, когда занозы в заднице из осины объявляются лучшими, чем занозы из ели.
Откровенно, на месте Гугли я б вообще не позорился называть ЭТО языком, да ещё и показывать общественности!Слово "простой" в данном случае вовсе не положительное свойство. Как лом "прост" в своей структуре, настолько же он неудобен при рубке ветвей.
А вот более подробное объяснение, почему "язык для мартышек только мартышка и захочет использовать": https://habr.com/ru/post/344356/