Comments 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/
Такое же было ощущение на PHP проекте когда чтобы понять что происходит в полном инциденте понадобилось прочитать 4000 строк кода. Бизнес логика и состояние были размазаны по совершенно неожиданным частям приложения и IDE мне никак не помогал. А типов не было совсем.
Правда, ужасные проекты на c# я тоже видел
Хоть убей, не могу хейта голанга понять. Не нравится - не используйте, но нет, каждый второй своим долгом считает грязью облить. Пишу на го (с версии 1.6) всю свою карьеру в разработке, слезы радости вытираю. И деньги хорошие, да
Хейтерам - вы, надеюсь, не используете в работе ни Docker, ни Kubernetes, ни Nats, ни Grafana, ни Terraform, да? Они ведь на богомерзком Golang написаны, тьфу-тьфу
Не нравится - не используйте
Индустрия методом проб и ошибок рождает решения, совершенствуется. Очень часто случается, что сценарий использования не совпадает с идеями, на которыми инструмент создавался. На каждом углу трубят, что для каждой задачи - свой инструмент, так как же понять границы применимости и сильные/слабые стороны, если все время не шатать их обсуждением опыта с коллегами? Каждый такой наброс - это приглашение к дискуссии, проверка гипотезы.
Но тут интересно другое:
грязью облить
почему хейт инструмента скорбляет вас лично? Или вы глубоко в душе сами боитесь найти несокрушимый аргумент, разочароваться и пожалеть о том, сколько сил и времени вложили?😉
Почему статья выглядит как "GPT вот тебе темы, сделай суммаризацию"
Давайте забаним Авито на хабре и разбаним только когда они сфоткаются с паспортом
Одна из главных фишек го это утиная типизация.
Плюсы: можно не писать в ООП
Минусы: это не четкий контракт
В duck typing нет формально объявленного контракта, а подразумевается набор требуемых методов. Например, если функция вызывает метод quack(), она ожидает, что переданный объект поддерживает quack(), но нигде это явно не записано. При изменениях в коде или смене команды трудно отслеживать, что именно должен реализовывать объект – компилятор об этом не скажет, ошибки обнаружатся только при выполнении. Это и есть неявный контракт.
конкурентность через горутины - скрыто синхронно или асинхроннонно будет выполнено, что даёт источник ошибок при синхронизации
А общем, для микросервисов да, для большого монолита нет.
Не привычно, что в го нет явного указания, какой интерфейс реализует класс (если реализует конечно). Ну как в плюсах нельзя тыкнуть на базовый класс и узнать. Надо чето исследовать(((
Почему Go такой странный, и ещё 8 холиварных тем про Golang