После шести месяцев разработки компания Google представила (https://blog.golang.org/go1.9) релиз языка программирования Go 1.9 (http://golang.org), который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си.Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора.
Основные новшества (http://golang.org/doc/go1.9), представленные в выпуске Go 1.9:- В язык добавлена возможность определения псевдонимов типов (https://golang.org/design/18130-type-alias), которая может оказаться востребована при проведении рефакторинга кода (https://talks.golang.org/2016/refactor.article) и постепенного перевода проектов на новые API. Например, при помощи конструкции "type T1 = T2" для существующего типа "T2" можно определить псевдоним с именем "T1" по аналогии с тем как имя "byte" является псевдонимом типа "uint8";
- В состав включен новый пакет math/bits (https://golang.org/pkg/math/bits), предоставляющий функции для битовых операций и манипуляции беззнаковыми целыми числами с задействованием при возможности специальных инструкций CPU. Например, на системах x86-64 функция bits.TrailingZeros(x) будет выполняться с использованием инструкции BSF;- В пакет sync добавлен новый тип Map (https://golang.org/pkg/sync#Map), который возможно применять в многопоточных приложениях. Данный тип в некоторых деталях отличается от штатного типа map, поэтому не предназначен для его прозрачной замены;- В пакет testing добавлен новый метод Helper, применимый с объектами testing.T и testing.B. При помощи данного метода можно организовать вывод номера строки вызывающей функции при возникновении ошибки, вместо указания ссылки на фактический номер строки, из которой вызван метод t.Fatal;
- В пакете time обеспеченно прозрачное отслеживание монотонного времени (время, прошедшее с определённого момента) для всех значений Time, что позволяет обеспечить надёжный расчёт разницы между двумя значениями Time без влияния таких факторов как изменение времени или подстановка (https://www.opennet.ru/opennews/art.shtml?num=42528) лишней секунды.
- Для ускорения процесса сборки реализована поддержка параллельной компиляции разных функций в пакете.URL: https://blog.golang.org/go1.9
Новость: https://www.opennet.ru/opennews/art.shtml?num=47083
geth (go ethereum) синхронизируется неделями, беспощадно насилуя систему. Вот она, производительность Go.
Так в наше время под "высокой производительностью компилируемых языков" подразумевают скорость на уровне джавы, что печально
В подавляющем большинстве случаев проблема в алгоритме и структурах данных, а не в языке программирования. Нормальный программист на пхп напишет эффективнее, чем хипстер на си.
Сервер на Go против сервера на Java говорит сам за себя 13ms против 52ms на прогретом окружении. Понятно что конечно ситуация синтетическая, но таки непонятно почему в пять раз медленее статический "Hello, world" отдает.
Что тут непонятного? Нативный код против эмулятора.
> Что тут непонятного? Нативный код против эмулятора.Go у нас теперь эмулируется? Или у жабы отменили JIT?
OK, нативный код против эмулятора с JIT.
> непонятно почему в пять раз медленее статический "Hello, world" отдаетC фороникса сбежал? Сделай нормальный бенчмарк, с кучей хотя бы с 10ГБ (а лучше 50-100) и хоть каким-то движением в ней. Сразу увидишь убогость go-йского non-compacting GC.
Подавляющее большинство алгоритмов - линейная последовательность с парой ветсвлений. Там ошибиться негде.
Откуда же тогда берутся бажные программы? Рептилоиды баги в них запихивают?
В подавлющем большинстве софта алгоритмов раз два и обчелся. В основном БД, бизнес логика и интерфейс. И все это ляпают кто как умеет.
Если программу писал криворукий кодер, значит язык виноват? Странная точка зрения.
Не правда. Над geth работает большая команда профессиональных разработчиков. На данный момент это самый популярные ethereum клиент. А иссурки висят, их много: https://github.com/ethereum/go-ethereum/issues?page=1&q=is&#...
Пофиксить синхронизацию никак не получается уже очень долго. Они уже добавили режим fast, добавили кэши, которые все выкручивают до запредельных значений, и все равно ситуацию это не спасает.
> Не правда. Над geth работает большая команда профессиональных разработчиков. На данный
> момент это самый популярные ethereum клиент. А иссурки висят, их много:
> https://github.com/ethereum/go-ethereum/issues?page=1&q=is&#...
> Пофиксить синхронизацию никак не получается уже очень долго. Они уже добавили режим
> fast, добавили кэши, которые все выкручивают до запредельных значений, и все
> равно ситуацию это не спасает.И что? Если проблема принципиально решается, и её не смогли решить - значит проблема в решальщиках.
Go в сравнении с сишечкой может отставать по производительности в 2-3 раза.
Если есть программа на C с вменяемой скоростью, и программа на Go остаёт от неё более чем в 5 раз, значит виноваты разрабы.Нет такой программы на С? Тогда почему вы решили, что виновата Go ? Может изначально в etherium заложены такие не эффективные алгоритмы, что они на лшюбом языке будут тормозить?
> в 2-3 раза.
> в 5 разЭто уже уровень производительности скриптовых языков.
Одну нет, но совокупность программ вполне могут говорить о качествах языка. В данном конкретном случае версия 1.7.0 на подходе. Если разработчикам за столько времени и выпущенных версий не удалось решить проблему производительности, значит её корни лежат за пределами доступа разработчиков, в языке и/или применяемых библиотеках.
Или в алгоритмах, которые эти разработчики пытаются реализовать или используют.
А язык причём? На чём клиент btc написан? На сях небось. С нуля блокчейн качался больше неделиДело в хайпе, а не тормозах яп
Bitcoin core написан на с++, у него нет никаких проблем с синхронизацией.
Проблем никаких, но 122гб блокчейна качается 8 дней
Рад за вас, ethereum у меня синхронизируется без конца, вот уже 2 недели. При том всё медленнее и медленнее.
Ну и выкинь его.Взял какую-то какашку, а теперь жалуешься, что она воняет. Какашки всегда воняют, и о качестве того, чем они были до попадания в пищеварительную систему, это не говорит.
140Gb месяц качал на 200 Мбит
Так надо же:
1. Базу блок-чейна хранить на ssd.
2. С опцией клиента -prune 2048
Они оптимизировали синхронизацию, теперь она занимает где-то 2 часа, зависит от системы.
В смысле 122 гига на моих 10 мегабитах будет выкачивать за 2-3 часа? огооо архиватор попова какой-то? или как это она так сжимает блокчейн, выкачивает, а потом у меня на компе распаковывает?
10 мегабит - таких тарифов уже давно нет. У скайнета минимум 50 мегабит ненужных за 350 рублей. Если бы был у кого-то такиф 10 мегбит, я бы первый с радостью перешел на него.
> 10 мегабит - таких тарифов уже давно нет. У скайнета минимум 50За МКАДом жизни нет!
Я за МКАДом, если чё. И тарифов 10 мегабит не существует лет 5, как DSL вымер.
> Я за МКАДом, если чё. И тарифов 10 мегабит не существует лет 5,А причем тут тариф? Если максимально доступная скорость не превышает 10 мбит, то платить за большее глупо.
> как DSL вымер.
Угу, угу. Кое-где даже не родившись.
Я вообще на PPPoE сижу отнюдь не по собственному желанию, а также приходится 150 руб/мес только за реальник платить, что для меня дикость, но выбора у меня нет.
При этом долгое время пакет rp-pppoe в openSUSE и SLES был тупо сломан и не работал нормально, пока я это не обнаружил и не взялся за его сопровождение.
А вы тут об отсутствии 10-ти Mb говорите и про то что вы за МКАДом.
Вопрос должен стоять в другим образам, а есть ли у Вашего провайдера тариф в 100 Mb и если есть, то почему Вы, наверняка имея не хилую ферму из видеокарт, не можете себе его позволить?
Но в место этого адекватного вопроса Вы несёте неадекватную чушь зажравшегося МКАДовца.
DSL еще жив. Причем не так далеко от мкада.
И это нетрудно - ведь когда кроме РТ нет провайдеров - зачем торопиться с оптикой?
Провайдерам не выгодны такие низкоскоростные тарифы, т.к. трафик сейчас относительно дешевый, а 10 мегабит вполне достаточно для FullHD. Все бы подключались к таким тарифам. Поэтому сейчас только задранные по скорости тарифы по соответствующей плате.
> Провайдерам не выгодны такие низкоскоростные тарифы, т.к. трафик сейчас относительно дешевый,Мля, откуда вы такие лезете, а?
Вы что, совсем не допускаете даже мысли о том, что кроме мегаполисов, абсолютно совсем внезапно, есть еще пригороды и всякая мелочь и тут уже как повезет и хре*овая инфраструктура тупо может не пропускать 50мбит?
Мля, откуда вы такие лезете, а?
Вы что, совсем не допускаете даже мысли о том, что кроме России, абсолютно совсем внезапно, есть ещё другие страны и тут уже как повезёт, на отшибе мира где-нибудь (Кипр, NZ) может быть и 1мб/с по ценам, которые вам и не снились (~70$/мес) огромным счастьем?
Развелось тут квасных диванных рассуждаторов. Лол.
И чё прикопались к скорости инета? МКАД, ЗАМКАД.В случае с btc тупо канал не утилизируется. Или сеть перегружена или не масштабируется нормально. Торрентами 50 мегабит ест, bitcoin-qt телепается на 2-5 и хоть тресни. Реальный IP есть. Высовывать порт в инет? Щаз!
> телепается на 2-5 и хоть тресни. Реальный IP есть. Высовывать порт в инет? Щаз!Лол, толку от твоего реального айпи если ты порт не высунул? ССЗБ.
> Мля, откуда вы такие лезете, а?
> Вы что, совсем не допускаете даже мысли о том, что кроме России,
> абсолютно совсем внезапно, есть ещё другие страныОчередной клоун.
Попробуйте открыть входящие порты, заметил что разные блокчейны с закрытыми портами ведут себя не очень адекватно.
Блокчейн сама по себе не эффективная с точки зрения производительности технология.К слову, как правило там внутри leveldb что не есть самая быстрая БД, но зато наиболее экономная по месту и в целом самая сбалансированная, если судить по этим тестам:
https://www.influxdata.com/benchmarking-leveldb-vs-rocksdb-v.../
> geth (go ethereum) синхронизируется неделями,А docker написан на go - и это один из самых фапабельных ПО, что я знаю.
Наверно дело не в бобине.
Мужду нами девочками - он только и ноден чтобы недо-лошади на него ... мнээээ ... фапали :-))) В продакшене (за редкими исклбчениями) - докер это боль! :-\ Впрочем _НЕ_ из за Go :) А из-за аффтарафф ...
> А docker написан на go - и это один из самых фапабельных ПО, что я знаю.Для пони и кобыла - невеста.
> и обеспечивает возможность использования сборщика мусора.А можно и не использовать сборщик мусора?
>> и обеспечивает возможность использования сборщика мусора.
> А можно и не использовать сборщик мусора?Есть много техник, позволяющих уменьшить кол-во создаваемого мусора.
В принципе, ни кто не мешает на чистом Go написать malloc-free. Просто со встроенными типами будет не легко работать.
Можно. Rust его и не использует
Никто не запрещает делать типы с выделением памяти под них через malloc.
Если программа уровня хелловёлд, то гц не отработает даже. Если прога большая то гц это не минус, а плюс.
знаю 2 случая косяков, связанных со сборкой.
1 на джаве: в библиотеке jetty СМ просто не справлялся на больших нагрузках и со временем уводил программу в OOM.2 на C#: сборщик освобождал то, что не должен был. Прогеры долго танцевали с бубном, пытаясь как-то это обойти. Обратились в техподдержку, и те сказали "да, мы знаем, что такой баг есть. КОГДА-НИБУДЬ починим"
А при чём тут Go?
> 1 на джаве: в библиотеке jetty СМ просто не справлялся на больших нагрузках и со временем уводил программу в OOM.У жабовых GC максимальная скорость мусора сборки гигабайты в секунду. Если чё-то там где-то не успевало, вывод - прога генерила десятки гигабайт мусора в сек. Шо как бэ намекает на то, из чего сделан прогер 8)))
> У жабовых GC максимальная скорость мусора сборки гигабайты в секунду.И он работает не переставая, или всё-таки даёт выполниться какому-то другому коду?
>> У жабовых GC максимальная скорость мусора сборки гигабайты в секунду.
> И он работает не переставая, или всё-таки даёт выполниться какому-то другому коду?Не знаю как в GO, а вот жаба получается быстрее си в плане управления памятью. 8)
Т.к. сишники в основном потоке делают new и delete, reallocate итд для дефрагментации памяти, а жабка этим занимается в отдельных потоках, большая часть фаз сборки выполняется ПАРАЛЛЕЛЬНО с основной прогой. В отличие от могучего си...
Вопрос был не об этом. Эта фантастическая скорость в "гигабайты в секунду" — это когда gc запущен, так? А как часто он запускается, и какова средняя скорость сборки? Только её есть смысл сравнивать со скоростью замусоривания.
> Вопрос был не об этом. Эта фантастическая скорость в "гигабайты в секунду"
> — это когда gc запущен, так? А как часто он запускается, и какова средняя скорость сборки?Если на самом деле интересно... С достаточно толстой задачи - распарсить 750ГБ XMLек и вытащить из них полезную инфу. GC срабатывает в среднем раз в 3 сек на 0.01-0.04 сек. Освобождает, как видишь 2ГБ за 0.02сек. Так что, получается что сборщик в среднем в секунду чистит 666МБ, тормозя прогу на 0.0066(6)сек.
[GC (Allocation Failure) [PSYoungGen: 2060768K->19907K(2088960K)] 7512698K->5471837K(7875584K), 0.0192799 secs] [Times: user=0.18 sys=0.01, real=0.02 secs]
> Т.к. сишники в основном потоке делают new и delete, reallocate итд для дефрагментации памяти
> сишники ... new и delete, reallocate ... дефрагментации памятиЯ правильно понимаю, что и все остальные рассуждения и "аргументы" такого же "качества"?
>> Т.к. сишники в основном потоке делают new и delete, reallocate итд для дефрагментации памяти сишники ... new и delete, reallocate ... дефрагментации памяти
> Я правильно понимаю, что и все остальные рассуждения и "аргументы" такого же "качества"?У тебя этим занимается специальный класс в отдельном потоке? Наверное называется он MyNotGarbageCollector ? :)))))
В сишечке нет классов, new и delete.
>В сишечке нет классов, new и delete.Наиболее могучие сишники не умеют плюсики. Очень смешно...
Наиболее лютые жабисты не видят разницы между C и C++. Очень грустно…
> У тебя этим занимается специальный класс в отдельном потоке? Наверное называется он
> MyNotGarbageCollector ? :)))))Во первых, нормальные быстрые проги вообще в основном рантаймовом цикле ничего не выделяют и не освобождают, всё выделяется заранее, и освобождается при завершении работы класса.
В вторых - потоки не резиновые.
В третьих - как всегда пишешь на основе собственных размышлений и теории. Я тоже так могу, смотри: прежде чем ГЦ что-то освободит, он должен понять, что пора собственно это освобождать. Пока он будет понимать, мусор будет валить.
Далее, гигабайты в секунду - это вообще некорректные измерения. При чём тут гигабайты? Нужно считать кол-во системных вызовов, может он эти гигабайты один раз выделил разом, и затем освободил за пару микросекунд. И на какой машине? Короче, не позорься.
> C#: сборщик освобождал то, что не должен был. Прогеры долго танцевали с бубном,Пять лет работаю с дотнетом, встречался с такими ситуациями только в руководствах. Но да, технически это возможно.
>> и обеспечивает возможность использования сборщика мусора.
> А можно и не использовать сборщик мусора?Можно. Разрешаю.
> А можно и не использовать сборщик мусора?Если крафтовое пиво обсохло на бороде
> при этом код легко читается и воспринимается.. если вы уже специалист по Go.
> Данный тип в некоторых деталях отличается от штатного типа map, поэтому не предназначен для его прозрачной замены
Вот она, расплата за отсутствие дженериков..
>> Данный тип в некоторых деталях отличается от штатного типа map, поэтому не предназначен для его прозрачной замены
> Вот она, расплата за отсутствие дженериков..Какая расплата и причем тут дженерики? Этот тип предназначен для постоянного набора ключей и сильно сливает стандартному по скорости добавления/удаления ключей. Странно было бы если бы не было никаких потерь из-за встроенных мютэксов.
Cектантов спросить забыли.
Действительно. Причин предостаточно и вспоминать D для этого не нужно.
Причин чего? Перестань разговаривать сам с собой.
Ух ты, оказывается, если переносить всё на свете на следующую строку и оставлять пробелы, код будет казаться объемнее!
Это разве показатель? Код на Go я понял, на D - нет, при том никогда не писал ни на том, на на другом. Почему D вдруг лучше?
А вот я как раз понял на D
Никто не мешает написать свою либу, чтобы было так же коротко, как на D.
> Никто не мешает написать свою либу, чтобы было так же коротко, как на D.Не знаю, что там с либами в первом примере, но во втором – тот же "reduce" заменяется банальным циклом на две-три строки по типу гошного.
И основной упор там, как я понял, как раз таки на демонстрацию экономии массы лишних телодвижений (с сохранением строгой типизации и соотв. возможности оптимизации компилятором) с помощью дженериков.
~~Абстрактный полиморф~~генерики уже завезли?
Зачем они? Научись использовать интерфейсы.
^ Gо-шники во всей красе. "генерики ни нужны, будем копипастить и костылить интерфейсами"
И ты учись. Когда научишься, копипастить не придётся.
> ^ Gо-шники во всей красе. "генерики ни нужны, будем копипастить и костылить
> интерфейсами"Кстати, накручивание плюсиков-минусиков к комментам настолько же бессмысленно, как и копипастинг кода.
Вопрос не в том нужны ли они. А в том, что если ты хочешь сколотить обычный табурет, то нет смысла использовать шурупы что бы в будущем его можно было разобрать. Задача сделать дешевый и простой табурет.
Да нет, тут дело в другом. В Go принципиально отсутствуют инструменты, позволяющие делать одно и то же. Есть шурупы, но только под крестовую отвёртку. В некоторых других языках дают полный ассортимент — и под плоскую отвёртку, и под шестигранник, и под всякие звёздочки, и с левой резьбой… В итоге приходится для разработчиков сочинять всякие политики, какими шурупами надлежит пользоваться, чтобы не приходилось с собой всегда полный набор инструментов таскать (см. например https://google.github.io/styleguide/cppguide.html). В случае Go язык сразу создаётся вместе с политикой, и ничего, политике не соответствующего, в нём просто нет.
А что лучше, C# или Go?
> А что лучше, C# или Go?1C (1-е сентября).
AngelScript
Visual Basic 6.0, конечно.
Слушайте, отвалит от Golang типа "не производительный". Вон мейлру (извините) переходит на него потому как рукоплещет горутинам и производительности.
Руки распрямите.
> мейлру (извините)Нет, этому нет прощения.
Вообще то нет. Вы явно не видите леса за деревьями.
Все эти языки приводят к распущенности. Программы на них тормозят не из-за того, что язык в какие-то 2-3 раза медленнее по своей структуре, а из-за того, что разработчика никак не волнует накладная стоимость применяемых структур и операций, которая в итоге вырастает многократно. Логика всех C#, Go, python,... программистов - язык сам всё оптимизирует. Но даже чисто физически это возможно далеко не всегда.
Просто это не программисты. Человек, освоивший какой-то (любой) язык программирования, ещё не становится программистом. Надо хотя бы минимальные представления об алгоритмах иметь.
> Все эти языки приводят к распущенности. Программы на них тормозят не из-за
> того, что язык в какие-то 2-3 раза медленнее по своей структуре,
> а из-за того, что разработчика никак не волнует накладная стоимость применяемых
> структур и операций,Может ещё не поздно тебя полечить... :)) Слушай сюда: коттедж лучше всего строить из кирпичей. Но это не значит, что можно построить небоскреб из кирпичей. А если небоскреб надо построить за 20 дней, то увы и ах, могучие каменщики, которые вручную мажут раствором и веревочкой меряют кривизну стены просто идут далеко-далеко.
> Слушай сюда: коттедж лучше всего строить из кирпичей.Коттедж лучше всего строить из готовых блоков.
А аналогии лучше даже не пытаться приводить, все одно будет сравнение мягкого с теплым.
> А если небоскреб надо построить за 20 дней..."Небоскрёбы" (т.е. серьёзные программы уровня ядра ОС или компилятора) за 20 дней не пишутся, друг мой. За 20 дней пишутся гoвнoприложения для смартфона на Джаве, и для этого Джава замечательно подходит. А ядра ОС и пр. делают именно "каменщики", которые вручную мажут раствором и веревочкой меряют кривизну стены, да-да.
>> А если небоскреб надо построить за 20 дней...
> "Небоскрёбы" (т.е. серьёзные программы уровня ядра ОС или компилятора) за 20 дней
> не пишутся,И эти люди кичатся сверхинтеллектом, переключаемость нулевая. Я написал про небоскрёбы и 20 дней. Китаёзы строят небоскребы за 20 дней. Что ещё непонятно?
Линукс на си пишут уже 26 лет потому что Торвальдс не осилил плюсы. Когда он помрёт и проектом начнет рулить другой, всё сильно поменяется. И верёвочки и каменщики могут внезапно пойти далеко далеко...
> Линукс на си пишут уже 26 лет потому что Торвальдс не осилил плюсы.Ога, а JVM почему на Си написана? Потому что жабисты даже жабу не осилили?
>> Линукс на си пишут уже 26 лет потому что Торвальдс не осилил плюсы.
> Ога, а JVM почему на Си написана? Потому что жабисты даже жабу
> не осилили?Для развития загугли list of java virtual machines
Потом на чём написан HotSpot
Потом на чём написан весь стек JavaEE и тонны жабобиблиотек.
> Для развития загугли list of java virtual machinesЗагуглил.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
Навскидку:
Avian на C++
CACAO на C++
HaikuVM на C/C++Больше не проверял, остальные, наверное, на джаве..
> Потом на чём написан HotSpot
http://www.stroustrup.com/applications.html
"The HotSpot Java Virtual Machine is written in C++ (this is the leading edge, high performance replacement for Sun's "classic JVM" which was written in C)."
А есть хотя бы один компилятор С++, написанный на Джаве? А ядро ОС промышленного уровня? Ну ладно, профессиональный видео-редактор? Может быть, CAD?
Нетути.
Игрушечную ОС, студенческую поделку, bloatware-монстра написать - можно, а что-то действительно сложное, производительное, долгоживущее - нет. Такие дела...:(
>> Линукс на си пишут уже 26 лет потому что Торвальдс не осилил плюсы.
> Ога, а JVM почему на Си написана? Потому что жабисты даже жабу не осилили?
> Загуглил.И где там си? сплошь плюсы.
>что-то действительно сложное, производительное, долгоживущее - нет
Школу закончишь, поумнеешь.
Слив, кагрццо, засчитан :)
Можете попробовать конкатенативную парадигму.
Теоретически, правильно, но дело в том, что приоритеты за последние несколько десятилетий изменились. Машины стали быстрее, вместимее, более user-oriented (следовательно основное время тратят на ожидание ввода от пользователя), следовательно быстродействие и прожорливость стали не так важны. С другой стороны, стали более важны быстрота разработки и лёгкость поддержки приложений. Ну, и плюс программирование стало массовой профессией. Так что, естественно, что эти языки становятся мейнстримом для прикладного программирования.
lol no generics
вот расскажите мне, пожалуйста, зачем вам обобщенное программирование в языке низкого уровня?
> языке низкого уровняВы темой ошиблись, тут про Go.
Язык Go разрабатывался как язык системного программирования для создания высокоэффективных программ, работающих на современных распределённых системах и многоядерных процессорах.
Он может рассматриваться как попытка создать замену языку Си.Неужели язык Си плох тем, что там не поддерживается generic programming?
Тоже самое, я думаю, относится и к языку Go.
> Язык Go разрабатывался как язык системного программирования
> Он может рассматриваться как попытка создать замену языку Си.Где ты такую глупость вычитал?
>> Язык Go разрабатывался как язык системного программирования
>> Он может рассматриваться как попытка создать замену языку Си.
> Где ты такую глупость вычитал?https://blog.golang.org/go-one-year-ago-today
> We set out to build a language for systems programming - the kinds of programs one might typically write in C or C++ - and
> we were surprised by Go’s utility as a general purpose language.https://github.com/golang/go/wiki/GoForCPPProgrammers
> Go is a systems programming language intended to be a general-purpose systems language, like C++.
> These are some notes on Go for experienced C++ programmers.https://golang.org/doc/faq
> Go was born out of frustration with existing languages and environments for systems programming.