LINUX.ORG.RU

Go 1.3

 


1

3

Версия 1.3 выпущена спустя шесть месяцев после версии 1.2 и не содержит изменений в языке. Основная работа была произведена над реализацией, что обеспечило точную сборку мусора, рефакторинг тулчейна, результатом которого стала более быстрая сборка, особенно больших проектов, и значительное улучшение производительности. Как всегда, Go 1.3 держит обещание совместимости, и с новой версией почти все приложения будут продолжать собираться и запускаться без изменений.

Главные улучшения:

  • Прекращена поддержка Windows 2000.
  • Появилась экспериментальная поддержка Dragonfly BSD.
  • Вернулась поддержка Native Client (NaCl).
  • Добавлена экспериментальная поддержка Plan 9.
  • Добавлена экспериментальная поддержка Solaris.
  • Изменилась реализация стеков горутин: прежняя, «сегментированная» модель заменена на непрерывную, что устраняет старую проблему «горячей точки», когда вычисление многократно выходит за границу сегмента. Подробности, включающие статистику производительности, можно посмотреть здесь.
  • Долгое время сборщик мусора был точным при изучении значений в куче. В версии 1.3 аналогичная точность добавлена для значений в стеке. Это значит, что значения Go, не являющиеся указателями (например, целые), больше не будут ошибочно приниматься за указатели и препятствовать повторному использованию незанятой памяти.

А также многое другое.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 1)

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

Вон из профессии?

а при чем тут профессия? Это было понаписание скриптца для составления укрупненной схемы мозаичного оленя, которого моя девушка вяжет/сшивает. Этож не работа, по работе я и так достаточно много читаю. Я видел высказывания на ЛОРе в духе «какой простой и элегантный язык, осилил за вечер». И это, наверное, верно вполне, если ты сишник. А мне батареек надо, я девушке оленя делаю.

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

Кстити, а бинарники то в размере меньше стали:

$ du -h gone-*
13M     gone-1.2.2
9.3M    gone-1.3

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

Windows 2K с установленным MinGW скорее всего поддерживает твой компилятор, который «не поддерживает Windows 2K»

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

Юкихиро Мацумото по прозвищу Безумный Матц создает Ruby, чтобы предотвратить какой-то таинственный апокалипсис, который превратит Австралию в пустыню, захваченную воинами-ирокезами и Тиной Тёрнер. Позже язык будет переименован его настоящим создателем, Дэвидом Хейнемейер Ханссоном, в Ruby on Rails. (Немного об изобретении Мацумото, языка, называемого Ruby, никогда не существовало, и было бы лучше удалить его из следующей версии этой статьи — DHH). http://radioprog.ru/?p=118

Полагаю, go с docker-ом ждет похожая участь

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

Даже олени имееют право воспроизводится, не фашизм, чай, у нас пока еще.

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

вот внутри haskell Data.Text

Вот именно, что внутри. И причём скорее всего не UTF-16, а UCS-4, так как юникоду нужно четыре байта, а не два.
Для всего, что снаружи — только UTF-8.

quantum-troll ★★★★★
()
Ответ на: комментарий от makoven

Полагаю, go с docker-ом ждет похожая участь

Про них напишут смишной фельетон?

anonymous
()
Ответ на: комментарий от quantum-troll

И причём скорее всего не UTF-16, а UCS-4,

Не-не-не, блейн, это в String. А смысл для нормальной библиотеки в ucs-4? Все равно есть символы модификаторы. Тот же icu тоже вроде utf-16. Сомнительная гипотеза.

Для всего, что снаружи — только UTF-8.

Не тебе решать, слава т.н. Б-гу. Лично мне не чужды интернациональные порывы в поддержку тех же китайцев)).

anonymous
()
Ответ на: комментарий от umren

Почему бы и нет: https://github.com/BurntSushi/wingo Да забейте, людям нравиться бросать камни в огород чему попало. Голанг хороший язык и главное то, что мы об этом знаем.

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

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

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

Для всего, что снаружи — только UTF-8.

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

UTF-8 не умеет в китайский?

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

ещё бы copy-on-write в go и у него будет оптимизированный рантайм

Где-то читал, что COW не такая уж значимая оптимизация, особенно в многопоточном коде.

Типа того.

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

vs 50% андерхед для ASCII?

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

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

UTF-16 имеет оверхед в байт на символ для ASCII, требует костылей вроде BOM и не покрывает весь юникод. В общем, UTF-16 considered harmful.

quantum-troll ★★★★★
()
Ответ на: комментарий от anonymous

мне не чужды интернациональные порывы в поддержку тех же китайцев

И мне не чужды. Как UTF-8 их ограничивает?

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

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

quantum-troll ★★★★★
()
Ответ на: комментарий от buddhist

раз уж узнал когда-то и про utf и про bom, разузнать не можешь, такая беда

RedPossum ★★★★★
()
Ответ на: комментарий от quantum-troll

UTF-16 имеет оверхед в байт на символ для ASCII

Как и utf-8 для ряда языков.

требует костылей вроде BOM

Может вы не совсем внимательно читаете, напомню: Go 1.3 (комментарий) , второй абзац. Ваш вброс однобок и предвзят.

не покрывает весь юникод

Можно поподробнее?

В общем, UTF-16 considered harmful.

И это тоже, пожалуйста. Или это уже собственный «вывод»?

anonymous
()
Ответ на: комментарий от quantum-troll

В общем, UTF-16 considered harmful.

и чего теперь, не делать нормальну поддержку всего что кривое? После такого в 1Сники будут только интравертов брать.

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

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

