Релиз Go 1.1

не все могут осилить плюсы, даже С не все осиливают

You got that backwards, bro.

При «GOMAXPROCS=2» - параллельно.

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

Забаньте этого товарища пока ещё не поздно.

Забаньте этого товарища пока ещё не поздно

просто ты не захотел подумать, большая часть уязвимостей вылавливается после релиза, обкатав либу года два-три ты значительно уменьшишь вероятность нахождения новых багов, банальный пример на практике - RHEL и debian

Присваивание значения указателю не атомарная операция?

Присваивание значения указателю не атомарная операция?

В C (да наверное почти в любом языке, может кроме жабы там или php с питонами) на мультипроцессорной x86 при отсутствии выравнивания по 4-байтам это точно не атомарная операция.

В языках со сборщиком мусора, - нет.

код на С и С++ вообще банально упадет без явной синхронизации

С какого перепугу, если при g!=0 g будет указывать на созданный объект, причем уже после инициализации поля msg?

Присваивание значения указателю не атомарная операция?

выше уже написали - даже в С это не обязательно атомарная операция, а в Go еще и GC есть

при отсутствии выравнивания по 4-байтам

А что в C указатели уже не выравниваются?

Зависит от копилятора, платформы, опций, прагм и пр.

С какого перепугу, если при g!=0 g будет указывать на созданный объект, причем уже после инициализации поля msg?

это я не про тот пример в частности, а в общем, надо было мне уточнить

В алфавитном порядке.

А что на x86 или x86_64 команду записи по не лежащему на границе слова адресу можно прервать посреди выполнения так, что часть данных будет записана, а часть нет? И какое же значение тогда будет у счетчика команд, дробное что-ли?

Циферки то давай, статист.

С какого перепугу, если при g!=0 g будет указывать на созданный объект, причем уже после инициализации поля msg?

А если оптимизацию включить? :) Я бы на месте компилятора мог оставить 2 строчки в goroutine вместо трех, исключив локальную переменную...

А что на x86 или x86_64 команду записи по не лежащему на границе слова адресу можно прервать посреди выполнения так, что часть данных будет записана, а часть нет? И какое же значение тогда будет у счетчика команд, дробное что-ли?

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

не всем надо/не все могут осилить плюсы, даже С не все осиливают

Где ты таких дефектных видал? :) Любой мощный язык позволяет пользоваться лишь его подмножеством.

Циферки то давай, статист.

их у меня нет, в принципе может я и не прав, но таки идея debian'a, например, где сначала софт обкатывается и исправляются найденные баги, мне кажется надежней чем RR

Как всегда, орда экспертов.

Go предельно прост и лаконичен, осваивается за несколько недель. C++ икспертам: Страуструп говорит, что чуть не ежедневно узнаёт что-то новое о своём языке.

Go надежен. Здесь невозможно столкнуться с типичными проблемами C/C++.

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

Ну так способов выстрелить себе в ногу всегда хватало.

Какой-то у Вас алфавит странный: O идет раньше L.

Пожалуйста, проследуйте вот сюда http://habrahabr.ru/post/136283/ и нам результаты сообщите.

Результат: руки надо отрывать писунам неоднозначного кода. Я знаю _подмножество_ Си, которое мне надо и там для меня нет подобных сюрпризов.

не обязательно

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

Почитал по диагонали - волшебный язык!

Слив защитан. Мы пишем так, что даже не встречаем undefined behaviour. Такого даже Торвальдс не говорил, кажется.

В него даже libc влинкована статически? Закопайте это немедленно.

Где там была тема про вред динамического связывания?

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

«2 строчки» там никакая оптимизация не даст так как есть 3 действия: создать объект, инициализировать поле объекта, присвоить значение глобальному указателю.

исключив локальную переменную...

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

P.S. В Go нет аналога volatile и сам он не может такое отследить? Если так, то странно звучит фраза о поддержке многопоточности.

надо было мне уточнить

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

А вот приведи пример, где без всяких там прагм и опций компилятора присваивание значения указателю будет проведено частично.

:) Лучше не полагаться на атомарность int-ов и указателей, если не хочешь потом ловить баги на ровном месте. В принципе, код типа

