Язык программирования Go от Goooooogle

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

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

Тем не менее все эти разработки объединяет одно - они никак не могут отойти от наследства основополагающих языков программирования С и C++. Отчасти сделать это удалось языкам вроде Haskell или Erlang, однако в силу других причин эти языки пребывают ныне в забвении.

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

Как рассказали в Google, Go имеет новую систему типов и переменных, быструю компиляцию, хорошую производительность, а также встроенные средства, облегчающие написание кодов. Язык был в разработке внутри компании около двух лет. Вначале им занималась инициативная группа программистов, позже эти работы были выделены в свое направление. Сейчас язык и его спецификации опубликованы под лицензией BSD, допускающей свободное использование, а также создание на базе Go новых дочерних языков более узкой специализации.

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

Сейчас с Go поставляются два типа компилаторов - 6g и 8g для 64-битных платформ и общей архитектуры x86 соответственно. Оба компилятора, как заверяют в Google, работают очень быстро. Есть альтернативный компилятор Gccgo, базирующийся на знакомой всем пользователям Linux системе компиляторов GNU GCC. Последний компилятор не так быстр, но он может создавать более эффективный код. Все компиляторы полагаются полностью на собственный код. Создаваемый код не является управляемым, то есть для его работы не нужна виртуальная машина. По словам Пайка, получаемый после компиляции байт-код совершенно автономен.

Внешне код Go представляет собой занятный симбиоз старого-доброго C++ и нового языка Python, используемого в интернете.

В наследство от С новый язык получил систему типов и объектно-ориентированную концепцию программирования с возможностью наследования. Программисты сами могут определять типы и создавать методы для управления ими. Еще одной изюминкой языка является параллелизм. Go изначально поддерживает конкурентные потоки, более того Google здесь добавила механизм каналов, в каждом из которых может выполняться свой поток внутри программы.


Сайт проекта http://golang.org/

взято с cybersecurity.ru

8

Занимательная переводная хабростатья Что я изменил бы в Go.

0

Сообщение от S_el Занимательная переводная хабростатья Что я изменил бы в Go.

50/50

По пунктам:

В Go особенно трудно придерживаться функциональной парадигмы

Ну так Go не ЯФП и никогда так не позиционировался. ФП тоже не панацея и имеет свои недостатки.

Работы над Go и Rust начались примерно в одно время: Go анонсировали в 2009-м, а Rust — в 2010-м.

И где сейчас Go? А где Rust?

Go — стабильный язык с относительно большим количеством сторонних библиотек и примеров «real-world»-применения, а что с Rust'ом?

Даже авторы (Mozilla) до сих пор не используют его полноценно (Servo всё ещё в стадии разработки).

Вероятно, оба языка предназначались для замены С++: разработчики Go утверждали, что первичным мотиватором для них стало недовольство сложностью С++

Одно маленькое дополнение: «… для замены C++» в некотором круге задач гуглодевелоперов. Вовсе не общая замена C++ во всех его сферах применения.

Servo — один из основных Rust-продуктов Mozilla

Это пока проект, а не продукт. Вот переведут FF на Servo, тогда и будет продуктом.

В Rust есть поддержка операций реального времени, при необходимости он способен оперировать только стековой памятью. В Rust сложная система типов, которая может, к примеру, выявлять проблемы посредством многопоточного (concurrent) обращения к общим данным в ходе компилирования. Всё это увеличивает сложность Rust-программ. Тот же borrow-checker славится своей кривой обучения.

Вот то-то и оно, что пока Mozilla возилась с языком, авторы Go «заморозили» некоторую простую семантику и сосредоточились на развитии инструментов и инфраструктуры. Ибо в современном мире это важнее красоты «правильности» языка.

Что меня особенно раздражает в Go. nil

Про nil согласен, но, полагаю, основной причиной было упрощение использования Сишных библиотек.

Про обработку ошибок тоже, в целом согласен, но

а если программист пренебрежёт проверкой на ошибки или допустит небольшую оплошность вроде проверки неправильной переменной ошибки (error variable), то компилятор не выявит проблему.

Ничто не мешает Rust-программисту вместо реальной обработки ошибки вставлять какую-нибудь заглушку и благополучно забывать о ней. Как, например, Java IDE, при обёртывании выражения в try-catch, вставляют какой-нибудь дефолтный e.printStackTrace(). Это не обработка ошибок.

Ещё одна пощёчина Go от функционального программирования: в этом языке нет хорошего способа писать полиморфные функции, которые умеют манипулировать слайсами произвольных типов

К чему это конкретика? Это следствие отсутствия параметрического полиморфизма, о котором и так в статье далее идёт речь. Ну это так, придирка.

По поводу дженериков авторы Go давно написали ответ в FAQ. Мне самому при использовании Go иногда их не хватало, и я понимаю всю их пользу, особенно для библиотечного кода, но я никогда не занимался разработкой и реализацией ЯП и компиляторов, поэтому судить авторов Go за их решение в данном случае не стал бы. Кроме того, нередко злоупотребление дженериками приводит просто к адовому коду. =)

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

