Как стать автором
Обновить

Комментарии 22

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

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

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

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

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

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

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

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

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

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

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

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

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

А вот от такого кода я в восторге:
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.

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


    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)
    }

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

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

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

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


Однажды я увидел в нашем проекте примерно следующий код на 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 там не в одном скоупе были, а в разных — но общий алгоритм был именно такой.


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

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

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

В том то и дело что есть десяток разных способов. А тут всего 2. На go сбегают после C++ умышленно уменьшая вариативность. И для кого-то лучше минимально необходимое число возможностей. Каждому по языку на свой вкус.
После 5-го пункта ожидал что-то вроде «6. И вообще, ООП в языке нет. Совсем»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий