а как сравнивалось? какие бы там не были шаблоны, ассемблер это не то чтоб прям усложняет

моя очередь спросить - ORLY?

ну то есть в асме будут уже инстанциированные шаблоны и сам код будет сравним с тем если писать это все руками без шаблонов (явно указать типы)

так, я все понял

что закончили?

или - где учились?

в школе еще

вопросы ок пошли

какие ответы - такие вопросы

так я ж не против ) спрашивайте

ну - я спросил

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

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

> там наверное можно всегда понять пойдут данные на стек или в куче выделятся а разве нет?

А в го не всё в кучу идёт? Кроме того, что escape analysisом на стек убирается?

ИМХО, Gо не "ближе к асму", а ближе к абстрактной тьюринг машине. Хотите вставку в середину слайса? Будьте добры выполнить две "инструкции" - скопировать первую половину слайса, дописав нужный элемент, потом скопировать результат и дописать вторую половину слайса. Такая фигня из-за того, что цель была написать _простой_ для изучения язык, а соответственно в минимуме сахара в языке. А так, да, если рассматривать с точки зрения близости к asm практика показывает, что go+asm не плохо дружат под голым железом, без C и прочего. Почти весь рантайм Go можно реализовать под голое железо на Go, asm понадобиться только что бы прокинуть runtime.Println в __go_println, к примеру. Но это не значит, что Go ближе к asm, чем, допустим C++, как минимум GC и runtime (довольно обширный, кстати) вкладывают некоторые ограничения для близости Все выше сказаное - ИМХО

А в го не всё в кучу идёт? Кроме того, что escape analysisом на стек убирается?

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

как гарантированно что-то положить на стек? ну в общем далек он от железа по сравнению с си

https://golang.org/doc/faq#stack_or_heap

мда, и правда..

From a correctness standpoint, you don't need to know

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

ИМХО, Gо не "ближе к асму", а ближе к абстрактной тьюринг машине. Хотите вставку в середину слайса? Будьте добры выполнить две "инструкции" - скопировать первую половину слайса, дописав нужный элемент, потом скопировать результат и дописать вторую половину слайса. Такая фигня из-за того, что цель была написать _простой_ для изучения язык, а соответственно в минимуме сахара в языке. А так, да, если рассматривать с точки зрения близости к asm практика показывает, что go+asm не плохо дружат под голым железом, без C и прочего. Почти весь рантайм Go можно реализовать под голое железо на Go, asm понадобиться только что бы прокинуть runtime.Println в __go_println, к примеру. Но это не значит, что Go ближе к asm, чем, допустим C++, как минимум GC и runtime (довольно обширный, кстати) вкладывают некоторые ограничения для близости Все выше сказаное - ИМХО

а как c gc быть?

в смысле “реализовать рантайм на го"

а как c gc быть?

"Пилите, Шурочка, пилите, она золотая" - самому реализовывать или брать реализации и переписывать

ну это про то что рантайм все же сильно толще чем требуется для с++

с основным тезисом — про то что цель была получить простой для изучения язык я согласен конечно собственно это сразу и сказал )

пока не появился эксперт по с++ )

в смысле “реализовать рантайм на го"

В прямом - пилить рантайм Go для железа (без ОС) - на самом Go вполне реально, в большинстве случаев asm понадобится только для "прокидывания" методов runtime из пакета "runtime" в валидные имена __go_%method_name%. Хотя, чую, что это можно и при сборке сделать, но пока руки не доходят копать в эту сторону

В прямом - пилить рантайм Go для железа (без ОС) - на самом Go вполне реально, в большинстве случаев asm понадобится только для "прокидывания" методов runtime из пакета "runtime" в валидные имена __go_%method_name%. Хотя, чую, что это можно и при сборке сделать, но пока руки не доходят копать в эту сторону

нене, как в этом рантайме написать на go gc ?

Так же как управление памятью =)

погоди, это и есть управление памятью в го )

— как написать управление памятью? — так же как управление памятью … ну ок

Не путай управление памятью в плане железа и GC

ну в го оно такое, от железа далекое

нет никакого C++ без boost

Есть. С Qt ;)

Ага, только если ты пишешь под железо - сначала все равно реализуешь алокации и прочее, а уже потом будешь пилить GC ;)

Есть. С Qt ;)

тсс, не порти картину мира человеку

Ага, только если ты пишешь под железо - сначала все равно реализуешь алокации и прочее, а уже потом будешь пилить GC ;)

