Язык программирования Go

[DIzer]

Проект go1 рассчитан на веб?
так в ГО же статическая компиляция...

Концепция проекта в ide -моделирует его окружение (структуру) -в тех областях для которых ЯП спроектирован (так как воспринимают эти области создатели ide) -  а Go планировался производительная альтернатива  PHP,Ruby,Python... ну и СИ++  для некоторых видов серверных приложений -разве нет  ?

[valexey]

Проект go1 рассчитан на веб?
так в ГО же статическая компиляция...

Концепция проекта в ide -моделирует его окружение (структуру) -в тех областях для которых ЯП спроектирован (так как воспринимают эти области создатели ide) -  а Go планировался производительная альтернатива  PHP,Ruby,Python... ну и СИ++  для некоторых видов серверных приложений -разве нет  ?

Не совсем. Go это логическое развитие Limbo, то есть языка общего назначения. В том числе и для всякого там "системного" программирования. Поскольку язык общего назначения, то использовать его можно для чего угодно. Ну, например для веба. Google его там и использует - см. GAE. Это просто та ниша куда гугл его может проще всего пропихнуть пользуясь своим весом на этом рынке и своими сервисами.

Да, а IDE у Go официального нет. :-) Основные разработчики используют Acme.

[vlad]

При запуске программы на go, скомпилированной компилятором 8g рантайм пытается выделить 512 мегабайт виртуального адресного пространства для нужд сборщика мусора.

Oberon warning: fat runtime detected.

Не, ну нахера ему 512 метров на стартапе??? А почему не гигабайт тогда, для ровного счета?

[valexey]

При запуске программы на go, скомпилированной компилятором 8g рантайм пытается выделить 512 мегабайт виртуального адресного пространства для нужд сборщика мусора.

Oberon warning: fat runtime detected.

Не, ну нахера ему 512 метров на стартапе??? А почему не гигабайт тогда, для ровного счета?

Где там fat runtime? Оно ПЯМЯТИ не требует 512 метров. Оно требует адресное пространство. В плане памяти там рантайм очень скромный. Скромнее чем у всяких птонов и тем более жаб.

[vlad]

Где там fat runtime? Оно ПЯМЯТИ не требует 512 метров. Оно требует адресное пространство. В плане памяти там рантайм очень скромный. Скромнее чем у всяких птонов и тем более жаб.

Я понял, что речь об адресном пространстве. Но его длиннее писать. Итак, нахрена ему 512 метров адресного пространства?

[valexey]

Где там fat runtime? Оно ПЯМЯТИ не требует 512 метров. Оно требует адресное пространство. В плане памяти там рантайм очень скромный. Скромнее чем у всяких птонов и тем более жаб.

Я понял, что речь об адресном пространстве. Но его длиннее писать. Итак, нахрена ему 512 метров адресного пространства?

Чтобы 10 раз за ним не бегать? :-)

[vlad]

Чтобы 10 раз за ним не бегать? :-)

Хорошо, почему не гигабайт?

[valexey]

Чтобы 10 раз за ним не бегать? :-)

Хорошо, почему не гигабайт?

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

Почему 512 - хез. Может прикинули максимальный средний объем ОЗУ который потребуется приложению.

PS. Но никто не мешает использовать gccgo, где рантайм другой и этой проблемы нет.

[valexey]

Кстати, как я понял, Go резервирует большое адресное пространство для более эффективной работы сборщика мусора. А именно - таким образом они пытаются уменьшить вероятность коллизий консервативного сборщика мусора (а у них он консервативный). Таким образом, проблема не специфична именно что для Go - при любой реализации рантайма (вне зависимости от языка) с консервативным сборщиком мусора приходится выбирать - либо высокая вероятность коллизий (а следовательно и утечек памяти), либо резервируем большое адресное пространство, но тогда будут проблемы на архитектурах с "тесным" адресным пространством (32 битным например).

[valexey]

Собственно вот тут: http://code.google.com/p/go/issues/detail?id=909 как раз описание проблемы с утечками на 32битной архитектуры из за мелкого адресного пространства в сочетании с консервативныс сборщиком мусора.

[DIzer]

Так и не понял что нужно чтобы его подсадить - вроде на XP32 - примитивщина запускается (может версия компилятора была старая...)

[DIzer]

Да, а IDE у Go официального нет. :-) Основные разработчики используют Acme.

На безрыбье сойдет и liteide - довольно удобна - в особенности для ознакомления новичками - недочеты допилят за год (если не забросят, конечно).

[valexey]

Собственно вот тут: http://code.google.com/p/go/issues/detail?id=909 как раз описание проблемы с утечками на 32битной архитектуры из за мелкого адресного пространства в сочетании с консервативныс сборщиком мусора.

Кстати, цитатка из Вирта (глава 8. Память: разметка и управление):

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

Ну и в оригинале:

In the case of three spaces, arbitrarily determined size limits are unavoidable. The presence
of an address-mapping hardware alleviates the problem, however, because the virtual address space is
so large that limits will hardly ever be reached.

[valexey]

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

[Губанов Сергей Юрьевич]

ничего про сканирование стека на предмет указателей

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