Тут разница не только в возможности наличия nil, но и в использовании. ИМХО, использовать ссылки для возможности установки nil - плохой вариант. Например, в этом коде изначальная переменная тоже изменится:
var with_nil *int64
anotherVar := with_nil
anotherVar = 123
По ссылкам я передаю сервисы (условные синглтоны), а данные (обычно DTO) - без ссылок. Конечно, это моего кода касается: во внешний я отдаю ссылки тогда, когда он требует :)
просто вы думаете что go это ооп язык, и сравниваете его с java, php и подобным
Все верно: я PHP-разработчик, а Go - новый для меня язык. Я сравниваю его с тем, к чему привык. Я понимаю, что там нет ООП, но речь не об ООП как явлении, а об оставленных возможностях. Например, создание объекта из структуры без заполнения всех обязательных полей. В PHP я бы был зол на того, кто так пишет) Но это не PHP, все верно, и ООП тут нет. Поэтому не стоит использовать этот язык там, где ООП было бы уместнее.
Как PHP-программист, первые недели работающий с Golang, хочу свои 5 копеек вставить.
У структур нет единой точки создания объекта, только кастомные статические конструкторы, которые использовать необязательно. Что ведёт либо к потенциальным ошибкам, либо к огромному количеству проверок на корректность заполнения полей.
Объекты-ошибки вместо исключений есть, но благодаря их обработкам код становится в среднем в 1.5 раза длиннее, чем аналогичный на PHP. Это мой опыт в моем проекте, у других людей разница может быть другой. Но она будет.
Категорически не согласен с фразой о строгой типизации языка. В нем присутствует утиная типизация, а не строгая. Твой интерфейс может случайно совпасть по сигнатуре с каким-нибудь другим, и реализующий один из этих интерфейсов класс будет реализовывать их оба, без вариантов. Либо метод структуры случайно совпадет по сигнатуре с каким-нибудь интерфейсом.
В Го нет nullable типов, но ссылки всегда могут указывать на nil. Благодаря этому даже не проинициализированная переменная любого типа содержит значение этого типа. Integer содержит 0, объект структуры - всю структуру. И нет никакого способа узнать, 0 в переменной лежит потому, что его туда сознательно положили, или это дефолтное значение.
Я отнюдь не хочу сказать, что один язык хуже или лучше другого. Они для разных целей. Го из коробки умеет быстро мапить json на структуры и делать крутую многопоточность благодаря горутинам. Моя первая программа на го - парсер сайта аренды квартир, который я написал за 15-30 минут (благодаря помощи ChatGPT :D). Но я бы не стал брать Го для вещей, где нужно описывать бизнес-логику. Уж лучше PHP: "правоверный" ООП для этого больше подходит и оставляет меньше места для ошибок.
Автор также не указал, что canvas — не единственный способ представления приложения в веб. Его можно так же скомпилировать в привычные html + css + js. Пруф.
Тут разница не только в возможности наличия nil, но и в использовании. ИМХО, использовать ссылки для возможности установки nil - плохой вариант. Например, в этом коде изначальная переменная тоже изменится:
По ссылкам я передаю сервисы (условные синглтоны), а данные (обычно DTO) - без ссылок. Конечно, это моего кода касается: во внешний я отдаю ссылки тогда, когда он требует :)
Все верно: я PHP-разработчик, а Go - новый для меня язык. Я сравниваю его с тем, к чему привык. Я понимаю, что там нет ООП, но речь не об ООП как явлении, а об оставленных возможностях. Например, создание объекта из структуры без заполнения всех обязательных полей. В PHP я бы был зол на того, кто так пишет) Но это не PHP, все верно, и ООП тут нет. Поэтому не стоит использовать этот язык там, где ООП было бы уместнее.
Как PHP-программист, первые недели работающий с Golang, хочу свои 5 копеек вставить.
У структур нет единой точки создания объекта, только кастомные статические конструкторы, которые использовать необязательно. Что ведёт либо к потенциальным ошибкам, либо к огромному количеству проверок на корректность заполнения полей.
Объекты-ошибки вместо исключений есть, но благодаря их обработкам код становится в среднем в 1.5 раза длиннее, чем аналогичный на PHP. Это мой опыт в моем проекте, у других людей разница может быть другой. Но она будет.
Категорически не согласен с фразой о строгой типизации языка. В нем присутствует утиная типизация, а не строгая. Твой интерфейс может случайно совпасть по сигнатуре с каким-нибудь другим, и реализующий один из этих интерфейсов класс будет реализовывать их оба, без вариантов. Либо метод структуры случайно совпадет по сигнатуре с каким-нибудь интерфейсом.
В Го нет nullable типов, но ссылки всегда могут указывать на nil. Благодаря этому даже не проинициализированная переменная любого типа содержит значение этого типа. Integer содержит 0, объект структуры - всю структуру. И нет никакого способа узнать, 0 в переменной лежит потому, что его туда сознательно положили, или это дефолтное значение.
Я отнюдь не хочу сказать, что один язык хуже или лучше другого. Они для разных целей. Го из коробки умеет быстро мапить json на структуры и делать крутую многопоточность благодаря горутинам. Моя первая программа на го - парсер сайта аренды квартир, который я написал за 15-30 минут (благодаря помощи ChatGPT :D). Но я бы не стал брать Го для вещей, где нужно описывать бизнес-логику. Уж лучше PHP: "правоверный" ООП для этого больше подходит и оставляет меньше места для ошибок.
Автор также не указал, что canvas — не единственный способ представления приложения в веб. Его можно так же скомпилировать в привычные html + css + js.
Пруф.