LINUX.ORG.RU
ФорумTalks

А как вообще Go взлетел?

 


1

3

Решил вот посмотреть на язык, читаю, дошел до слайсов.

                                                                                                                                                                                                         
package main

import (
	"fmt"
)

func main() {
	a := []int{1, 2, 3, 4, 5}
	b := []int{1, 2, 3, 4, 5}
	c := a[1:3]
	d := b[1:5]
	c = append(c, 10)
	d = append(d, 10)
	c[0] = 0
	d[0] = 0
	fmt.Println(a)
	fmt.Println(b)
	fmt.Println(c)
	fmt.Println(d)
}
Вывод:
[1 0 3 10 5]
[1 2 3 4 5]
[0 3 10]
[0 3 4 5 10]

То есть в зависимости от одного индекса зависит, будет ли меняться низлежащий массив или нет. Да, я знаю про синтаксис [1:3:3], но это избыточность, и по умолчанию так же все равно не пишут. И если мне это в функцию дают, мне что, каждый раз сравнивать size и capacity, чтобы дел не напороть? А учитывая, что я не могу в сигнатуре функции указать константность, это еще сильнее усугубляет.
Ну а про классические претензии вроде отсутствия дженериков и перегрузки, но при этом существования generic-like встроенных типов с ad-hoc синтаксисом, жуткой обработки ошибок и прочего, я уж молчу, это давно уже обсосали везде. Вот и вопрос, как оно взлетело?

★★

Последнее исправление: keyran (всего исправлений: 1)

Ответ на: комментарий от keyran

Как по мне, slice должен быть «окном» в низлежащий массив. Все, что за пределами окна, ему доступно быть никак не должно.

Так и есть. До первого append за границу, который создаёт копию массива и возвращает слайс с него.

Меня больше занимает обоснование полуоткрытого интервала в качестве индексов.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Ну, значит Golang — такой автомобиль

Вот я по этому и неудомеваю. Просто то, как они определили умолчальную ёмкость – это же не абсолютный догмат, поэтому аргумент слабый. Было бы интересно услышать от авторов: у нас ёмкость до конца, потому что мы руководствовались тем-то и тем-то.

uuwaan ★★
()
Последнее исправление: uuwaan (всего исправлений: 1)
Ответ на: комментарий от Deleted

Это новомодное go решает только отсутствие толи мозга толи желания нормально обучаться

Мне сейчас почти нет разницы, на чём набрасывать какую-нибудь числодробилку. И на Си/Си++ я активно писал лет 10. Но сейчас числодробилки набрасываю на Golang. Просто потому что тупо удобно и быстро, как собрать, так и потом распространять :) Да, и на Си++ можно собрать монолитный статический бинарник, но телодвижений надо намного больше. И при написании, и при компиляции. А тут — всё из коробки.

KRoN73 ★★★★★
()
Ответ на: комментарий от baka-kun

Ок, уточню. «Фиксированным окном». Оно не должно ни знать о существовании чего-либо за своими пределами, ни уничтожать это.

Полуоткрытый интервал как раз понятен, чтобы можно было писать

d := b[1:len(b)]

keyran ★★
() автор топика
Ответ на: комментарий от uuwaan

Вот я по этому и неудомеваю.

Эх, не видел ты Lua :) Вот где масса удивлений ждёт программиста, выращенного на Си-like языках :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

и на Си++ можно собрать монолитный статический бинарник, но телодвижений надо намного больше. И при написании, и при компиляции

Расскажи об особых телодвижениях при написании программы на Си или Си++, собираемой статически.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Расскажи об особых телодвижениях при написании программы на Си или Си++, собираемой статически.

Надо или возиться с опциями линковки библиотек, или лепить make-file. Это часто выливается в двойной объём работы по сравнению с чистым быстрым программированием.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Расскажи об особых телодвижениях при написании программы на Си или Си++, собираемой статически.

Надо или возиться с опциями линковки библиотек, или лепить make-file

Хм. Я просил рассказать именно о телодвижениях «при написании» , а не «при компиляции»:

KRoN73> Да, и на Си++ можно собрать монолитный статический бинарник, но телодвижений надо намного больше. И при написании, и при компиляции

tailgunner ★★★★★
()
Ответ на: комментарий от keyran

Ок, уточню. «Фиксированным окном».

Ну, возможность прямо изменять длину слайса (в пределах массива, на который он ссылается) прописана прямо. Им же flexibility хотелось, а арифметику с указателями запретили, вот и выкручиваются. Опять же, массива за слайсом в явном виде часто и нет: var k []char; for { k = append(k, foo()); } . Смотришь на код, и видишь слайсы везде.

d := b[1:len(b)]

Я про это и говорю.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Вот я же и говорю, что котлеты лучше держать отдельно, а мух отдельно. Пусть будут динамические массивы, у которых будет append и прочее, и будут слайсы, которые будут уже фиксированного размера.

Так, я что-то под вечер не догоняю, а каким образом адресная арифметика заменяется изменяющими свой размер слайсами?

Я про это и говорю.

Тогда я, видимо, не понял, в чем недоумение.

keyran ★★
() автор топика
Ответ на: комментарий от uuwaan

то, как они определили умолчальную ёмкость – это же не абсолютный догмат

А что же ещё? Любой язык — это синтаксис и аксиоматическая семантика. Могли ли они сделать иначе? Из исходных предпосылок — нет.

baka-kun ★★★★★
()
Ответ на: комментарий от keyran

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

И прощай вся эффективность. Тогда достаточно только массивов и указателей без арифметики.

Как теперь жить?

Так, я что-то под вечер не догоняю, а каким образом адресная арифметика заменяется изменяющими свой размер слайсами?

А что ещё предлагается использовать? Практически везде, где в Си был бы указатель и malloc() — слайсы.

baka-kun ★★★★★
()
Ответ на: комментарий от KRoN73

Помню, говорили так же про delphi — если надо попырику прикладуху накидать. И где он теперь? :)

Про распостранять вообще странно, он же не кроссплатформенный. Тогда уж лучше java брать.

Единственный плюс это нейтив бинари, не надо ставить интерпритаторов или вирт. машин. Но «побыстрому накидать числодробилку и куда-то ее переносить» это яхз кому надо. Возможно, тебе одному :)

Странные аргументы, в общем.

Deleted
()
Ответ на: комментарий от KRoN73

Кстати, по скорости го дробит числа сопоставимо с си?

Deleted
()
Ответ на: комментарий от Deleted

он же не кроссплатформенный

Nani? Возможность одним go get стянуть программу на какой-нибудь Plan 9 не есть кроссплатформенностью?

commagray ★★★★★
()
Ответ на: комментарий от baka-kun

А куда денется вдруг эффективность? Может, мы о разном говорим? Там, где были в си указатель и malloc, там динамические массивы (те же слайсы, что сейчас в go, но всегда владеющие своей памятью). Там, где надо получить окно - аналог питоновских слайсов, то есть тройка из указателя на хэндлер динамического массива или на статический массив, и константные оффсет и размер, к примеру. Они памятью никогда владеть не должны, и всегда должны полагаться на внешний массив. А сейчас слайс может владеть, а может не владеть памятью, может обладать сайд-эффектами, а может не обладать, бррр....

keyran ★★
() автор топика
Ответ на: комментарий от keyran

Там, где были в си указатель и malloc, там динамические массивы (те же слайсы, что сейчас в go, но всегда владеющие своей памятью). Там, где надо получить окно - аналог питоновских слайсов, то есть тройка из указателя на хэндлер динамического массива или на статический массив, и константные оффсет и размер, к примеру. Они памятью никогда владеть не должны, и всегда должны полагаться на внешний массив. А сейчас слайс может владеть, а может не владеть памятью, может обладать сайд-эффектами, а может не обладать

Пиши на Rust - там вопросов «кто владеет» нет. Есть другие, в ассортименте.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

На раст посмотреть в планах. Пока я пишу на плюсах, и там последнее время вопрос владения тоже в тренде.

keyran ★★
() автор топика
Ответ на: комментарий от tailgunner

У меня не тает надежда, что он в итоге и из С++ выберется :)

keyran ★★
() автор топика

golang очень клев при больших нагрузках и многопоточности. Писать на нем не очень сложно, и это круто. Как пример - он просто идеален для биллинга.

spider_russia
()
Ответ на: комментарий от tailgunner