В какой перспективе? UTF-8 имеет 50% оверхед лишь в четверти диапазона, итого 12.5% и 50% в 1/8 диапазона. Итого «экономия» в UTF-16 на примерно 6% как-то не сильно впечатляет. При том, что это без учета сравнения количеств ASCII символов и диапазона, где у UTF-16 преимущество.

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

А кто сказал, что «ограничивает», просто менее удобен для нац. языка. Интересно будет посмотреть что (и есть) из utf-* они будут стандратизировать (не в теме, разве что про gb* слышал).

anonymous
()
Ответ на: комментарий от quantum-troll

не покрывает весь юникод

Там для того, что не влезает, используются пары слов. Не надо путать с UCS-2.

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

Можно поподробнее?

А, пардон, перепутал с UCS-2. У UTF-16 есть особый костыль, позволяющий разложить один символ в два. Таким образом, UTF-16 совмещает несовместимость с ASCII и оверхед на его символы, как в UCS, с невозможностью прямого доступа к символу, как в UTF-8.

quantum-troll ★★★★★
()
Ответ на: комментарий от korvin_

В какой перспективе?

Не передергивайте пожалуйста. В этой подветке аргументы приводил с точки зрения конкретного _языка_. В перспективе: что-то вроде Go 1.3 (комментарий), для общего стандарта для пары стран, например. Уменьшение искусственного дисбаланса тоже было бы неплохо.

6% как-то не сильно впечатляет.

А где-то говорю, что utf-16 сильно лучше? Началось с «безальтернативности» utf-8, Go 1.3 (комментарий) - имхо несправедливо.

anonymous
()
Ответ на: комментарий от quantum-troll

UTF-16 есть особый костыль

Хватит уже вбрасывать. Тогда нужно и unicode назвать костылем, ибо для surrogate-pair зарезервировы интервалы.

anonymous
()
Ответ на: комментарий от shamkir

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

Какую ещё «динамическую линковку»? Go априори умеет только статические бинарники собирать. А для уменьшения бинарника можно upx-ом воспользоваться - хоть немного, да пожмёт.

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

Go априори умеет только статические бинарники собирать

Это наврено к компилятору, а не языку. Он ниже пример написал. (Правда до сих пор ломаю голову, нафига "-s" в кавычки взял, и зачем показал, что не знает опции du.)

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

anonymous
()

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

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

Так а как они собираются бороться с обновлениями библиотек, плагинами, размерами бинарей? Ладно в плане9 есть идея 9p серверов, но тут то как?

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

gccgo не может в динамическую линковку?

Кажется может, но он «экспериментальный» вроде, в продакшен не рекомендуется, или как?

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

тот же Питон, как по мне, так гораздо «интуитивно-понятнее»

Под «прост» имеется в виду простота реализации, а не простота использования (в лучших традициях worse is better). И если посмотреть на спецификацию (http://golang.org/ref/spec), то можно убедиться, что го действительно прост.

quantum-troll ★★★★★
()
Ответ на: комментарий от loz

Так а как они собираются бороться с обновлениями библиотек, плагинами, размерами бинарей? Ладно в плане9 есть идея 9p серверов, но тут то как?

Можешь и тут воспользоваться 9p, вроде как Go'шная реализация полноценна, насчет остальных языков — не знаю.

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

Уменьшение искусственного дисбаланса тоже было бы неплохо.

А где-то говорю, что utf-16 сильно лучше? Началось с «безальтернативности» utf-8, имхо несправедливо.

А на кой черт плодить форматы, которые еще и ничем не лучше? Мало было (и местами до сих пор есть) развлечений с зоопарком koi8r, cp866, cp1251? Предлагаешь теперь каждой стране выбрать «свой любимый формат» utf? Нет уж, utf-8 оптимальна и должна остаться одна. Если придумают что-то значимо лучше, тогда пожалуйста.

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

Под «прост» имеется в виду простота реализации, а не простота использования (в лучших традициях worse is better). И если посмотреть на спецификацию (http://golang.org/ref/spec), то можно убедиться, что го действительно прост.

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

Ведь в том то и дело, что его кругом пиарят так - «даже проще чем Питон, а ещё и компилируемый, и параллельный!»

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

anonymous
()
Ответ на: комментарий от korvin_

А на кой черт плодить форматы

Что-то мне подсказывает, что utf-16, если считать его наследником ucs-2, появился раньше utf-8.

Нет уж, utf-8 оптимальна и должна остаться одна.

Go 1.3 (комментарий) , второй абзац.

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

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

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

How about dead code elimination? Unused code from statically linked runtime should go away. How much do you really need to push a read-only segment onto stack and do a «write» system call to print «Hello, World»? Few bytes of code & data.

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

Что-то мне подсказывает, что utf-16, если считать его наследником ucs-2, появился раньше utf-8.

UTF — это формат UCS, а не наследник. Мне вика подсказывает, что UTF-16 в современном виде (т.е. умеющий весь юникод) появился в 96-м году, а UTF-8 — в 92-м.

второй абзац.

Ага, и большинство уже решило в пользу UTF-8.

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

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

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

Ну и чисто субъективно - Go сухой и колючий язык, а Питон живой и питательный )))

Т.е. если бы был язык с синтаксисом Питона, но с функционалом Go, то я бы ни на секунду не задумываясь выбрал его.

anonymous
()
Ответ на: комментарий от korvin_

UTF — это формат UCS, а не наследник

В определенном наследник: The older UCS-2 ... was superseded by UTF-16. С вашей же вики.

что UTF-16 в современном виде

Это уже оговорки.

Ага, и большинство уже решило в пользу UTF-8.

Если, сударь, вам будет легче, ту цитату можете понимать, как «не только тебе». Да и gb и jis кое-где стандарты, хотя может ваше большинство берет европейским качеством.

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

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

Например?

korvin_ ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.