Comments 17
А если append перераспределяет память — как часто это бьёт по производительности на практике?
Для маленьких срезов (до сотен элементов) перераспределение памяти практически не заметно Процессор и память справляются с такими операциями быстро. В таких случаях можно не беспокоиться о производительности append.
Для больших срезов (тысячи или миллионы элементов) перераспределение будет проблемой. Каждый раз, когда емкость исчерпывается, происходит копирование всех элементов в новый массив. Это создает дополнительную нагрузку на память и процессор, что может замедлить выполнение программы.
Сегменты, слайсы, срезы. Неужели терминология всё ещё не устаканилась?
Ну вот в Go срезами называют то, что в других языках называют векторами.
В других языках срезы это именно отображения массивов, без возможности менять их длину, вот исключает такие вот грабли, как добавил элемент в слайс и он реалоцировался, а ты же хотел добавить элемент в исходный массив.
Так что да здравствует путаница.
Так и я именно про Go. В том учебнике, который я читал самым первым, за авторсством Макгаврена, это были сегменты. И поэтому в конспектах у меня сегменты. В следующем "учебнике" (даже автора этого недоразумения писать не хочу) был транслит "слайсы", но я уже знал про slice (хотя в учебнике этого не было), поэтому тоже понял легко. А тут уже срезы, и тут нужно не просто знать о slice, но и догадаться, что это один из переводов на русский.
Проблема не в том, что слово сложное или непонятное, а в том, что для меня, как для полного новичка, сегменты и срезы — это два разных понятия, и они, скорее всего, обозначают разные вещи. Даже если оба они []string, то вторым словом могут обозначать некий подвид, например. Я же этого не знаю.
А вот карты, их второй "автор" писал как "мапы", тут их как называют? Хэш-таблицы?
Так же было, когда я изучал обобщённые типы и читал про "дженерики". Я и понятия не имел, что я уже знаком с тем, что такое дженерики, пока случайно не наткнулся на код.
Срезы наверное одна из самых неудачных частей Go, наравне с map. Вместо того чтобы сделать по человечески явные структуры данных с ожидаемым поведением, как в других ЯП, придумали костыли в виде встроенных магических типов работающих через встроенные магические функции.А все потому что ну очень не хотелось добавлять дженерики в современный ЯП, которые все равно добавили, и пришлось делать костыли с make, append, len неявными функциями чтобы как то работать с разными типами данных для этих контейнеров. И по итогу получилось что вместо нормальных срезов - отображений подмассивов у нас срезы которые на самом деле динамические массивы, вместо логичного numbers.Len() и numbers.Add(2) у нас len(numbers) и users = append(numbers, 2). Даже с именами путаница - по идее публичные функции должны быть в верхнем регистре. В результате в языке который должен быть простым одни косячат на ровном месте а другим приходится писать подробные статьи о том как работает простейшие операции.
Я только-только ознакомился с базовыми элементами, но уже сумел сделать type JSlikeStrings []string, которому приделал поведение .forEach(callback). Думаю, приделать .Len() к numbers тоже можно.
А потом я узнал, что можно писать имена переменных кириллицей, и как раз вчера выяснял у нейросетей, как делать экспортируемые переменные, если они написаны китайскими иероглифами или арабской вязью. Оказалось, что никак, придётся спереди приписать символ, для которого можно распознать регистр.
Вам и @Metotron0, скромный совет или мнение, как угодно: не стоит делать из Go то, чем он не является. Было множество подходов к созданию аналогов Linq, каких-то своих удобных строк, хэлперов для горутин и так далее. В основном это бесполезное движение против ключевых концепций языка, которое только отдаляет приобретение мастерства и накопление релевантного опыта. Идиоматический код на Go пишется с циклами, с len, с громоздким select и т.д., ибо эта семантика понятна и привычна разработчикам на этом языке. Ее успешно и быстро считывает натренированный взгляд. И на условном собеседовании будут спрашивать именно про тонкости работы append, а не про обертки и кастомные библиотеки. Потому что как минимум нужно уметь читать код, который уже написан в рекомендованном официальными и неофициальным гайдами стиле.
Дзен понимания языка приходит, когда пишешь на нем, а не воссоздаешь парадигмы Java/C++/Rust, используя другие ключевые слова. Есть альтернативное мнение, что мы как зомбированные повторяем одно и то же, мол не надо изобретать, не нужны фреймворки и не надо использовать ORM. Возможно в нем есть доля истины. Но языку правда не нужна "команда по спасению", которая все исправит, понатащив концепций из других языков.
Объективно, если бы язык был плох, то он не сыскал бы такой популярности. Да, можно сказать, что за ним стоит Google, но так ли они его пушат?.. Кмк здесь больше все строится на доверии инженеров и сарафанном радио.
Объективно, если бы язык был плох, то он не сыскал бы такой популярности.
JavaScript не даст соврать.
Кмк здесь больше все строится на доверии инженеров и сарафанном радио.
Чтобы язык стал популярным он должен статьи интересным бизнесу, не обязательно за то что он хороший и плевать хотел бизнес какое-там у инженеров к чему доверие. И он стал популярным, когда бизнес нащупал в языке уникальное сочетание качеств: неплохой эффективности с минимальным временем на обучения, что позволило эффективно переучивать и переманивать разрабов с других стеков и отчасти закрывать проблему кадров. До этого, у товарищей инженеров очень было модно дружно критиковать этот язык, во-многом за дело.
Чтобы язык стал популярным он должен статьи интересным бизнесу, не обязательно за то что он хороший и плевать хотел бизнес какое-там у инженеров к чему доверие
Фундаментально не согласен с этим утверждением. Бизнесу интересно заработать деньги, часто для этого нужно решить ряд инженерных проблем. За решение проблем отвечают инженеры. Выбор подходящего инструмента на 90% лежит в плоскости инженерной работы (с запасом оставлю 10% на логистику, правовые аспекты и т.д.)
Если бы бизнес выбирал инструменты разработки... страшно представить! Сразу оговорюсь, что есть IT-сферы бизнеса, где многие руководители являются бывшими инженерами. Влияние такого бизнеса на инженерные решения сомнению не подвергаю. А вот условная строительная фирма, сеть медицинских клиник, ритейлер - разве они как заказчики должны знать что-то о преимуществах или недостатках Go? В требованиях бывают слова про актуальный и распространенный стек разработки, реже про конкретный стек, например совместимый с текущим. Но и это все либо со слов, либо с аппрува инженеров обычно делается. Что они сами смогут сказать? "Где-то когда-то слышали, что PHP не очень, давайте делать на Go"? Или "у конкурента все на Java и они преуспевают, значит и нам надо Java"?
переманивать разрабов с других стеков и отчасти закрывать проблему кадров
А как тогда появились другие стеки, если за всем стоит бизнес? :) Вряд ли они породили бы текущий зоопарк технологий. В общем, есть в этом топике "проблема курицы и яйца", но как будто сначала язык занимает нишу и хорошо решает проблемы, а потом он начинает привлекать бизнес тем, что инженеры на нем быстро и качественно решат проблему. Не язык не решает проблему, а владеющие им инженеры.
За решение проблем отвечают инженеры. Выбор подходящего инструмента на 90% лежит в плоскости инженерной работы.
Приходят такие инженеры к бизнесу и говорят:
- хотим внедрить новый язык X потому что он крутой и потому что так говорят и мы умные инженеры считаем так правильно
- зачем нам это?
- ну как зачем? Это более современный язык, он нравится нам
- т.е. мы внедрим новый стек, текущие разрабы на нем не смогут писать нужно будет нанимать новых?
- ну да
- а они есть на рынке?
- пока немного но все изменится, язык же крутой
- мы заработаем с этого больше денег?
- ну в теории может быть, язык более производительный можем сэкономить на серверах
- хорошо, а мы можем для этой же задачи использовать например Java стек как у конкурентов которому несколько десятилетий,который вылизанный, по которому куда продуктов библиотек и инструментов сделано, под который все уже давно настроено и для которого на рынке есть разработчики?
- ну да
- ну тогда мы рассмотрим перспективу перехода на Java, спасибо за предложение, до свидания
Выглядеть это будет как то так. Но я конечно же верю что в Вашем мире мамкины инженеры не продают идеи бизнесу и бизнес не рассчитывает их целесообразность, они просто пишут на чем хотят. Да да.
А я не создавал свою библиотеку и ничего толком на Go не писал, кроме одного файлика. Я всего лишь хотел понять, правильно ли я понял, что можно сделать .forEach с колбеком. Оказалось, что да. Но, вообще, после JS возвращение к школьным техникам из Паскаля ощущается каким-то отсталым. Где я раньше писал .map(), тут нужно явные циклы прогонять и заводить временную переменную.
Select я ещё не проходил, но видел его в чужом коде. То ли он появился позже моего учебника, то ли это что-то более продвинутое. Пока пытаюсь понять, как работают модули, что писать в package, нужно ли их при этом раскладывать по директориям, обязательна ли main(), если модуль просто что-то экспортирует. В учебнике это было недостаточно внятно. Буду экспериментировать.
К слову, не факт, что я буду использовать это в работе. Так-то, я фронтендер. А для себя же можно сделать и clog := fmt.Println, никто не увидит.
Где я раньше писал .map(), тут нужно явные циклы прогонять и заводить временную переменную.
Да, в го пишется более примитивный код таков дизайн языка. Проблема не в том что нет встроенного forEach ( может и есть кстати ) а в типизации. Когда привык что можно пихать любые переменные куда угодно а тут за это го бьет по рукам. Но имхо оно того стоит, плоский примитивный код, который просто работает.
круто, давай про мапы теперь
Срезы(slices) в Go