LINUX.ORG.RU

Google представляет Go

 , , ,


0

0

Go — экспериментальный язык програмирования, разработанный в Google. Основные разработчики языка — Роб Пайк и Кен Томпсон, также известные как разработчики unix и plan9.

Go предназначен в первую очередь для написания крупных серверных приложений и способен сократить время сборки с десятков минут до нескольких секунд (в сравнении с C++) за счет системы модулей и явного указания зависимостей.

В языке отсутствуют классы, исключения, метапрограммирование и ручное управление памятью, однако присутствуют указатели, сборщик мусора и goto. Также на уровне языка поддерживаются легковесные процессы (goroutines) и каналы (channels).

Можно использовать фигурные скобки и юникод в идентификаторах.

>>> Подробности

★★★

Проверено: hibou ()

Why are maps built in?

мой ответ: потому, что их реализации нужны дженерики

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>язык без дженериков обречен

Не видел ни одной успешной платформы базированной на статической типизации с ранним связываением. Что COM, что Жаба - везде позднее связывание и стандартизованный ABI. Вероятно, те же плюшки и в .NET

Absurd ★★★
()
Ответ на: комментарий от faustus

> Знал когда-то язык, где брейку можно было сказать, через сколько вложенных циклов вывалиться.

Кстати, вспомнил - return-from в Common Lisp.

faustus
()
Ответ на: комментарий от faustus

>> Знал когда-то язык, где брейку можно было сказать, через сколько вложенных циклов вывалиться.

>Кстати, вспомнил - return-from в Common Lisp.

break label в жабе

Absurd ★★★
()
Ответ на: комментарий от yk4ever

> Ну я рад за него. И где они, эти языки?

Речь шла об опыте разработки языков и у Пайка он есть. Причем опыт более чем успешный. То, что Вы он них (языках) ничего не знаете, ни в коей мере не характеризует их (языки), а скорей характеризует Вас, как человека, скажем, не в теме.

Для справки - перечисленные языки (за исключением, пожалуй, Alef) имеют в настоящее время промышленное применение.

anonymous
()
Ответ на: комментарий от faustus

> Я не знаю, что такое "декларативная диспетчеризация", но наследование - это прежде всего полиморфизм, виртуальные функции.

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

А теперь давайте вспомним, что виртуальные функции можно определить не только в базовом классе, но и в интерфейсе. Если вы подумаете чуточку подольше, то поймёте, что наследование - это всего лишь реализация интерфейса, неявно определённого предком. Когда есть интерфейсы - наследование не нужно.

yk4ever
()
Ответ на: комментарий от anonymous

> Для справки - перечисленные языки (за исключением, пожалуй, Alef) имеют в настоящее время промышленное применение.

Ну так и Python его более чем имеет, что не помешало нашему товарищу яростно брызгать слюной :]

yk4ever
()
Ответ на: комментарий от pazak

>Да вместо goto для выхода из 3-х вложеных циклов всегда можно использовать нечто боллее удобоваримое:

>1. удовлетворить условия завершения всех циклов разом


Мысль гениальна, осталось её реализовать :)

>2. сгенерировать исключение. 3. воткнуть все вложеные циклы в отдельную функцию, и там где вам хочется вызвать goto просто вернуть управление и эвентуально значение :)


Феерично! Процу больше нечем заняться и вместо кондового JAMP`а надо его поднагрузить call`ами, балавством со стеком и прочими плюшками, связанными с вызовом функций.

Наш лозунг "Память дешОвая и процы наши быстры!"

Attila ★★
()
Ответ на: комментарий от denis_ka

>кто нибудь из гугла рассказал почему новый велосипед, а не развитие D?

Потому же, почему и не любой другой язык -- NIH-синдром.

sinister666 ★★
()
Ответ на: комментарий от Absurd

> break label в жабе

Точно! Про это вообще забыл. Имхо, все эти плюшки надо запретить.

faustus
()
Ответ на: комментарий от faustus

>> Да? Сколько лет, какое образование, какой опыт работы в команде?

отдел быдлокадров в конторе быдлокодеров?

Urthang
()
Ответ на: комментарий от www_linux_org_ru

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

Неймспейс - средство группировки имён. Позволяет определить квалифицированное имя, типа MyModule.myFunction.

"Статический метод класса" есть вызов функции по квалифицированному имени: MyClass.myFunction. Т.е. статический класс = неймспейс.

Для нестатических методов класс-неймспейс указывается неявно, через тип (базовый) экземпляра.

yk4ever
()
Ответ на: комментарий от Absurd

> Указатель же можно сделать ключем,

И чё, перемещающему гарбаж коллектору бегать по всем ассоцмассивам, ключи править?

yk4ever
()
Ответ на: комментарий от yk4ever

>> Указатель же можно сделать ключем,

>И чё, перемещающему гарбаж коллектору бегать по всем ассоцмассивам, ключи править?

Ну по факту в Go указатель можно сделать ключем, так что identity в хеши можно сваливать. Это примерно как сваливать в жабский HashMap объекты у которых не перегружен equals() и hashCode().

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Но нет экзепшенов (???)

