Комментарии 31
Про сам Go только 1 вопрос, остальное про бабки. ~когда же IT очиститься?~
Generics в Go долго выпрашивали, долго ждали. Подвезли. И вот я не заметил масштабного применения в серьезных code base. Единственный попавшийся мне пример элегантного и вразумительного использования -- клиент API OpenAI https://github.com/openai/openai-go
Интересно в avito есть практика применения generics? Приветствуется ли генерализация кода корпоративными стандартами?
Недавно шарился по вакансиям в DS/ML и у многих в стеке висит Golang, хотя раньше был Java
Почему Go такой странный
Ожидание: нехватка юнион-типов, недостаточно гибкие дженерики, нужен ли тернарный оператор или его функциональный аналог
Реальность: как вкатиться?? как назвать папки??? зочем софты????
А Го тут каким боком вообще?
Ожидание: нехватка юнион-типов, недостаточно гибкие дженерики, нужен ли тернарный оператор или его функциональный аналог
У гошников таких вопросов не возникает - видимо, такая предметная область у них. Продолжатели дела PHP? Вопросы есть только у тех кто смотрит на Го извне, из своих ЯП.
Вот, вроде адекватный аккаунт: есть интересные статьи, комментарии по делу, но иногда нутро берет верх и хочется просто кого-то обосрать, да? Без причины, просто душа просит.
Почему я плохо отношусь к PHP?
Проект у меня такой, ужжассс
Есть еще на шарпе, поинтересней будет
Хотя, я больше по алгоритмам и архитектуре, слава Богу
Так может быть стоит относиться плохо к проекту, а не к инструменту? Говно наклепать можно на чём угодно :)
PHP провоцирует плохой код
Без разделения на слои (разделение даёт меньше пользы чем на c#, ну никто и не делает)
Без типизации (можно, значит не будут), одни словари без описания
Простые crud я не против PHP, но не в ответственных системах с развитой бизнес логикой на 200.000 строк
Без разделения на слои (разделение даёт меньше пользы чем на c#
А в чем тут языковая разница?
Без типизации (можно, значит не будут)
А можно не надо? Странная у вас логика. Если можно сделать хрень, значит её надо делать... Лампочку тоже можно в рот засунуть, но вы же этого не делаете?
Простые CRUDы можно клепать на чём угодно, хоть на PHP, хоть на Go, хоть на C++. Так же и большие, сложные системы можно делать на чём угодно, в т.ч. и на PHP. Если у вас не хватает компетенций использовать все возможности, которые предоставляет ЯП и инструменты, будь то строгая типизация, гибкий PHPDoc для описания различных структур "в массивах/хэштаблицах", статический анализ, и т.д., то точно ли дело в языке?
Ну а ещё, развитая бизнес-логика развитой бизнес-логике рознь. Где-то можно простую вещь сделать просто, а где-то надо нагородить абстракций над абстракциями, обмазать всё десятком интерфейсов, и внезапно 10 строк реальной бизнес-логики превращается в 1000... Это я к тому, что оценивать сложность/серьёзность проекта по LoC -- это какое-то писькомерство. У кого больше.
Go — это не случайный эксперимент, а результат многолетних исследований и практических наработок в области системного программирования.
Ну да, ну да. Для примера, рассмотрим Хелловорд (https://gobyexample.com/hello-world).
package main
import "fmt"
func main() {
fmt.Println("hello world")
}Вопрос: как в Go пишутся имена пакетов?
Ответ: в Go имена пакетов пишутся и как строки и как идентификаторы, поочёрдно.
Вопрос: начиная с?
Ответ: начиная с идентификатора, чтобы часто необходимый main был двусмысленным.
Вопрос: а это зачем?
Ответ: чтобы было хоть какое-то основание утверждать
Освоение Go вызывает схожие трудности у разработчиков с разным бэкграундом
не добавляя во фразу "за вечер понедельника".
По вечерам, за ужином, читаю учебник по Go и программирую понемногу. Фазу хелловорлда уже миновал не заметив в ней ничего странного.
Что за учебник читаете?
Дак первоисточник https://go.dev/learn/
Мне как-то пришлось сделать PR в соседний проект примерно на 200 строк, внутрь довольно запутанного модуля. Потребовалось часа четыре, хватило для твердого осознания: на этом я больше не буду писать никогда в жизни, даже за миллион в час.
Такое же было ощущение на PHP проекте когда чтобы понять что происходит в полном инциденте понадобилось прочитать 4000 строк кода. Бизнес логика и состояние были размазаны по совершенно неожиданным частям приложения и IDE мне никак не помогал. А типов не было совсем.
Правда, ужасные проекты на c# я тоже видел
Хард-скиллы объективно проще оценить и развить через литературу и курсы
Через литературу и курсы невозможно развить хард-скиллы. «Потрындеть о языке в курилке» — это не хард-скиллы.
Хоть убей, не могу хейта голанга понять. Не нравится - не используйте, но нет, каждый второй своим долгом считает грязью облить. Пишу на го (с версии 1.6) всю свою карьеру в разработке, слезы радости вытираю. И деньги хорошие, да
Хейтерам - вы, надеюсь, не используете в работе ни Docker, ни Kubernetes, ни Nats, ни Grafana, ни Terraform, да? Они ведь на богомерзком Golang написаны, тьфу-тьфу
Не нравится - не используйте
Индустрия методом проб и ошибок рождает решения, совершенствуется. Очень часто случается, что сценарий использования не совпадает с идеями, на которыми инструмент создавался. На каждом углу трубят, что для каждой задачи - свой инструмент, так как же понять границы применимости и сильные/слабые стороны, если все время не шатать их обсуждением опыта с коллегами? Каждый такой наброс - это приглашение к дискуссии, проверка гипотезы.
Но тут интересно другое:
грязью облить
почему хейт инструмента скорбляет вас лично? Или вы глубоко в душе сами боитесь найти несокрушимый аргумент, разочароваться и пожалеть о том, сколько сил и времени вложили?😉
Golang без малого 16 лет существует, все никак не разберетесь? Меня в такие дискуссии не приглашайте, есть сомнения в профессиональных компетенциях участников.
Из которых более десяти он существовал без дженериков и на корпоративной многозадачности.
Пайк сам сказал: это язык для середняков («They [Googlers] are not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.»)
Может быть, нет ничего странного, что профессионалам с опытом разработки на разных языках, — он не очень-то нравится обычно?
Почему статья выглядит как "GPT вот тебе темы, сделай суммаризацию"
Давайте забаним Авито на хабре и разбаним только когда они сфоткаются с паспортом
Одна из главных фишек го это утиная типизация.
Плюсы: можно не писать в ООП
Минусы: это не четкий контракт
В duck typing нет формально объявленного контракта, а подразумевается набор требуемых методов. Например, если функция вызывает метод quack(), она ожидает, что переданный объект поддерживает quack(), но нигде это явно не записано. При изменениях в коде или смене команды трудно отслеживать, что именно должен реализовывать объект – компилятор об этом не скажет, ошибки обнаружатся только при выполнении. Это и есть неявный контракт.
конкурентность через горутины - скрыто синхронно или асинхроннонно будет выполнено, что даёт источник ошибок при синхронизации
А общем, для микросервисов да, для большого монолита нет.
Не привычно, что в го нет явного указания, какой интерфейс реализует класс (если реализует конечно). Ну как в плюсах нельзя тыкнуть на базовый класс и узнать. Надо чето исследовать(((
Почему Go такой странный, и ещё 8 холиварных тем про Golang