Хм. Я просил рассказать именно о телодвижениях «при написании» , а не «при компиляции»

При написании — очевидно же, что вся ручная работа с памятью и т.п.

KRoN73 ★★★★★
()
Ответ на: комментарий от Deleted

Помню, говорили так же про delphi — если надо попырику прикладуху накидать. И где он теперь? :)

А Дельфи никогда и не занимал никакой заметной ниши, кроме прикладного программирования в xUSSR :)

Но «побыстрому накидать числодробилку и куда-то ее переносить» это яхз кому надо. Возможно, тебе одному :)

А я по этому пункту за всех и не говорил. Только за себя. Вот прямо так и начал ответ: «Мне сейчас …»

KRoN73 ★★★★★
()

Ну хз. Вот есть gogs на go, gitlab на руби и rabbitmq на erlang. gitlab жрет сотни памяти чтобы просто запуститься, раббит гоняет память туда-сюда просто так, а gogs, таки да, няшка. Это субъективное наблюдение, конечно и я допускаю, что просто особо gogs не нагружал или то, что где-то что-то делали через жопу.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от keyran

динамические массивы

Слайс и есть динамический массив. Просто если ты его инициализировал уже существующими данными, он и будет с ними работать, пока не потребуется сделать realloc() при увеличении размера.

Они памятью никогда владеть не должны

Кому не должны? И зачем вводить в язык ещё одну сущность со своей семантикой? Выгоды от усложнения языка не очевидны. Хочешь, чтобы слайсы были read-only окном? Работай с ними как с r-values. Хочешь как «тройка из указателя и константные оффсет и размер» — не меняй размер.

А сейчас слайс может владеть, а может не владеть памятью

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

baka-kun ★★★★★
()
Ответ на: комментарий от Deleted

Быстрее же, не?

Не факт. У нас физики долго с Фортрана на Си переписывали и плевались. Хотя, конечно, на любом языке можно писать на Фортране.

baka-kun ★★★★★
()
Ответ на: комментарий от Deleted

Тогда уж лучше java брать.

эта штука, программы на которой жрут память как в не себя, иногда долго задумываясь? Это же адский кошмар с точки зрения эксплуатации, когда от админов/девопсов/что-ещё-там требуются знания магических циферок для ГЦ подходящих под конкретную нагрузку. Профиль нагрузки изменится - подставляй другие.

Joe_Bishop
()
Ответ на: комментарий от Joe_Bishop

Справедливости ради, в Golang тоже сборщик мусора. Которые по сути не настраивается и не отдаёт сразу освобожденную память системе.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Практически везде, где в Си был бы указатель и malloc() — слайсы.

Что-то я не понял, если слайсы это эдакие указатели на исходный массив, то откуда в Си был бы malloc()?

Deleted
()
Ответ на: комментарий от baka-kun

Слайс и есть динамический массив. Просто если ты его инициализировал уже существующими данными, он и будет с ними работать, пока не потребуется сделать realloc() при увеличении размера.

Вот в этом то и беда, что слайс — это и динамический массив, и окно. А это совершенно две разные вещи, зачем-то смешанные в одну сущность.

Кому не должны? И зачем вводить в язык ещё одну сущность со своей семантикой? Выгоды от усложнения языка не очевидны. Хочешь, чтобы слайсы были read-only окном? Работай с ними как с r-values.

Зачем вводить было строки тогда? Статические массивы? Пусть все было бы одной сущностью, чтобы не усложнять.

Хочешь как «тройка из указателя и константные оффсет и размер» — не меняй размер.

А как мне убедиться, что этого не сделает вызываемая функция?

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

И кто владеет анонимным массивом?

keyran ★★
() автор топика
Ответ на: комментарий от KRoN73

При написании — очевидно же, что вся ручная работа с памятью и т.п.

Если в структурах данных нет циклов (я думаю, ч то в «числодробилках» их нет), управление памятью в Си++ не сложнее, чем в Go.

tailgunner ★★★★★
()
Ответ на: комментарий от baka-kun

Я работаю с математиками, которые пишут программы для предметной области, которая в свою очередь есть раздел физики, они пишут на C/C++, про фортран только вспоминают благодаря удобному синтаксису для получения произвольной колонки.

Deleted
()
Ответ на: комментарий от Joe_Bishop

