Каукин Игорь Zanak

Извините, но не считаю тему раскрытой:

1. Не уяснил причину сравнения с плюсами. Это заметно разные языки. Более логично было сравнить, с каким нибудь скриптовым языком.
2. В perl есть, например, функция sort, которую можно использовать в функциональном стиле для сортировки массивов с чем угодно. Есть функция map, которую любят демонстрировать поклонники функциональной парадигмы. Автор этот момент опустил, хотя для иллюстрации они, на мой взгляд, более подходят, чем пример с замыканием.
3. Сама по себе механика обратных вызовов не является признаком функциональной парадигмы, потому как давно используется в perl, например при работе с GUI.
4. В чем прелесть использования FP в perl?

PS Возможно кому нибудь будет интересна книга: «Higher-Order Perl» by Mark Jason Dominus. Книга раздается в сети бесплатно, и она доступна для скачивания.

Есть конкретная задача, посчитать сумму элементов КОНКРЕТНЫХ массивов, и сделать это максимально лаконично, просто и понятно. Да, по хорошему следовало бы каждый раз заново выделять память под слайс. По поводу принципиальной необходимости это делать: если вы знаете способ написать сумматор для массива произвольных целых, не прибегая к рефлексии или другим нетривиальным приемам, я с удовольствием возьму ваш метод на вооружение. Я ни когда не утверждал, что я гуру разработки на Go. Я тоже учусь, и делаю это при любой возможности.

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

Go следит за типами, поэтому и приходится явно приводить тип (Да, да, да неявного приведения типов нет), и поэтому приходится выделять память.

Да только и вы лукавите: [1, 2, 3, 4, 5] — это массив целых какой размерности, int8, int16, int32, или 64 бита? Ваш вариант должен быть чуть побольше, хотя да, он будет все еще лаконичнее Go.

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

package main

import "fmt"

func Sum(slice []uint64) (acc uint64) {
	for _, v := range slice {
		acc += v
	}
	return acc
}

func main() {

    list8  := []int8 {1, 2, 3, 4, 5}
    list16 := []int16{1, 2, 3, 4, 5}
    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

	data := make([]uint64, len(list8))
	for k, v :=range list8 {
		data[k] = uint64(v)
	}
	fmt.Println(Sum(data))
	for k, v :=range list16 {
		data[k] = uint64(v)
	}
	fmt.Println(Sum(data))
	for k, v :=range list32 {
		data[k] = uint64(v)
	}
	fmt.Println(Sum(data))
	fmt.Println(Sum(list64))
}

Что касается аргументов командной строки, как я понял, вы просто передаете имя файла и с ним работаете, тогда имя файла можно получить проще: я вот об этом — https://gobyexample.com/command-line-arguments

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

У Rust, да даже у плюсов он по вашему более человечный? :)

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

Не уверен, что вы правы.

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

Но даже изначальное ориентирование на универсальность применения не гарантия для языка. Сколько крупных проектов на D вы знаете? Я уж молчу про экзотику вроде ocaml-а.

Не смотрел про 7, но 5 пых вроде как использует CoW, судя по существованию copy/deepcopy в питоне, та же фигня. Я уже признал, что неосторожно попутал ссылки на один инстанс и 2 разных инстанса с одинаковыми значениями свойств. Не вижу смысла продолжать.

Ок. Спор постепенно мигрирует в сторону холивара, и это пора прекращать.

Go вышел в прод раньше Rust, и возможно это не пошло ему на пользу.

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

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

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

То что сами авторы говорят о языке: https://golang.org/doc/faq. Искать по строке «Is Go an object-oriented language?».

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

А где тут противоречие? В том, что поведение задокументировано? Претензия ведь в том, что самому аналогичную функцию написать нельзя.

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

Можно объяснить чем так уникальные скриптовые языки и чем выделяется Go?

похоже брякнул не до конца подумав. Имел ввиду, что скриптовые языки для сложных типов данных используют copy-on-write, а Go сразу выделяет память, но это не аргумент.

Ок перечитал статью от начала и до конца. Стало только хуже.

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

panic/recover?

Упор на многопоточность.

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

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

Эти предложения только мне кажутся странными?

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

Сами авторы языка говорят об отсутствии ООП в Go и только об эмуляции некоторых аспектов ООП дизайна.
Про легковесные акторы коллеги уже обращали внимание :)

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

Вот интересно, автор слышал про go vet…? (Если нет, то посмотреть здесь: https://golang.org/cmd/vet/)
Хотя наверное в чем-то упрек можно признать справедливым. Я не гуру Go, я только учусь.

А что насчёт начального значения (zero value)? Каким оно будет для функционального типа, интерфейсного типа без nil? Думаю, что начальные значения — тоже плохая идея.

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

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

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

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

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

Манипулирование списком непрактично

Правилно сказать, что в Go отсутствуют шаблоны, в том виде, как это понимается в том — же C++. Более специализированные функции вполне реализуемы.

Ещё одна пощёчина Go от функционального программирования

Повторюсь: кто вам сказал что Go является языком ФП?

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

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

В Go есть «магическая» функция make. Похоже, она умеет делать с конкретными типами всё, что хотят авторы стандартной библиотеки.

А вот и не правда. В документации сказано: The make built-in function allocates and initializes an object of type slice, map, or chan (only), что в моем вольном переводе звучит как «функция make предназначена только для создания экземпляров slice, map или chan».

Что ещё важнее, range можно применять только к типам из стандартной библиотеки.

Подозреваю что нет ни какого секретного заговора, просто нет поддержки шаблонов а-ля C++, вот и все объяснение.

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

Рискну предположить, что операции сравнения реализованы только для стандарных типов, вот и все объяснение.
Возможно авторы отложили на потом решение вопроса: являются ли равными 2 инстанса структуры, если все значения их полей одинаковы. В скриптовых языках, вроде php или python, ответ на этот вопрос очевиден, с Go это не так.

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

Допускаю, что Rust выполняет более тщательную проверку, но говорить о полном отсутствии контроля со стороны Go нельзя.
Да, go требует отдельного телодвижения, в виде запуска go vet ..., и не очень понятно, зачем это было сделано.

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

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

PS Я прилично знаю Go, немного Rust. Честно говоря, за Rust я не взялся, только потому, что сами создатели еще недавно говорили, что Rust-у в продакшен пока рано.
Лично меня автор не убедил, в том, что я не прав. Да, оба языка «из коробки» имеют поддержку паралельного исполнения кода. Автор ни чего не сказал про конкурентность.
Rust в этом смысле выглядит перспективнее, но обоснованно говорить об этом, как мне кажется, пока рано.

PPS Пока, мне реально не хватает возможности контролировать судьбу горутин.
Да, ты ее запустил, и все. Работает она, упала с ошибкой, заблокировалась, ты узнать не можешь, если сам не закодировал. Ты не можешь ее даже завершить, если об этом заранее не позаботился.
Опять же, если говорить о многопоточности, немного напрягает двойственность каналы\и\или\мютексы. А если использовать и то, и другое, как это отражается на планировщике?

Эмоциональная статья ни о чем.

>>В Go особенно трудно придерживаться функциональной парадигмы
А кто сказал что Go — вообще функциональный язык? Функциональная парадигма хороша там, где есть для нее поддержка со стороны среды исполнения. Во всех остальных случаях — скорее зло чем благо.

Источники приведенные в начале статьи приводят подобные авторским рассуждения, на тему «почему Go это не C/C++», почему «Go это не Haskell», на мой взгляд — абсолютно субъективные.
В общем, бросил читать после 4 или 5 абзацев.

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