Релиз Go 1.1

101 йарутины!

мб не стоит таких людей подпускать к программированию

Вы только что предложили уволить ~90% программистов. А новых где взять?

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

Зависть — плохое чувство.

Идея в целом неплоха,

чем??

фцытатнег! особенно хорошо про quasimoto

ЛОР развивается по спирали, но на каждом витке всё хиреет и хиреет :(

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

Ах да на сраной жабке даже этот ресурс написан. А ты продолжай дрочить на безконсистентную х*ню в гуглопространстве.

И зачем это всё тогда? Я понимаю, когда синтаксический сахар делают для читабельности или чтобы меньше набирать, но просто так, из любви к Паскалю?

не всем надо/не все могут осилить плюсы, даже С не все осиливают, более того - не везде С и С++ вообще надо, а Go - простой, но довольно мощный ЯП, свое применение найдет

Вот ровно тоже самое говорят фанаты Python и Java, а между тем программы написанные на этих языках тормозят и пожирают процессорные ресурсы.

+ 1Мб к бинарнику нынче никто и не заметит

Для C++ вынесли из libstdc++ функции для обработки exceptions в отдельную либу libgcc_sjlj, что позволило выиграть около 400 KB тем кто не использует в коде обработку исключений.

Как же тогда блокировки работают?

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

Чем связка C++/Python не устраивает?

Поделил на ноль. Python тормозное, прожорливое убожество. Надо быть совсем упоротым что бы использовать в связке с C++ этот ужас.

Прочитал это и понял, что мне напоминает go. Visual Basic. Такое же нагромождение нелогичных конструкций.

или ТОРМОЗЯТ, или ТОРМОЗЯТ, или ТОРМОЗЯТ

И программист может выбрать одно из трёх либо ничего. Но не в го.

И в сях он тоже в кавычках. Ну или в скобках, да.

Ну или в скобках, да.

Что-то типа map[int]map[string][]byte ? Или недостаточно смешно?

Нет.

Ну так не используй их

Мы про качество языка. Я го пользовать не буду точно. Потому что там ровно ничего _хорошего_ нет. Если придется пользоваться заменителем С++ - пока выигрывает rust.

Простой и понятный синтаксис.

Главное для такой мегафичи было язык создавать. Бенжамин Пирс и люди изобретающие разные effect systems и higher kinded types рвут на себе волосы. Одерский готовиться кончить житзнь самоубийством - ему надо было не HKT заниматься а очередной вариант присваивания изобрести.

func do() (int, error) {

во первых работать не будет потому что x, y, z вне скоупа - для этого эти инициализаторы и изобрели. Во вторых - спосибо поржал.

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

Пользователи?

Впрочем, range ещё и каналы умеет, так что если очень хочется, можно изобразить что-то подобное:

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

Rust решает другие задачи, не стоит его сравнивать с Go.

Ровно те же самые. CSP, замена крестов. Только он его более адекватно заменяет - хотя там тоже не все что хотелось бы есть, но в го нету абсолютно ничего.

Я бы не был так категоричен. Когда перечитываешь темы за ~2000 год (+-4), там та же самая концентрация толковых и бестолковых персонажей. Только сейчас язык немножко уже поправился, а в тех тредах слишком много «фдисятке» и «ржунимагу».

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

Ну да return x сильно сложнее return.

В rust со скобками в if обошлись точно так же, и это правильно.

У меня претензии не к убиранию скобок, а к тому что в го ничего практически кроме убирания скобок нет. В русте мешок фич, и скобки там вообще значения не имеют есть они или нет. А в го из всех «фичь» сплошные бессмысленные манипуляции синтаксисом.

<По поводу> всей этой истерики насчет «Go» и какой он замечательный бла-бла-бла <Эти идеи> пропагандировались группой Оберон в ETH и всеми пользователями Оберона еще в 90-х гг. За немногими исключениями, заведомо недостаточно большими, чтобы фундаментально изменить язык, Go — это ТО ЖЕ САМОЕ, что и Оберон-2. Почему люди не могут просто перейти на Оберон — и просто жить с ним? Я скажу почему — потому что он был спроектирован Никлаусом Виртом. Он — антихрист, исчадие ада. Никто не любит его — и вы тоже не должны. Он коммунист, фашист и капиталистическая свинья одновременно. И — только подумайте! — в его языках ключевые слова пишутся заглавными буквами! О УЖАС!

<Его никто не должен любить> Кроме, разумеется, тех, кто хочет подзаработать на идеях Вирта, сохраняя при этом уродский, в высшей степени чреватый ошибками, умственно отсталый синтаксис С/С++. В этом пункте я не чувствую ни малейшего уважения к Пайку и Томпсону — они просто плагиаторы и на самом деле ИСПОРТИЛИ язык. И сделали его невероятно неудобочитаемым и трудноподдерживаемым в сравнении <с Обероном>.

Им должно быть стыдно.

Меня уже просто тошнит от всего этого сверхоппортунизма и политиканства в сфере ИТ. Больше всего меня раздражает то, что когда появляется замечательная технология, она сначала охаивается со всех сторон, а потом какой-нибудь болван со словами «Bell Labs» в своем резюме выдает ТОТ ЖЕ САМЫЙ ЯЗЫК под другим синтаксическим соусом и с несколькими бубенцами и колокольчиками (которые легко можно было бы вставить в Оберон-2, если бы они кому-то понадобились), — и каким-то непостижимым образом он зарабатывает восторги толпы.

ГО$#!+.

Сейчас в моде специальные возвратные значения (го, скала).

Только в отличии от скалы в go эквивалент do-notation не напишешь. Даже в чертовом эрланге можно. А в go эти возвраты error только до if - вот именно как в Си.

В Go есть какой-то аналог (defer, кажется).

Он очень кривой. В finally есть локальная область этого try finally. Область defer вся функция. Вон я уже спросил выше что сделать если мне надо выполнить что-то после какого либо defer - мне предложили лямбду туда замкнуть - то есть по сути написать вверху то что навернется где-то внизу, да еще применить arcane art если вдруг мне понадобятся какие-то вычисленные ниже значения.

Ну нихрена себе бомбануло.

Жизненный цикл любой новости о ЯП на ЛОРе.

В последнее время стал появляться анонимус который на 4-5 странице занимается предсказаниями на тему скатывания темы про языки в аппликативные функторы.

А биореактор из жабосрачей перешел к провоцированию нацполов. Взрослеет.

если мне надо выполнить что-то после какого либо defer - мне предложили лямбду туда замкнуть

Ну и что? В Rust вообще везде сплошные лямбды с замыканиями и даже Rust-аналог try/catch сделан на замыканиях.

Ну если setjmp/longjmp, то, например, возможностью выйти из всех функций ^_^ С exceptions конечно покрасивее получается и понадежнее, зато в плане реализации очень просто - быстрый возврат к нужной точке стека (или состоянию стека).

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

Профит от сигналов менее очевиден, это обычные асинхронные callbacks, которые могут возникнуть в каких-то случаях. Потенциал, имхо, недостаточно реализован. Иногда удобнее, сигналы, чем постоянно проверять - а сейчас случайно не сработал ли таймер и не появилось ли сообщение какое-то? Имхо, сигналы могли бы быть удобным вариантом обработки сообщений (т.е. не ждать сообытия/сообщения где-то в цикле, а просто приостановить все и обработать полученное сообщение). С точки зрения линейности выполнения программы и понимания кода сигналы проигрывают, но не более чем, например, асинхронное копирование файла, или обработчики прерываний в контроллерах.

Ну и что?

Суть в том что область видимости вся функция. То есть defer f.Close() сработает только при завершении скоупа. Я не могу например фигурально выражаясь

f = open_read
try
X = f.read
finally
f.close

modify(X)

f = open_write
try
f.write(x)
finaly
f.close

потмоу что defer первого не закроет до завершения функции. Следовательно если я хочу подобный код - все опять к закатыванию солнца вручную. «Так же придетс ядействовать в любых подобніх обстоятельствах» (C)...

То есть как я уже говорил - благодаря подобным решениям go прямо напрашивается на свой вариант boost который будет кривокосо компенсировать недостатки языка.

Да, забыл еще... Можно попробовать сделать SEH на системные ошибки, но это достаточно убого получается. С другой стороны, в unix это кажется единственный вариант сделать так, чтобы при сегфолте программа не просто тихо упала с одним сообщением в stdout/stderr, а попыталась максимально корректно завершить работу или откатится к предыдущему рабочему состоянию или отправить дамп/стектрейс разработчику.

Я не могу например фигурально выражаясь

Ну, это ерунда. Если уж очень надо, можно решить кладжем.

Ну, это ерунда.

А по моему совсем не ерунда если нельзя контролировать скоуп различных закрываемых ресурсов типа файлов/соединений/запросов в бд. Особенно это критично в бд будет когда insert/update после select будет конкурировать с этим же select чуть ранее не отпуская его до завершения функции.

Да и вообще - посмотри код работы с бд из их же примеров:

age := 27
rows, err := db.Query("SELECT name FROM users WHERE age=?", age)
if err != nil {
    log.Fatal(err)
}
for rows.Next() {
    var name string
    if err := rows.Scan(&name); err != nil {
        log.Fatal(err)
    }
    fmt.Printf("%s is %d\n", name, age)
}
if err := rows.Err(); err != nil {
    log.Fatal(err)
}

Даже на эрланге аналог будет приблизительно таким:

 Age = 27,
 do([error_m || 
      Rows <- db:query(db, "SELECT name FROM users WHERE age=?", Age),
     db:foreach(fun({Name}) -> io:format("~s is ~d\n", [Name, Age]) end, Rows)
 ])

без всего этого бойлерплейта.

Особенно мне нравится что я тут совсем не вижу почему оно прерывает execution. Черная магия log.Fatal?

Fatal is equivalent to Print() followed by a call to os.Exit(1).

пацтулом!!!!

Пацаны просто канонический пример antiPOLA.

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

Fatal is equivalent to Print() followed by a call to os.Exit(1).

Простенько и со вкусом.

Простенько и со вкусом.

Я не против такой семантики per se - пусть бы оно было os.exit(msg, status). Но когда log.Fatal (я надеялся что это логирование с уровне fatal) - делает os.exit.....

«Как завершить программу? Залогируй фаталную ошибку....»

Наркоманы...

тут остается вспомнить только логлевел в андроиде

log.wtf(«go-lang»)....// what a terrible failure...

Пока ты здесь. Как думаешь, какое будущее у Scala? Стоит ли смотреть в ее сторону?

Ну сколько можно этот тупняк повторять?! Не разрабатывала компания Google язык Go! Его разработали несколько сотрудников компании Google, используя часть рабочего времени, отведенную в компании для личных проектов сотрудников. Сама компания к этому языку отношения не имеет.

Для C++ вынесли из libstdc++ функции для обработки exceptions в отдельную либу libgcc_sjlj

в моем дистрибутиве (убунта 13.10) - нет такой библиотеки

Пока Chrome не перепишут на Go, не нужно.

в го нету абсолютно ничего

Пожалуй, это его главное преимущество.

Я понимаю, когда синтаксический сахар делают для читабельности или чтобы меньше набирать

Именно для читабельности и чтобы меньше набирать. a := 1 эквивалентно var a = 1

Я го пользовать не буду точно.

Это обнадёживает.

… люди изобретающие разные … и … рвут на себе волосы. … кончить житзнь самоубийством …

Ну зачем же? Пусть изобретают на здоровье. А мы пока код писать будем.

во первых работать не будет потому что x, y, z вне скоупа - для этого эти инициализаторы и изобрели. Во вторых - спосибо поржал.

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

Пользователи?

Пользователи библиотеки, читатели кода, ты сам через n дней.

«А потом пользователи сидят и думаю как это обход дерева пошел через CSP...»

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

Я правильно понял, что выполнение setup вообще не гарантируется?

Эти идеи (если ты про конкурентность) появились ещё в языках squeak и newsqueak, в восьмидесятых годах, ещё раньше этого вашего оберона. Затем были развиты в языке alef, использовавшимся в раннем Plan 9, затем алеф заменили на си с libthread, затем появился в 95-х язык limbo, на котором была написана Inferno OS.
Почему ты об этих языках ничего не слышал? Ну, как минимум потому, что Bell Labs не умеет в маркетинг. А вот гугл умеет, и поэтому го стал известным.
Анонимусу следовало бы хоть немного знать историю.

Fatal — губительный, пагубный, смертельный, летальный, смертоносный, вызывающий смерть

Ты бы хоть в словари заглядывал что-ли.

Теперь понятно, проблема не в auto а в моем недопонимании оператора ":=" в Go. Похожая техника применялась в Бейсике когда любая неизвестная переменная автоматически получала некоторый тип при ее инициализауии (забыл уже какие они там были). И еще раз, auto - обобщенный тип, := - оператор. Вы ведь можете написать на плюсах:

vector<some_very_complicated_type> v[1];
static auto x = v[0];

Сомневаюсь, что := (почти неотличимое от =) читается лучше чем var, и что набирать на 2-3 символа меньше - это реально праздник отдыха для пальцев. Вот foreach(list) вместо vector<type>::const_iterator.... - это да, удобно. А 2 символа - бред какой-то ради бреда.

Он соврал. «a := 1» аналогично «var a int = 1». А если вместо int какая-то сложная конструкция?

И ещё к слову

type MyInteger int

Конструкция type примерно аналогична typedef, только int и MyInteger будут разными типами, которые придётся явно приводить друг к другу.

Остуди уже свою попку, крестофаг. Не осиливаешь синтаксис так и не берись. Сходи лучше стандартную библиотечку перепиши, она же не соответствует твоим задачам.

std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >

Как думаешь, какое будущее у Scala? Стоит ли смотреть в ее сторону?

Стоит. Она сейчас уже очень неплохо, - мне за прошлый год только прямых предложений о работе пришло штук 15, есть проекты даже в крупных офшорках типа люксофта. Весь жабий энтерпрайз доступен - только без нервов. Если есть собственный контроль над проектом - можно мягко внедрять например в жабий проект без скрипа и пыли. Ну и много всего интересного там есть и для мозга и для квалификции - вроде HKT в языке который можно в энтерпрайзе применять с места в карьер.

Ну как же, a := 1 - это Short variable declaration, которое

shorthand for a regular variable declaration with initializer expressions but no types