Why does Go not have exceptions?

Exceptions are a similar story. A number of designs for exceptions have been proposed but each adds significant complexity to the language and run-time. By their very nature, exceptions span functions and perhaps even goroutines; they have wide-ranging implications. There is also concern about the effect they would have on the libraries. They are, by definition, exceptional yet experience with other languages that support them show they have profound effect on library and interface specification. It would be nice to find a design that allows them to be truly exceptional without encouraging common errors to turn into special control flow that requires every programmer to compensate.

Like generics, exceptions remain an open issue.

pi11 ★★★★★
()
Ответ на: комментарий от fyrer

...2056 год. в школах на уроках информатики детки пишут код своего генератора велосипедов языков

Предвкушаю реализацию от майкрософт
[dot]G

скорее gg#

ramil
()
Ответ на: комментарий от www_linux_org_ru

Они-же по сути своей упирают на безтиповость. То-есть язык должен гарантировать надёжность преобразований либо не преобразований типа значений(!) по необходимости. Соответственно, раз у нас нет жёсткой типизации, значит нам ненужны ни наследования ни полиморфизм как средства обеспечения типобезопастности.

Вопрос теперь в другом, чем отслеживать привычные иерархии "значений" ? Модулями ? А как-же ограничение области видимости ? Разве модулями это обеспечивается ?

pazak
()
Ответ на: комментарий от Attila

> Феерично! Процу больше нечем заняться и вместо кондового JAMP`а надо его поднагрузить call`ами, балавством со стеком и прочими плюшками, связанными с вызовом функций.

Сразу вспоминаем про static inline и не парим мозг окружающим.

pazak
()
Ответ на: комментарий от ramil

>..2056 год. в школах на уроках информатики детки пишут код своего генератора велосипедов языков

Вам, уважаемый, видимо в школе не рассказывают про то что давно существует YACC :) LOL

robot12 ★★★★★
()
Ответ на: комментарий от faustus

> Знал когда-то язык, где брейку можно было сказать, через сколько вложенных циклов вывалиться

Ada

Darkman ★★★
()
Ответ на: комментарий от pi11

>Why does Go not have exceptions?

Я уже разобрался - там вроде бы туплы можно возвращать. Так что можно вернуть пару bool success, SomeT result.

Absurd ★★★
()
Ответ на: комментарий от pazak

>Сразу вспоминаем про static inline и не парим мозг окружающим.

И забИваем (на) исключения :)

Attila ★★
()
Ответ на: комментарий от pazak

> А как-же ограничение области видимости ? Разве модулями это обеспечивается ?

Да. Только ими и должно обеспечиваться.

yk4ever
()

Ааааааааааааааааааааааааааааааааааа!

Они убрали скобки у if, for

Тип возвращаемого значения надо указывать после имени функции

Типы аргументов можно указывать перед функцией

Имеются типы функций и анонимные функции

Тип переменной нужно указывать после идентификатора

Для присвоения использовать :=

Добавили оператор <- для отправки/получения данных по сети

Одним словом еще один язык с синтаксисом ортогональным по отношению ко всем существующим языкам.

sign
()
Ответ на: комментарий от sign

>Одним словом еще один язык с синтаксисом ортогональным по отношению ко всем существующим языкам.

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

Absurd ★★★
()
Ответ на: комментарий от yk4ever

>А теперь давайте вспомним, что виртуальные функции можно определить не только в базовом классе, но и в интерфейсе. Если вы подумаете чуточку подольше, то поймёте, что наследование - это всего лишь реализация интерфейса, неявно определённого предком. Когда есть интерфейсы - наследование не нужно.

Ты сам себе противоречишь.

<ф цитаты bash.org.ru>

>>Когда есть интерфейсы - наследование не нужно.

</ф цитаты bash.org.ru>

Полиморфизм это тот самое, без чего просто нет ООП. Если нет строгой типизации, ненужен ООП, и полиморфизм в том числе.

Когда ты это поймешь, а не просто будешь попугайничать псевдо-умными фразами, тогда можно будет вести беседу.

pazak
()
Ответ на: комментарий от pazak

>Полиморфизм это тот самое, без чего просто нет ООП. Если нет строгой типизации, ненужен ООП, и полиморфизм в том числе.

В COM есть интерфейсы, но нет наследования.

Absurd ★★★
()
Ответ на: комментарий от yk4ever

> Да. Только ими и должно обеспечиваться.

Ага, щаз ... привожу пример: язык lua. Теперь ты свою заяву обоснуй.

pazak
()

А goto они включили лишь потому, что язык с таким названием не может не содержать такого оператора?

dn2010 ★★★★★
()
Ответ на: комментарий от Absurd

>>язык без дженериков обречен

> Не видел ни одной успешной платформы базированной на статической типизации с ранним связываением. Что COM, что Жаба - везде позднее связывание и стандартизованный ABI. Вероятно, те же плюшки и в .NET

я про фому, ты про ерему

причем тут позднее связывание? в современной яве есть (неполноценные) дженерики, в плюсах почти полноценные