volatile int terminated=0;

void run()
{
  while( terminated!=0 )
  {
    /* делать что-то */
  }
}

void terminate()
{
  terminated=-1;
}

где terminated меняется всегда одинаково с «0» на «не 0» вполне допустим без всяких примитивов синхронизации.

Если хотят выделить new

Не new, а автоматическое приписывание типа и объявление новой переменной. Не нравится, пиши «var t = new(T)».

А вот приведи пример, где без всяких там прагм и опций компилятора присваивание значения указателю будет проведено частично.

не вижу смысла - стандарт этого не гарантирует, мы ведь про С говорили, а не про x86 + gcc

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

Ну так уточни сейчас, при какой «нужный порядок» выполнения, который позволяет не падать при отсутствии явной синхронизации, ты там говорил

порядок там обычный - это был ответ A-234, который решил, что Go меняет порядок команд, а не падать позволяет не порядок, а сам Go, который безопасно работает с указателями

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

P.S. В Go нет аналога volatile и сам он не может такое отследить? Если так, то странно звучит фраза о поддержке многопоточности.

Просто предположение почему может не работать. В принципе, если убрать t, то получаем примерно вот такое вот http://en.wikipedia.org/wiki/Double_checked_locking_pattern

Какая-то полуэкспериментальная и возможно небезопасная оптимизация вполне может убрать локальную t и сразу полезть в глобальную переменную.

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

Ну так в стандарте и многопоточности нет.

Ну так в стандарте и многопоточности нет.

man C11

решил, что Go меняет порядок команд

т.е. Go не меняет порядок команд? Тогда почему в том коде при g!=nil g.msg может быть неинициализировано?

Присваивание значения указателю не атомарная операция?

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

Дай ссылку на текст стандарта. Может там и про атомарность присваивания есть?

Этим кто-нибудь пользуется, кроме хипсторов?

Только хипстеры типа меня и пользуют.

Спасибо ymn'ому человеку за позитивную новость! Ж8-]

т.е. Go не меняет порядок команд? Тогда почему в том коде при g!=nil g.msg может быть неинициализировано?

потому-что указатель Go != указатель С, если не считать специальный unsafe.Pointer

оптимизация вполне может убрать локальную t и сразу полезть в глобальную переменную.

И что она таким образом оптимизирует? Ну ни как не время выполнения.

рада сообщить о выходе...

Ура! Радостное ненужно!

проектированием занимались Роб Пайк и Кен Томпсон...

Я думал, они уж померли давно! Это же «те самые», что юникс смастырили, да?

lazy evaluation и присваивание в одном участке кода? ССЗБ.

Т. е. если в Go я присваиваю указателю значение, то автоматиески создается новый объект и инициализируется полями того, на который указывает присваиваемое значение. Семантики указателей вообще нет что ли?

Go предельно прост и лаконичен, осваивается за несколько недель. C++ икспертам: Страуструп говорит, что чуть не ежедневно узнаёт что-то новое о своём языке.

C++ на то и рассчитан, чтобы можно было строить сложные вещи поверх существующих компиляторов, а не добавлять прямо в мейнстримный компилятор, делать анонс и лишь потом ждать пару лет, пока это доделают в остальных реализациях (если они вообще есть). Так что это фича.

Go надежен. Здесь невозможно столкнуться с типичными проблемами C/C++.

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

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

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

Здесь есть интерфейсы, и использовать их очень удобно.

Думали удивить кого-то утиной типизацией? Да, она хороша, но не более того.

Д(М)ур(д)ак

Go надежен. Здесь невозможно столкнуться с типичными проблемами C/C++.

Не понимаю этой женской логики.... Давайте слегка перефразируем:
«Йогурт более полезен, ведь в нём же не стоит ложка как в сметане!». *фэйс WTF*

От того, что в Си есть куча _обходимых_проблем_, Игого никак не становится от этого безопаснее! Указатели - это только часть проблем Си. В профессиональном коде вы возможно вообще никогда не увидите «null pointer exception»! Зато алгоритмических и многопоточных проблем - море и Го их никуда не спрячет.