ну ты понимаешь, при таком варианте использования брать го особо смысла нет (

чувствую, за живое зацепил

это хоролшо

это говорит нам о сохранении связей с реальностью

В прямом - пилить рантайм Go для железа (без ОС) - на самом Go вполне реально, в большинстве случаев asm понадобится только для "прокидывания" методов runtime из пакета "runtime" в валидные имена __go_%method_name%. Хотя, чую, что это можно и при сборке сделать, но пока руки не доходят копать в эту сторону

есть даже какой-то проект предлагающий ранить kvm в котором как "ядро ОС" брать специальный бинарник Гошный

чувствую, за живое зацепил

дада, особенно когда смешно с темы съехал

ути-пуси

есть даже какой-то проект предлагающий ранить kvm в котором как "ядро ОС" брать специальный бинарник Гошный

о, не видел. а ссылка есть?

но

есть даже какой-то проект предлагающий ранить kvm в котором как "ядро ОС" брать специальный бинарник Гошный

Тихонечко пилю свою ОСьку на Go, чисто в исследовательских целях

мы же не будем всерьез обсуждать, что c++ ближе к машинным кодам, чем go?

или будем?

о, не видел. а ссылка есть?

ох... сейчас поищу

мы же не будем всерьез обсуждать, что c++ ближе к машинным кодам, чем go?

с++ ближе, чего тут обсуждать? )

ну ты понимаешь, при таком варианте использования брать го особо смысла нет (

Да ну? HAL - знакомое понятие?

с++ ближе, чего тут обсуждать? )

ммм

Да ну? HAL - знакомое понятие?

знакомое, но обычно gc и железо не очень дружат

а каков ваш набор критериев оценки близости?

ну, кроме "я так вижу"

@quetzal а прошу прощения, там похоже таки есть микроядро реализующие базовые сисколы.

https://github.com/deferpanic/gorump

или я что-то другое видел

Тихонечко пилю свою ОСьку на Go, чисто в исследовательских целях

Ты тоже?

а каков ваш набор критериев оценки близости?

да вон выше было уже.

пока я отходил чаю попить - тут случился шквал

повторите, пожалуйста

Ты тоже?

Давненько уже, аж на хабру пару статей писал ) Руки не доходят из личного репа в гитхаб слить и статейки помалякать

самое простое — в го ты не знаешь где у тебя лежит переменная стек-хип и когда ее память вернут системе это уже довольно далеко от железа в го нет арифметики над указателями в го свои зеленые потоки которые прозрачно для тебя ложатся на os и ты не влияешь на то как и когда они переключаются

вот это все в с++ ближе к железу / os чем в го

ERROR: S client not available

знакомое, но обычно gc и железо не очень дружат

Прямая работа с памятью -> ... -> GC А, и да, при желании можно спокойно обойтись без GC ;)

@quetzal про "близкость к ассемблеру" - посмотри реализации структур данных, как сделаны слайсы, массивы и пр. - вот это вот все.

Прямая работа с памятью -> ... -> GC А, и да, при желании можно спокойно обойтись без GC ;)

это уже будет другой язык наверное ) у го семантика сильно завязана на gc

@quetzal про "близкость к ассемблеру" - посмотри реализации структур данных, как сделаны слайсы, массивы и пр. - вот это вот все.

а что там? как будто в с++ внутри массива единорог и еще куча магии

о, и если мы тут говорим за слайсы как узнать адрес backing массива в слайсе?

самое простое — в го ты не знаешь где у тебя лежит переменная стек-хип и когда ее память вернут системе это уже довольно далеко от железа в го нет арифметики над указателями в го свои зеленые потоки которые прозрачно для тебя ложатся на os и ты не влияешь на то как и когда они переключаются

это про go. а про c++

в с++ знаешь ) куда положишь там и будет

@quetzal https://godoc.org/unsafe

это уже будет другой язык наверное ) у го семантика сильно завязана на gc

Попробуй, узнаешь )

там и адресная арифметика и ответы на остальные твои вопросы про указатели

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

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

ну это то же самое что сказать “вот библиотека на го которая очень использует reflect и хер знает что делает внутри”

мы ж не библиотеки сравниваем все же

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

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

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

адресная арифметика есть, владимир опередил меня

а за нарушение договренностей получишь от операционки по мозгам

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

ну нет. я решаю стек или нет а если хип то могу написать свой аллокатор

а про зеленые потоки - вообще-то, знаю. и знаю, куда yeld воткнуть

ну нет. я решаю стек или нет а если хип то могу написать свой аллокатор

ты не можешь просто взять и сказать "переменная, ты лежишь вот по этому адресу"

тебе нужно попросить у ОС памяти

либо извращаться с линкером

ты не можешь просто взять и сказать "переменная, ты лежишь вот по этому адресу"

адрес нет, речь про стек-хип например

ну и еще раз — есть вариант написать свой аллокатор

мне кажется кто-то здесь тролль

ну и еще раз — есть вариант написать свой аллокатор

аллокатор тебе поможет только при условии что у тебя нет ОС

и есть вся память твоего девайса

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

и обычные-то классы, со множественным наследованием и полиморфизмом, хер проссышь, как говорили в школе. но там же еще оптимизатор, и вся херня

а про зеленые потоки - вообще-то, знаю. и знаю, куда yeld воткнуть

ээ? RLY? вот прям знаешь как эти зеленые потоки ложатся на потоки ос?

а что там знать-то?

и обычные-то классы, со множественным наследованием и полиморфизмом, хер проссышь, как говорили в школе. но там же еще оптимизатор, и вся херня

множественное наследование и полиморфизм вообще никак не усложняют дела если честно