кстати, им таки пришлость заюзать дженерики в built-in каналах -- их каналы типизированы, так что фактически у них chan<int>

но своим пользователям они такие возможности не дают -- вопиющий недемократизм, если не сказать фашизм языка

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от yk4ever

> Для нестатических методов класс-неймспейс указывается неявно, через тип (базовый) экземпляра.

просветление уже недалеко... как же ты сделаешь в классах, которые "частные случаи неймспейса", конструктор по умолчанию, конструктор копирования по умолчанию и прочие нестатические фенечки?

З.Ы. гораздо проще сделать из класса неймспейс, сделав класс открытым в области статических полей и методов, тогда можно будет сказать, что неймспейс есть частный случай класса

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> но своим пользователям они такие возможности не дают -- вопиющий недемократизм, если не сказать фашизм языка

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

Casus ★★★★★
()
Ответ на: комментарий от yk4ever

>> что вы привязались к этому синтаксису? вам не пофигу, есть там фигурные скобочки или нет?

>Нет, не пофигу. Они мешают.


Хорошему танцору, как известно, не мешают.

volh ★★
()
Ответ на: комментарий от robot12

с MPS знаком, сыро

> Вам, уважаемый, видимо в школе не рассказывают про то что давно существует YACC :) LOL


YACC - не слышал, но...
вас, видимо, в школе учил сам Джонсон, которому не знакома физиология и уровень подростка, либо вы вундеркинд (тогда зачем вам ЛОР)

ramil
()
Ответ на: комментарий от www_linux_org_ru

>> Не видел ни одной успешной платформы базированной на статической типизации с ранним связываением. Что COM, что Жаба - везде позднее связывание и стандартизованный ABI. Вероятно, те же плюшки и в .NET

>причем тут позднее связывание?

Такая вещь как дженерики и связывание символа с реализацией должны относиться скорее к платформе, а не языку. А на уровне платформы их реализовать нельзя. Дотнет не смотрел, но ожидание чуда невелико.

>в современной яве есть (неполноценные) дженерики

Пошли на поводу у плюсовых троллей.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>>COM это простите язык ?????

>Это ООП-модель такая. Без наследования, но с интерфейсами.

вобщем это отдельная тема для разговора не имеющая отношения к ЯП и типизации. Для сведения: реализуя интерфейс, вы, несмотря на ваше отрицание данного факта , его наследуете :) неявно конечно, т.к язык на котором вы пишете приложение (в данном случае C) ООП средствами сам не обладает.

pazak
()
Ответ на: комментарий от pazak

>>Когда есть интерфейсы - наследование не нужно.

Это почти что правильно.

Когда есть интерфейсы (тайпклассы) и параметрический полиморфизм (а желательно еще и зависимые типы), наследование может быть смоделировано, и как таковое нужно не очень часто.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от yk4ever

Алгебраические типы шагают по планете.

4.2. До гугла не дошагали :)

Кстати, из всех возможностей этого недоязычка понравился только message passing и конкурентность (long live Erlang), но без pattern matching юзать его придётся через жопу с кучей nested cases.

zenith ★★★
()
Ответ на: комментарий от Absurd

> Такая вещь как дженерики и связывание символа с реализацией должны относиться скорее к платформе, а не языку. А на уровне платформы их реализовать нельзя.

нельзя? по какой причине? (все же сильно подозреваю бред)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Absurd

> Пошли на поводу у плюсовых троллей.

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

faustus
()
Ответ на: комментарий от Casus

> Вообще-то, их язык ещё не финализирован.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от faustus

> В смысле? Generics в Яве - самое серьезное улучшение языка за его историю, позволяют обходиться без кастингов и писать более-менее чистый код. Достоинства значительно перевешивают недостатки.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Когда есть интерфейсы (тайпклассы) и параметрический полиморфизм (а желательно еще и зависимые типы), наследование может быть смоделировано, и как таковое нужно не очень часто.

Если есть интерфейсы которые нужно реализовывать, (в не зависимости от присутствия или отсутствия в ЯП ООП-фичек), явно или неявно (COM и C) но наследование происходит. В случае с COM отсутствует полиморфизм. Но его реализовать можно только средствами языка.

Параметрический полиморфизм , всё равно полиморфизм. ООП быть при жёсткой типизации, без вариантов. Без типизации, ООП ненужен. Логика железобетонная и доказана кочей языков в последние 40 лет. Доказано самими ЯП, от: юниксовых шеллов, перла, луа, лиспов и питона, до: ява, C# и вершины ООП С++.

pazak
()
Ответ на: комментарий от Casus

> Вообще-то, их язык ещё не финализирован.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>> Такая вещь как дженерики и связывание символа с реализацией должны относиться скорее к платформе, а не языку. А на уровне платформы их реализовать нельзя.

>нельзя? по какой причине? (все же сильно подозреваю бред)

Да хз. Я не представляю как бы я это сделал. Вероятно, в .NET что-то такое сделали, с контрпримером я бы ознакомился с удовольствием.

Absurd ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.