Но Go не ЯФП!

В Go приходится везде перереализовывать абстракции списков (list abstractions). Рассмотрим функцию Go: …

Ну, может, автору стоило бы посмотреть на пакет sort.

Ведь я хочу ловить ошибки и не могу отправлять через канал типы (models.Document, error), потому что кортежи Go не являются значениями первого класса…

Мне кортежей тоже иногда не хватает, в том числе и в Java. Но
1) в части случаев вместо кортежа лучше всё-таки создать отдельный тип структуры с «говорящими» именами полей;
2) иногда можно использовать анонимные структуры, хотя это менее удобно.

Кроме того, Rust возвращает ошибочное значение, как только возникает сбой, а Go всегда ждёт завершения всех извлечений.

Э-м… Канал закрывать не пробовал?

В Go есть «магическая» функция make

И? Это часть языка, как for, func, import. Более того, с точки зрения языка, make — не функция, а такой же keyword, как и остальные. Вот нафига в Rust ключевое слово fn? Могли бы как в Хаскелле обойтись без него. Зачем в ML let rec, когда в Хаскелле rec отсутсвует?

Нечто подобное демонстрирует оператор range

То же, что и make, только range — это действительно оператор. Точнее даже, скорее просто ключевое слово синтаксиса for, чтобы отличать for i := range от «классического» for i := 0; i < n; i++

Довольно странная придирка. Я бы ещё понял, если бы он написал, что неплохо бы, чтобы range был хотя бы встроенным типом, как chan, и его можно было бы создавать и возвращать как результат работы процедуры, например. В общем, был бы first-class citizen.

Ещё одна привилегия заключается в том, что только типы из стандартной библиотеки могут сравниваться с помощью ==, >, и т. д.

Перегрузка операторов — вообще отдельная тема. В функциональненьком Ocaml тоже нельзя перегружать операторы, более того, для арифметических операций над целыми и floating-point используются разные операторы.

Конечно, только стандартной библиотеке позволено определять типы дженериков.

Это не дженерики. make работает практически также, как malloc в C, не более того.

Как может выглядеть реализация make в Rust

Господи, да скажите ему, что в Go make — это примитив языка.

Отсутствие маркированных объединений, ограниченное сопоставление с образцом

