7 странных особенностей Go

[dark_ruby]

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

[AndreySu]

Как для чего? Только для рекламы онлайн-курсов SkillFactory.

[kvaps]

Ну стоит признать что описанный метод демонстрирует не наследование а самую что ни на есть композицию.

[Meiblorn]

Вопрос по первому пункту: каким боком был выведен факт, что в go придерживаются минимализма? В go каждый warning ведет к ошибке компиляции и unused import — это как раз этот случай. Как вы вывели, что «fail on warning == minimalism» для меня неясно.

[Shtucer]

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

И они их получат! Пустая строка это валидное значение.

[Sly_tom_cat]

Пример выбран неправильный. Вот если бы в структуре был бы мьютекс или канал — то там без инициализации много где попадать может в рантайме потом.

Но самое главное — как можно заявлять об отсутствии конструкторов, если при этом демонстрируется аж целых два варианта конструкторов. Да, они не привычные для того кто привык к конструкторам Java/C++, но это не дает право заявлять что конструкторов нет.

[some_x]

а если они ожидают не пустую строку?

[Shtucer]

То это тянет на "неожиданность" №8.

[yvm]

>Атрибуты видимы, когда начинаются с заглавной буквы
вот это действительно странно и не явно…

[arrakisfremen]

А что в нем показалось вам самым странным

Что этот язык взлетел и создал такой ажиотаж вокруг себя.

[Meiblorn]

Go — это С++ на минималках. В мире колосально много разработчиков, кому С++ перестал нравиться в силу своей сложности работы с поинтерами и памятью, но в то же время они не хотят переходить на такие языки как java или c# (эти языки выбраны из учета их популярности и схожести с С/С++), где приходится пологаться на сборщик мусора. Go, даже несмотря на наличие такового сборщика, обещает гораздо больше в плане менеджмента памяти и дает желаемый перформанс на уровне С++ по сравнению с перечисленными ранее языками.

Ажиотаж вполне ожидаемый, как и ажиотаж вокруг rust. К тому же, не стоит забывать что сейчас многие гиганты перестраивают архитектуру под микросервисы и для них такое соотношение как «минимальный порог вхождения в язык» / «цена обслуживания» — далеко не пустой звук. Go — яркий победитель в этом соотношении: например, миинимальная программа на go-micro нуждается лишь в ~10мб оперативной памяти, тогда как минимальная программа на Spring Boot примерно в 150-200 мб.

[AnthonyMikh]

Go — это С++ на минималках

Определение в высшей степени сомнительное. В C++ есть: пространства имён, обобщённое программирование, константность, RAII, ссылки (которые можно в какой-то степени считать ненуллабельными указателями). Это всё — вещи, которые непосредственно влияют на эргономику написания и использования, а также на его безопасность. Всего этого в Go нет. Как его в принципе можно с C++ сравнивать?

[LynXzp]

А вот от такого кода я в восторге:

x := [4]string{"one","two","three","four"}
    for _, entry := range(x) {
       fmt.Printf("Element %s\n", entry)
    }

Потому что он не позволяет сделать так:

x := [4]string{"one","two","three","four"}
    for entry := range(x) {
       fmt.Printf("Element %s, index %v\n", entry, x.find(entry))
    }

А я такое видел и не хочу больше. Ну еще это позволяет как-то избежать однозначности range по индексу.
P.S. ни одной странной особенности. Ну кроме 1, это меня тоже немного удивляет. Хотя зависимости по большей части добавляет и удаляет goland.

[mayorovp]

А что мешает написать вот так?

    x := [4]string{"one","two","three","four"}
    for _, entry := range(x) {
       index := x.find(entry)
       fmt.Printf("Element %s, index %v\n", x[index], index)
    }

Не вижу каким образом язык этому воспрепятствует...

[Shtucer]

как-то так:
x.find undefined (type [4]string has no field or method find)
Но даже если бы такой метод был, некоторые рузультаты, конечно, могут удивить, например при
x := [4]string{"one","one","three","four"}

[mayorovp]

Какого индуса останавливали такие мелочи?

[LynXzp]

Указанная мною ошибка была сделана потому что программист не знал как получить индекс при итерировании. Я вот сейчас тоже не помню как получить индекс в python, т.к. пройтись по коллекции без индекса гораздо более частое использование: for entry in x. Причем если загуглить «for python» то индекса скорее всего вы не уведите. Т.е. программист мог и пытаться посмотреть как индекс брать и не найдя другого выхода написать так. Ок, это джун программист. Но на python таких много.

[mayorovp]

Согласно моему опыту, такие ошибки обычно возникают потому что программист вообще не понимает что он делает, просто комбинируя увиденные где-то куски примеров.

Однажды я увидел в нашем проекте примерно следующий код на Javascript:

for (var i=0; i<array.length; i++) {
    var item = array[i];
    // ...

    var index = -1;
    for (var j=0; j<array.length; j++)
        if (array[j] === item) {
            index = j;
            break;
        }
    // ...

    var obj = array[index];
}

Это всё было "приправлено" вызовами функций, т.е. переменные i, item, index и obj там не в одном скоупе были, а в разных — но общий алгоритм был именно такой.

Вот чего автору кода не хватало в языке? Не думаю что тут проблема в способах итерации...

[polRk]

O(n^2) Вот, что препятствует

[AnthonyMikh]

В более нормальных языках индекс добавляется вызовом enumerate, и этим даже, как правило, удобно пользоваться.

[LynXzp]

В том то и дело что есть десяток разных способов. А тут всего 2. На go сбегают после C++ умышленно уменьшая вариативность. И для кого-то лучше минимально необходимое число возможностей. Каждому по языку на свой вкус.

[maxzhurkin]

После 5-го пункта ожидал что-то вроде «6. И вообще, ООП в языке нет. Совсем»