The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Доступен язык программирования Go 1.6

18.02.2016 11:09

После шести месяцев разработки компания Google представила релиз языка программирования Go 1.6, который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD.

Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов), что позволяет добиться производительности, сопоставимой с программами на языке Си.

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

Основные новшества, представленные в выпуске Go 1.6:

  • В модуль net/http добавлена поддержка протокола HTTP/2, которая при использовании HTTPS включена по умолчанию как для клиентов, так и для серверов. Использование новой версии модуля позволит задействовать HTTP/2 в уже существующих проектах на языке Go, в том числе в http-сервере Caddy;
  • Расширены возможности, связанные с использованием шаблонов (модуль text/template). Добавлена поддержка чистки пробелов вокруг операций в шаблоне и реализована новая операция "{{block}}" для создания блочных шаблонов, собираемых из других шаблонов;
  • Включена по умолчанию поддержка директории vendor, предназначенной для поставки внешних зависимостей, привязанных к определённому поставщику;
  • Проведена оптимизация работы модулей compress/bzip2, compress/gzip, crypto/aes, crypto/elliptic и crypto/ecdsa, производительность которых возросла приблизительно на 10%. Изменён алгоритм сортировки, используемый в sort.Sort, что также позволило поднять производительность примерно на 10%. Cтарый алгоритм сортировки доступен через вызов sort.Stable для тех кому требуется полная идентичность порядка вывода;
  • Сокращено число пауз, вызванных работой сборщика мусора, что особенно заметно в программах, расходующих большие объемы памяти;
  • Добавлены экспериментальные порты для Linux на 64-рядных процессорах MIPS (linux/mips64 и linux/mips64le) и Android on 32-разрядных процессорах x86 (android/386);
  • Для сборки порта во FreeBSD в качестве внешнего компилятора по умолчанию задействован Clang вместо GCC;
  • В компилятор, систему динамического связывания и команду "go" добавлена новая опция "-msan", доступная только на архитектуре linux/amd64 и включающая режим совместимости с анализатором памяти Clang MemorySanitizer, который удобно использовать для тестирования приложений, содержащих вставки на C и C++;
  • В runtime добавлен легковесный механизм выявления неправомерного одновременного использования ассоциативных массивов (map). Если одна go-программа (goroutine) записывает в map, то другая go-программа не может прочитать или записать в map. В случае, когда данное условие нарушено и runtime выявил конфликт, программа будет экстренно завершена с выводом соответствующего сообщения об ошибке. Для выявления подобных проблем на этапе отладки предлагается использовать race-detector;
  • В runtime изменён метод вывода информации о крахе программы, которая теперь включает только дамп стека для вызвавшего проблему goroutine, а не для всех goroutine как раньше. Изменить данное поведение можно через переменную окружения GOTRACEBACK или вызвав функцию debug.SetTraceback;
  • В Cgo, механизм для организации вызова кода на C/C++ из программ на языке Go, внесены изменения в правила совместного доступа к указателям, которые в основном связаны с обеспечение сосуществования кода на языке Си со сборщиком мусора языка Go.


  1. Главная ссылка к новости (https://blog.golang.org/go1.6...)
Лицензия: CC-BY
Тип: Программы
Ключевые слова: golang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (76) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Crazy Alex (ok), 11:55, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не понял - что такого в том, чтобы в двух goroutine обращаться к одному map? Они ж кооперативные, никаких проблем с локами быть не должно?
     
     
  • 2.4, Sergey (??), 12:23, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    map-ы в Go не thread-safe. Читать можно конечно и без всяких lock-ов, но не писать. Удобно поэтому для конкурентного доступа к map использовать sync.RWMutex.
     
     
  • 3.26, Дима777 (?), 16:49, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да, удобно. Но зачем теперь сразу ошибку сегфолтить?
     
     
  • 4.51, skybon (ok), 23:37, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Явное лучше неявного.

    Словить панику на месте приятнее чем чесать репу разбирая странности потом.

     
     
  • 5.54, Кирилл (??), 01:58, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    С вашей логикой тогда надо крэшить для всех типов одновременный доступ, например, для int. Одновременная запись в string не вызывает паники, и как бэ "явное неявное" почему-то всех устраивает. Race - все же на совести программиста. Зачем паниковать, тоже не понимаю.

    Тем более есть прекрасный sync в стандартной либе.

     
     
  • 6.69, Никто (??), 15:16, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > С вашей логикой тогда надо крэшить для всех типов одновременный доступ, например,
    > для int.

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

     

  • 1.3, Аноним (-), 12:00, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Абзац про гоу-няшное костылестроение с горутином в мужском роде — это пять. Сегодня так ещё не смеялся.
     
  • 1.5, Аноним (-), 12:24, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Хороший язык!
     
     
  • 2.13, Аноним (-), 13:12, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Для написания фирмваре?
     
     
  • 3.78, Аноним (-), 21:55, 20/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    CS 1.6 - понимаю
    CS Go - понимаю
    Go 1.6 - не понимаю
    ¯\_(ツ)_/¯
     
  • 2.21, Настоящий Аноним (?), 14:53, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Отличный язык!
     
     
  • 3.22, Аноним (-), 15:42, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    От какого языка отличный?
     
     
  • 4.24, Аноним (-), 16:17, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    От других.
     
     
  • 5.32, Аноним (-), 19:08, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Злые языки бають, что от лимбо не отличный. Ату их!
     

  • 1.6, Никто (??), 12:28, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >с такими достоинствами скриптовых языков, как ... защищённость от ошибок.

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

     
     
  • 2.7, Никто (??), 12:29, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >Скриптовые языки НЕ предоставляют защищённости от ошибок

    Исправлено

     
  • 2.14, Kodesu (ok), 13:18, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > легко отлавливаемых

    У низкоуровневых языков есть свои траблы.
    Программы с миллиардами (!) пользователей, написанные на C страдают от таких проблем, как переполнение буфера и выход за границу массива. (Пруфы? Открой список CVE за последние пару лет)
    И что-то не сильно легко эти баги отлавливаются.

     
     
  • 3.17, Аноним (-), 13:31, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем, как переполнение sql-injection и сравнение нуля с пустой строкой. (Пруфы? Открой новости за последние пару лет)
     
     
  • 4.31, Аноним (-), 18:43, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ПХП же хуже мерзкого бейсика, к чему он тут?
     
     
  • 5.35, Никто (??), 19:51, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как бы о защищённости от ошибок динамически типизированных языков.
     
  • 5.60, Чепукто (?), 06:08, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Обоснуй!
    PS: я не про то, что PHP или, упасихоспади, Basic в чем-то хороши. Но вот так PHP равнять с Бейсиком! Не настолько же он плох!!!
     
  • 4.56, Лютый жабист (?), 05:10, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем, как переполнение sql-injection и сравнение нуля с пустой строкой


    Дык программы на си и этим страдают и перечисленным предыдущим оратором.
    То что на php или java можно сделать 'rm -rf /' не повод считать их плохими.

    А вот то, что на си даже крутой программер не может обеспечить 100% отсутствие переполнений - это повод назвать сишечку какашечкой.

     
     
  • 5.61, Чепукто (?), 06:25, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем,
    > как переполнение sql-injection и сравнение нуля с пустой строкой
    > Дык программы на си и этим страдают и перечисленным предыдущим оратором.
    > То что на php или java можно сделать 'rm -rf /' не
    > повод считать их плохими.
    > А вот то, что на си даже крутой программер не может обеспечить
    > 100% отсутствие переполнений - это повод назвать сишечку какашечкой.

    Ща вот прям срыв покровов будет. ПХП написан на C (как, в общем-то, и Java, и даже само небо и сам Аллах). Поэтому:
    1. Программы на ПХП имеют кучу проблем, обусловленных ПХП.
    2. Программы на ПХП наследуют проблемы С, на котором написан ПХП.
    3. Программисты на ПХП не могут поправить косяки программистов С, написавших ПХП, и живут как-то с этим.


     
  • 3.20, Мяут (ok), 14:52, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Справедливости ради, такие ошибки можно и нужно вылавливать статическими анализаторами типа PVS-Studio (на чем они кстати и пиарятся). То, что это мало кто делает -- вопрос другой.
    А вот для языков с динамической типизацией статический анализатор как-то трудно представить
     
  • 3.33, Никто (??), 19:35, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ваше замечание в целом верно кроме того, что не имеет отношения к моему комментарию. Я не писал про низкоуровневые языки. Перечитайте, у меня написано:

    >статически строго типизированных компилируемых языках

    На всякий случай уточню - это не про Си, ему не хватает строгости.

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

     
     
  • 4.40, Kodesu (ok), 20:46, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > это не свойство вида типизации.

    Согласен. Мой комментарий был не к месту.

     
  • 4.50, angra (ok), 23:36, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    При выходе за границу массива или иной структуры в скриптовых языках не произойдет чтения или перезаписи других данных. С этой точки зрения они защищают(но не предотвращают) от данного класса ошибок.
     
     
  • 5.65, Никто (??), 13:43, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >При выходе за границу массива или иной структуры в скриптовых языках не произойдет чтения
    >или перезаписи других данных

    Это не свойство динамически типизированных языков.

     
  • 2.27, Аноним (-), 17:15, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –6 +/
    никнейм у тебя правильный, соотвествует уровню комментариев
     

  • 1.8, Никто (??), 12:38, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >Код на языке Go компилируется в обособленные бинарные исполняемые файлы,
    >выполняемые нативно без использования виртуальной машины (...), что позволяет
    >добиться производительности, сопоставимой с программами на языке Си

    Сопоставимая с Си производительность достигается на том же уровне, что и в Java с обособленной виртуальной машиной и не всегда в пользу Go. А при использовании AOT подходы становяться ещё более похожими.

     
     
  • 2.23, freehck (ok), 15:51, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хм. Мой опыт использования aptly показал, что это инструмент весьма шустрый.
    Раз Вы взялись утверждаеть, что у Go такие же проблемы с производительностью, как и у Java - пожалуйста, подтвердите пруфами.
     
     
  • 3.25, Аниним (?), 16:45, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А у java есть проблемы с производительностью?
     
     
  • 4.29, Аноним32 (?), 17:57, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    java вообще летает, особенно в связке с 100500 мб оперативы и N ядерным процом с тактовой частотой 100500 ГГц.
     
     
  • 5.57, Лютый жабист (?), 05:15, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > java вообще летает, особенно в связке с 100500 мб оперативы и N
    > ядерным процом с тактовой частотой 100500 ГГц.

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

     
     
  • 6.62, . (?), 07:59, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    На чём написана jvm напомнить? :)
     
     
  • 7.64, Лютый жабист (?), 08:59, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На чём написано си себе напомни.
     
     
  • 8.73, _ (??), 17:24, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Внезапно - на С же и написанна Но жабофилам этого не понять, мозжечок не вмещ... текст свёрнут, показать
     
  • 3.34, Никто (??), 19:47, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Я не писал о проблемах производительности. Я указал на то, что утверждение:

    >Код на языке Go компилируется в обособленные бинарные исполняемые файлы,
    >выполняемые нативно без использования виртуальной машины (...), что позволяет
    >добиться производительности, сопоставимой с программами на языке Си

    Является ошибочным.

    По поводу доказательств. Посмотрите, кто соседствует друг с другом в тестах скорости:
    http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
    Раньше этот тест был более информативным:
    http://web.archive.org/web/20150923053032/http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html

    Поинтересуйтесь, почему в блоге разработчиков так радуются улучшению производительности сборщика памяти:
    https://blog.golang.org/go15gc

     
     
  • 4.46, freehck (ok), 22:11, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Прошу простить мне неграмотность, однако не подскажете ли Вы мне также, что я должен знать, чтобы понимать эти графики? Я нигде не нашёл описания подобного рода графиков, хотя совершенно точно видел их уже не раз. Я боюсь, что читаю их не правильно.

    1) Что значит жирная линия посередине столбца? Это среднее значение всех программ, участвовавших в тесте?

    2) Что означает белый столбец, внутри которого содержится линия? Это разброс всех замеренных результатов?

    3) Что означают чёрные палочки под и над столбцом? Это погрешности измерений?

     
     
  • 5.66, Никто (??), 13:53, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это графики для визуализации статистических данных. Можете почитать про боксплоты в "Наглядная статистика. Используем R" биолога Шипунова. Если лень - просто ориентируйтесь на жирную горизонтальную линиию - медиану.
     
  • 4.47, freehck (ok), 22:41, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Окей, значит я пока понял это дело так. Go процентов на 30% шустрее Java, но оба они примерно в 2 раза медленнее C.
    http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

    Результат, в принципе, интересный. Меня также удивляет, что OCaml оказался позади Java и Scala, хотя на данный момент, как утверждают некоторые товарищи из Inria, он обладает самым быстрым GC, пускай и однопоточным: при столь малых размерах получаемых бинарей программы на Ocaml могут позволить себе форки, и забить на треды.

    Ещё такой момент: я не понимаю, каким образом у Java/Scala получаются такие хорошие результаты. Это AOT тому причиной? Я вот чего не знаю наверняка:
    1) Jar-ники с jvm-байткодом можно полностью перегнать в нативный код для ускорения программы после старта?
    2) В jvm есть gc, но ходят слухи, что работает он так "хорошо", что сжирает вообще все русурсы CPU, и потому его отключают. Вам известно, как дела обстоят на самом деле?

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

     
     
  • 5.48, freehck (ok), 23:05, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 1) Jar-ники с jvm-байткодом можно полностью перегнать в нативный код для ускорения программы после старта?

    Так с этим вроде стало яснее. Был AOT-compiler GCJ из набора, который похоже загнулся, ибо последние обновления датированы 2009-м. Сейчас осталось проприетарное поделие Excelsior JET, которое, впрочем, уже поддерживает восьмёрку.

    Я так понял, что они перегоняют набор jar-ников в бинарь. А в самих jar-никах содержится исключительно jvm-байткод. Всегда.

    Попровьте меня, если где-то ошибся.

     
  • 5.58, Лютый жабист (?), 05:26, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Окей, значит я пока понял это дело так. Go процентов на 30%
    > шустрее Java, но оба они примерно в 2 раза медленнее C.

    Ты неправ. Во первых задачи бывают разные, я сталкивался с реальными задачами, на которых java быстрее си.

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

    Ну, а так, в теории да, "сферическовакуумная сишечка быстрее в 2 раза".

     
  • 5.59, Лютый жабист (?), 05:31, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > 2) В jvm есть gc, но ходят слухи, что работает он так
    > "хорошо", что сжирает вообще все русурсы CPU, и потому его отключают.
    > Вам известно, как дела обстоят на самом деле?

    Странно иметь какие-то мнение по вопросу вообще не будучи в теме. Сборщик мусора в java-программах часто вообще не запускается.

    На очень жирных программах, в духе - системная интеграционная шина огромной организации, которая имеет потребление порядка 20ГБ ОЗУ и лютое количество enterprise java bean-ов ("потоков") может например срабатывать раз в 6-10 часов и тормозить программу на пару-тройку секунд. И что? Кто лучше-то может?

     
  • 5.67, Никто (??), 15:05, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >2) В jvm есть gc, но ходят слухи, что работает он так "хорошо", что сжирает вообще все
    >русурсы CPU, и потому его отключают

    GC в Oracle JVM работает куда лучше для модели Java чем GC в Go, но разработчики инструментария для Go не стоят на месте.
    Потенциально Go предоставляет возможность для большей эффективности при работе с памятью поскольку в отличии от Java позволяет размещать переменные структурного типа статически. На практике это может никак не проявиться, потому что это сложнее, особенно для бывшего Джависта, который тянет в Go патерны из Java. С другой стороны, JVM в ряде случаев способна провести оптимизацию и разместить динамические с точки зрения языка данные статически. Это не говоря уже о AOT, который позволяет провести более глубокую оптимизацию за счёт меньших ограничений на время компиляции. С другой стороны JIT позволяет получить профиль использования программы и делать оптимизацию более предметно.

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

     

  • 1.9, anonymous (??), 12:41, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Мне вот интересно, зачем они все эти модули в языке тащат.
     
     
  • 2.10, anonymous (??), 12:47, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Потому как язык изначально для толковых студней создавалася, поэтому, с кучей стандартных либ в Go проще стартануть.

    Я, конечно, за минимальньное ядро языка (aka runtime) - работа со строками, числами, базовый I/O (сокеты, файлы) - должно быть достаточно.

     
  • 2.36, Crazy Alex (ok), 20:11, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что это означает, что оно всё будет развиваться в гармсонии с остальными частями языка, и будет какой-то понятный мейнстрим с понятным статусом, а не десяток "стандартов де-факто", тянущих каждый в свою сторону.

    "Batteries included" - это сейчас вообще необходимость для любого нового языка.

     
     
  • 3.45, anonymous (??), 21:44, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пользователь IDE? :)

    ЯП = синтаксис, и либы тут немного сбоку. Хороший пример - C/C++ к-ми можно пользоваться без стандартных либ.

     
     
  • 4.49, angra (ok), 23:23, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Начни с ввода/вывода в консоль без стандартных либ в С/С++.

     
     
  • 5.52, anonymous (??), 00:10, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну посмотри как в линукс ядре, например, выводят на консоль. Без стандартных либ.
     
     
  • 6.63, . (?), 08:11, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Дооо - ты напиши корректный printf сначала чмо малолетнее :) Там и зубры тока так зубы ломают :-F
     
  • 6.76, Андрей (??), 05:14, 20/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так в ядре же есть своя libc: klibc. И вот куча функций:
    usr/klibc/printf.c
    usr/klibc/vfprintf.c
    usr/klibc/vsnprintf.c
    usr/klibc/stdio/fwrite.c
    usr/klibc/SYSCALLS.def

    Происходит следующее:
    --> printf()
                 --> vfprintf(stdout,... )
                                           --> vsnprintf()
                 --> _fwrite(..., stdout)
                                           --> fwrite_noflush()
                                                                --> write() (SYSCALL)

     
  • 2.37, Никто (??), 20:12, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Этих модулей нет в языке, они в стандартной библиотеке. Чем это хорошо при должном уровне разработки библиотек - понятно, чем плохо - не понятно.
     

  • 1.12, Аноним (-), 13:09, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > что позволяет добиться производительности, сопоставимой с программами на языке Си.

    а затем:
    > Сокращено число пауз, вызванных работой сборщика мусора, что особенно заметно в программах, расходующих большие объемы памяти;

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

     
     
  • 2.42, Никто (??), 21:14, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скорость только возрастает, если рантайм встраивается в исполняемый файл. Рантайм есть и у Си, но обычно идёт в виде динамической библиотеки при возможности статической компоновки. Для Go выбрали обратный подход - по умолчанию идёт статическая компоновка, но возможна и динамическая.
     

  • 1.15, Аноним (-), 13:19, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    CS GO 1.6 вышел?
     
  • 1.16, 0eviy (ok), 13:25, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    круто!
     
  • 1.18, Аноним (-), 13:35, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Изменён алгоритм сортировки, используемый в sort.Sort, что также позволило поднять производительность примерно на 10%

    судя по коммиту, увеличили минимальный размер массива для сортировки вставками, но добавили сортировку Шелла.
    Интересно, почему там не используется timsort, как в большинстве современных библиотек. (видимо потому что появился после 1990-го года. Все эти Коксы с Пайками - они такие)

     
     
  • 2.77, Андрей (??), 05:32, 20/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, почему там не используется timsort, как в большинстве современных библиотек

    В большинстве??? Согласно википедии: питон, а также джава, андроид и октав. Всё.

    > (видимо потому что появился после 1990-го года. Все эти Коксы с
    > Пайками - они такие)

    Ну, Роб Пайк, может, и да. Но Рас Кокс - поколение помоложе.

     

  • 1.19, Аноним (19), 14:25, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Добавлены экспериментальные порты для Linux на 64-рядных процессорах MIPS (linux/mips64 и linux/mips64le) и Android on 32-разрядных процессорах x86 (android/386);

    прошу гугл добавить arm/arm64 и powerpc/powerpc64 - очень хочется докеры

     
  • 1.28, Аноним (-), 17:16, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Cтарый алгоритм сортировки доступен через вызов sort.Stable

    Дезинформация. sort.Stable был и до этого, а sort.Sort был отличен от него.

     
  • 1.30, Андрей (??), 18:15, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В Cgo, механизм для организации вызова кода на C/C++ из программ на языке Go

    А вот этот последний пункт - самая большая головная боль для кучи проектов. Даже если ты передавал opaque указатель, теперь - нельзя! Указатели нужно хранить в map, и передавать можно только "указатели" на эти указатели.

     
     
  • 2.38, Crazy Alex (ok), 20:12, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В общем, извращенцы
     
     
  • 3.74, Андрей (??), 04:56, 20/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще, я - за Go! Но, признаю, что это решение выглядит неуклюже. Причина: сборщик мусора. Чтобы ему было удобней, решили пожертвовать удобством для cgo.
     
  • 2.53, Аноним (-), 01:35, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Наркоман, что ли? Ничего подобного и близко нет.
     
     
  • 3.75, Андрей (??), 04:58, 20/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для тех, кто в танке, один из основных разработчиков Go, ответственный за gccgo/cgo:
    https://github.com/golang/go/issues/8310#issuecomment-66096613
     

  • 1.39, rvs2016 (ok), 20:20, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Привет, мир, пожалуйста, в студию.
    Какие браузеры поддерживают язык?
     
     
  • 2.43, Никто (??), 21:26, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Здравствуй, школьник. В привычном понимании этого слова никакие браузеры не поддерживают этот язык. Тем не менее и как это ни смешно, "привет, мир" можно попробовать прямо из браузера сразу на главной странице официального сайта https://golang.org/
     
  • 2.55, Аноним (-), 02:45, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    при чем тут браузеры?
     

  • 1.41, 321 (??), 21:11, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    версии слишком быстро плодятся. версия gccgo - не поспевает.
     
  • 1.68, Аноним (-), 15:13, 19/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что за версия языка еще? Это, типа, стандарт Go99 или Go14?
     
     
  • 2.70, Andrey Mitrofanov (?), 15:51, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Что за версия языка еще? Это, типа, стандарт Go99 или Go14?

    Чего https://golang.org/ref/spec (см.внизу: "Build version go1.6."!) непонятого-то? Спецификация - часть билда компилёра, компилёр - референсная (и единственная, надо полагать?) реализация, включённой в него спецификации, и т.д., и т.д -- чтобы понять рекурсию, надо понять: Ленин - Партия, Партия - Ленин.

     
     
  • 3.71, Аноним (-), 16:57, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Версия компилятора все-таки? Вот есть GCC 5.3.1, поддерживающий C++11. 5.3.1 - версия GCC, а C++11 это версия стандарта языка С++. Сабж то какую версию Go поддерживает? И как у языка может быть версия?
     
     
  • 4.72, Andrey Mitrofanov (?), 17:21, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Версия компилятора все-таки?

    Многие жалуются, что я непонятно пишу, поэтому для тех, кто не понял: я написал "версия и того(компилятора=реализации), и другого(языка=спецификации)".


    > C++11 это версия стандарта языка С++
    >И как у языка может быть версия?

    Это Вы так сам с собой разговариваете? Извините, если помешал.

    Мне так казалось, что [как бы очевидно, что] язык=спецификация, версия языка=версия "стандарта".

     

  • 1.80, IvAnZ (?), 08:32, 22/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто-нибудь Caddy производительность смотрел против nginx?
    Я смотрю там reverse-proxy failover check  из коробки, чего у nginx нет (есть в Plus версии или надо Lua прикручивать)
    https://caddyserver.com/docs/proxy

    Думаю есть ли смысл только как Load-Balancer Caddy поставить перед nginx?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру