Pull to refresh

Comments 270

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

Н-р: нет функции типа IsFileExists () (ну серьезно нет)

«Чего только нет стандартной библиотеке Go, практически ничего нет»

Стандартными средствами для работы с SQL невозможно получить данные запроса полный состав которых и тип которых вам заранее неизвестен. Обработка элементарного запроса «select * from table» превратится для вас в ад по поиску костыля.

Определение видимости элемента в зависимости от кейса первой буквы отдельный гемор, что будет если вы решите поменять область видимости? Да, да…

Возвращаемых функцией кортежи нельзя на лету преобразовать тип.

func get() (int64, err) {}

i int
err error
i, err = get() // Ошибка, которую нельзя исправить в этой строке

А ещё нет директив компилятора (Ну и так далее)

Вообще, взглянув на те решения которые предлагает Go в тех или иных ситуациях (Синтаксис и прочее)

Создается впечатление, что автор языка школьник который решил изобрести свой язык. Как ещё можно объяснить такое решение для условной компиляции под разные платформы:

pkg_windows.go
pkg_linux.go

и многие, многие другие решения.

Серьезно, строить современный язык, стоя на плечах гигантов и имея весь их опыт и сделать такое? Ну блин(

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

Тут именно особенности. Например, мне жутко не нравится штука с импортами. Закомментировал кусок кода, комментируй и импорт?


Отключалось бы оно, вопросов бы не было, но…


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

Дак да, в этом и прелесть. В итоге можно читать чужой код без боли.

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


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


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

Да, в рамках одной команды никто не мешает. Но учитывая что есть постоянная потребность использовать чужие пакеты, в идеале слать реквесты и вот это все (open source)… Гайдлайнов к сожалению не хватает, да, но сравнивать выходит все равно не с чем. :)

Ну, могу сказать, что Python и Java в целом отлично обходятся и без такого жесткого забивания в open-source пакетах и в 90% случаев код читаем и прост.


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

UFO landed and left these words here

Тут я что-то затупил, спасибо за замечание :)
Можно заменить "компилятор" на "интерпретатор" для питона, суть то все равно не поменяется. Он так же мог бы ругатся на неиспользуемые импорты и прочее.

UFO landed and left these words here

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


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

Почему каждая строка? Только лишь объявление переменной. Это какраз прекрасно ибо хорошо видно область видимости каждой переменной, да и вообще это статическая типизация — попахивает холиваром статическая vs динамическая.

Это как раз вопрос к тому, почему в Go нельзя отключить проверку на неиспользуемые импорты и переменные.


А вот причем тут статическая типизация, я к сожалению, не пойму.

Тред просто ушел в что-то большее и границы размылись. По поводу импорта, да, не сильно радует. Но с другой стороны можно найти этому логичное объяснение: не нужно использовать «лишние» компоненты. Хотя конечно, напрягает во время тестирования новых пакетов. :)
Но с другой стороны можно найти этому логичное объяснение

У многих языков есть несколько режимов компиляции, хотя бы Debug и Release. Что мешает Go при импорте лишних пакетов выдавать warning, а ошибку компиляции оставить только для Release-варианта?
Сделать это элементарно, зато Вы смогли бы во время разработки не отвлекаться на удаление импортов, а потом почистить их единоразово, когда текущая задача уже решена.

Я уверен что технически ничего не мешает. Дело в подходе.
Ну вот я, например, не могу читать без боли код, в котором фигурные скобки не располагаются на отдельной строке. Чем больше язык ограничивает стиль разработчика — тем хуже.
Отнюдь.

1. Современные IDE поддерживают автоформатирование. Настройте под себя чтобы при открытии код становился таким как вам нужно. Поправьте под себя gofmt или вовсе не запускайте его — пока вы работаете один никому нет дела.

2. Если вы работаете над чем-то серьезным, в коллективе — то у вас есть git (или нечто подобное).
Простое переформатирование кода под потребности ОТДЕЛЬНОГО программиста превращает компактные ИНФОРМАТИВНЫЕ коммиты git, в котором ты ТОЧЕЧНО видишь что было изменено — в ужастные гигантские простыни, состоящие большей частью из переносов скобочек на иную строку да изменению отступов.

Та же проблема возникает из за разности стилей написания — пока глаз подстроится, проходит время. Немного. Но часто.

То есть по сути выбор только между:

или
ТЫ МЕШАЕШЬ КОЛЛЕГАМ.
или
ТЫ ПОДСТРАИВАЕШЬСЯ ПОД ЕДИНЫЙ СТИЛЬ и КОЛЛЕГАМ ОБЛЕГЧАЕШЬ ЖИЗНЬ.
Ну вот я, например, не могу читать без боли код, в котором фигурные скобки не располагаются на отдельной строке. Чем больше язык ограничивает стиль разработчика — тем хуже.

Наоборот, в идеале синтаксис должен поддерживать только один стиль написания. Остальное сразу отлавливается компилятором (или IDE уже при написании).
UFO landed and left these words here
UFO landed and left these words here
Не можно, а нужно )) Но, естественно, это не единственный критерий хорошего ЯП.
UFO landed and left these words here
Например, мне жутко не нравится штука с импортами. Закомментировал кусок кода, комментируй и импорт?

Я использую редактор Atom с плагином для go и он так умеет делать.
в atom/vim-go это решается использованием утилиты goimports, которая сама проставляет или удаляет импорты. Пока не используется кастомная сборка (gb и прочие), работает очень сносно.
Странно, что вас напрягают такие мелочи.
У меня вот vim при записи автоматически удаляет или добавляет нужные импорты.

Nil interfaces, одна из самых нетривиальных подлянок

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


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

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

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

То, что в других языках пытаются исправить с помощью code style guide да специальных линтеров для проверки этих стилей — в golang просто жестко директивно внедрено создателями языка.

Сие экономит кучу времени именно в больших проектах.

И позволяет меньшими усилиями интегрировать код, написанный сторонними программистами (например, открытые библиотеки).

Я согласен, что та же фигурная скобка после if { может напрягать.
Но нужно себя пересилить.

Иначе, если каждый будет писать «не в ногу», то в тех же коммитах в git мы будем получать «ложные срабатывания» — всего-то один программист использует другое расположение фигурной скобки, а уже найти то, что она на самом деле изменил в коде довольно сложно.

Если у вас большой сложный проект, то все решается довольно просто — у вас точно есть CI, если у вас есть CI, у вас есть немного автотестов, которые блочат выкатку, если падают. Добавляем к ним style-check и профит. Если проект небольшой — то практика Code Review, которая все равно должна использоватся вас спасет.


Про интеграцию сторонних библиотек я уже говорил — 90% либ на Java или Python написаны хорошо и понятно, и им для этого не нужна жесткая проверка.


И опять же таки — Golang создает иллюзию защиты — он не спасает от неправильных названий, большой цикломатической сложности и быдлокода. А все его вроде как сложные и правильные ограничения перебивает кодогенерация, которой наговнокодить — раз плюнуть.

UFO landed and left these words here
И опять же таки — Golang создает иллюзию защиты — он не спасает от неправильных названий, большой цикломатической сложности и быдлокода. А все его вроде как сложные и правильные ограничения перебивает кодогенерация, которой наговнокодить — раз плюнуть.

А вот как с этим то быть? Все равно же и для Golang нужно настраивать синтаксический анализатор, что бы такие случаи отлавливать.

UFO landed and left these words here

Нет, я утверждаю следующее:
"У golang есть строгий, бесполезный и не отключаемый статический анализатор, который по факту не решает проблем".
И поэтому зачем он там нужен, мне не понятно. Качества кода в целом доверить ему нельзя, и в итоге он просто иногда вставляет палки в колеса.

UFO landed and left these words here

Возможно, я не совсем понимаю, но чем именно этот компилятор заставил программистов задуматся? Так же, он все равно не убирает необходимостью Code Review и прочих проверок.


Более того, для того, что бы обойти этот компилятор, люди сделал goimport, который автоматически обновляет строку импортов и удаляет/добавляет туда строки.


Собственно, возникает вопрос — зачем?


P.S. Скорее всего, я просто плохо формулирую мои мысли, поэтому так и получается. + я таки немного люблю спросить, потому что, например, в спорах так же всплывают и позитивные стороны Go :)

UFO landed and left these words here
Собственно, встречный вопрос — почему нет?

Если я не ошибаюсь, то Go вроде хотел быть минималистичный. Зачем добавлять в минималистический язык бесполезные вещи?

UFO landed and left these words here

В целом, мой аргумент остается таким же: если занятся автоматизацией code style на проекте, то все равно нужно будет переделывать или значительно дополнять то, что делает компилятор.


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


А если взять гипотезу у том, что значительная часть этих проверок была сделана для ускорения сборки, то почему бы ее не включать по ключу --release или как-то так?

UFO landed and left these words here
Останутся проблемы плохого кода, конечно же.
Но часть проблем плохого кода УЖЕ РЕШЕНА за вас.
И способ решения ЕДИНООБРАЗЕН по всему программисткому сообществу golang.

Code style guide возникли не просто так.

Это как Вавилонское стопотворение — пока ты говоришь на одном языке, пока ты манипулирует одинаковыми категориями в коллективе — ты работаешь намного быстрее.

Поэтому чем раньше происходит унификация и чем невозможнее её избежать — тем лучше.

golang решает известную проблему: «есть 100 стандартов, как так можно работать, давайте придумаем общий стандарт… упс — и уже 101 стандарт». golang решает это навязыванием своего видения, подобно тому, как Python учил программистов правильно делать отступы.

У меня есть опытнейший коллега (не golang, другой язык) — но после него просто невозможно работать над кодом, пока отступы не выставлены как нужно.

Люди в большинстве своем — весьма ленивы, посредственны и инертны.

Если позволить людям решать все самим — мы получим скатывание 99% программного кода в полный шлак.

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

К примеру, когда-то именно для этого была в Java сделана обязательная обработка/прокидываение наверх exception вплоть по всей иерархии стека вызовов в ЯВНОМ виде.

Дизайн Java пытался решить ту же задачу что и Go. Принудительно поднять средний уровень разработки. Чуть раньше такую задачу пытались решить, проектируя язык Ada.

Просто Go пытается минималистично, облегчая работу программисту, поднять уровень кодирования. Java пытался сделать это же максималистично.
Да конечно можно все сделать вручную. Можно и свою ОС написать и свой компилятор — прежде чем приступать к основной задаче.

Но ЗАЧЕМ лишний труд, если за вас уже решили часть задач?

Авторы golang установили минимальную планку, ниже которой язык/компилятор запрещает опускаться.

То есть просто принудительно подняли средний уровень code style.

Но ЗАЧЕМ лишний труд, если за вас уже решили часть задач?

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

После решения любых проблем — проблемы останутся. Это жизнь.
Там может, вообще, лучше лечь на диван и ничего не делать?
1.

if _, err := os.Stat("./config.ini"); os.IsNotExist(err) {

}

2. тут строгая типизация, чего вы хотели?
3. вы так говорите «такое решение для условной компиляции под разные платформы», будто это что-то плохое.
1. Напиши сложную конструкцию, вместо одной функции.
2, Хотел бы например такого: int64(i), err = get()
// для чего кортежи в языке со структурами, для меня тоже вопрос.
3. Очень плохое, те возможности которые дает банальный IFDEF в коде, во истину удивительны.
.// тут ещё вспомнил про include-ы (
UFO landed and left these words here
Коллизия, ну ок, есл итакой слабый анализатор, придумайте другой синтаксис н-р так: (i)int64 или как то иначе
Ну про отсутствие исключений я не упоминаю, про это и так написано не мало.
UFO landed and left these words here
UFO landed and left these words here
а то, что результат, к примеру, нужно вернуть в поле структуры. и без промежуточных переменных и лишних строк кода никак не обойтись.
Так нельзя: https://play.golang.org/p/vNXS9ufN7a
Действительно. Только так работает:
	var err error
	x.x, err = get()

https://play.golang.org/p/UPcj383JTp
UFO landed and left these words here
Попробую ответить на претензии.

1.
IsFileExists ()


Почему это должна быть отдельная функция?
if _, err := os.Stat("/path/to/whatever"); os.IsNotExist(err), одно условие, понятное вполне

2.
По поводу «select * from table»

Язык строготипизированный, поэтому результат потребуется описать, через хаки можно разобрать результат как map[string]sql.RawBytes, это не очень удобно, но, возможно, решит вашу проблему.

3.
По областям видимости

Можно подробнее описать проблесный кейс? Для каких то кейсов подойдет gorename, для других придется или ручками изменять, или надеяться на ide, но где это не понадобится?

4.
func get() (int64, err) {}

i int
err error
i, err = get() // Ошибка, которую нельзя исправить в этой строке


Тут да, Роб Пайк против сложных авто приведений, придется использовать дополнительную переменную.

5.
А ещё нет директив компилятора

Вы смотрели на ключи сборки?
Ну и вкусовщина
pkg_windows.go
pkg_linux.go
для платформозависимого кода, очень неплохо
для платформозависимого кода, очень неплохо

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


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


Так получается, что решение в С++ как-то проще и логичнее.

В C++ так же применяется такой подход.
Например в Qt
qfilesystemwatcher.cpp
qfilesystemwatcher.h
qfilesystemwatcher_fsevents.mm
qfilesystemwatcher_fsevents_p.h
qfilesystemwatcher_inotify.cpp
qfilesystemwatcher_inotify_p.h
qfilesystemwatcher_kqueue.cpp
qfilesystemwatcher_kqueue_p.h
qfilesystemwatcher_p.h
qfilesystemwatcher_polling.cpp
qfilesystemwatcher_polling_p.h
qfilesystemwatcher_win.cpp
qfilesystemwatcher_win_p.h


В целом, правильнее будет сказать что в С++ может применятся такой подход.


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

Никаких может. Он применяется. Чрезмерное использование #ifdef ухудшают чтение и модификацию кода.

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


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

У разных библиотек обычно разный интерфейс. Например таким образом сделана поддержка различных UI библиотек в CoolReader и FBReader.

И это, знаете ли, хорошо. Рискну предположить, что вы не видели С/С++ библиотек, состоящих из #ifdef наполовину и более.

Видел. Для непривычного глаза — дичь дикая, разобратся сложно, особенно, если не знаешь что означают все эти переменные.
Рискну предположить, что люди, которые с этим работают как-то привыкли.


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

И в этом то, почему Го так многим нравится. Чем меньше способов сделать одно и тоже, тем лучше. Была бы возможность, из него стоило бы еще немного отрезать.

"Урезанность" Го — вопрос отдельный.

1.
if _, err := os.Stat("/path/to/whatever"); os.IsNotExist(err)
vs
if FileExists("/path/to/whatever") {}

Правда не понятно почему? (И это я только один пример взял первый пришедший в голову)

2. «Язык строготипизированный» это совсем не объяснение. Костыли и не достаточно проверенные решения типа sqlx — превращают Go в СтрогоВелосипедизированный язык

4. Это непродуманность языка.

5. x:={ifdef windows}5{elseif linux}1{endif} — вот это очень неплохо
а если речь про кастомные определения, позволяющие управлять кодом, эх!

«но где это не понадобится» — вот поэтому я называю автора языка школьником не имеющим достаточного опыта, для того, чтобы понять, где это понадобится.
UFO landed and left these words here

Очевидно, в микросервисах практически не нужна платформозависимая работа. Немного примеров о том, где может приходится IFDEF:


  1. Работа с графическим окружением. Там, добавление иконки в трей, отрисовка на экране, вывод алертов и прочее.
  2. Работа с сложными вычислениями для разной архитектуры\
  3. Работа с графическими движками или просто поддержка нескольких графических оболочек (например, QT/GTK) при компиляции.
  4. Кроссплатформенные консольные утилиты, которые требуют работы с системой.
UFO landed and left these words here

То есть, вы согласны с тем, что Go — язык не универсальный с ограниченной зоной применения ну или разрабатывался таким?

UFO landed and left these words here

Скорее всего именно так :)

В Go меня привлекает сама платформа, отсутствие необходимости таскать за собой рантаймы.
Но в самом языке многое напрягает, о чем я пишу.
Почему бы Фольксваген не сделать лучше, а не залазить каждый раз в салон через багажник?
UFO landed and left these words here

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

Это закономерность, а не намеренное продвижение. Считаете что лучше бы везде был Rust, например? :) Хочу Вас огорчить: сообщество с этим не согласно.

Я все еще помню эти шикарные success статьи про то, что ребята переписали микросервисы с tomcat+java на go и получили 10-кратный прирост в силе. А их тогда были десятки.


Это слишком было похоже на такое продвижение.

UFO landed and left these words here

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


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


Глупо отрицать, что маркетинга у Goland нет.


P. S. Писать на Go никто не заставляет, но я же могу критиковать продутк, которым мне предлагают попользоватся?

Маркетинг?
КОМУ это надо?

В отличие от .NET — golang совершенно некоммерческий.

Есть добровольческий евангелизм тех, кому golang нравится,
не путайте с коммерческим маркетингом (market — это рынок по английски)

Сразу нагугли три конференции:
http://golanguk.com/
https://gophercon.com/
http://www.dotgo.eu/


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

Вы путаете причину и следствие.

Спонсоры хотят ЗАСВЕТИТЬСЯ там, где куча профессионалов собирается.

Особенно засветится хочет google :)


В целом, цепочка работает так:


  1. Google разрабатывает что-то на golang.
  2. Ему нужно сообщество вокруг golang, что бы он развивался.
  3. Он спонсирует разработку и вкладывается в маркетинг, что бы больше людей начало его использовать.

Современный мир IT работает именно так.

Google вкладывает средства в разработку языка по доброте душевной?

> Google вкладывает средства в разработку языка по доброте душевной?

Google язык вовсю использует.
Уже очень давно.
Он первый пользователь языка.

Он вкладывается в СВОЙ СОБСТВЕННЫЙ ИНСТРУМЕНТ.
При чем здесь душевная доброта?

Собственно и по некоторым замечаниям разработчиков понятно — они часто говорят «нам так надо, нас так устраивает». Например, про вендоринг — «нас устраивает, внутри Гугля есть своя система вендоринга, для массового потребления она не годится, кто хочет — пишите свою».

Вы правда не замечаете некоторой противоречивости утверждений "golang совершенно некоммерческий" и "Он вкладывается в СВОЙ СОБСТВЕННЫЙ ИНСТРУМЕНТ"?

Нет никакого противоречия.

Если у вас на рабочем месте стоит удобное кресло — то какое отношение это кресло имеет к сайтам на 1С-Битрикс, которые вы создаете с коммерческой точки зрения?

Ваш коммерческий интерес — в создаваемых вами сайтах.

А вовсе не в кресле.

В огороде бузина, а в Киеве дядька.


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


Во-вторых, ситуация такова, что golang контролируется Google, а его разработка ведется со вполне определенной целью — повысить эффективность сотрудников Google, использующих его в работе.


Так что аналогия с креслом тут никак не применима.

Вполне применима.

Кресло такой же инструмент повышения производительности труда. НЕ ПРИВЯЗАННЫЙ к технологиям Гугля, как и язык программирования.

Вот пример Apple с его Swift или Objective C — это да.
Тут если хочешь писать под OS X или iOS — намного проще это делать на языках, развиваемых Apple.

С golang — нет жесткой завязки под сервисы Гугля. Нет требований сервисов использовать именно golang.

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

Такие же кресла и тот же язык программирования — их могут использовать кто угодно. Ограничений при создании веб-сервисов нет никаких.

Нет привязки к Гуглю, нет монопольного требования использовать только golang на сервисах Гугля — нет и коммерциализации.

Golang + Google такая же связка как C#/.net Core + Microsoft. Тоже вроде как open-source в Github, но все то понимают, кому принадлежит основной актив и разработка языка/экосистемы.

Разумеется ВСЕГДА КТО-ТО КОНКРЕТНЫЙ принимает решения о развитии языка. Так и должно быть.

И лучше бы этот кто-то зарабатывал бы очень много и имел бы достаточно времени и достаточно опыта.

Так что какая разница кто ему платит (если это не лично ты из своего кармана), если язык УЖЕ СУЩЕСТВУЕТ, если ОН УНИВЕРСАЛЕН.

Касаемо golang 1.7, к примеру:

в релизе приняли участие 170 человек,
из которых 140 — НЕ ИЗ Google.

1. Про релиз — это как релиз ядра Linux. Вроде и дофига разработчиков, но все знают, кто главный.
2. Разница в том, что центр языка не какой-то фонд, а компания. Следовательно язык будет развиватся так, как выгодно компании.
Беспомощная у вас аргументация.

Главный разработчик запрещает вам лично писать/использовать сторонние библиотеки?

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

А какой достаточно развитый язык развивался децентрализовано?

C# — Microsoft
Python — Google; кое-какая свобода дала две плохосовместимые версии, в результате полмира уже много лет как сидит на Python 2, хотя Python 3 уже зрелый.
Golang — Google
Delphi — Borland
Java — Sun, Oracle
Rust — Mozilla централизовано его разрабатывает, в своих целях.
Ruby — там там вообще один разработчик, в результате чего и скорость компилятора не успевает поднять, хотя знает как, нет времени.

С++ — получили зоопарк компиляторов и стандартов. Если на Golang или Python компилиться с полпинка, то для С++ умение написать так, чтобы компилилось везде или умение адаптировать, чтобы скомпилировалось под конкретную систему — это отдельное умение.
Давайте не будем уходить от темы разговора.
Мы говорим о том, что golang — коммерческий язык. А вы тут начали обсуждать пути и развитие языков.
Коммерческим можно назвать Object Pascal — потому что иначе как в весьма платном Borland Delphi его и негде было применить.

Коммерческим можно было МНОГО ЛЕТ НАЗАД назвать C#.

Коммерческим можно назвать язык 1С.

Большая же часть языков — некоммерческая.

golang — не более чем кресло или удобная мышь сотрудника Google.

Да, он позволяет Google делать больше бабла за счет большей производительности труда и меньшей нагрузки на сервер.

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

Так что он — некоммерческий.

А всего лишь — внутренний продукт, предназначенный для повышения прибыли.

Внутренняя эффективность компании — это отнюдь не коммерция.
«Коммерческим можно назвать Object Pascal»

http://www.lazarus-ide.org/
Лазарус появился много позже Delphi

А баги в Лазарусе были основные устранены и можно стало без боязни использовать в продакшене ко времени, когда коммерческие возможности Delphi были исчерпаны.
UFO landed and left these words here

Это зависит от ваших намерений относительно молотка.


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


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


Еще бывает благотворительность, там цель — передача некоторых ценностей третьим лицам (в случае, если лица оказались не третьи, этим всем могут заинтересоваться органы).


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


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


Так что, молоток для чего нужен?


Возвращаясь к golang, Google, очевидно, контролирует разработку языка, а цель разработки явно далека от чистого исследования или от благотворительности.

Ерунду пишете.

1. Любое удобное кресло или цветы в горшочках в офисе — в конечном итоге ради увеличения производительности труда, то есть ради увеленичения прибыли. Но это не означает, что коммерция делается за счет кресла.

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

2. И хорошо, что проект golang не исследовательский.

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

Google сделал удобное кресло.
Другие подсмотрели — и стали использовать такие же кресла.

Для увеличения производительности труда и, следовательно, прибыли.

Но коммерцию на кресле Гугль не делает.

Пример коммерции на языке программирования — это Visual Studio, .NET. MS развивала долгие годы эту платформу как специализированную под свои Windows.

golang — слишком малоспециализированная, мало заточенная на сервисы Google вещь.

Даже для коммерческого хостинга Google AppEngine язык golang — всего лишь один из многих. И появился не самым первым в хостинге.

Может дело в том, что переписав с tomcat+java на tomcat+java с 10-кратным приростом, получится покаянное письмо "какими же говнокодерами мы были"?

Дело в том, что использование tomcat для микросервисов уже указывает на такое утверждение.

Catalina не столь уж тяжеловесна. Можно подставить вместо томката jetty/vertx/jboss swarm/whatever, оно не противоречит идее микросервисов, которая в первую очередь про разделение ответственности, данных и возможность независимой эволюции.

1. Непонятно, почему утилитарные функции должны засорять общий namespace? Этот php-style, простыни функций, и это плохо.

2. В каком кейсе вам нужно получить «получить данные запроса полный состав которых и тип которых вам заранее неизвестен»? Когда вам нужен велосипед, вы используете велосипед. Еще раз, то можно сделать, и да, после динамических языков, это будет очень неудобно, и это нормально.

4. Это привычки из нетипизированных языков.

5. Опять же вкусовщина, мне кажется, что проще иметь отдельный файл, который содержит все «платформозависимые» фичи. + если уж хочется что то такеого есть runtime

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

Я попросил привести кейс, если вы используете инкапсуляцию, у вас не будет проблем
Есть несколько штук SQL API, для строго типизированных языков, скажем для простоты JDBC и ODBC, где спокойно можно доставать метаданные и данные любого SQL-запроса. И никакого нарушения статической типизации при этом не происходит. И никаким велосипедом там не пахнет.

Более того, это вполне удобно (хотя конечно, не так просто делается, как запрос с известным числом колонок результата).
согласен, database/sql не может конкурировать с odbc/jdbc по функционалу, просто для меня, отсутствие поддержки * не является краеугольной проблемой.
UFO landed and left these words here
Ага.
Сначала добейся (с).
Написать относительно не сложно, но этот пункт про велосипеды, о котором я писал.
Чем плох велосипед?
Он скорее всего хуже протестирован, чем стандартная библиотека
У каждого разработчика будет свой велосипед и чужой код будет восприниматься хуже
Лишняя работа по поиску или написанию велосипеда
UFO landed and left these words here
Он скорее всего хуже протестирован, чем стандартная библиотека

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

Так что в своём велосипеде, скорее всего, всё будет гораздо хуже. :)
UFO landed and left these words here
Где-то в (около)официальных источниках было рекомендовано использовать название Golang для устранения коллизий и возможности поиска.
У меня недавно случился нехилый факап из-за незнания особенностей работы go с базами данных (db/sql). А именно: по умолчанию количество открытых соединений к БД не ограничено, это надо делать вручную при помощи функций SetMaxOpenConns и SetMaxIdleConns. Ну а если это значение не указать, то при возросшей нагрузке забьется весь пул соединений к БД, и все остальные запросы будут просто отфутболиваться с ошибкой.
Да, таких моментов много в любой платформе. Но ведь… В настройках любой DB может быть любое кол-во соединений и они могут использоваться\переиспользоваться по разному.
Вообще интересно стало: неужели где-то в языках на уровне драйвера DB есть встроенное ограничение на кол-во коннектов?
Тут скорее претензия к документации. Эти две функции лишь кратко упомянуты на этой странице документации, и нигде более. Про механизм connection pooling'а ничего не раскрыто. Да даже в большинстве примеров в интернете (в том числе в официальной вики на гитхабе) про них ничего нет. Хотя момент как бы довольно важный.
А раскрывать и не нужно. Для деталей есть код, а основная информация уже в документации. В том числе то, что библиотека использует пул подключений
Простите, но ради того, чтобы писать программы на C++ или Go, я что, должен изучить исходники всей стандартной библиотеки?
Описанная мной проблема возникает только при нагрузке. Если не проводить нагрузочное тестирование (да, грешен) и не знать про подобные тонкости, то предусмотреть ее практически невозможно. Поэтому я и считаю, что подобные вещи обязаны описываться в документации.
На самом деле знание + тестирование обязательно. Не важно какой язык\платформа\библиотека. Т.е. такие вещи должны освещаться в каких-то базовых курсах\статьях чтоли…
Все абсолютно библиотеки требуют тестирования перед применением, вы как в первый раз вообще. Детали реализации не должны быть в документации, именно так. Наружу выставлены методы и достаточно информации о том, что они делают. Это как бы везде так, по крайней мере в серьезных фреймворках и больших библиотеках. В закрытых библиотеках так вообще черный ящик. А тут вам дается исходный код, чтобы при крайней необходисти узнать все точно.
Мда… Собирался на выходных поизучать этот язык… Прочитал про особенности и коментарии и понял, что это не тот язык, на котором мне хотелось бы писать…
А в чем проблема? Половина особенностей тут только от незнания языка от слова вообще. Аж смешно от большинства пунктов
GoLang — это не для чукчей-писателей.

В принципе, если писать на Java, то Eclipse почти всё из вышеперечисленного в статье списка, т.е. свойственного «индусскому коду» помечает жёлтым цветом и приходится все эти «желтки» править, хотя компилятор их переварит и никто не заставляет. Т.е. если бы под GoLang был аналогичный IDE, который бы помечал бы всякий «индусский код» до компиляции, а не после, то ИМХО процесс был бы гораздо дружественным и более приятным.
В Visual Studio Code есть отличный плагин для Golang-а, который делает вышеописанное, разве что индусокод не помечает желтым. Но вещи которые не дадут коду скомпилироваться указывает. Переехал на Code с LiteIDEб и доволен.
UFO landed and left these words here
UFO landed and left these words here
Вместо ошибки можно было бы просто предупреждать, при отладке кода не очень удобно, лучше потерять миллисекунды на сборку лишнего кода, чем время программиста на переход в начало файла, а потом ещё и обратно, где код до этого писался. Ладно ещё прерывать компиляцию при go build, но при go run то зачем останавливать её из-за такой мелочи?

В общем-то это наверное единственное, что меня не устраивает, да и то, проблему решил с помощью среды разработки, стал использовать VS Code, и вообще забыл про import, он сам автоматически формируется и при этом ещё разбивается на группы и сортируется.

А вот остановка компиляции при неиспользуемых переменных это благо, позволяет выявить ошибки в коде, навроде определения переменной в блоке, вместо присваивания, например: a := -1; if a < 0 {a := 0} выдаст ошибку, и убережёт от долгого поиска лишнего двоеточия, и кроме того, заставляет писать законченные куски кода, раз объявил переменную, будь добр, доделай дело.
Go просто очень строг в своей идеологии — или так, или никак. В конечном итоге это только на благо. Потому что, что вот обычно делают с варнингами? Правильно, игнорируют. Поэтому нужно сразу бить по руками, чтобы потом эти тонны неиспользуемых импортов, про которые все давно забыли, не попали в релиз, не тормозили билд машины и не сжирали место на диске.
Так и говорю, достаточно быть строгим лишь при сборке проекта (go build), а при отладке (go run) можно и послабление дать, чтобы время разработчика не отнимать. Да и то, это касается лишь неиспользуемых import, с переменными это может иметь неприятный эффект, когда не заметили, что используется := вместо =
Чем раньше почищено — тем быстрее работать дальше.
UFO landed and left these words here
UFO landed and left these words here
Т.к. винда говорила «че-то оно как-то названо слишком длинно».

Go как-то защищает от таких проблем?

UFO landed and left these words here
UFO landed and left these words here
JavaScript до ужаса кривой язык.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Боюсь что читал. Но он впринципе не особо дизайнился. Сейчас ES6+ конечно намного лучше. Но суть все та же: callback hell, итд, итп. И это уже никогда не уйдет из языка.
Одни профи кругом со своим мнением
;)

Callback hell — это прежде всего свойство общепринятой методологии «как писать», свойство конкретных библиотек.

Сам язык не мешает вам использовать callback напрямую или использовать библиотеки реализующие обертку по типу await/async…
Да, в том то и дело что в Go идет пересечение дизайна языка вместе с идеологией (ограничениями). Поэтому не совсем корректно сравнивать лишь дизайн JS. Еще раз: ES6+ довольно красивый и не плохой, но проблем от этого в языке меньше не становится. Т.е. я рассматриваю язык в целом, а не только дизайн синтаксиса или какую-то другую часть.
UFO landed and left these words here
func main()
{
}

tmp/sandbox505802630/main.go:8: syntax error: unexpected semicolon or newline before {
Проблема в обманутых ожиданиях. Я ожидал новый современный язык общего назначения, который с оглядкой на недостатки других языков, предлагает некий некий новый мир, в котором прошлое исправлено и можно теперь жить по другому, красиво и изящно. Но здесь я вижу какой-то странный, на мой взгляд, вариант низкоуровневого языка. Непривычное поведение во многих случаях (например строки, реакция на неиспользуемые переменные и импорт, nil и многие другие) создаст дискомфорт в задачах общего назначения (читай рутина).

Так что нет, для работы мне не надо, а для души поищу (или подожду) чего нить другого.
Дело просто не в «фишках» а в идеалогии.
UFO landed and left these words here
Т.е. вы не видите разницы между «помечает» и «не компилирует, и выключить нельзя»?
UFO landed and left these words here
предлагает некий некий новый мир, в котором прошлое исправлено и можно теперь жить по другому, красиво и изящно

Именно это он и предложил для конкурентного кода, а это как раз серверный код. И именно там Go живет прекрасно, решая проблемы, которые создавали прошлые языки. И еще спецификация языка призвана решить костыли, которые традиционно качуют в С-подобные языки. И это тоже успешно получилось исправить. Из языка вырезали весь хлам, которые есть в «мощных» языках, чтобы разработчик просто сел и написал надежный быстрый код, который легко читать, а не сидел на форумах с вопросами, а какой же способ реализации ему выбрать. Я это тоже не понимал до тех пор, пока не написал на нем несколько серверных приложений. Сложно описать, какое удовольствие получаешь от серверного Go кода на горутинах, каналах и select'ах.
Не холивара ради, посмотрите в сторону Rust. Как человек давно занимающийся компиляторами могу сказать, что это именно «новый мир, в котором прошлое исправлено». Это язык, который ставит своей задачей решать фундаментальные проблемы, а не «быть модным и не таким как все».

Если хочется получить быстрое введение в те проблемы, которые Rust позволяет решать, советую посмотреть статью Fearless Concurrency.
Ну вот почему люди смешивают языки программирования в одну кучу ТОЛЬКО ПОТОМУ, ЧТО ИХ СИНТАКСИС отдаленно НАПОМИНАЕТ синтаксис С?

Вы бы еще на JavaScript предложили посмотреть. Или Swift. Или на уже умирающий D.

Ниша у Rust совершенно другая.
Я ответил на конкретный вопрос конкретного человека. Что-то там сравнивать и обсуждать я не собираюсь.
UFO landed and left these words here
Очень возможно. К сожалению, в его систему типов я еще не лазил, так что ничего сказать не могу. Вообще, эти товарищи Пирса читали точно. Многие концепции срисованы из книги почти один в один.
Вот вполне развернутое объяснение целей Go: https://talks.golang.org/2012/splash.slide
Вкратце: он разрабатывался для написания сложного ПО большими группами программистов. В общем, это скучный энтерпрейз-грейд язык, не особо веселый и дружественный.
9. Использование nil-слайсов (slice) и хеш-таблиц (map):
append() — инициализирует слайс, если необходимо.
Утверждение о возможности добавить значения в переменную, которая указывает на не инициализированный слайс (nil) в корне неверно.
Более того, нет такого понятия nil-слайс, есть, как я уже сказал выше, в котором не определен массив для хранения значений.
Вы правы, в процессе перевода тоже хотелось отметить недопонимание автора механизма append (если не хватает capacity в текущем слайсе, по сути создается новый), но, поскольку это перевод, оставил как есть.
Для тех кто пишет на Go Си биндинги стоит учитывать:
/*
Си код
*/
import «C»
Только так, с одним переносом (иначе компилятор ругается)
Запрещено использование pointer to pointer (с версии 1.6+)
Например:
var b *C.MyStruct = &C.MyStruct{}
err := C.MyFunc((**C.MyStruct)(unsafe.Pointer(&b)))
При переезде с 1.5 на 1.6 это стало довольно неприятным сюрпризом
UFO landed and left these words here

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


А про компилятор — в треде выше обозначили вполне понятный момент и даже пояснили, что проблема не в строгости, а в отсутствии возможности эту строгость временно уменьшить, тогда как inspections в IDE являются рекомендациями, enforce которых может происходить дальше (при релизной сборке, например), а не всегда при разработке. Это и плюс, и минус.


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

что проблема не в строгости, а в отсутствии возможности эту строгость временно уменьшить

А зачем ВРЕМЕННО уменьшать? Вот разработчики не согласны с любым уменьшением строгости. И я с ними согласен.
UFO landed and left these words here

Из строгого синтаксиса не следуют фашиствующий компилятор, равно как и наоборот.


И, конечно, ещё вопрос что называть строгим синтаксисом. Например, можно ли сказать, что у whitespace строгий синтаксис? Если писать для него лексер и парсер, то они будут описываться тривиальной грамматикой в ABNF/EBNF, но писать при этом на нём можно очень по разному.

UFO landed and left these words here
Неиспользуемые импорты и неиспользуемые переменные вот надо что бы все IDE и компиляторы на это ругались и не собирали приложения и библиотеки.
За вам неиспользуемые импорты и неиспользуемые переменные? Про запас?
Думаю, что ошибки, пойманные компилятором, подводными камнями никогда не станут (или избавят от других подводных камней).
Вопросы для тех, кто пишет на Го:
5,7. При беглом взгляде на код можно отличить объявление и присваивание?
6. Чем поле так отличается от переменной?
8. Почему такая разница в поведении контейнеров?
12. Чем отличается слайс от указателя на массив?
13. Неужели индекс элемента при перечислении важнее его значения?
22. Кто вообще дал такие привилегии логгеру?

UFO landed and left these words here
5. не даст скомпилировать, про себя могу сказать, что делаю такие ошибки крайней редко.

7. частая проблема, пару раз очень долго разбирался с кодом, спасает metalinter, прикрутил в atom, теперь вижу все такие блоки, без подсказок может стать адом.

6. Это особенность синтаксиса, грубо говоря, слева от := могут быть только имена переменных.

8. nil это константа без типа, язык строготипизированный, чтоб не творить магии, «дефолтного» типа нет.

12. Лучше почитать в офф доке, слайс, это ссылка на массив + пара доп полей, для обеспечения динамического поведения.

13. Я думаю посыл в том, чтобы ходить по индексу, и изменять значение.

22. Это и правда ужасно, когда первый раз наткнулся на exit(1), в Fatalf, я не ожидал такого поведения, с тех пор пользуюсь другими библиотеками.
> 5,7. При беглом взгляде на код можно отличить объявление и присваивание?

Да. И такая локаничность объявления очень удобна.

> 8. Почему такая разница в поведении контейнеров?

Ради скорости.

> 12. Чем отличается слайс от указателя на массив?

https://habrahabr.ru/post/202948/

> 13. Неужели индекс элемента при перечислении важнее его значения?

key, value или value, key? Первый порядок — логичнее.

> 22. Кто вообще дал такие привилегии логгеру?

В сложных системах используют другие логгеры.
С помощью интерфейсов они совместимы со стандартными логгерами.
По поводу FileExists, как ни странно, в документации nodejs можно увидеть, к чему может привести его необдуманное использование: https://nodejs.org/dist/latest/docs/api/fs.html#fs_fs_exists_path_callback возможно, в го его не стали реализовывать по этой же причине.
Я привет FileExists только как пример, и уж разработчик разберется обоснованно ли он его использует.
Но даже если вы правы, допустим, почему в Go нет например и функции Round делающей округление?
UFO landed and left these words here
Хотите найти недостатки начните писать на Го, что то полезное и они сразу полезут.
Я на Го пробую писать всего 2 недели, написал пару серверных приложений, поэтому к экспертам себя не отнесу,
Но куда не ткни, везде тихий ужас.
UFO landed and left these words here
Интересно, какими вы ещё языками пользовались, на основании опыта общения с которыми, вы не видите очевидных недостатков Го. Наверное если бы это был первый язык в жизни и не с чем было бы сравнивать, но увы.
UFO landed and left these words here
Я не знаю куда вы меня загнали и зачем вы это делаете, я язык обсуждаю и конкретные его недостаки, которые выше приводил, а вы меня загнать пытаетесь, с вами все ок?
Гонения на неверных признак религиозного фанатизма?
UFO landed and left these words here
Если виден недостаток нужно пойти и открыть Issue/Pull Request.
Если это действительно bug/недостаток он будет исправлен.
Если это стон от недостаточной квалификации, будет получено немного опыта и боли. :)
Ок, про функцию Round есть issue, закрытое по причине «нам это не надо».
А так же есть религиозная догма в одной из вики Golangю Примерного содержания: Если чего то нет в Go, то это ненужно, довольствуйтесь тем, что есть ибо нам виднее как нужно.
UFO landed and left these words here
Посмотрел.
Вот 2 варианта округления: https://play.golang.org/p/Xog_9wXSqj
Один из них, самый популярный выглядит так: math.Floor(f + .5)
Вопрос, зачем для самого популярного варианта плодить сущность если он элементарен, понятен и расширяем?
Т.е. Вы предлагаете сделать что-то типа math.Round(f, 0) вместо math.Floor(f + .5)?
Ну и чем же это надо обосновывать? Не забываем про общую архитектуру (нельзя сделать значение для функции по умолчанию).
> Один из них, самый популярный выглядит так: math.Floor(f + .5)
И абсолютно неправильный. Потому что по стандарту IEEE 754 для floating point при округлении -3.5 должно быть -4, а оба описанные по ссылке методы дают -3.
Т.е. Вы предлагаете сделать еще If/case на ровном месте чтобы поддерживать еще один вариант.
В этом то и суть, зачем? Сделайте math.Floor(f — .5) если округляете отрицательные значения.
Хотите универсальности? Сделайте навороченную функцию в 5 раз медленнее и на 20 строк кода.
Выбор за Вами.
> Вы предлагаете сделать еще If/case на ровном месте чтобы поддерживать еще один вариант.
Я предлагаю ввести функцию, которая делает это правильно. Если вы хотите правильно округлить число знакового типа, вам ПРИЙДЕТСЯ расширить приведенные формулы.

> В этом то и суть, зачем?
Как раз затем, что выше описаны два неправильных но очень часто используемых без знаний об потенциальной ошибке костыля.

> Сделайте навороченную функцию в 5 раз медленнее и на 20 строк кода.
А может не будем кидаться крайностями? Округление — это типичная операция.
Уделил немного времени: вот корректный вариант https://play.golang.org/p/kIOGJMGafI и то, есть что доделать (см. комментарии).
Элементарный тест производительности представлен, вот результаты:
Round(3.5, 0): 10.0159ms
math.Floor(3.5+.5): 2.0011ms
Разница в скорости в 5 раз. Я прямо угадал. :)
Буду рад дальнейшему обсуждению по сути.

p.s. чтобы работало время, тестировать надо локально.

Т.е. Вы мотивируете отсутствие корректной реализации тем, что она медленнее некорректной?
Давайте по такому же принципу вместо сортировки будем только первые 2 элемента сравнивать, так ведь быстрее.

Ну а почему это не может являться мотивацией? Сравнение, кстати, абсолютно некорректно.
Ну а почему это не может являться мотивацией?

Наверно потому, что быстро делать не то, что нужно, никому не надо…
И почему сравнение некорректное? И то и то будет правильно работать в некоторых случаях.

В случае Round — в большинстве.
В случае сортировка — почти никогда.

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


Пример на C# http://ideone.com/KTbHGi


Может быть из-за этого и добавляют встроенные функции для таких операций?

Может быть.
Вообще Go написан на Go. Так что встроенность мало чем поможет. :)

К нашей великой радости, на Go написана только каноничная версия Go. Модуль math напичкан оптимизациями под разные процессоры https://go.googlesource.com/go/+/master/src/math/, которые должны быть эквивалентны каноничной версии

Спасибо. Не знал.
Тогда выходить что надо требовать чтоб добавили нормальный Round на C! :)
А потом кто-то захочет вместо банковского округления — математическое, и придется дополнять функцию, вон в пхп например 4 способа поддерживаются http://php.net/round, в других языках тоже по несколько вариантов (которых вообще не мало https://ru.wikipedia.org/wiki/%D0%9E%D0%BA%D1%80%D1%83%D0%B3%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5 ), и часто это вызывает проблемы у людей, которые берут метод по умолчанию, не зная, как он точно работает.
Почти в каждом первом языке есть floor, ceil, чуть реже round, а иногда еще и trunc. То, что в php через параметры одной функции доступны они все — это конкретно его проблемы дизайна.
Опыт 20 лет: Java, C#, C++, C, Pascal, Object Pascal, 1C, PHP, JavaScript, TypeScript

1. Почему в Go должны быть вещи, имеющиеся в других языках? Почему это само собой разумеющиеся? Зачем нам вторая Java или второй С++?

Просто потому, что человечество придумало уже какие-то программные концепции — так давайте их все запихаем в очередной новый язык?

Так ведь было уже — PL/I. Им невозможно пользоваться. Так и не было создано ни одного компилятора, который поддерживает на 100% синтаксис PL/I.

Язык Go ФОКУСИРУЕТ программиста и заставляет самого брать ответственность за узкие места в программе (отсутствие remove, например, при наличии append)

Многоопытные авторы языка фокусируют вас. Да, принудительно.
Но другие многоопытные коллеги (Docker, Dropbox и пр.) проверили многоопытных авторов — и сказали — это хорошо.

2. Язык — это всего лишь инструмент. Не считаете, что он подходит — выбирайте другой.

А вот аппеляция к Docker — это зря.
Не знаю, как "многоопытные" коллеги могут каждый релиз ломать обратную совместимость и файловую систему, а потом предлагать хранить данные в контейнерах.

Дополню свой ответ тем, что у них не было особо выбора, на чем писать помимо Go. Не на С++ же.

А разве это не вы тут рядышком в комментариях утверждали, что выбор языка Go для серьезных продуктов — это галимый маркетинг?

Теперича утверждаете — что и альтернатив нет?

Юлите, меняете мнения по 100 раз на дню…

Я не помню такого, если было — ткните меня в это.


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

UFO landed and left these words here

Маркетинг — это одно, а неиспользуемые импорты — это другое :)


Просто, если бы не было маркетинга — критики было бы меньше, так как всем было бы пофигу на язык. Например, как в случае с D.

Это не маркетинг. А евангелизм.
Он — бесплатный и добровольческий.

Люди освоили, испытали и — делятся опытом. Бесплатно. Это не маркетинг, это не за деньги.

Что вам не нравится?
Что люди УЖЕ освоили Golang, что он уже В МЕЙНСТРИМЕ у многих КРУПНЫХ проектов, а в ВЫ ВСЕ ЕЩЕ ДУМАЕТЕ?
Это не маркетинг. А евангелизм.

Название ничего не меняет.


Что люди УЖЕ освоили Golang, что он уже В МЕЙНСТРИМЕ у многих КРУПНЫХ проектов, а в ВЫ ВСЕ ЕЩЕ ДУМАЕТЕ?

У вас там стул впорядке? Я просто не знаю, как этот капс читать, но когда я читаю текст в голове, то получается, что вы прямо кричите.


Два года назад все осваивали javascript + nodejs. Как-то поутихло.

Меняется — маркетинг это за деньги. Вас там убеждают, что черное это белое. Были бы бабки в очередной смене цвета.

Евангелизм — это из опыта, из практики и совершенно бесплатно. Вам ДОБРОВОЛЬНО рассказывают, о том как у них все ПОЛУЧИЛОСЬ.

Вы в каком времени живете?
В крупных проектах уже намного более чем 2 года назад с Ноды сползли в пользу Go.

Ну или вы занимаетесь мелкими поделками — там, да, Нода только только пришла из мира «больших систем».

Я на Go уже 4-й год сижу. И уже тогда golang был в мейнстриме. У вас точно нет машины времени? Вы нам пишете примерно из 2008 года…

Окей, четыре года назад. Суть то не меняется.
Появится новый язык, вот как Go, только лучше, и все начнут переписывать вещи на него.

Это лично я 4-й год.
До того, когда я начал — я тоже долго присматривался.

Еще задолго до меня началось практическое использование Go в серьезных проектах. Он ведь от рождения создавался не как исследовательский, а как практический проект языка. Со стапелей — сразу в дело.

Появится очередной язык, который делает ЦЕЛЕСООБРАЗНЫМ переписывание — начнут переписывать.

Появился D — переписывать не бросились.

Появился Golang — тогда да, переписывать нагруженные веб-сервисы стало целесообразным.

Много лет назад (ну около 5-6) ваши слова о том, что golang — это всего лишь мода, были бы разумными.

Сейчас — уже мейнстрим, уже несколько лет как мейнстрим.

И проверенный в деле на серьезных задачах в том числе — масштабы Dropbox, Youtube, CloudFlare, Bitbucket и пр. и пр…

Ребята выбрали себе путь совершенствования без оглядки.
Это вполне допустимый путь — ведь старые версии Docker остаются доступными. Всегда можешь использовать старые, проверенные уже в продакшене.

Бекпортирование фиксов, обновление безопасности и утилит тоже обеспечили? Если нет (а оно так и есть), то и пользоватся старыми версиями тоже нельзя.

Какое это имеет отношение к НЕДОСТАТКАМ ЯЗЫКА программирования?
На Go написан серьезный продукт, ежедневно запускающий миллиарды контейнеров…

К тому, что называть разработчиков Docker — многоопытным, это как-то вот совсем неправильно.


То, что они написали обертку на lxc, который был не очень удобен и теперь ее допиливают — это здорово. Но проблемы Docker от этого никуда не пропадают и большинство этих проблем похожи на проблемы из-за неопытности, которая сильно сказалась на старте проекта.


А к недостаткам языка никакого. Но это же вы аппелируете к разработчикам Docker.

UFO landed and left these words here

Шутку понял, но не понял, причем тут она :)

ПО Докер — открытое, любой может скопировать.

Тем не менее, используется прежде всего Докер, а не его клоны (вы их вообще назвать-то сможете, эти клоны? ), при том, что в инфраструктуре на базе Докера заинтересованы весьма богатые конторы — могли бы клонировать, если бы это было целесообразным.

Значит, ребята достаточно квалифицированы.

Докер — СТАНДАРТ ДЕ-ФАКТО.

А вы все пытаетесь его очернить только потому, что он написан на Go.

А вы все пытаетесь его очернить только потому, что он написан на Go.

Мне плевать, на чем он написан. Мне не плевать на его недостатки, которых море. Например, вот тут можно прочитать (часть придирок тут правда просто бред) https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/


По поводу клонок и альтернативных решений — mesos, rkt, atomic и это только первое, что приходит на ум. Существенная проблема только в том, что пока они разрабатывались, ребята уже закодили Docker и теперь развлекаются. + опять же у них довольно хороший маркетинг.

С таким подходом… Можете написать какие стеки часто используете и я напишу что из этого маркетинг (90%), и где что трууушно… Надо?)))

Нет, потому что так и будет (я про 90%).
Но маркетинг же не делает ребят из Docker трушними программистами, которые правильно разрабатывают продукт?

Делает, если смотреть с прикладной стороны.
1. Прикладная. Docker успешный продукт. Это уже показатель трушности, в том числе и программистов. :)
2. Теоретическая. Трушность будет только в самой хардкорной математике. Программирование не тру.
Оффтоп конечно но куда же без: немного троллинга богу троллинга и любителю троллинга. %)
1. Мне кажется, тут нужно оценивать успех всей команды, а не программистов. В истории куча примеров написанных так себе продуктов, которые становились прибыльными, потому что решали важные и насущные задачи прямо сейчас, а не через 2 года.

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

2. Тут сложный вопрос. У меня действительно важный претензий в Docker только три: обновления без поддержки предыдущих решений и предупреждений о том, что «все плохо», документация и то, что управление жестким диском все на тебе (особено жесткого это в случае регистра). Поправили бы все это и был бы отличный продукт.
Простите, вы не в теме.

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

2. mesos — гораздо более грандиозная система, целая операционная система для датацентров. В то время как Докер — локальная система управления контейнерами.

Вы пишете о том, в чем не разбираетесь.
  1. Это инструмент призванный исправит недостатки Docker. Вы просили меня назвать клоны, я назвал.
  2. Окей, если я скажу mesos-container, станет лучше? В целом, там так же есть изоляция и контейнеры. Да, оно большое альтернатива Docker-swarm + Docker, чем самому docker, но контейнеры то там другие.

Или вам нужны именно технологии, которые были до Docker? Тогда есть lxc и chroot.

Недостатки есть у всех.

Тем не менее, Докер — мейнстримовый продукт.
ЗАСЛУЖЕНО.
Стандарт де-факто.

Речь вообще о другом.

Разработчики Докера выбрали инструмент — и не прогадали.

Распространенность, в том числе — и благодаря особенностям языка, который упростил его написание, отладку и портирование.

Огромное количество СЕРЬЕЗНЕЙШИХ продуктов реализовано на golang.

Люди поумнее вас и поумнее меня выбрали его — и НЕ ПРОГАДАЛИ.
А вы тут до сих пор ищете идеальный язык…

Кто-то перешел на Go с Node, кто-то c Python, кто-то с Java.
Об массовых ситуация ОБРАТНОГО перехода — не слуху не духу.
Тем не менее, Докер — мейнстримовый продукт.

Контейнеризация — это мейнстрим. Docker просто самый популярный инструмент, который делать контейнеризацию проще. Но это не делает его разработчиков крутыми, это делает крутым того, кто придумал такую концепцию раньше других. Разницу чувствуете?


Огромное количество СЕРЬЕЗНЕЙШИХ продуктов реализовано на golang.

Огромное количество "СЕРЬЕЗНЕЙШИХ" продуктов реализовано на java, python, c#, javascript. И что? Это как-то исправит недостатки языков?


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

А Go значит вот идеальный?)

Я разве писал, что нельзя уже писать на Java, Python, C# — просто потому что появился Go?

Вопрос в другом: почему вы ожидаете, что Go будет делать то же самое, что и Java? Зачем пихать в Go то, что уже есть в других языках? Тогда это и будет Java, Python, C#. А они УЖЕ есть.

Идеал — недостижим.

Go достаточно развит для серьезного практического использования. Ровно это я и хочу сказать.

На нем УЖЕ и очень ДАВНО пишут серьезнейшие проекты. Крупные конторы. Опытные программисты, которые умнее и вас и меня.

А вы все еще живете в прошлом.

Go достаточно развит для серьезного практического использования. Ровно это я и хочу сказать.

Ну так у него есть недостатки по моему мнению, что мне мешает на них указать?


PHP вот тоже готов для сереьезного практического использования уже лет 10. И что?

Для того, чтобы ПОНИМАТЬ то, о чем вы пишете — неплохо бы иметь опыт. Не теоретизировать, а иметь СОБСТВЕННЫЙ опыт.

Пока ваши претензии выглядят так:

«Я привык иначе» — какой же это довод? Все языки разные.
Что из того, что вы привыкли иначе — то же был другой язык.

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

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

Это всего лишь ваша привычка. И отсутствие у вас опыта работы на больших проектах. Не более того.

Когда сначала в языке появляется одна бесполезная вещь, которую нельзя отключить (типа импортов), а потом, что бы убедить всех в том, что это нормально, авторы языка разрабатывают тулзу для автоимпорта (у которой проблемы с версионностью как и у всех Golang либ в целом) — это дичь.


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


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


