LINUX.ORG.RU

Выпуск Go 1.4

 


2

5

Вчера состоялся выпуск языка программирования Go 1.4. Go — это компилируемый императивный язык программирования, созданный Робертом Гризмером, Робом Пайком и Кеном Томпсоном в компании Google как более удобная и безопасная альтернатива C++. Сейчас у него тысячи пользователей по всему миру, на нём написаны такие открытые проекты, как Docker или Ubuntu Juju, а также многие серверные приложения, особенно для внутрикорпоративного использования. В ноябре языку исполнилось пять лет.

Одна из главных новостей: компилятор gc теперь поддерживает платформу Android. Библиотеки пока ещё не готовы, но уже можно писать простые приложения целиком на Go. Кроме того, добавлена поддержка NaCl на процессорах ARM и Plan 9 на AMD64.

В новом выпуске сделано два изменения синтаксиса. Во-первых, разрешено писать цикл с range таким образом:

for range x {
	...
}
что эквивалентно:
for _ = range x {
	...
}
то есть цикл, в котором сами элементы последовательности не обрабатываются. Это изменение полностью совместимо со всеми существующими программами.

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

type T int
func (T) M() {}
var x **T
x.M() //!!!
то теперь в последней строчке будет ошибка. Такой код противоречит существующей спецификации языка, потому что она разрешает не более одного неявного разыменования, но раньше и gc, и gccgo его принимали.

В утилите go появилась команда generate, которая запускает внешние программы (например, yacc) для автоматической генерации файлов .go. Если некоторые файлы в пакете нужно сгенерировать из других файлов, то теперь с помощью специальных комментариев в файлах, написанных вручную, можно заставить go build вызывать go generate с нужными опциями перед сборкой. Таким образом можно реализовать, например, генерацию схожих функций для разных типов без использования дженериков. В go также добавлена команда stringer, которая позволяет быстро создавать метод String() для типов (чтобы удовлетворить fmt.Stringer).

Кроме того, утилита go теперь позволяет указывать «канонические пути» для импорта пакетов: если для пакета указан канонический путь, но где-то в программе он импортируется прямо из интернета по другому пути, то программа не скомпилируется. Добавлена сокращённая форма для импорта субрепозиториев. Слегка изменена ожидаемая структура каталогов в дереве исходников.

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

О прочих, менее значительных изменениях можно прочитать в информации о выпуске.

Кроме того, начиная с выпуска 1.4 разработчики перешли с Mercurial на Git и Gerrit, а скоро планируют переехать с googlesource.com на Github (сейчас там работает зеркало). Go 1.4 доступен на Google AppEngine для бета-тестирования. Тем временем компилятор GCC 4.9 поддерживает только Go 1.2, а поддержка Go 1.4 ожидается в GCC 5.

Go 1.4 Release Notes

>>> Объявление о выпуске

★★★★★

Проверено: maxcom ()
Последнее исправление: proud_anon (всего исправлений: 2)

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

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

Ну да, проверил. Текст goappend.go:

package main

import "fmt"

func main() {
	x := []int{1, 2, 3}
	fmt.Println(x)
	x = append(x, make([]int, 10)...)
	fmt.Println(x)
}
Вот что делает gccgo 4.9 с -O3 в релевантном месте:
0000000000401af4: add rsp, 32
0000000000401af8: mov edx, 10
0000000000401afd: mov esi, 0x00402f00
0000000000401b02: lea rdi, [rsp+32]
0000000000401b07: call 0x0000000000401650		<goappend::__go_make_slice1@plt>
0000000000401b0c: mov qword ptr [rsp], rbx
0000000000401b10: mov qword ptr [rsp+8], 3
0000000000401b19: mov ecx, 8
0000000000401b1e: mov qword ptr [rsp+16], 3
0000000000401b27: sub rsp, 8
0000000000401b2b: push 3
0000000000401b2d: push 3
0000000000401b2f: push rbx
0000000000401b30: mov rdx, qword ptr [rsp+72]
0000000000401b35: mov rsi, qword ptr [rsp+64]
0000000000401b3a: lea rdi, [rsp+32]
0000000000401b3f: call 0x0000000000401660		<goappend::__go_append@plt>
0000000000401b44: mov r13, qword ptr [rsp+32]
(goappend — это название программы)

Результат работы gc чуть сложнее читать из-за отсутствия символов и нестандартной конвенции вызовов, но там, по-моему, всё так же прямолинейно.

Так что нет, рано ещё полагаться на такую оптимизацию.

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

Гороутины разве что, но и они не прорыв, разве что удобными сделаны.

Ну покажи тогда другой язык, в котором есть нормальные корутины(не хиленькие итераторы типа тех, что в новом джаваскрипте) и каналы с оператором select. При этом есть и preemptive треды, и всё хорошо друг с другом работает. И всё это поддерживается во всём стандартном апи и сторонних библиотеках.

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

