Пользователь
0,0
рейтинг
29 марта 2012 в 15:55

Разработка → Google выпустила финальную версию языка программирования Go 1

Вчера стало известно о том, что поисковый гигант выпустил финальную версию языка программирования Go 1, анонс о котором появился в 2009 году. Загрузить бинарные дистрибутивы языка для Linux, FreeBSD, Mac OS и Windows можно здесь. Язык выпущен под лицензией BSD.

Язык Go1, согласно команде его разработки, представляет из себя «попытку объединить скорость разработки динамических языков, таких как Python, с производительностью и безопасностью компилируемых языков, таких как C или C++» Справедливости ради, один из инженеров Google, занимающихся новым языком, признаёт, что экосистема языка ещё развита недостаточно — отсутствует IDE и набор поставляемых библиотек не очень большой, но, тем не менее, компания активно работает над улучшением ситуации.


Go 1 содержит компиляторы для x86 и для 64-битных платформ, также имеется Gccgo, основанный на GNU GCC.

Сакраментальный «Hello, world!» на Go 1 выглядит следующим образом:
package main

import "fmt"

func main() {
	fmt.Println("Hello, Habr!")
}


Пример немного сложнее — вычисление ряда чисел Фибоначчи.

 package main


func fib() func() int {
	a, b := 0, 1
	return func() int {
		a, b = b, a+b
		return a
	}
}

func main() {
	f := fib()
	println(f(), f(), f(), f(), f())
}