Особенно смешно то, что никто из тех, кто любит Go не может просто пожать плечами и сказать "Ну хз, захотелось и вплили".

Нет, как раз сам подход «так надо, потому что так надо» хорош (потому Go и занял свою растущую нишу). Спорить можно только о конкретных решениях.
UFO landed and left these words here
Нет не правы, я сам предложил Golang и взял на тест. Хотя у меня есть языки которые мне субъективно нравятся, наверное есть у каждого.
UFO landed and left these words here
UFO landed and left these words here
Я не особо силён в Go, но количество WTF просто зашкаливает. Есть какая-нибудь документация почему было сделано именно так, а не иначе?
Логика + ключевые слова: code style, effective go. Обсуждения также можно погуглить по конкретным моментам.
Вот в прошлый раз меня такими же словами обозвали. Погуглил, но все ответы сводились к «потому что Пайк так сказал». Взять ту же тему коды возврата vs исключения (статья здесь с id 269909) — так там в комментариях удивляются почему это реализовано в языке именно так и считается хорошей практикой. Собственно, ответа на эти вопросы я и не нашёл.
В любом языке есть идеолог/группа идеологов отвечающих за развитие языка. Что Вы еще хотите найти? Не смогли найти какой-то конкретный ответ — можно ведь спрашивать у разных людей, вплоть до Пайка.
UFO landed and left these words here
UFO landed and left these words here

В целом, все так — вам не нравится то, что нравится Пайку — Go не ваш язык :)

Я бы даже сказал не Ваша ниша в разработке… ((
Есть же замечательные статьи — почему плохи исключения в Java или почему от них отказались в Google для C++.
http://neverworkintheory.org/2016/04/26/java-exception-handling.html
https://google.github.io/styleguide/cppguide.html#Exceptions

Если вкратце: не все так здорово с исключениями.

Лет 20 назад, когда еще были попытки развить тематику исключений в Java, люди в исключения еще верили. И при попытке отказаться от них тогда — вертели бы пальцами у виска.

Сейчас — люди поумнели и смотрят на мир шире.

Извините, но вы сами читали что по второй ссылке написано? Там написано, что причины в основном исторические. Более того:


On their face, the benefits of using exceptions outweigh the costs, especially in new projects

и


Things would probably be different if we had to do it all over again from scratch.

Удивительно, как люди продолжают ссылаться на Гугл как аргумент против исключений, даже не прочитав, что же там на самом деле написано.

> потому что Пайк так сказал

Ну так это же хорошо, все в одном стиле, даже если этот стиль не нравится, то к нему можно просто привыкнуть.
Как противоположность можно привести php, где есть определенная неконсистентность языка.
А можно привести в пример и python, где pep8 лишь рекомендация, но которую соблюдают все.
Почему Go должен копировать другие ЯП?
Вопрос от новичка, возможно наивный.
Пункт 31, последний листинг. Допустим
workerCount := 100

и doit выглядит следующим обоазом
func doit(workerId int, wq <-chan interface{},done <-chan struct{},wg *sync.WaitGroup) {  
    fmt.Printf("[%v] is running\n",workerId)
    defer wg.Done()
    for {
        select {
        case m := <- wq:
            time.Sleep(time.Second * 1) // чтобы наверняка задействовать больше одной горутины
            fmt.Printf("[%v] m => %v\n",workerId,m)
        case <- done:
            fmt.Printf("[%v] is done\n",workerId)
            return
        }
    }

Допустим все воркеры запущены, в канал wq посланы все данные и наконец закрыт канал done, т.е. во
всех запущенных горутинах доступны для получения оба канала wq и done. Возможна ли ситуация, когда
все select во все горутинах случайным образом прочтут предсмертное послание из done и закончат свое выполнение? Или я не правильно понимаю логику работы select? Или вообще ничего не понимаю? :)
Пока wq не пуст — все go-routine (видимо doit завернут в go-routine? ) будут считывать данные из него.
Как только wq пуст — будет предпринята попытка прочитать из done.
Поскольку done закрыт — будет завершена процедура

Если вы используете done как сигнал о завершении работы — то следует поместить done выше, сделав его самым первым в select

И закрывать done не сразу, а только тогда, когда вам нужно завершить все go-routine с doit
Пока wq не пуст — все go-routine (видимо doit завернут в go-routine? ) будут считывать данные из него.

то что завернут в го-рутину — это очевидно из примера в п.31 статьи. ПОЧЕМУ будут считывать из wq ??? Ведь если у select-у доступны для прима данных несколько каналов, то данные выбираются из одного из них СЛУЧАЙНЫМ образом. Или я все-таки что-то недопонимаю? :)
Данные выбираются из первого доступного среди веток в select.

Так как нет ветки default — то select должен быть заблокирован до тех пор, пока какой нибудь из каналов (wq или done) не будет закрыт или в него не поступят данные.
Если вы используете done как сигнал о завершении работы — то следует поместить done выше, сделав его самым первым в select

а зачем?? чтение при нескольких доступных каналах производится из случайным образом выбранного канала.
или я неправ?
UFO landed and left these words here
Речь шла о ЗАКРЫТИИ done. Закрытый канал прекрасно читается.

Я постоянно использую подобную методу — создаю фиктивный канал chan struct{}, в который никто никогда не пишет, а использую этот канал для сигнализации, что объект/структура/сервис более не используется — просто вызвав close(done).
Это разблокирует все select и корректно завершает go-routines
В пределах одного select чтение происходит не случайным образом, а сверху вниз.

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

Если второй канал ничего не дает прочитать, а default нет, то select останется заблокированным — будут предприниматься попытки прочитать из двух каналов.

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

Но мне все же представляется логичным помещать сигнализирующий о прекращении процесса done — в самый верх. Это на случай начального входа в select, когда мы еще не знаем — сразу же мы из него выйдем или будем заблокированы.

Ведь если процесс уже завершен ДО НАЧАЛА SELECT, то нам НЕ СЛЕДУЕТ ЧИТАТЬ НИЧЕГО ИЗ WQ, а правильным будет сразу выйти по ветке done.

Советую ознакомиться с документацией по select, особенно на пункт 2, дабы не наткнуться в какой то момент на потерянные данные. Для решения проблемы «приоритезации» опций внутри селекта, насколько я знаю, пока нет общего решения, можно погуглить golang select priority, решения есть, разной степени странности.
Не выдумывайте проблем на пустом месте.

ОК, специально для вас РАЗЖУЮ:

select {
case < — каналСигналаВыхода:
default:

select {
case<-каналСигналаВыхода:
case d:= < — каналСДанными:
}

}
В этом примере невозможна ситуация, когда close(done) выполнится перед тем как воркерами будут получены все данные из wq. Потому что канал wq небуферизованный, до close(done) управление дойдет только после того как последнее значение будет отправлено в канал wq и вычитано в воркере (потому что согласно go memory model: A receive from an unbuffered channel happens before the send on that channel completes).

Если у wq будет буффер — тогда поведение недетерминировано и воркеры могут завершиться до выполнения всей работы. В этом случае как-то по-другому нужно написать код.
Это при условии, что когда дело доходит до чтения wq, туда УЖЕ записано.
Если будут перерывы при записи wq, то select соскользнет в закрытый done и go-routine завершится.

Для меня самой удивительной особенностью оказалось то, что горутину нельзя взять и принудительно убить.
Вызываю к примеру я в своей горутине какой-то из сторонней библиотеки, которая, например, выполняет бесконечный цикл. Как мне после такого убить свою горутину (к примеру, по таймауту)?

Если это ваша goroutine — то легко.
Закладываете внутри вашего цикла конструкцию

for {
   select {
      case <- stopChan:
      default:
   }
}


Убиваете методом закрывания канала stopChan или методом записи в него.

пишу вам из 2022 года, тк статья популярна в наше время и ее читают прямо сейчас!

нужно сипользовать контекст context.WithTimeout, и в горутине в секции select слушать, если получили ctx.Done(), то остановить запрос

Only those users with full accounts are able to leave comments. Log in, please.