Можно поинтересоваться чем? Да, мне не нравится язык - не скрываю, но стараюсь быть объективным. Он достаточно простой и удобный - это да. А интересность в чём? Ничего нового и оригинального, вроде. Гороутины разве что, но и они не прорыв, разве что удобными сделаны.

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

А вот реализация исключений (особенно отношение к ним) и отсутствие шаблонов сильно портят язык на мой взгляд.

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

маргинальщина

Go - это вообще-то пока тоже не такой уж мейнстрим. Да и вообще какой-то тупой аргумент.

Ну и да, я не знаком со всеми перечисленными языками. Так можно подумать ты знаком.

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

Go - это вообще-то пока тоже не такой уж мейнстрим.

Ну хоть какой-то шанс появился. К тому же, может остальные проснутся - вон для жабы любители запилили библиотечку Quasar, например. Глядишь, до людей дойдёт наконец-то и начнут проталкивать в языки.

Да и вообще какой-то тупой аргумент.

Библиотеки, проекты-вакансии-популярность-сообщество.

Ну и да, я не знаком со всеми перечисленными языками. Так можно подумать ты знаком.

Ну я интересуюсь темой, смотрел, где есть нормальные корутины. По C# только не помню ситуацию, вероятно, там виндовские файберы(вот внезапно, DEVELOPERS DEVELOPERS, думают таки о людях), а в остальном всё печально - нигде.

У меня баттхёртлютое негодование от всей этой ситуации. Корутины известны с 60-х годов, описаны Кнутом, были реализованы в божественной прародительнице всего нынешнего мейнстрима Симуле 67, причём, продвигались как мажорная фича. Тривиально реализуются на ассемблере. Но при этом практически во всех мейнстримных языках поддерживаются чуть более, чем никак, даже сраный ucontext.h в POSIX задепрекейтили.

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

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

Библиотеки, проекты-вакансии-популярность-сообщество.

Ну это понятно. Просто одно дело если мы сравниваем, например, джаву и какой-нибудь лисп, то да - разница в популярности огромная. А если Gо и какой-нибудь F#, то что тут «уровень маргинальности» не сильно отличается.

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

Вот если бы так сразу. Ну а вообще я ж не спорю - это сразу в плюс языку записал. Просто лично для меня фичи важнее «простоты», а в Gо предпочли второе.

DarkEld3r ★★★★★
()

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

:-)

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

Зря ты эту картиночку запостил), делаю на D одну интересную вещь и уже рабочая альфа. Кода по размеру и времени ушло в 5-7 раз меньше если бы делал на C и в 2-3 чем на С++. Знаю все три языка примерно одинаково на данный момент.

Язык уже созрел, просто в нем немного подпортило картину метание Танго-Фосос, вер.1 - вер.2. Но это уже всё в прошлом.

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

даже сраный ucontext.h в POSIX задепрекейтили.

Зачем он нужен, если

Тривиально реализуются на ассемблере

Не говоря уже о том, что setjmp/longjmp и есть твои «корутины», а один раз RSP/RIP поменять можно и однострочником на асме.

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

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

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

Думаю, что да, но время покажет. А если они и так же после выхода версии 1.0 будут менять синтаксис раста, то 100% не видать ему успеха.

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

Нет, не могу. (Я не анонимус, но попытался угадать ответ.)

Virtuos86 ★★★★★
()

безопасная альтернатива C++

Прям как резиновая женщина, безопасная альтернатива живой.

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

что setjmp/longjmp и есть твои «корутины»

char stack[2048] типа? Как насчёт нет? К тому же, по стандарту, повторное использование jmp_buf - это undefined behaviour.

а один раз RSP/RIP поменять можно и однострочником на асме.

Особенно, когда он не под интел.

Ты какой-то на-коленке-самоделкин, видимо, МОЖНАСДЕЛАТЬ. Можна-то можна, да только есть всякие другие соображения, например, поддержка в библиотеках. Если, например, какой-нибудь сиране пипиетарный драйвер базы данных(на сферическом языке в вакууме) использует блокирующий ввод-вывод, и блочит весь операционкин тред с тысячью твоих легковесных тредов, то никакого другого выхода, кроме как отправить его в отдельный собственный тред, и потом ещё париться с многопоточностью, нету.

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

char stack[2048] типа? Как насчёт нет?

Как насчет «обоснуй»? Техника используется уже не первый год. google: state threads, c++ mordor, libcoro

К тому же, по стандарту, повторное использование jmp_buf

А, соображалки не хватает, как это сделать правильно? Не то что стандарт, valgrind не чирикает.

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