Странно. Я выше писал об опыте коллег. Ещё от них слышал, что компилятор интела, который, вроде как, считается самым шустрым преобразует код фортрана в сишный, а уже потом компилирует.

Deleted
()
Ответ на: комментарий от tailgunner

Если в структурах данных нет циклов (я думаю, ч то в «числодробилках» их нет)

Ну, вот, я последнюю задачу считал по задаче коммивояжёра в графах переменной размерности. Чистая числодробилка, но очень много работы с динамическими объектами (переменное всё — число узлов, число связей, веса связей). Сперва на PHP прототипировал, как не стало хватать производительности и памяти, легко перенёс всё на Golang, за час-два. А вот на Си/Си++ я бы провозился несколько дней, наверное, не смотря на то, что на них я писал порядка на 2 больше, чем на Golang.

KRoN73 ★★★★★
()
Ответ на: комментарий от commagray

У меня тут коллеги решили на go писать инфраструктурные скрипты. Не спрашивайте зачем.

Дженкинс настроили, и он теперь каждый go-скрипт собирает в три артефакта: под мак, под винду и под Линукс. А так как пишут они на маках, то проверяют тоже там же. Поэтому о том, что под Линукс их бинарник не работает узнали только через месяц, когда я попыталась его на серваке запустить.

Такая вот кроссплатформенность получилась.

В это время еще одна команда решила «проблему кроссплатформенности» запуском go в контейнере. Теперь у нас инфровые скрипты через docker-образы распространяются. И например рендерить шаблон параметрами надо через docker run infra/my-script file.

Но только для этого надо файл примонтировать внутрь контейнера. А монтирование в докере на маке работает по-разному в зависимости от версии и варианта Docker for Mac. Так что для унификации и кроссплатформенности приходится еще makefile писать, в котором описывать запуск докера.

Но! Make нам нужен обязательно версии 4.0 а он есть не у всех, так что для кроссплатформенности...

alpha ★★★★★
()
Ответ на: комментарий от alpha

Мне кажется здесь проблема не в Go, а в маководах на свободе.

tailgunner ★★★★★
()
Ответ на: комментарий от KRoN73

последнюю задачу считал по задаче коммивояжёра в графах переменной размерности. Чистая числодробилка

А, ну если и это - числодробилка, тогда конечно.

tailgunner ★★★★★
()
Ответ на: комментарий от Deleted

Что-то я не понял, если слайсы это эдакие указатели на исходный массив, то откуда в Си был бы malloc()?

Слайсы — всего лишь указатели на область памяти с размером для проверки выхода за границы. Инициализация со ссылкой на уже существующий массив — всего лишь частный случай. А malloc() и realloc() в функциях работы со слайсами.

baka-kun ★★★★★
()
Ответ на: комментарий от KRoN73

похоже, в твоей жизни остро нехватало явы :)

я слышу твой аргумент про несколько дней на сях, это норма

но клепать новые яп для такого... неубедительно как-то

Deleted
()
Ответ на: комментарий от keyran

зачем-то смешанные в одну сущность.

Не было смысла вводить ещё одну сущность, если слайс покрывает все кейсы.

Зачем вводить было строки тогда? Статические массивы?

Затем, что func(n [3]int) не примет аргументом [4]int , что бывает полезно. У них разный тип.

Массивы можно сравнивать. Они значения, а не указатели, присвоение или вызов функции создаёт копию массива. И так далее, но в принципе и этого достаточно.

А как мне убедиться, что этого не сделает вызываемая функция?

Ознакомиться с ней? По идее все побочные эффекты должны быть документированы.

И кто владеет анонимным массивом?

Сборщик мусора. :)

baka-kun ★★★★★
()
Ответ на: комментарий от Hertz

Метапрограммирование

закопать этот высер обратно в цпп и выкапывать на день всех святых — народ пугать

Deleted
()
Ответ на: комментарий от Deleted

пишут на C/C++, про фортран только вспоминают

Да, сейчас про фортран всё больше только вспоминают.

baka-kun ★★★★★
()
Ответ на: комментарий от keyran

и будут слайсы, которые будут уже фиксированного размера

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

Вообще удивление такие вещи могут вызывать только у тех, кто не читает документацию.

feofan ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.