Опубликован (http://blog.golang.org/2012/03/go-version-1-is-released.html) первый релиз языка программирования Go (http://golang.org/), который ознаменовал стабилизацию спецификаций и набора библиотек. Go 1 является первым выпуском, доступным в форме бинарных пакетов для Linux, Mac OS X, FreeBSD, Windows и других поддерживаемых платформ. Язык Go создан в компании Google, распространяется под лицензией BSD и поддерживает компиляцию для архитектур AMD64, x86, x64 и ARM.С одной стороны, в новом релизе нет какого-то существенного редизайна языка или глобальных новшеств, но с другой, наконец-то исправлены некоторые старые ошибки, исправление которых ранее откладывалось по причине создания несовместимости с первоначальной спецификацией. Выпущена специальная утилита go fix (http://golang.org/cmd/go/#Run_go_tool_fix_on_packages), которая максимально автоматизирует приведение старых исходных кодов к текущему стандарту языка Go 1. В целом, в текущем релизе разработчики сосредоточились на оптимизации и очистке кода, повышении его универсальности и переносимости, сведя модификации самого языка к минимуму.
В качестве примеров изменений (http://golang.org/doc/go1.html) можно назвать появление типа rune для Unicode-символов (http://golang.org/doc/go1.html#rune), добавление типа error (http://golang.org/doc/go1.html#errors) и модуля os.Error для обработки ошибок, создание типа time для задания времени (http://golang.org/doc/go1.html#time) и незначительных переименований в strconv (http://golang.org/doc/go1.html#strconv). Кроме этого проведена огромная работа по полной переработке и улучшению сервисной программы go (http://golang.org/doc/go1.html#cmd_go). Самое заметное новшество которой в том, что теперь можно отказаться от файлов Makefile и сборочных скриптов, вся необходимая информация теперь будет извлекаться непосредственно из самых исходников программы. Одновременно выпущен новый Google App Engine SDK (https://developers.google.com/appengine/docs/go), который полностью доработан с учетом новых возможностей Go 1, и предназначен для создания приложений для App Engine.
Напомним (http://www.opennet.me/opennews/art.shtml?num=24209), синтаксис языка Go сильно похож на язык Си с стилистическими примесями из Python. Это компилирующий императивный язык, поддерживающий структурное программирование. Google утверждает, что разработка нового языка оправдана тем, что сложность C++ приводит к большому количеству ошибок при создании больших приложений, поэтому Go - это попытка создать, с одной стороны - более наглядный и гибкий язык, и с другой, - изначально спроектировать его дизайн с учетом актуальных тенденций и специфики современного аппаратного обеспечения (например, оптимальная работа на многоядерных системах).
Основные особенности языка:- Высокая безопасность и стабильность языка, включая полную поддержку type-safe (http://en.wikipedia.org/wiki/Type_safety) и memory-safe (http://en.wikipedia.org/wiki/Memory_safety);
- Язык изначально спроектирован для многопроцессорных систем, с встроенной поддержкой (на уровне операторов) параллельных операций и межпроцессорных взаимодействий;
- Высокая эффективность и читаемость, лаконичность языка;
- Высокая скорость работы, практически аналогичная языку Си.
Отдельно отметим, что язык Go (http://en.wikipedia.org/wiki/Go_%28programming_language... не стоит путать с языком Go! (http://en.wikipedia.org/wiki/Go!_%28programming_languag... являющегося своеобразным клоном языка Prolog, разработчики которого ранее даже пытались оспорить это название у Google, но пока безрезультатно.URL: http://googledevelopers.blogspot.com/2012/03/go-project-reac...
Новость: http://www.opennet.me/opennews/art.shtml?num=33476
Что это за архитектура такая - x64, и чем она отличается от amd64?
Может быть нативная х64, а не та, в которой long mode?
x64 и amd64 - одно и то же. Компания AMD называет технологию "AMD64" (маркетинг), Intel использовать имя конкурента в рекламе по понятным причинам не хочет. Там ещё десяток названий: x86-64, Intel64, ..
Я имел в виду Intel Itanium и ему подобные несуществующие
Itanium - это IA64
amd64 содержит указание компании, поэтому не рекомендована. По той же причине вместо Intel 8086 писали x86. Да и просто запись "x64" короче :)
Перечитайте первый параграф
>...архитектур AMD64, x86, x64 и ARM.Повторяю вопрос Анонима: что такое х64 и чем оно отличается от амд64
«ты что, Скрипач, дальтоник? зелёный от оранжевого отличить не можешь?!»
А серьёзно? Если х64 == амд64, зачем 2 раза писать? А IA64 уж никак х64 не назовёшь. Так что, пожалуйста, объясните, что есть зелёное и что оранжевое.
эх. ну совсем молодёжь цитаты не понимает. я же уже ответил. все дальтоники, что ли?
> эх. ну совсем молодёжь цитаты не понимает.Ну и откуда эта цитата, старичок? Рекомендую перед ответом самостоятельно проверить ее точность, а то выглядит как смесь из двух разных источников с искажением смысла.
>> эх. ну совсем молодёжь цитаты не понимает.
> Ну и откуда эта цитата, старичок?бан на гугле, да?
> amd64 содержит указание компании, поэтому не рекомендована. По той же причине вместо
> Intel 8086 писали x86. Да и просто запись "x64" короче :)Полная чушь.
1. х86 - это сокращение для (8086+80286+80386+80586 и тд), а не для "Интел 8086".
2. х64 - такой архитектуры не существует. Сложно посмотреть хотя бы википедию? Интел называет "свою" 64-битную архитектуру IA64, а экс-АМД64 - Intel64. А вариации на тему "запись короче" - можно понимать так: "пись" (т.е. видимо половой член длиной 64мм...) такая, что короче некуда =)
Мне кажется имелась ввиду поддержка Windows x64
Адресацией памяти
Go, Google, Go!эту фразу можно оспаривать в суде до бесконечности...
зы: гуглофанатом не являюсь...
Я, вот, думаю: придумывают новые языки, придумывают... А если бы хоть один (желательно не самый убогий) из них не только выдавал на выходе работающие на всех основных ОС (хотябы Windows, Linux и MacOS X) модули, но и шёл в комплекте с хорошей формо-ориентированной средой разработки (по типу VisualStudio WinForms, VisualBasic, Delphi) - это был бы хит! Под Linux такого очень не хватает.
"Не убогий язык" и "формо-ориентированная среда разработки" - вещи несовместные.
Не хотите учить язык - рыбку съесть не получится.
> Не хотите учить язык - рыбку съесть не получится.Причём здесь это? Что мешает знать язык и при этом удобно окошки рисовать и кнопочки тыкать вместо того, чтобы руками расписывать это всё?
то, что потом на этом же языке придётся софт писать. причём не так, как привыкли формодавы: вся логика в обработчике кнопок, достаточно два раза щёлкнуть.впрочем, формодавы умудряются с Qt то же самое проворачивать.
Это Вы про себя, наверно? Некоторые действительно всю логику в "обработчики кнопок" пихают. Вообще удобно иметь такую возможность (иногда надо быстренько написать простенькую программу "на коленке" под конкретную задачу). А обычно, когда пишут серьёзный проект, в том же VisualStudio, логику таки в отдельные классы и даже в отдельные библиотеки выносят обычно, а "обработчики кнопок" общаются только с наивысшим уровнем абстракций.Сейчас я пришёл к тому, чтобы логику делать в виде web-сервисов или CLI-программ на Scala, а фронтенды в виде WinForms (WPF и изучить пока руки не дошли, и вообще он только под виндой запускается, а это "не айс") приложений в VisualStudio, т.к. удобнее инструмента нет. Но напрягает зависимость от Винды для разработки. Думаю дальше на JavaFX 2.0 или ExtJS для фронтэндов переходить.
Раньше, живя под Windows и используя для всего C#, начинал проект так: 1. Создаю пустой solution, 2. добавляю проект типа class library для логики, 3. добавляю проект WinForms для фронтенда. При этом всё, что можно разбивается на потоки, абстрагируется и выносится в class library, а "обработчики кнопок" все буквально на пару (если не на одну) строк.
Среда, имеющая визуальный редактор форм, не обязательно является формо-ориентированной.
Формо-ориентированная среда самой своей ориентированностью провоцирует говнокод, неизбежно.
> Под Linux такого очень не хватает.кому не хватает? формолепилам-кнопкокидателям? нененене, оставайтесь там, где обитаете. а то вы как тараканы: раз в углу заведётесь — придётся весь дом потом чистить.
>> Под Linux такого очень не хватает.
> кому не хватает? формолепилам-кнопкокидателям? нененене, оставайтесь там, где обитаете.
> а то вы как тараканы: раз в углу заведётесь — придётся
> весь дом потом чистить.Вы обитаете только в консольке и считете иксы позором и предательством Великой Консольной Строки? Или наоборот признаете только web-интерфейсы?
два раза не угадал.(чёртов пробел)
Java/Eclipce
Ближе всего к этому подобралась Delphi. Компиляция для MacOS уже есть, обещают добавить Linux в следующей версии.
Есть Lazarus. Типа почти кроссплатформенный.
>Ближе всего к этому подобралась Delphi.http://ru.wikipedia.org/wiki/Free_Pascal
http://ru.wikipedia.org/wiki/Lazarus>Компиляция для MacOS уже есть, обещают добавить Linux в следующей версии.
Ну вот для компиляции под MacOS там и используется Free Pascal Compiler (причем довольно старая версия)
http://decoding.narod.ru/practic/MacOS_and_iOS/MacOS_and_iOS...
В каком году обещали-то? Помнится, я в далёком 2004-м рассматривал их поделие под названием Киликс - убогое и устаревшее на пару версий qt уже в момент выпуска. Впрочем, это была эпоха великого падения Делфи, возможно сейчас у них Ренессанс, благо другая контора прикупила?
Есть QTCreator
Кнопочку-на-формочку-таскатели C++ ниасиливают.
> Кнопочку-на-формочку-таскатели C++ ниасиливают.MFC, Builder негодуэ
>> Кнопочку-на-формочку-таскатели C++ ниасиливают.
> MFC, Builder негодуэВоистину так. Ни разу в жизни на дельфях не кодил, а вот под MFC ещё во времена Windows NT 4.0, а потом в C++ Builder... Единственный недостаток C++ - гимор с управлением памятью, кучу времени экономишь если себе этим на таком уровне голову не забивать.
это, может, потому, что тебе забыли рассказать про «автоматические» переменные и «умные» указатели? не то, чтобы эти костыли были идеальны, но проблему с управлением памятью вполне решают.
Тут сначала надо рассказывать про то, что С++ - язык для ООП.
Простое заворачивание в классы всех близких сущностей уменьшает большую часть хлопот по управлению памятью до написания грамотных конструкторов и деструкторов, да еще использования shared_ptr и наработок, уже давно включенных в STL.
> Тут сначала надо рассказывать про то, что С++ — язык для ООП.хорошая шутка, бро!
Отличный язык.
Haters gonna hate.
"Отдельно отметим, что язык Go не стоит путать с языком Go!, являющегося своеобразным клоном языка Prolog, разработчики которого ранее даже пытались оспорить это название у Google, но пока безрезультатно."Мелькнуло "настоящее" лицо гугла с политикой некрософта: бабло побеждает. Так, ребята, как будем гугл побеждать?
>Так, ребята, как будем гугл побеждать?А зачем? Потом появится новая компания. которую хомячки окрестят "корпорацией добра", будет вытеснять гугл. потом и её будут вытеснять. И за хомячковым протестом все эти компании будут работать на благо США,а толпы фанатов будут штурмовать ветряные мельницы.
> как будем гугл побеждать?Так-же как и микрософт побеждали. Отвернемся, закроем глаза и будем говорить что его не существует, а если и существует, то, наверное, оно гораздо хуже чем то что есть у нас.
> как будем гугл побеждать?предлагаю начать с уборки в квартире. пропылесосить хотя бы, одежду постирать. а то как-то непрезентабельно личный состав выглядит.
Ждём переписывания Java VM на Go. Хотя без политической воли Oracle такого никогда не будет.
От она моя любимая рыба! Наконец-то зарелизили.
Толку с этого языка? С- шные библиотеки подключаются только помощью такой то матери и работают через раз. И вместо libcurl - http://golang.org/pkg/net/http/ блевотный велосипед. Вместо zlib - блевотный велосипед. Вместо openSSl - ну вы поняли.
При этом этот "высоко скоростной, компилируемый язык" в два раза(!) медленнее интерпретируемого javascript в node.js
https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/di...
Я тоже ждал от языка чего то большего, УГ с куцой стандартной библиотекой, и по скорости выполнения сливает C++ в разы.Еще это тупая статическая компиляция где проги хэлловорд по 2 мегабайта.
нечего сравнивать первые реализации молодого языка с годамы оптимизированными мамонтами. Нужно время.
А что Ruby помогла его 15 летняя история? А питону? А яве?
Давайте взглянем правде в глаза, рожденный ползать летать не может.
Каким макаром динамические интерпретируемые языки должны были обогнать компилируемые статические? И при чем тут Go?
Причем тут обогнать? Выше все написано читайте внимательнее.
Если коротко то - горбатого могила исправит.
>Причем тут обогнать?При том что Python, Ruby и т.д. не могут быть быстрыми по определению. При чем тут они когда мы обсуждаем компилируемый статический язык?
>Выше все написано читайте внимательнее.Выше не написано ничего внятного. Сишные библиотеки работают идеально, CGO в помощь.
Претензии к написанию реализации стандартной либы на го - просто смешны.
>Каким макаром динамические интерпретируемые языки должны были обогнать компилируемые статические? И при чем тут Go?Ну, скала
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
и лисп
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
этот Го как то ухитряются обгонять.
И где там динамичность (Scala) и интерпретируемость?
Читать умеем? (хотя вопрос глупый)
Умеем, умеем. Прямой ответ давай.
А если умеем то ответ сверху написан, читайте внимательнее.
Я тупой, объясни мне пожалуйста.
1. Что мешает увеличить производительносто Go.
2. Зачем на вопрос
>Каким макаром динамические интерпретируемые языки должны были обогнать компилируемые статические?давать бенчмарки на Scala и CL?
3. Какой смысл приводить в пример улучшения производительности за 15 лет Python и Ruby, скорость которых ограничена их типом исполнения и типизацией.
Руби изначально был гогном из перл-клонов и с этим ничего особого не сделать.питон за 15-20 лет проделал большой путь развития и на текущий день наиболее вменяемый из всех высокоуровневых скриптовых языков общего назначения. Но ещё не всё хорошо с его реализациями.
Ява аналогично руби, колека от начального дизайна. С ООП головного мозга ничего сделать нельзя.
Особенно здесь уместен последний пример и ещё с++. Оба языка широко используются сегодня и оба полное гогно. Т.е. сейчас уже есть осознание у специалистов недостатков принятых подходов в дизайне этих ЯП. От этого и появляются различные Go, D и т.п. В этой нише всё ещё нет нормального ЯП.
сказочный долбоёб.
> нечего сравнивать первые реализации молодого языка с годамы оптимизированными мамонтами.
> Нужно время.не нужно релизить непонятно что, вот и всё. дотянули бы уровень сначала. но — релиз. поэтому мы будем считать, что авторы удовлетворены качеством, и сравнивать безо всяких скидок на молодость.
Наверно, поторопились с пиаром. Начал парить про инновационную разработку - будь добр в ближайшее время предоставить работающий прототип со всеми анонсированными преимуществами. Маркетинг прошел, а реализации не последовало - постепенно про него забыли. Малоизвестных языков существует тьма тьмущая, среди которых есть языки и поинтереснее этого Go, и даже у них проблемы с популярностью
Гугль использует его в продакшене на Youtube.
Вот дураки, да?
Они релизили не за производительность, а за (ограниченную) гарантию обратной совместимости. Т.е. как только они решили, что язык снаружи стабилизировался, то объявили, что на него можно ставить. А внутреннюю реализацию библиотек можно допиливать и дальше.И, кстати, бенчмарки именно релиза Go 1?
Уровень такого ЯП невозможно дотянуть одной конторе за обозримые сроки. Т.е. если избрать такую стратегию, то к моменту дотягивания он уже не будет нужен. Ещё раз поппытаюсь донести эмпирическое правило жизни - дотягивание современных ЯП занимает много лет, или даже десятки лет. На данном этапе нужно привлечь к ЯП аудиторию и сделать дотягивание делом многих заинтересованных лиц.
>https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/di...Там уже разобрались:
>Besides the other comments made, one should note that even _bash_ is
>faster than Go.. try this snippet, for instance:
>
> $ nginx
То есть ничего подобного nginx на Go мы никогда не увидим? И зачем он тогда нужен?
Чтобы интернет-нытики имели что делать.
>То есть ничего подобного nginx на Go мы никогда не увидим?Моё мнение, что в ближайший год - нет. Вообще тут больше надежда на Go из GCC.
>И зачем он тогда нужен?
Да, тут не поспоришь. ЯП нужны, чтобы аналог nginx реализовать, других задач нет.
> Толку с этого языка? С- шные библиотеки подключаются только помощью такой то
> матери и работают через раз. И вместо libcurl - http://golang.org/pkg/net/http/ блевотный
> велосипед. Вместо zlib - блевотный велосипед. Вместо openSSl - ну вы
> поняли.
> При этом этот "высоко скоростной, компилируемый язык" в два раза(!) медленнее интерпретируемого
> javascript в node.js
> https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/di...Отличная ссылка. Но по ней нужно читать до конца.
Во первых не в 2 раза. Они одинаковые по скорости. Во вторых, конечно
там нет никакого яваскрипта. Тупо гоняют оптимизированный сишный вебсервер
против вебсервера go из стандартной библиотеки.
Совсем другая картинка получается: напильник на си,
против стандартной либы из языка с гарбадж коллектором. Совсем не дурно для гоу.
Ты хоть читал свое "доказательство".
По ссылке которую ты дал есть опровержение.
Нет.
если чо node.js тоже то еще уг, это всего-навсего круто распиаренный асинхронный однопоточный фреймворк, на который хомячки молятся как на бога кукурузы
да тестирование скорости на хеловорлде это тестирование скорости хеловорлда. не более того
> если чо node.js тоже то еще угкакие ваши доказательства? Однопоточность - не проблема, когда есть многопроцессность и вменяемый ipc из коробки. Какие ещё недостатки? Да и, кстати, приведите вменяемые аналоги, сравнимые c v8 по скорости выполнения
Синтаксис мне не понравился - то, как раставлять скобочки, где какой символ использовать := и = и прочие "мелочи", которые убивают каждый отдельно.
+1
и правда, не понятно зачем в константах и var "=", а в цикле ":=".
":=" - присваивание с выведением типов, "=" - просто присваивание.
Все просто и понятно если хоть немного почитать.
понятнее даже без чтения документации это "for var i = 0", в отличии от дурной "for i := 0".
>стилистическими примесями из Pythonэто их самая большая ошибка
Маскот языка как бы намекает...
Заверните мне пожалуйста 2 шт. Пойдёт как удобрение в огород.
Мдя
03.04.2012 14:36:17 файл: http://go.googlecode.com/files/go.go1.windows-386.msi//go.ca... обнаружено: троянская программа 'Backdoor.Win32.Agent.chhf'