Так непонятно, что ты сказать хочешь. Я говорил, что setjmp - это более убогий костыль для реализации корутин, чем ucontext, ты говоришь, что нет. Ну ок, пускай setjmp той же убогости, или менее убог, пусть так, проблема вообще не в этом. Проблема в этом:

state threads, c++ mordor, libcoro

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

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

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

Тогда Rust тоже ждет провал?

Провал всегда возможен. Но Rust точно проще Си++ и, в отличие от D, в Rust есть нечто реально новое (для промышленных языков): концепция «memory safety without garbage collection».

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

По C# только не помню ситуацию, вероятно, там виндовские файберы

а где там они вообще? Await/Async если, то там пул тасков.

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

главное достоинство Go - он продвигает корутины на уровне языка

Корутины - это coroutines? Если что, goroutines не являются coroutines.

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

Я говорил, что setjmp - это более убогий костыль для реализации корутин, чем ucontext, ты говоришь

В следующий раз прежде чем говорить, сходи в исходники glibc. _setjmp/_longjmp намного быстрее, чем swapcontext

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

Какие же? Хочу также напомнить, что чем ближе язык к железу, тем более дикие вещи на нем можно творить. К примеру, легким движением руки через LD_PRELOAD любая сишная (и плюсовая) reentrant-библиотека, работающая с IO, превращается в асинхронную.

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

kawaii_neko ★★★★
()

Язык чистый маркетинг. Ради будущего российского софта, надеюсь что 99% комментариев к новости писали школьники, или любители как я. p.s. Взяли бы и написали нормальный кирилический яп, а либы можно портировать. Самих ошибки в именах с weight, height, width и безграмотность в комментариях, доках, не достали?

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

Да, конечно, там нет явных resume/yield и есть планировщик.

«Легковесные потоки» или «кооперативная многозадачность» в широком смысле - symmetric/asymmetric coroutines / fibers / goroutines / green threads - дайте хоть что-нибудь! Часто одно из этого выразимо через другое.

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

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

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

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

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

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

Ну так я и говорю, что в нормальных языках (а это C и местами C++) все уже давно есть. В Python сопрограммы, в scheme call/with-cc, к перлу через библиотеки прикручивается тот же coro.

В Go не изобрели ничего революционного, просто js-павианы, число коих в последние годы превысила даже популяции php-макак и java-шимпанзе, не знали ничего кроме DoSomething(args, when-ready-function). А теперь увидели то, чем нормальные люди уже больше десятка лет спокойно пользуются.

Я все к тому, что не стал бы возлагать какие-то надежды на Go. Google пилит его для своих внутренних нужд, так что оно будет неплохо работать, если их нужды пересекаются с вашими. Для всего остального уже есть куда более удобные и/или производительные решения.

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

Еще бы ему хотя бы один полноценный биндинг для гуя, а лучше собственную гуи-библиотеку.

у visualfc, автора liteide — простой и понятной IDE для GoLang есть целых три биндинга: к IUP и к Qt , причём к Qt почему-то два — пустой goqt и go-ui.

ну и можно посмотреть, как это IDE собирается, на предмет

go install -ldflags "-s" -v liteide_stub
...
go install -ldflags "-s" -v github.com/nsf/gocode

хотя ЕМНИП, основной GUI там на C++, а на GoLang — небольшие куски.

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

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

про динамические библиотеки это ещё из Plan9 пошло. и да, особого профита нет: «когда мы первые добавили динамические библиотеки в Solaris, мы сделали замеры, и выяснили что это тормознутая технология с угрозами надёжности и безопасности (man ksplice, например). но школота их очень хотела, так что мы их там оставили» (с) авторы динамических библиотек, программисты ядра Solaris.

так что если очень хочется, то можно и сделать, но профита не так чтобы очень уж много.

собери например g++ --static helloworld.cxx -o hello.exe && ls -lh hello.exe

и ты увидишь бинарник на 1,8 Mb, который после strip символов станет ~650k, плюс-минус.

расказывай теперь, что в GoLang бинарники толстые, ага.

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

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

глянь например на CPC, continuation passing C (гитхаб). На этом торрент клиент написали.

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

Тогда Rust тоже ждет провал?

я б сказал, что для языков, которые компилируются в Си — ржавчина ближайший и лучший вариант. из-а семантики владения, корутин, каналов, асинхронности, а также инфраструктуры типа cargo , поддержки всех основных платформ ибо LLVM, и макросов, например.

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

// другой анонимус, если что.

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

Ну это интересно всё, но только для хобби-проектов, к сожалению.

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

про ексепшны — это разумно. потому что представь их себе в асинхронном многопоточном коде

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

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

Тем более, что и в Go в итоге сдались и таки сделали размотку стека, просто как-то очень своеобразно.

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