Да, этого не хватает временами. В том числе и в Java =(

Rust не требует явным образом закрывать каналы.

Отлично. И как GC узнает, какой канал и какие потоки, работающие с ним, можно подчистить? Ах да, в Rust'е же нет GC, осталось только правильно подобрать модели владения и времени жизни для всех участников…

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

А ещё в Go есть оператор select, например. Как раз для этого случая. Разные типы сообщений отправляем разными каналами и всё ОК.

Поскольку Go не поддерживает маркированные объединения, сообщения в полиморфных каналах типизируются динамически. Можно использовать интерфейс в качестве параметра типа для канала, который ограничивает набор типов сообщений, отправляемых в канал. Но в Go интерфейс не запечатан (sealed): при создании нового типа, реализующего интерфейс, при компилировании не выполняется проверка, позволяющая удостовериться, что все потребители канала способны обработать новый тип. Распаковка сообщений канала с переключением типов (в отличие от использования исключительно интерфейсных методов) может привести к багам, которые выловила бы другая система типов.

См. выше про select.

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

Интересно, что за неконтролируемое приведение типов в Go. Хотелось бы пример кода. Может, это с помощью пакета unsafe (которым я никогда не пользовался)? Ну, на то он и unsafe. В Хаскелле, вон, тоже есть UnsafePerformIO или как там.

Блоки unsafe, функции и трейты в Rust выполняют неконтролируемые приведения типов.

А, ну вот.

В Go динамическая диспетчеризация используется при каждом вызове метода интерфейса. Динамическая диспетчеризация, подтверждения типов и переключения типов должны быть отражены в runtime (runtime reflection), что увеличивает накладные расходы.

Но именно для это и существуют интерфейсы в Go, для динамической диспетчеризации. Сравнивать разные инструменты, предназначенные для разных целей просто некорректно.

В Haskell это делалось как минимум за 10 лет до Go. И в Haskell не меньше полиморфности, чем в Rust или Go.

Но тайпклассы Хаскелла и интерфейсы Go — это вообще не одно и то же.
([]Stringer) и (Show a => [a]) — это сильно разные вещи.

Отсутствие кортежей первого класса

Тут, в основном, согласен, тем более что в предшественнике Go — Limbo, были полноценные кортежи.

Из-за отсутствия первоклассности в Go нет очевидного способа сообщения о потенциальных сбоях по каналу

Используй разные каналы для разных типов сообщений.

Насколько мне известно, лучшим вариантом будет определить кастомный тип struct, чтобы принудительно удерживать тип interface{} для положительных и ошибочных значений.

Бред какой-то.

Нехватка высокоуровневого параллелизма и средств многопоточного программирования

Из всего раздела так и не понял, в чём тут проблемы у Go. Например, чем это:

Но параллельные итераторы являются высокоуровневыми абстракциями, которые решают вместо вас некоторые сложные вещи. Например, Rayon прозрачно разбивает работу на пакеты (batches), такой подход более производителен по сравнению с помещением в очередь по отдельности каждого вызова колбэка map

отличется от помещения в канал того же пакета? Если речь про реализаци обобщённой библиотеки, то это всё же в тему к дженерикам, а не могопоточность. Кроме того, про проблемы таких вот «высокоуровневых» абстракций неплохо рассказано в критических статьях про Java'вский Fork-Join Framework. Вкратце: всё в итоге сильно упирается в количество ядер/процессоров, т.е. реально параллельных вычислителей, и бездумное употребление таких абстракций может легко привести к печальным последствиям, типа исчерпания пула процессоров. В этом не сложно убедится, достаточно насоздавать кучу thread'ов и программа просто загнётся. А теперь представьте, что каждый умник использует в своём коде этот самый .par_iter(), где надо и где не надо. JVM на 4-х ядерном Интеле (8 «виртуальных» ядер) умерает на нескольких тысячах (или паре-другой десятков тысяч) запущенных thread-ов. Scala со своим Akka — примерно на 200k. Такие дела. И горутинами, не смотря на всю их «легковесность» злоупотреблять не стоит.

2

ресурсы:
Go
https://tour.golang.org/welcome/1
https://go-tour-ru-ru.appspot.com/list
https://gobyexample.com/
http://golang-book.ru/
https://golang.org/ref/spec#Return_statements
https://www.jdoodle.com/execute-go-online
https://habrahabr.ru/post/133281/

http://losst.ru/wp-content/upl... -Doksi.pdf
https://www.socketloop.com/home/
https://github.com/avelino/awesome-go
https://www.youtube.com/channe... vXg/videos
https://astaxie.gitbooks.io/bu... /01.0.html
https://codegangsta.gitbooks.i... index.html
http://www.golangbootcamp.com/book/frontmatter
https://tproger.ru/translations/golang-basics/
https://devhints.io/go

2

вот по чему вы должны учиться Go Programming language

0

Сообщение от geekyvicky вот по чему вы должны учиться Go Programming language

1. Go programming language has positive credentials Google fully finances Golang. Its creators were geniuses, and they contributed to things like JVM, UNIX, C, B among others. Purpose of Golang was to serve as a future-proof language to solve present challenges and challenges that may come up in the future.

Аппеляция к авторитету Google, а не техническим преимуществам — маркетоидный булшит.

2. Golang is an open language It’s essential for any programming language to be open. Being open enables it to be cleaner, better and more efficient.

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

3. Golang is quite fast Golang has a simple syntax and structure.

Заголовок никак не связан с последующим предложением.

The Go language is mainly based on functions

Серьёзно? Откуда такой вывод? Автор не знаком с ML/Haskell/Scheme?
И как из этого следует утверждение «Golang is quite fast»?

so it enhances shorter feedback saves time and money, and the time to market is shortened.

— маркетинг на маркетинге и маркетингом погоняет.

Its simple nature makes it easy to maintain, and the development is cost friendly and fast.

Ассемблер ещё проще, а уж Brainfuck так почти идеал простоты. Или Whitespace, например. Но писать на этих языках, поддерживать код на них крайне сложно и дорого. Автор явно ничего не понимает в ЯП и разработке ПО.

4. Concurrency Concurrency is vital for any program. It allows numerous programs to run at the same time

НЕТ! Жесть, как можно быть таким невежей?

Programs like goroutines, garbage collection and channels make concurrency in Golang a much easier task.

Просто

5. Golang is a cross-platform

Как и большинство современных языков. Дальше что?

6. It keeps bugs away Golang is a compiled language with strict typization.

1) Нет такого слова «typization», в нормальном английском это пишется как «with strict typing»/«with strict types»/«with strict type system»/«with strict type checking». И обычно таки «strong», а не «strict».
2) Таких языков полно и в Go далеко не самая строгая типизация, рекомендую ознакомиться с зависимыми типами, например по http://www.cse.chalmers.se/~bengt/papers/hlcs.pdf

Developers have to be very attentive and accurate to make the code a bit neater and safe.

Это они просто с ML и Haskell не знакомы.

Disadvantages Of Go Programming Language The absence of third-party modules

ЩИТО? Либо поясни, что такое «third-party modules», либо открой для себя гихаб, например. Или хотя бы гугл.

Disadvantages Of Go Programming Language It has a big difference from the C based languages

Это не недостаток, а преимущество.

geekyvicky, если ты написал эту статью, то лучше удали её, не позорься. Если не ты, то никогда больше не пости ссылку на неё. Если ты просто бот, то убей своего хозяина.

1