Опубликован (http://netsago.org/ru/docs/1/16/) перевод одной из частей официальной документации по языку Go (http://golang.org/) от компании Google. Данный документ будет полезен опытным программистам, пишущим на языке C++, что, при желании, сделает их переход на новый язык гораздо менее болезненным.URL: http://netsago.org/ru/docs/1/16/
Новость: http://www.opennet.me/opennews/art.shtml?num=28106
напоминает городок-игроги в Го играют в Но...
Посмотрел обзор... НЕ НРАВИТСЯ
Желаю успехов тем кто пытается создавать языки вразрез с предпочтениями большинства и мнением большинства, а нам с ними не попути. Это надо ж... var x int!...
безнадежно отравлен C/C++?
Да это то нормально. Напоминает Паскаль даже немного :) Ностальгия ))) Даже понравилось.. Но дочитав до этого:
Go трактует конец не пустой линии, как точку с запятой.И увидев пример.... дальше уже и смотреть не хочется ) Никогда не понимал записей типа:
> записей типа:рр... ну вообщем что там в примере )
Да не, с этим как раз проблем нет - нормальный код на C++ именно так на строки и разбивается.
нахрен он нужен этот Go?
коротко говоря, чтобыбыл
1. Делаем свой фреймворк на нормальном языке.
2. Заворачиваем его в компилятор нового языка. Тем самым:
2.1. теряем совместимость с кем бы то ни было;
2.2. но избавляемся от недостатков "веревки достаточной длины...";
2.3. снижаем порог вхождения;
2.4. имеем возможность портирования кода на новые платформы посредством портирования компилятора.
3. Рекламируем новый язык, надеясь, что повторится история с РНР.
4. Если повезет - имеем армию крепостных разработчиков, которым без открытого компилятора деваться некуда.Примерно так, полагаю. Разве что не хватает пункта 0: "Становимся компанией №1 в Интернете" ;)
Забыли:
5.??????
6. PROFIT
Нет, это вы забыли, что здесь не Луркоморье.
Нажимание кнопок ради копирования мемов - это бессмысленное, ничем не оправданное увеличение энтропии цифровой вселенной.
Спасибо. Наконец-то кто-то это сказал.
> 3. Рекламируем новый язык, надеясь, что повторится история с РНР.Не повторится. PHP повезло оказаться в нужном месте в нужное время - когда новая ниша (web-программирование) еще только зарождалась, и была острая потребность. И это обусловило распространенность, несмотря на полную говнстость как языка (и даже превозносимая простота уже не там - посмотрте, как они выкинутые фичи перла обратно втягивают).
А какая новая ниша у Go?
Как только не извращаются, лищь бы писать на Лиспе
> Как только не извращаются, лищь бы писать на ЛиспеЛисп стал читабельным языком? Зачем все в скобках писать, чтобы их потом считать?
Когда разрабатывая задачу пишу алгоритм на человеческом языке, то это далеко от Лиспа и ближе всего к Паскалю и Аде, хоть на них и не программирую.
Качественное ПО, которое необходимо народу/на_рынке, будет иметь успех независимо от языка, на котором оно написано.
В том-то и проблема - если при этом оно будет написано на г*не, ничего не останется как использовать его и плеваться.
> Качественное ПО, которое необходимо народу/на_рынке, будет иметь успех независимо от языка,
> на котором оно написано.ещё бы язык затрудняющий написание непонятного кода (вынуждающий писать максимально прозрачно и максимально алгоритмично, в идеале в виде графических блоксхем из логических блоков как-то "проход по циклу с выполнением блоксхемы номер N для каждого элемента", "сортировка" и пр с возможностью указать нужна ли в конкретном блоке реализация по скорости или по памяти)
Порог "непонятного кода" только у всех разный. Кому-то перегрузка операторов непонятна, кому-то конструкция @x=map {$a=~/-/:/g}@y или open F, "</etc/passwd" || die("Error") - а для кого-то это элементарщина, которую даже разбирать не надо - также, как вы не разбираете слово на буквы, а просто воспринимаете целиком, как "иероглиф".
> ещё бы язык затрудняющий написание непонятного кода (вынуждающий писать максимально прозрачно
> и максимально алгоритмично,Да, и еще програмеров бы идеальных :) желательно железных, чтобы плохо программить не могли в принципе - просто запретить им это на уровне фирмвари головного мозга... :))).Ну а вы пойдете в дворники за ненадобностью :)
> Качественное ПО, которое необходимо народу/на_рынке, будет иметь успех независимо от языка,
> на котором оно написано.Только язык может внести свои коррективы. Скажем если мне для запуска байды на яве надо 100 мегов явы скачать, а потом оно будет полминуты стартовать каждый раз натужно хрустя диском - спасибо, но я другую программу поищу. Без такого безобразия. И крайне маловероятно что ваша программа уникальна и незаменима. Туда же идут и дотнеты с их 200 меговыми сетапами и установкой по часу.
>> Качественное ПО, которое необходимо народу/на_рынке, будет иметь успех независимо от языка,
>> на котором оно написано.
> Только язык может внести свои коррективы. Скажем если мне для запуска байды
> на яве надо 100 мегов явы скачать, а потом оно будет
> полминуты стартовать каждый раз натужно хрустя диском - спасибо, но я
> другую программу поищу. Без такого безобразия. И крайне маловероятно что ваша
> программа уникальна и незаменима. Туда же идут и дотнеты с их
> 200 меговыми сетапами и установкой по часу.Время запуска - это статический оверхед. Загружеатся в память виртуальная машина только один раз. Отчего долго - от того что там много разной функциональности. KDE приложения тоже с задержкой стартуют первый раз, по той же самой причине.
Только большая часть этой функциональности любой данной программе не нужна. Плюс новомодные проверки безопасности кода, разнве JIT, сборщик мусора (который требует от 2 до 5 раз больше памяти, чтобы программа работала с той же скоростью, что и с ручноым управлением памяти). Плюс непригодность джавы для десктопа из-за неумения возвращать свободную память системе. Пусть энтерпрайз-обезьяны на этом пишут.
Более того - в случае манагед кода очень трудно сразу быстро и на глаз засечь утечки памяти, даже весьма большие. Которые как ни странно там не только бывают но и вполне штатное явление природы. В случае прог выделяющих память обычными методами - видно все и сразу, так что если жрач памяти линейно растет в течение долгого времени и не стабилизируется - значит оно скорее всего течет и надо чинить, при том кто и сколько жрет видно более-менее в реальном времени. А в случае манагед - там вообще на глаз такое не поймаешь. Кто там его этот GC знает когда он там мусор собрать изволит. И вот прога жрала 100 мегов а стала через полдня жрать 200. И вот думай - толи это так и задумано, толи GC не отдуплился еще, толи просто течет что-то внаглую. В результате - я видел случаи когда большие утечки памяти оставались не пойманы годами т.к. все думали что это оно просто так работает.
Знаю, нарывался. Правда, я на джаве и ЭкшнСкрипте писал - так там ещё без деструкторов очень неудобно чистить все ссылки на объект - что-то остаётся и в результате сборщик вообще объект не удаляет. В этом плане с D получше дело обстоит - и сборщиком можно управлять, и деструкторы есть... В общем, уже терпимо.
Сборщик мусора открывает большое количество фич, которые просто невозможны с ручным управлением памяти. Ты такая же обезьяна, только по другую сторону, так как будешь всю свою сознательную жизнь иметь дело с malloc/free и так и перейдешь на более высокий уровень где есть array slicing, замыкания итп. Сборщик мусора при правильном использовании позволит достичь большей производительности.
>Сборщик мусора при правильном использовании позволит достичь большей производительности.В основном он позволяет просрать предсказуемость этой самой производительности (потому что живет своей жизнью малоподконтрольной програмеру) и наделать трудноуловимых багов. По опыту тестирования барахла на манагед языках, если что.
А еще - ну допустим захочется вот написать *надежную* программу. Которая не загнется при нехватке памяти в системе и прочая. Мало ли, демон там, который полгода в батч-режиме будет фигарить (в зависимости от того что это - это может считаться и как прикладная программа и как системная). На unmanaged это даже можно - заранее при старте выделяем себе кус памяти, юзаем его. И готово. У нас уже никто его не отхапает, он наш. Поэтому мы будем спокойно работать не боясь навернуться от того что не удалось что-то выделить через 2 дня с момента старта. А вот в случае с принудительным автоматическим управлением памятью в этом плане наступает полная ж. Грубо говоря - сколь-нибудь надежную программу написать нереально вообще. Наступил oom - попробовали выделить памяти - померли/заглючили/сломались. А какие еше варианты, если нужного куска памяти чисто физически уже неоткуда взять в системе? Типичная картина.
> Время запуска - это статический оверхед. Загружеатся в память виртуальная машина только
> один раз.Ага, только как-то так получается что у меня нет ява-приложений и поэтому каждый раз надо втыкать на то как оно там 30 секунд винчом хрустит. Спасибо, сами этим и пользуйтесь. А мне это не надо. Видимо остальным тоже. Так, глядя на популярность программ на этом при наличии возможности добровольного выбора.
> Отчего долго - от того что там много разной функциональности.
Да, поэтому особенно прикольно ради хелловорлда в 10 кило качать еще 100 с хреном мегов рантайма. Очень напоминает ералаш про наручные часы с телевизором. И 2 огромных чемодана батареек к ним. Поэтому чувак охотно их обменял при первом удобном случае, помнится :)
> KDE приложения тоже с задержкой стартуют первый раз, по той же самой причине.
KDE у меня стартует вместе с системой. Секунд за 10-20 взлетает вся система вообще. И софта юзающего кути у меня более 1 программы, так что вот уж что-что а кутево-кдешные программы не тормозят при старте т.к. почти все либы которые им нужны и так сразу в памяти сидят. Это и gtk касается в общем то. Алсо, никто не предлагает качать на систему без кутей и кед Qt и kdelibs как один монолитный кус на сто мегов. В конце концов, оно на подкомпоненты порезано и кроме дефолтного тулкита системы - качаются только реально нужные довески. Поэтому если ни одной программе в системе не нужен какой-нить там модуль вебкита, мегов так на эн - он и качаться не будет. Ну а всяким микрософтам и санко-ораклам такой подход ессно незнаком, они в своих девяностых намертво застряли и/или погрязли в изобретении кривых велосипедов с квадратными колесами. Поэтому их велосипеды ездят только по специальным дорогам.
>что-что а кутево-кдешные программы не тормозят при стартеА у меня Okular в GNOME запускался быстрее, чем в KDE4 (раз в 10, ололо). После чего весь этот сраный KDE отправился в помойку. В который раз.
> А у меня Okular в GNOME запускался быстрее, чем в KDE4 (разв 10, ололо).Ткнул на окуляр. Он появился через примерно ~секунду (за это время появилось полностью инициализированное окно в котором можно жать контролы и открывать документ). Я даже точно время померять не смог. Ну, даже если он появится за 0.1 секунды - врядли я увижу при этом большую разницу :).Хоть я и сомневаюсь что вы 0.1 секунды от старта до появления окна можете точно померять (интересно, какой тулзой?).
> После чего весь этот сраный KDE отправился в помойку. В который раз.
Гном имхо не сильно лучше. Вон его оконный манагер например - туп как пробка и вообще ничего не умеет. И некрасивый до кучи. Из GTK-based окружений понравился XFCE. Конечно попроще кед раз так в эн, зато все относительно компактно и аккуратненько. А в какойнить хубунте и вовсе epic win: приятная тема сразу по дефолту, набор софта куда лучше чем в гноме бубунты, etc :). Сразу остается очень приятное впечатление от среды. Задолбают монструозностью кеды? Уйду на XFCE тогда, если всякие непоймуки и аконади станут насильно впариваемой неотключаемой и невыпиливаемой фичой (да, я тоже не люблю bloat от ненужного мне функционала высосанного из пальца).
> Ткнул на окуляр. Он появился через примерно ~секунду (за это время появилось
> полностью инициализированное окно в котором можно жать контролы и открывать документ).
> Я даже точно время померять не смог. Ну, даже если он
> появится за 0.1 секунды - врядли я увижу при этом большую
> разницу :)Ага. А если комп не топовой конфигурации, а, скажем, 3-4 летней давности, то разница уже будет 5-7 секунд против 1-2. Уже более ощутимо, да?
> Гном имхо не сильно лучше.
По крайней мере он не тормозит и глюков в поставляемых приложениях поменьше.
>Вон его оконный манагер например - туп
> как пробка и вообще ничего не умеет. И некрасивый до кучи.Зато с гномом компиз прекрасно дружит. И работает лучше, чем KWin.
> Из GTK-based окружений понравился XFCE.У него одна проблема (или достоинство, кому как) - он может называться DE только с большой натяжкой.
Кошмарный непоследовательный синтаксис, уродская ОО модель, а больше я отличий от C++ я не заметил - boehm-gc и обертку над потоками можно использовать и в нём.
ООП как раз-таки там нормальное.
> Кошмарный непоследовательный синтаксис, уродская ОО модель, а больше я отличий от C++
> я не заметилДавай ка еще раз.
> Кошмарный непоследовательный синтаксис, уродская ОО модельТы наверное хотел сказать, что это как раз то, из чего состоит C++ и чего нет в Go?
Нет, давай-ка еще раз и так пока не поймешь что написано.
Некоторые решения действительно через жопу, но вот с ОО-моделью там как раз всё в порядке.См. http://rainman-rocks.livejournal.com/67138.html и http://rainman-rocks.livejournal.com/122876.html - тема подробно раскрыта.
Смесь паскаля и питона и в результате скриптовый язык, позиционируемый как системный. Как говорится, или крест сними или трусы надень.
Зачем обманывать? Go компилируемый. ;)
Притом одна из его фич, ну очень быстро компилирует.
> Зачем обманывать? Go компилируемый. ;)
> Притом одна из его фич, ну очень быстро компилирует.gcc без -O тоже быстро компилирует, только кому это накомпиленное потому нужно.
Когда массив используется в качестве параметра функции, функция получает копию массива, а не указатель на него.а если массив 500м а стек 8м???
Ну так не передавай массив, а передавай указатель.
Значит пора отбирать косяк у архитектора.
> Значит пора отбирать косяк у архитектора.А он там был? Чойта за архитект у которого массивы 500 мегов? Из индии чтоли?
А что вы, ничего в жизни не написавший, имеете против? У меня вот на соседней машинке прога обрабатывает массив uint64_t в полтора тера.
сколько памяти у машинки? а в чом смысл одним шматком хранить полтора тера?
> сколько памяти у машинки?16G
> а в чом смысл одним шматком хранить полтора тера?
А в чем проблема?
> А что вы, ничего в жизни не написавший, имеете против? У меня
> вот на соседней машинке прога обрабатывает массив uint64_t в полтора тера.И он передается в функцию "по значению" и ложится на стек? А стек при этом убирается в ОЗУ? И эта куча данных сделана именно как единый массив? Возникают сомнения насчет того, кто именно ничего в жизни не написал...
> И он передается в функцию "по значению" и ложится на стек?Нет.
> И эта куча данных сделана именно как единый массив?
Да.
> Возникают сомнения насчет того, кто именно ничего в жизни не написал...
В себе сомневайтесь прежде всего.
А что, mmap уже отменили?
Пайк с Томпсоном лучше бы Инферно до ума довели.
А почему про отставку Лужкова не сказал?
Угу, чтобы еще это чудо на полностью управляемо коде жило и тормозило? Нет уж, нехай эти архитекторы тратят свои силы на загубленные десяток подобных проектов - а то, не дай бог, сконцентрируются на одном и таки пропихнут.А как надо языки писать - сомтрите на D2. Вот та сделано УДОБНО для программиста, и при этом при надобности есть все возможности - от прямого вызова c-функций (и создания .so, используемый из C) и отказа от GC до функциональщины, от метапрограммирования, проектированного Александреску и генерации кода при компиляции до создания в рантайме экземпляра класса по имени как штатной возможности языка. О куче удобного syntax sugar вроде
foreach(i, item; array) writefln("index %s - value %s\n", i, item) еще надо упомянуть. При этом компилируется быстрее, чем Go.
> При этом компилируется быстрее, чем Go.Видимо, его проблема в том что авторы - не гугль, а гуглу как и всем прочим не чужд синдром NIH.
> О куче удобного syntax sugar вроде
> foreach(i, item; array) writefln("index %s - value %s\n", i, item)
> writefln("index %s - value %s\n", i, item)#define foreach(i, item, array) for (i = 0; i < sizeof(array)/sizeof(array[0]); i++, item = array[i] )
Где сахер-то?
> еще надо упомянуть. При этом компилируется быстрее, чем Go.
Сахер в том, что в foreach у вас есть не только элемент, но и номер итерации. Что довольно часто нужно.
sizeof(array) - не размер ли указателя?
А чем, простите, будет проинициализирован item на первой итерации?
> А чем, простите, будет проинициализирован item на первой итерации?array[0]
> Пайк с Томпсоном лучше бы Инферно до ума довели.Интересно, чем и для кого лучше?
>> Пайк с Томпсоном лучше бы Инферно до ума довели.
> Интересно, чем и для кого лучше?для всех - концепция Инферно тянет на нечто более чем "очередной велосипед"
> В языке предусмотрены хеш-таблицы. Они называются словарями (англ. maps)Позабавило. Жил-был Вася по имени Петя, которого завли Саша...
u nego je netu windows compilatora - poetomu slishkom uskii krug primenenia
Узкий? Просыпайтесь, разработкой софта на под винду, ни под виндой уже не занимаются.