Каукин Игорь @Zanak
Backend и все что с ним связано. Немного — фронт.
Information
- Rating
- Does not participate
- Location
- Новосибирск, Новосибирская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Backend Developer, Fullstack Developer
Middle
From 120,000 ₽
Python
PHP
PostgreSQL
MySQL
Golang
Git
Docker
Nginx
Linux
Perl
Да только и вы лукавите: [1, 2, 3, 4, 5] — это массив целых какой размерности, int8, int16, int32, или 64 бита? Ваш вариант должен быть чуть побольше, хотя да, он будет все еще лаконичнее Go.
Я немного поправил ваш вариант с суммированием, максимально не используя ни чего выходящего за за спеки языка:
Что касается аргументов командной строки, как я понял, вы просто передаете имя файла и с ним работаете, тогда имя файла можно получить проще: я вот об этом — https://gobyexample.com/command-line-arguments
Ну не могли поклонники языка в раз, взять и его забыть. perl сгубило обилие костылей, например сбоку приделанная поддержка уникода, это раз, попытка через расширения затянуть в язык не свойственные ему идиомы (кто ставил каталиста поймет о чем я), это два, ну и очень долгое пиление шестой ветки, это три.
На мой взгляд, есть языки узкой специализации. Например perl, я до сих пор уверен, что для обработки данных, особенно не структурированных в виде БД, ни чего лучше не придумали. Попытка внедрить туда массу вещей, ранее ему не свойственных, стала одним из гвоздей в его гроб. Да, сейчас язык существует, у него даже есть почитатели, но если пых не только не растерял свою аудиторию, но, похоже ее даже приумножил, кто сейчас на практике использует perl?
Но даже изначальное ориентирование на универсальность применения не гарантия для языка. Сколько крупных проектов на D вы знаете? Я уж молчу про экзотику вроде ocaml-а.
Go вышел в прод раньше Rust, и возможно это не пошло ему на пользу.
Язык прост, и это большой плюс. Программистов должно быть много, тогда язык будет жить (затянувшаяся смерть php тому живой пример :) ). При своей простоте язык имеет конкретные проблемы в дизайне, которые авторы, хочется верить, устранят.
Что же касается нововведений, о которых сейчас любят говорить, дженерики, функциональная парадигма, дальше добавить по вкусу, то я за разумный консерватизм. Rust заявляет о бесплатной поддержке абстракций, ура, я за, когда мне это потребуется, я вспомню о Rust. Для сайта я, почти всегда, возьму питон или пых. Если мне потребуется обработать большой файл с данными, то это однозначно будет perl. Go тоже имеет свою нишу, и каждый его пользователь, скорее всего, обозначит ее по своему, Для меня — это сервис, который можно быстро сделать и запустить, потребности в чем — то большем пока не возникало.
То что сами авторы говорят о языке: https://golang.org/doc/faq. Искать по строке «Is Go an object-oriented language?».
По поводу значений по умолчанию: пробелы в дизайне языка — это повод их исправить, и отказ от инициализации по умолчанию — кардинальный и не самый умный ход, хотя бы потому, что может обрушить уже существующий код, независимо от того, прав автор или нет.
не возьмусь высказывать предположения, почему постройка этих типов вынесена в отдельную функцию, но для всех остальных типов есть new. Не нужно в особенностях дизайна искать более глубокий смысл, чем есть на самом деле.
похоже брякнул не до конца подумав. Имел ввиду, что скриптовые языки для сложных типов данных используют copy-on-write, а Go сразу выделяет память, но это не аргумент.
panic/recover?
Очень категоричное утверждение. Поддержка многопоточности не означает, что вы должны ее использовать. Как по мне, так Go — это Си без плюсов, но с немного странным синтаксисом и да, поддержкой многопоточности.
Эти предложения только мне кажутся странными?
Сами авторы языка говорят об отсутствии ООП в Go и только об эмуляции некоторых аспектов ООП дизайна.
Про легковесные акторы коллеги уже обращали внимание :)
Вот интересно, автор слышал про go vet…? (Если нет, то посмотреть здесь: https://golang.org/cmd/vet/)
Хотя наверное в чем-то упрек можно признать справедливым. Я не гуру Go, я только учусь.
Автор подмечает косяк в дизайне языка, и тут же все портит излишне категоричным утверждением.
Это вообще не понял о чем. Я легко могу объявить структуру указав типы для ее полей, или речь о чем — то еще?
Опять странные утверждения. Автор наверное имел ввиду автоматический вывод типа переменной исходя из ее начального значения, и даже если так, как и всякий автоматический алгоритм этот тоже может ошибаться.
Правилно сказать, что в Go отсутствуют шаблоны, в том виде, как это понимается в том — же C++. Более специализированные функции вполне реализуемы.
Повторюсь: кто вам сказал что Go является языком ФП?
Передача через канал атомарна, а вот изменение данных вне контекста из go-рутины без защиты мютексом — это да, ошибка. Даже базовые типы, вроде мапы или списка не являются потокобезпасными.
А вот и не правда. В документации сказано: The make built-in function allocates and initializes an object of type slice, map, or chan (only), что в моем вольном переводе звучит как «функция make предназначена только для создания экземпляров slice, map или chan».
Подозреваю что нет ни какого секретного заговора, просто нет поддержки шаблонов а-ля 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 комьюнити, выдвигайте свои предложения, а лучше делайте свои комиты в репо проекта и будет всем счастье.