Обычно работает mmap, который держит в оперативной памяти то, что нужно, остальное, если что, подтянется с диска. Но если сама библиотека в лучших традициях выделят и использует хоть как-то под свои нужды гигабайт памяти из кучи, то, конечно, он тут не поможет. А для read-only секций библиотеки работает. К тому же эти секции ещё шарятся между всеми процессами, которые используют эту же библиотеку.

Есть ссылки на то, как это сейчас делается?

Это делается через mmap и demand paging. Насчет ссылок ХЗ - в https://www.akkadia.org/drepper/dsohowto.pdf слишком много технических деталей, но про mmap там сказано, а работа mmap описана в любом учебнике по ОС.

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

Правило всего одно. А я смотри чо могу:

package main

import (
	"fmt"
)

func andArrayNow(lst [3]int) {
	lst[0] = -1
}

func main() {
	arr := [3]int{1, 2, 3}
	andArrayNow(arr)
	fmt.Println(arr)
	// Output: 1, 2, 3
}

man slice

А какая вам разница как пользователю? О том у майнтейнера голова болит.

Быть самому себе маинтейнером очень удобно. Можно собирать самому себе что угодно и как угодно, и не надо ждать пока кто-то на другом конце планеты что-то там соберёт. А такого в отдельных случаях может вообще не произойти.

квест «подбери комплект библиотек, чтобы они удовлетворяли ограничениям всех установленных программ с плагинами»

Это какие-то специфические программы.

Быть самому себе маинтейнером очень удобно.

Ага. И развёртывание вида «просто положи исполняемый файл куда-нибудь в $PATH» очень упрощает жизнь самому себе-майнтейнеру.

Это какие-то специфические программы.

Ну, если за границы готового набора пакетов в дистрибутиве не выходить, то да. А если сделать шаг вправо или влево, то начинаются приключения.

https://github.com/golang/go/issues/22830

Даже сами разработчики делают эту ошибку, а ты предлагаешь маны читать.

И развёртывание вида «просто положи исполняемый файл куда-нибудь в $PATH»

А это у кого как. В бинарных дистрибутивах, разумеется, можно собирать пакеты. А в том же LFS'е можно везде собирать из исходников. Или поставить пакетный менеджер и собирать пакеты.

Наследование имеется, можно даже множественное эмулировать с помощью embedding'а

Ты определенно путаешь наследование и композицию. Наследования в go нет.

Да

Отладка злого бага в Go runtime

https://blog.not-a-kernel-guy.com/2017/12/04/evil-go-runtime-bug/

Да я и сам эту вот ошибку буквально недавно совершил. Правда до продажи она не дошла, а ещё на этапе запуска юнит-тестов срубилась.

Программисты вообще постоянно ошибаются, иногда вот на таких ровных местах.

Лично мне Go не нравится в первую очередь тем, что его официальный компилятор статично линкует бинарники

А для меня это самый большой плюс :)

Для больших самих по себе бинарников это, может быть, ещё и не так критично. Но, вот что касается небольших программ...

Пара мегабайт на полностью автономную переносимую программу с приличным быстродействием, ИМХО, сегодня совсем не много.

такая чуть более быстрая замена питону

Ну, если порядка 200 раз на объектной работе — это «чуть более быстрая», то я не знаю, что такое «намного более быстрая» :D

А теперь представьте себе, что всё это написано на Go

Его для этой цели, вроде бы, никогда и не позиционировали.

Современные системы состоят из тысяч пакетов, в каждом из которых десятки бинарников.

У меня на довольно обжитой системе:

/bin = 115
/sbin = 98
/usr/bin = 683
/usr/sbin = 98
----------------
Итого: 994

Оверхед при переносе на Go будет порядка 2Гб. Многовато, но не 40Гб же :)

И, повторюсь, никто в таких объёмах переписывание не планирует. Не смотря на наличие С/С++ львиная доля исполняемых файлов системы, один фиг, написана на sh/bash или python.

i,j += 1,2

А где так можно? :)

похож на си и ООП нет

ООП там есть, только выглядит и называется чуть иначе. Но его ООП от Си++ отличается намного меньше, чем, например, ООП С++ от JavaScript :)

find ...

Надо ещё -type f, а то там симлинков дофига :)

Нигде, но это не значит что так не надо делать в go, во имя консистентности (хотя мы же о go, при чем тут вообще консистентность)

говно

Однако каким-то образом Swift и Sixten решают сразу обе проблемы:

У Swift своя реализация дженериков, подсмотренная у древнего советского компилятора Clu. Она да, дает быструю компиляцию.

Серьезно? (c)

А где так можно? :)

> ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
Prelude> instance (Num a, Num b) => Num (a, b) where (x,y) + (x',y') = (x + x', y + y')

<interactive>:1:10: warning: [-Wmissing-methods]
    • No explicit implementation for
        ‘*’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’)
    • In the instance declaration for ‘Num (a, b)’
Prelude> (1,2) + (3,4)
(4,6)

А как же мы, палачи?

Верное замечание. С ним получается пять с половиной и два гигабайта для статической и динамической сборки соответственно. Я, вот, вообще не вижу пользы от такой экономии.

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

Это совершенно не проблема. Проблема сделать такой пакет универсальным, чтобы:

• работал везде и всюду. Даже на генте. Даже на убунте с неограниченным количеством левых ppa.
• не мешал работать другим. Жалобы вида «ваш пакет принёс с собой сильно нестандартную версию библиотеки и теперь мы не можем поставить $программу, т.к. она жаждет обладать другой, естественно несовместимой версией той же библиотеки» должны быть исключены.

А если не обеспечить универсальность, то придётся либо вкладывать немерянные ресурсы в тестирование совместимости со всеми актуальными версиями всех популярных дистрибутивов, либо делать сильные ограничения типа «мы работаем только с centos6 и никаких вам тут epel». И, прямо скажем, это довольно плохой выбор.

В том же Haskell

Вот неправда, в х-ле из-за полиморфной рекурсии и экзистенциальных типов далеко не всегда происходит мономорфизация, в особенности мономорфизация данных. Больше в этом треде: https://www.reddit.com/r/haskell/comments/46lux3/monomorphization_good_or_bad...

возьмите топор - он может быть тупым, может быть острым но он не может быть плохим

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

Пожаловался на тролля.

Он у всех языков наркоманский кроме питона. У того вообще синтаксиса нет

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

А мы покупаем или продаём?

Я вот не знаю: как там в го грузятся бинарники в озу для выполнения? А то будет капец много жрать оперативы?

Я вот не знаю: как там в го грузятся бинарники в озу для выполнения?

Наверное, также, как и во всех популярных десктопных ОС в последние 20+ лет — мапятся в память :)

У Swift своя реализация дженериков, подсмотренная у древнего советского компилятора Clu. Она да, дает быструю компиляцию.

Серьезно? (c)

Да. Я и сам удивился.

С чем ты споришь? Вот тебе embedding: https://golang.org/doc/effective_go.html#embedding

Теперь гугли diamond problem применительно к Go, уродскому ЯП без всякого дизайна, руководствующегося во всём простотой... простотой разработки игрушечного компилятора.

Брехня. Реальных симлинков там процентов 10 - все остальные - это не алиасы.

Еще раз: в go нет наследования, в go есть композиция. Остальное - фантазии. А embedding это как раз про композицию.

Мы работаем

В итоге, на Си можно делать бинарники на десятки килобайт, а на Go, если компилировать официальным компилятором, - нет.

А тебя кто-то заставляет использовать «официальный компилятор»? На данный момент есть компилятор, который позволяет «делать бинарники на десятки килобайт», чего тебе ещё не хватает?

Нет, не заставляет. Потому я и пишу «если компилировать официальным компилятором». Просто сторонники Go форсят именно официальный компилятор, утверждая, что неофициальный от него сильно отстаёт.

Тогда что такое «хороший топор» вы можете узнать у менеджера.

менеджер плохого не посоветует

Я всегда знал, что вы, дошколята, идиоты - но не до такой же степени.

Каким хреном ты считаешь по 2метра на бинарник? У меня 100 кедо-программ, каждая из которых зависит от 300метров блобов. И если их всех статически слинковать, то это будет не по 2метра, а по 200.

И если этот винт стоит 50 евро

Винт никому не интересен - им ты можешь только подтереться.

Вы такой агрессивный. Это из-за динамической линковки?

Меня просто удивляет тот невероятный уровень ахинеи, которые вы себе позволяете транслировать в эфир. Ну ты бы хоть подумал перед тем, как что-то считать и делать какие-то выводы. Это ведь не сложно.

Иди возьми AppImage какой-нибудь программы и посмотри на его размер. И вот при статической линковке уровня го - у тебя и будет этот AppImage на каждый бинарь.

Нет, не много.

Ещё один эксперт, который не умеет считать. Давай я тебя научу считать. Берёшь любой бинарь, травишь на него ldd, считаешь суммарный вес всех .so от которых зависит бинарь - это и есть искомый вес бинаря на го, а не та ахинея, что посчитал ты.

Нет, это из-за подтирания винтом.

Берёшь любой бинарь, травишь на него ldd, считаешь суммарный вес всех .so от которых зависит бинарь - это и есть искомый вес бинаря на го

А вот и нет, статически линкуется не вся либа, а только нужная часть. Так что может быть и (сильно) меньше.

так он что все сишные библиототеки статически линкует что ли?

А вот и нет, статически линкуется не вся либа, а только нужная часть.

Во-первых - это копейки, а во вторых - нихрена не нужная часть. Нужная часть - это про лто, а не про линкер. Да и вроде как у го он свой, а значит он параша.

При этом я выше даже делал уточнение по этому поводу:

И вот при статической линковке уровня го

В противном случае хелворд на этой параше не занимал бы 10метров, а занимал бы пол килобайта.

Так что может быть и (сильно) меньше.

Это мало кого волнует и теме отношения не имеет. Я дал наиболее вменяемую общую оценку. А рассуждать о том, что оно в частных случая может быть меньше - из этого ничего не следует. Это невозможно оценить.