[Источник]
Евгений @jeston
карма
80,2
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (143)

  • НЛО прилетело и опубликовало эту надпись здесь
    • –9
      Да, только у тебя
    • +5
      Напрасно минусуете человека, это распространённый вопрос. По ссылочке можно почитать зачем.
    • +2
      А мне больше интересно почему?

      if a < b { f() }             // Valid
      if (a < b) { f() }           // Valid 
      if (a < b) f()               // INVALID
      for i = 0; i < 10; i++ {}    // Valid
      for (i = 0; i < 10; i++) {}  // INVALID
      
      if x {
      }
      else {    // INVALID
      }
      
      • 0
        А еще больше интересно, почему никто не читает документацию?
        • 0
          Я лично читал документацию.

          Go does not require parentheses around the condition of an if statement, or the expressions of a for statement, or the value of a switch statement.

          if (a < b) {}                      // VALID
          for (i = 0; i < 10; i++) {}  // INVALID
          


          Ели вас не затруднит, поясните.
          • 0
            скобки относятся к выражениям, (a < b) — валидное выражение, а (i = 0; i < 10; i++) — нет
            • –2
              Так все что внутри скобок инструкции for тоже выражение!
              Нигде в документации не сказано, что это относится только к логическим выражениям.
              • 0
                да? быть может это «выражение» еще и может вернуть какое-то значение?
                • –2
                  Фактически такой вид цикла называется «цикл с предусловием», который может быть представлен в такой нотации:

                  i = 0;
                  
                  while (++i < 10) {
                     //...
                  }
                  


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

                  Мне просто не понятно почему во всех языках с которыми я работал для всех управляющих инструкция принята единая форма записи, в отличии от Go.

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

  • +2
    А что по скорости? Первые версии джаве в разборе регулярок проигрывали по скорости. А в этой исправили?
    • 0
      Судя по бенчмаркам Go двухнедельной давности, не исправили:

      shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java
    • +11
      При использовании GCCGO вместо 6g/8g быстродействие вырастает значительно. Но помимо быстродействия, следует учитывать и такие параметры как «потребление» RAM и CPU. В сферическом вакууме (с неограниченными памятью и процессорной мощностью) этим можно пренебречь, но на практике (в моём случае — HiLoad web apps) требования к RAM/CPU становятся критичными.

      Проще говоря, для сохранении равной скорости ответа при «тяжёлой бомбардировке» запросами, реализация на Go требует в 4 раза меньше железа чем Java. И почти в 20 раз меньше «любимого всеми» PHP. Фактически, реальная производительность (учитывая бутылочные горлышки, от которых никуда не деться) приближается к реализации на C/C++.

      Это, кстати, можно считать ответом на вопрос «зачем». Зачем нести издержки на 4-20 серверов там, где можно обойтись одним? А уж при оплате ресурсов по факту (на том же AWS) издержки снижаются ещё сильнее.

      Скажу больше: примерно для 7 задач из 10 — Go-фронтенд (включающий в себя и само приложение) справляется с HiLoad успешнее чем Nginx.

      NB: все доводы вы легко можете проверить самостоятельно с помощью ab/siege.
      • 0
        А зачем тогда нужны 6g/8g? Если с GCCGO все быстрее, то пилили бы его? В чем там подводные камни?
        • 0
          6g/8g быстрее работают, т.е. компилируют очень быстро, что позволяет легче использовать TDD к примеру.
          • 0
            Хм, а почему такая огромная разница получается www.opennet.ru/opennews/art.shtml?num=30784 — я как понимаю в тестах использовался 6g/8g, почему не провели тесты с использованием GCCGO?
  • +1
    >исполняемый код полностью переносим
    Это как?
    • 0
      Может речь все-таки про исходный код?
      • +1
        Ну в .net — исполняемый псевдокод на IL «полностью» переносим, если скажем создавать проект на .net 2.0, то в Linux'е на Mono — всё работает без перекомпиляции.

        P.S. Пытался в общих словах обрисовать, как пример, т.к. ситуация очень далека от идеальной.
        • +1
          нет и джава требуют виртуальной машины, которая псевдокод и исполняет. В Go такого нет, поэтому о переносимости бинарников можно позабыть.
    • +1
      Скажем так, я не очень разобрал, что говорится на видео, которое есть на сайте-источнике. Поэтому это спорное место уберу, но ваш вопрос вполне понятен — спасибо.
  • +2
    Что-то я не заметил ориентированности на ясность кода…
    На мой взгляд, главная WOW-фишка Python — визуальное форматирование (формирование блоков отступами). Раньше люди заинтересовывались питоном именно глядя на эту фишку.
    Вот второй пример какой-то невыразительный, имхо.
    Оговорюсь, что обращаю внимание только на синтаксис. Ибо о всем остальном говорить пока рано.
    • 0
      WOW-фишка пайтона заключается в том, что форматирование кода не просто рекомендуется, но сделано обязательным. Но никто не мешает адаптировать PEP для любого языка, применяя самостоятельно и по доброй воле красивое форматирование.

      Более того, «причесать» код написанный на языке Go легко можно простым инструментом gofmt, прилагающимся в комплекте :)
  • +21
    Вот эта строка:
    func fib() func() int {

    выглядит нечитаемой
    • –10
      функция fib() возвращает функцию которая возвращает int, рекурсия по нашему, что тут непонятно?
      • +15
        Это — не рекурсия, это — замыкание.
        • +3
          Замыкание, это когда функция захватывает контекст в котором используется… а это просто функция возвращающая функцию.
          • +7
            А переменные a и b, это что, не контекст?
          • +3
            Замыкание, это когда функция захватывает контекст в котором используется… а это просто функция возвращающая функцию.

            Это называется "Функция высшего порядка"
            • +5
              Понадобилось 6 коментариев, чтобы понять что означате эта строчка.
              Здорово :3
        • +9
          Да, прошу прощения, действительно замыкание.
      • –1
        Причем тут рекурсия? Это замыкание.
      • +1
        func fib() func() func() func() func() func() int {

        }

        А так можно будет делать?
        • 0
          Не знаю, потому как тело функции то одно, сразу после int, не ясно где тело других функций.
        • +4
          Можно: play.golang.org/p/KN4E1RotKl
          Но я очень прошу так не делать :)
          • +3
            О.О Вот и первые звоночки возможности наклепать говнокода при наличии кривых ручек и нежелания думать.
            • +2
              такая возможность есть в любом языке :)
              можно еще переменные и функции называть a, b, c, a1, b2, cc, anotherA, тоже язык виноват наверно
              • +1
                Я имел ввиду не программный говнокод а эстетический. Мне по сути не так важно что возвращает пятая по вложенности функция, мне главное знать что первый вызов вернет функцию. Дальше я уже определюсь сам. Мне кажется такой шаг был бы более удобным в плане описания функций которые с лямбдами работают.
                • 0
                  Не понял разницы между программным говнокодом и эстетическим.
                  Приведите пример правильного на Ваш взгляд «описания функций которые с лямбдами работают».
                  • 0
                    Непривычно:
                    func fib() func() func() func() func() func() int {

                    }

                    Привычно:
                    func fib func() {

                    }

                    Я это имел ввиду.
                    • +5
                      Я понял, Вам не важно, что возвращает функция, которую возвращает функция fib.
                      Так вот, добро пожаловать в извечный холивар: языки со строгой статической типизацией против языков с динамической типизацией.
    • +1
      А на каком языке аналог выглядит более читаемо? :)
      Имхо, читается легко слево-направо: функция fib() возвращающая функцию возвращающую int.
      • –3
        JS:
        func fib(){...} — очень читаемо

        PHP:
        func fib(){...} — очень читаемо

        Python:
        def fib(): — очень читаемо

        … Дальше лезть не буду, человек имел ввиду огранизацию вовзращаемых значений, это странно и непривычно как минимум.
        • +5
          Ни один из приведенных Вами языков не является строго-типизированным, описанные функции могут возвращать что угодно. Так что такие примеры не подходят. А вот пример на C: int (*fib())()
          Ну и что лучше читается? :)
          • –3
            Ну функция возвращает определенный тип — функцию, зачем мне дальше описывать?
          • 0
            Objective-C

            метод
            — (type) funcname: (type) arg{};

            клозура
            type (^blockname)(type) = ^(type arg) {};

            обычные функции там, понятное дело, сишные
      • +3
        На Haskell.
      • 0
        В популярных ФЯПах тип вообще описывать не надо, он сам выведется.
        • 0
          Да, погорячился я. Конечно подобные вещи в функциональных языках выражаются гораздо красивее, проще и роднее. Сравнивать Go имеет смысл только с другими императивными языками со строгой статической типизацией.
          • 0
            На самом деле мне даже C#'овое
            Func fib() {… }
            кажется более читаемым.
            • 0
              Парсер — лох
              Func<int> fib() {… }
            • +1
              Func Fib() {… } Уже не так красиво. Хотя лично мне тоже больше нравится. Но эта красота появилась далеко не в первой версии C#.
              • 0
                я тоже попался парсеру :)
            • 0
              На С++:
              std::function<int()> fib() { /* ... */ }
              
      • +1
        например нечто похожее на хаскеле будет выглядеть как
        fib :: [Int]
        fib = 0:1:zipWith (+) fib (drop 1 fib)

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

        Ну, или что-то более типизированное
        data Stream a = Stream a (Stream a)
        fib :: Stream Int
        fib = createStream 0 1
        • +1
          тьфу, рано отправилось. Вот оставшийся кусок

          where createStream a b = Stream a $ createStream b (a+b)

          Такая композиция будет уже ближе по смыслу.
          + такая форма записи легче воспринимается из-за разделение записи типа с записью внутренности
  • –1
    Думаю, теперь можно и попробовать.
    • –5
      сейчас можно начинать учить) а через годик уже и пробывать… сейчас все еще нестабильно
    • +1
      попробовать можно уже прямо в боевых условиях — на google app engine.
  • +1
    > a, b = b, a+b
    а почему не
    a, b := b, a+b
    • 0
      С двоеточием это объявление, а без двоеточия — присваивание?
      • +1
        Поглядел — оказывается, := — это присваивание с автоматическим выведением типов.
        • 0
          О, спасибо! Теперь стало понятнее и даже как будто логичнее.
        • 0
          Синтаксический сахар :)
          Очень удобно.
          • +1
            автовыведение типов — это, по моему, немножко больше, чем сахар)
            • +23
              Синтаксический торт
      • 0
        Полагаю, вопрос был как раз о том, зачем объявление и присваивание по-разному оформлять.
        По крайней мере, меня этот вопрос тоже заинтересовал.
      • 0
        Да, почти. С двоеточие это как в C# было бы var a = 1, или в C++11 auto a = 1. То есть это объявление переменной a c типом, который выводится из присваиваемого значения.
        В Go все построено на том, чтобы наиболее популярные конструкции имели сокращенные варианты. Это авторы и называют «простотой» языка.
        • 0
          Я так и подумал. Спасибо.
        • +1
          Странно, как они не дошли до $? etc.

          сарказм…
    • –2
      В смысле почему?
      Потому что приравнивание. Если бы была проверка равенства, было бы ==.
  • 0
    Установка и тут же первые грабли сменил путь который был по умолчанию.
    Пока только покрутить и посмотреть. Без хоть какой-то ide дальше сложно.
    • 0
      go-ide.com/
      Еще когда-то вроде упоминалась какая-то IDE на самом сайте языка, я ее даже ставил, но сейчас что-то не находится…
      • 0
        Не. Эта хочет Явы.

        Ниже привели уже ссылку на LiteIDE
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Попробуйте GoLangIDE — отличная IDE для Go 1. Поддерживает сборку проектов через go tool.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Почему? Имеется:
          Подсветка синтаксиса.
          Поддержка проектов.
          Поддержка debuger'а.
          Быстрый поиск по документации.
          Аналог Intellisense (требуется установка gocode).
          Не хватает только средств для рефакторинга, но IDE молодая, язык тоже, рано им еще :)
          • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • +7
      Да. Со статической типизацией.
  • 0
    Какое совпадение!
    Только вчера распечатал Learning Go

    Стало удобно. На сайте теперь лежат бинарники под MacOs, в том числе, и вместо:

    $ 6g hello.go
    $ 6l hello.6


    теперь достаточно сказать:

    $ go build hello.go

    Однако вчерашний скомпилированный hello занимал 1,072,890 bytes,
    в то время как сегодняшний 1,105,936 bytes

    Интересно, на что пошли эти 33 килобайта :)
    • +10
      На эти три процента они и живут :)
  • +1
    Хотелось бы немного дополнить пост:
    • +7
      Извиняюсь, clrl+enter сыграл со мной злую шутку
      Примечаниях к выпуску — все значительные изменения с момента последнего релиза (r60), а также объясняется, как обновить свой код до Go 1.
      Более подробно о совместимости программ, написанных под Go 1, с будущими версиями Go написано в документе «Совместимость Go 1».
      Инструкция по сборке Go 1 из исходного кода.

      Для меня самым заметным изменением относительно релиза r60 стало появление консольной команды go — это утилита для получения, сборки и установки сторонних Go пакетов и команд. С появлением этой утилиты, Makefile’ы уходят в прошлое. Эта команда работает по принципу convention over configuration, если структура проекта соответствует требованиям go tool, то Makefile для сборки не нужен. Все необходимые условия для сборки проекта go tool получит из исходного кода, определит отсутствующие сторонние пакеты, скачает и установит их. Описание go tool заслуживает отдельной заметки, которую я постараюсь написать в ближайшее время. В официальной документации есть замечательная статья “Как писать Go код”, в которой есть примеры работы с командой go. Всем проектам на Go разработчики рекомендуют перейти от использования Makefile к использованию go tool.
      • +2
        Ваш комментарий более важный и интересный, чем пост (да простит меня топикстертер).
        Про команду go тоже кратко отметил выше в комментариях.

        Может быть Go заслуживает уже своего собственного хаба?!
        • 0
          Спасибо :)
          На счет собственного хаба — я только за :) Только быстрый поиск по habrahabr.ru/info/help/hubs/ не дает ответ на вопрос, как же такой хаб создать.
          • +1
            Мне тоже не понятно, сам задавался подобным вопросом.
            Может быть организовать опрос о нужности такого хаба, а потом результаты отправить администрации(?)

            Может быть сюда прийдет какой-нибудь старожил и расскажет, как это сделать правильно.
          • 0
      • 0
        О! Отказ от makefile`ов + меньшее количество кода, да это просто прорыв для системного языка. Им осталось только производительность пофиксить и перейти к разработке инструментария.
        • +2
          Повторюсь, но с производительностью всё очень хорошо. Особенно если использовать GCCGO вместо родного инструментария. Если не заглядываться на сферические тесты, то в реальности Go лишь немного проигрывает C/C++.
          • 0
            Я бы сказал, что производительность Go вполне достаточная. То есть если мы пилим серверное приложение из разряда получить/отдать на обработку/вернуть результат, то врядли мы упрёмся в процессор. Однако синтетические тесты показывают, что математические вычисления/кодирование/архивация вполне могут быть в 3 раза медленнее.

            Впрочем, я имел ввиду пофиксить тормознутость регулярок, не больше.
          • 0
            Судя по shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=csharp пока даже C#+Mono лучше по производительности.
            • 0
              зато по памяти рвет :)
              • 0
                Это только когда она не используется. В binary-trees наоборот в 6 раз проигрыш почему-то.
                • +1
                  Из 11 тестов только в двух проигрывает по памяти. В остальных 9ти тестах выигрывает в 2 — 7 раз.
                  А вообще, во-первых это все синтетические тесты, которые всей картины не раскрывают, а во-вторых язык еще молодой, оптимизациями еще никто особо не занимался. То, что он компилируемый, не использует виртуальной машины, промежуточного байт-кода, в перспективе должно позволить обогнать C#, Java и динамические языки. C и C++ и т.п. обогнать ему не удастся никогда.
                  • 0
                    Во-первых, не такой уж и молодой — уже 2.5 года. Во-вторых, Go изначально создавался оптимизированным, в том числе и по архитектуре. Некоторые «грустные результаты» синтетических тестов связаны с тем, что код написан не для Go, а простой калькой, не учитывающей специфику языка, особенно многопоточность.

                    Обогнать C/C++ цели перед создателями и не стояло, но максимально приблизить производительность удалось. Как я уже ранее говорил, учитывая узкие места аппаратного обеспечения системы, быстродействие в реальных задачах уже можно сравнивать именно с C/C++.

                    Важно учитывать философию Go — приближаясь по простоте к Python (дающей высокую скорость разработки и практически незаметную по времени фазу компиляции), приближать производительность к C/C++. И в этой сфере язык оказывается вне конкуренции.
        • 0
          Тесты на производительность очень субъективны.
          Вот у bolk отличный пост на эту тему Google Go vs. Си. Так там Java проигрывает сильно. Но, повторюсь, все синтетические тесты не очень показательны.

          Go привлекателен низким порогом вхождения (любой знакомый c С и Python его освоит), шикарнейшей многозадачностью и ориентированностью (в перспективе) на web (сейчас это AppEngine, дальше будет больше — уверен).
          • +1
            Поправка. Go изначально неплохо ориентирован на web. Вот, например, два хорошо себя зарекомендовавших фреймворка:

            github.com/garyburd/twister (вдохновлённый Tornado/Python)
            github.com/hoisie/web.go (вдохновлённый Webpy/Python)

            Есть замечательные либы для MongoDB, CouchDB, Redis, Cassandra, SQLite, Mysql. Отличные движки темплетов (помимо встроенного). Что ещё нужно для полного счастья?
            • +1
              Ух, спасибо! Свеженькие.
              Еще бы все это хозяйство с uWSGI подружить — цены бы не было.
              • +2
                Никого не хочу обидеть, но uWSGI (равно как и FCGI, SCGI) — это по сути костыли, помогающие бегать в первую очередь интерпретируемым языкам. Web-приложения на Go достаточно стабильны и быстры (особенно если использовать одну из важнейших фишек языка — многопоточность), что даёт возможность их использовать в качестве самостоятельного фронтенда. Хотя, Nginx прикрывающий 3-4 Go-бэкэнда всё же надёжнее.
                • +2
                  Согласен, конечно же. Всё время забываю, что Go — компилируемый и приравниваю его к Питону.

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

                  И отдельное спасибо за все комментарии, которые вы оставили в этом топике. Жаль у вас нет постов по Go для web, но надеюсь с появлением у Go своего хаба, вы восполните эту нишу.
  • 0
    Я не совсем ещё безнадежный формалист, но предлагаю автору поста в качестве ссылки «Источника» поставить: blog.golang.org/2012/03/go-version-1-is-released.html,
    а не просто на офф. сайт языка
  • 0
    После некоторого детального ознакомления с языком впечатления двойственные:
    1) С одной стороны челюсть падает. Впечатляет простота и удобство, хотя бы testing с его Example* и Benchmark* чего стоит. Прям млин на уровне языка!!! Круто!
    2) Писать все-таки придется много. К примеру в Hash-ах нет SHA-{128|256|512} и ряда других алгоритмов.

    Вывод: пока подожду как будет развиваться ) Но на заметку взял, т.к. достаточно элегантен и прост)
    • +2
      Упс. не заметил часть нужных мне хэшей вынесли в crypto
  • +1
    А кто-нибудь может сравнить с D? По простоте/продуманности синтаксиса, по наличию библиотек и т.д.?
    • +2
      D тоже очень интересный язык. Но по простоте однозначно выигрывает Go. По моим субъективным ощущениям — D в 10 раз сложнее чем Go.
      Зато в D плюшек гораздо больше. Наверно тоже раз в 10 :)
      Стандартная библиотека у Go существенно больше, чем у D.
      Лично мне больше Go по душе.
      • 0
        оффтоп.

        C, D,… Надо было вовремя договориться и стандартизировать названия языков.
        P == PHP, R == Ruby, J == Java.
        :)
        • 0
          R уже есть, математический.
          J и так за Java всегда. Все библиотеки, так или иначе имеют J: JGraph, ICU4J…
          • +1
            Имя J уже занято. Кстати, довольно необычный язык…
  • –1
    Наконец-то под винду сделали версию
    • –2
      Что значит «наконец-то»?
      Для релиза r.60.3 уже c октября существует
  • –2
    package main

    import "fmt"

    func main() {
    fmt.Printf("hello, world\n")
    }


    В скомпилированном виде(#go build <hello.go file>) в MacOs весит 1,1 Мб
    Я как минимум удивился.
    • 0
      Линковка-то статическая
    • +4
      golang.org/doc/go_faq.html

      Why is my trivial program such a large binary?

      The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces.

      A simple C «hello, world» program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.2 MB, but that includes more powerful run-time support.
      • 0
        Стоит отметить что Rob Pike противник dynamic linking. Помнится читал его опус почему dynamic linking это плохо.
  • –2
    Трижды попытался проникнуться Go… но так и не смог побороть в себе неприятие синтаксиса. Наверное придется ждать нечто CoffeeScript для JavaScript. Идея отличная, местами просто отличная идеология(нет классов, только struct'ы, функции как first-class citizens, closures), но я не очень понимаю, как она могла излиться в таком синтаксисе в 2010 году.
    Я не против скобочек, но я за читабельность и интуитивность.
    • +2
      «Вы не поверите» (с) Люди до сих пор пишут на C и C++ и даже на Objective-C (который сейчас стремительно набирает популярность). И там нет сборщика мусора, куча скобочек, define'ы и header'ы. И все это в 2012 году.
      Мне руби тоже очень нравится, но каждому языку своя ниша.
      Более того, Go не заменит C и C++ никогда, потому что из-за сборщика мусора, он не пригоден для realtime-critical задач. Например для realtime обработки звука. Вот D мог бы. Но он не пошел, к сожалению.
      • +3
        Вы не поверите, но я в курсе :)
        Почему ObjC набирает популярность, думаю и Вы и я четко понимаем. Но это совсем не ориентир для создания нового языка, верно? Т.е. если Вы создаете платформу, которая интересна разработчикам, то можно использовать и Java, как сделали в Google. Популярность + пугающая простота + железобетонность языка позволили Android стать реальной альтернативой.
        Но я видимо уже too old for all this shit, хочу получать удовольствие от разработки. Выбрал я Python для себя в своё время. Я точно знаю, что если мне нужна будет «скорость»(целебную ценность которой, имхо, переоценивают в наших странах(СНГ)), я знаю, что смогу написать на Cython или чистом C необходимые вещи, чтобы уйти от bottleneck'ов. Пусть это будет pain in the ass, но это будет ограниченный кусок задачи, сделанный на С с чётким пониманием «зачем».
        Всякие специальные задачи типа realtime это специальные задачи, к которым подход _всегда_ будет специальный, если Go ориентировался на эти вещи, он проиграл бы ещё до выхода на ринг, имхо.
        Чтобы стать распространённым языком сейчас, нужно быть языком, в который можно влюбиться. В ObjC влюбляются, т.к. платформа великолепна, т.к. можно заработать деньги, т.к. нет многих убожеств C++. Python/Ruby/CS любят просто за то, какие они есть, красивые, быстрые в разработке, лаконичные и понятные. Что есть в Go такого, чтобы в него могли влюбиться — пока неясно. Goroutines хорошо, но это как «красивые коленки» у девушки, оно вроде как бы плюс, но явно условие недостаточное :)
        • 0
          Вам в журналы писать обзоры — харизматичный стиль (без шуток).

          Но всё же язык — удобный (для определенных целей), легкий для освоения и перспективный (учитывая, какая компания за ним стоит). А насчет «влюбиться» — язык это инструмент, и не более того, он может быть удобным или нет.
          Влюбиться можно в результат того, что сделано (хорошим) удобным инструментом.

          А синтаксис/«красивые коленки» — это больше вкусовщина.
          • 0
            Вот уж никогда не подумал, что годен что-то писать, спасибо :)

            Вот и я про то, что язык «для своих целей», для своей аудитории. По сравнению с С, это прыжок вперёд, как минимум. Если бы писал на с\с++ — перешёл бы на go без особых раздумий. Но увы, это сейчас нишевые языки, и именно на это и нужно напирать в первую очередь. Тут нет ничего страшного, бороться с другими general-purpose languages очень сложно, именно поэтому нужны такие фишки, которые будут «цеплять» разработчиков. Чтобы они не просто приходя на базар, выбирали этот молоток(как инструмент) не потому, что на нём красивый лейбл Google, а потому, что он реально подходит для их особых нужд и условий труда.
            Проблема в том, что все замахиваются сразу на мировое господство, Google иначе просто уже разучился метить, в этом проблема. Поиск их был лучшим не с первых дней своего существования, он стал лучшим как следствие хорошей идеологической базы + сотен итераций. Говорить, что «большая компания — большая дорога всем начинаниям» не очень верно, иначе бы все давно уже писали на C# под win или Java под *.
            • 0
              Говорить, что «большая компания — большая дорога всем начинаниям» не очень верно
              Согласен, не очень удачно выразился.

              Я имел ввиду, что психологически выгодней смотрится язык, который «выбрала» в production большая (прогрессивная) компания. Как с Python в свое время: язык был наравне с тем же Ruby, но Гугл рассказал, что использует в своих проектах Пайтон (gmail, если не изменяет память), включил его в AppEngine, дал бесплатно открыть аккаунты и размещать на них веб-приложения и качнулась чаша весов в сторону Python. Не только из-за этого, конечно, масса факторов, и за «красивые коленки» тоже, выражаясь вашим языком.

              Вот и я про то, что язык «для своих целей», для своей аудитории. По сравнению с С, это прыжок вперёд, как минимум
              Именно. Но уместней сравнить с Java для веб. Go уже предпочтительней смотрится, хотя бы потому, что требует меньше железа. Быстрая компиляция, отличная многозадачность.
              А на универсальность он и не претендует, и первенство так и не завоюет. Тоже ниша, тоже свою задачи. И это плюс, а не минус.
              Инструмент должен быть узко специализирован, универсальность чаще всего во вред.
              • 0
                Психологически — да. Но где сейчас GAE, кстати? :)
                Я, в свое время, выбрал Python чисто путем приобщения. По неделе питона и руби.

                Ну значит мы в нишевости сходимся, не вижу смысла дальше растекаться :)
                Есть плюсы, есть минусы. Равно как и у эрланга, в сравнению с тем же node.js :)
        • +1
          По поводу Python + buttleneck'и на C — я согласен полностью.
          Фишка Go — goroutines и channels. Что позволяет проще писать сложные асинхронные вещи.
          Судя по поведению Google — Go пиарить они не собираются. Он вряд ли будет массовым и популярным, но свою нишу займет и у него уже много поклонников.
          Также фишкой Go считается быстрая компиляция — это реальный плюс, понятный только тем, кто сталкивался с компиляцией крупных C++ проектов. Это позволяет работать по Agile принципу, постоянно внося мелкие изменения и постоянно прогоняя Unit-тесты.
          По поводу преждевременной оптимизации я тоже согласен. Но есть такие задачи, где сразу понятно, что нагрузки будут большие и писать на Python смысла нет. Сразу на C писать? Вот для таких задач Go и подойдет. Писать приятнее, производительность приближена к C. Пример: blog.golang.org/2011/12/from-zero-to-go-launching-on-google.html
          В блоге есть еще примеры успешного применения Go на практике.
          Я не считаю Go языком своей мечты, не все в нем мне нравится (мой родной язык — C#). Но в целом из прямых конкурентов: C, C++, ObjC, D — он мне нравится больше других.
          Ну а вообще, я наверно не очень объективен, Go мне еще и просто «нравится», что самому себе объяснить иногда не просто :)
          • 0
            Я и говорю, что нишевость это то, на что нужно делать упор. Не надо стремиться быть языком, который «люб всем», коим в свое время был С. В нем нет ничего реально «прорывного», что было в С, в свое время. Это скорее просто современный вариант С.

            Быстрая компиляция — да, это хорошо. Но если учесть, что сейчас 4 ядра это уже норма, на девелоперских машинах… когда подойдёт время, чтобы Go пошёл в массы, это не будет уже значительным плюсом, определяющим фактором при выборе языка для нового проекта, согласитесь? :)

            Производительность… Если говорить о серверсайде. Можно просто подбить бюджет, который понадобится на высоконагруженный проект(реально таких не так уж и много, но вдруг) и в нем внимательно посмотреть на цифры ЗП разработчикам(в городе 1м+) и расходы на железки, то станет ясно, что бюджеты могут быть вполне сравнимыми. Но только вот я, будучи начальником-бывшим-технарем, ну никогда бы не дал добро на «переписать все на Эрланге или Го», просто потому, что я знаю ТОЧНО, что в случае чего, я не смогу найти замену члену небольшой команды, которая разрабатывает продукт. Я даже скорее предпочту Java, если вся команда имеет с ней наибольший опыт(при всей моей нелюбви к этому языку, которому я отдал около 7 лет своей жизни), чем дам экспериментировать на минном поле ради выигрыша в несколько сотен баксов.
            Эта моя позиция сейчас сильно отличается от 3-5летней давности, когда я был «молод и горяч», но сейчас я вполне осознаю, что прагматизм должен быть при выборе технологии. И тут аргументы типа «просто нравится» заказчику могут не понравиться ;)
            • 0
              только вот я, будучи начальником-бывшим-технарем, ну никогда бы не дал добро на «переписать все на Эрланге или Го», просто потому, что я знаю ТОЧНО, что в случае чего, я не смогу найти замену члену небольшой команды, которая разрабатывает продукт.
              Это понятная позиция, но от этого не становится веселее. Именно в силу такого подхода LiveJournal исаользует Perl, а Facebook — PHP. И те, и другие покупают, и покупают «железо» — потому что дешевле купить серверов, чем поменять платформу.
              А Твиттер взял и выбрал «инструмент» сообразно назначению. Но да, квалифицированных программистов им находить и содержать сильно дороже. Ну и что? Просто разный подход.
              • 0
                LJ доживает последние дни(или уже дожил?) — нет смысла менять платформу, они не борятся с ростом в сотни процентов в год. Для Твиттера это был вопрос выживания.
                FB решили вопрос создав свой Hiphop для PHP и вроде как довольны, проблемы с железом решили.
            • +2
              Именно будучи начальником-бывшим-технарём, я дал зелёный свет Go ещё два года назад. Тут как в старом мультике — «лучше день потерять, потом за пять минут долетать». Увеличивая издержки на этапе разработки (хотя, увеличенные они оказываются лишь на первых двух-трёх разработках*, после чего язык столь обволакивает, что писать на Go становится проще, чем на Python) мы радикально снижаем постоянные издержки. И именно это становится решающим конкурентным преимуществом — себестоимость наших решений оказывается в десятки раз ниже, что позволяет откровенно демпировать цены на рынке (b2b) и тихой сапой выжимать из него игроков, предпочитающих «старый добрый PHP».

              * — Одна из моих любимых цитат гласит: «Скорость копипаста одинакова для всех языков программирования». Фактически, задачи прикладного программиста (не путаем с системным) сводятся к паре десятков операций, которые легко копипастить в виде сниппетов с небольшими правками. Собственно говоря, на этом принципе (DRY) основывается распространённость фреймворков.
              • 0
                А разве DRY и копипаст не антонимы?
                • 0
                  Как посмотреть. В более широком смысле принцип «не повторяй себя» позволяет избегать повторного написания одинакового кода. А уж реализация (процедуры, классы, библиотеки, фреймворки или обычный копипаст сниппетов) — дело вкуса. Например, я не люблю фреймворки, предпочитая выдёргивать из них исключительно нужные мне куски и интегрировать со своим кодом. Это несколько олдскульный подход, но зато на выходе не получается чего-либо монстроузного в стиле Microsoft-way :)
              • 0
                Вам повезло с командой, все что я могу сказать :)
                Ну и Вы также уже в позиции «впрягшегося», я пока смотрю с позиции «есть новый проект, есть старая команда — почему я должен выбрать Go?»

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

                Про копипаст и фреймворки я тоже недопонял, как и Mrrl.
                Спрошу про другое — сколько сторонних библиотек используете? Именно гошных, не на С\С++ или всё берёте из того мира? :) А может сами всё сервисное «пишете», склеивая сниппеты со стаковерфлоу? :)
                • +1
                  Начну с себестоимости. Наша работа заключается не только в создании корпоративных приложений, но и в их размещении и поддержке. Полный цикл, так сказать. С расчётом на долгосрочное, чуть ли не вечное сотрудничество. Таким образом, постоянные издержки (инфраструктура) становятся важнее разовых (разработка).

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

                  Так что расходы на команду не превышают обычных расходов в аналогичной компании использующей Python/Ruby/Java/PHP.

                  А вот постоянные расходы на вычислительные мощности и их обслуживание снижаются более чем значительно.

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

                  Можно даже вполне развить конспирологическую теорию на тему того, зачем Google создал такой язык с блестящими характеристиками как простоты разработки, так и производительности. Например, чтобы постепенно загрести под себя размещение всех сайтов, предоставляя конечному пользователю простой интерфейс CMS для создания магазинов, журналов и прочих стандартных сайтов, доля которых стремится к 99% от всех имеющихся в сети. Такой ход конём позволил бы им как сократить издержки на индексацию (всё же на своих «жёстких дисках» индексировать и искать куда быстрее, чем на сервере забитого виртуального хостера где-нибудь в Улан-Баторе), так и получить новые огромные объёмы пользовательских данных, столь нужных для построения гибких рекламных кампаний. Но это уж я отвлёкся, извините :)

                  Что касается библиотек, то мне более чем достаточно стандартного комплекта поставки. Честно говоря мне было достаточно стандартных библиотек и в Python, поскольку любое заимствование сторонних библиотек снижает уровень безопасности и повышает зависимость от их разработчиков.
              • 0
                Вы действительно пишете для Go веб-интерфейсы для b2b? Мне это очень интересно, у вас есть свой фреймворк для веб?
                • 0
                  Не рискну назвать это фреймворком. Скорее документированный (для служебного использования) конструктор. Если вы посмотрите на стандартные библитеки Go, то поймете сами — там и без фреймворков всё достаточно просто. Единственные сторонние библиотеки которые мы для себя форкнули — связки с MongoDB, CouchDB и Redis.
                  • 0
                    Расскажите, а что вы используете для Redis? Все клиенты, которые я смотрел поддерживают лишь часть функциональности и выглядят заброшено
          • 0
            Кстати, если выбирать из перечисленных языков — однозначно Go, мы просто в разных областях с Вами болтаемся, но выбор в этой _нише_ действительно очевиден, в плане чисто эстетических предпочтений — полностью солидарен! :)
  • –4
    Решил попробовать… Скачал и поставил… Скопировал HelloWorld… Запустил… Скомпилировал. Всё ок. Всё работает… Переписал под свой стиль (переставил открывающую скобку на новую строку — не переношу египетские скобки) — не работает! Он работает только с египетскими скобками!!! Удалил. Буду дальше любить C++…
  • +1
    Чертовски перспективный язык. Детские болезни пока есть, но эти проблемы с производительностью вполне решаемы. Отличная замена для С, когда требуется производительность, приближенная к максимальной — отставание в 2-5 раз вполне терпимо, всяко лучше чем 50-80 раз у PHP/Ruby/Python/Perl. Причем с возрастом отставание сведется до десятков процентов, а на некоторых задачах, решаемых на С/C++ через костыли — у Go ещё и выигрыш будет (я про SMP).

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

    Расстраивает, что исключили из спецификаций ексепшны. Некоторые программисты жить без них не могут, да и по производительности не так уж сильно бьют. Исключили скорее всего из-за предполагаемой ориентированости языка на системное программирование, но все равно жаль, концепция то полезная.
    • 0
      Своеобразная вариаця на тему еxceptions все-таки присутствует в Go, у неё правда другое название — panic. По сути это те же exceptions, только добавленные с другой целью. «Паника» в Go это не средство сообщение об класической ошибке, для этого возвращают два значения, где второе имеет тип error, а средство сказать что все пропало, Game Over, и упасть с стек трейсом. «Панику» можно словить и обработать как класический exception с помощью defer и recover, но это желательно использовать только когда без этого не обойтись (например для того чтобы безопасно закрыть удаленны ресурс.)
  • +1
    Кстати, постоянно забываю упомянуть об одной интересной фишке Go. Сей язык настолько юникодовый, что на родном языке можно называть и переменные и функции. Не назову это особенно мудрой практикой, но иногда удобно в дев-версии писать код вроде:

    go разобрать(фигня)
    <-ФигняРазобрана
    • 0
      Ого, этот Го :) Прямо 1С какой-то.
  • 0
    Лично мне кажется, что у стихийного CoffeeScript (не смотря на то, что это JavaScript, тем более, что последний набирает обороты на фронтэнде) уже больше шансов на нормальную жизнь и развитие. Имхо: Go away!

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