BP
Ну в случае с примитивами эти затраты могут быть заметны
Я думаю для примитивов есть тоже оптимизации
Size: a a a
2020 June 17
I
чё тут у вас, опять Антон связует несвязуемые нарративы?
опять мемами отвечаешь?
(
опять мемами отвечаешь?
хотел бы, но тут и не нужно
I
а если это тоже мем
(
Я не знаю, с чего всё началось, но точка зрения, которую пытается донести Антон, неясна и, при попытке задуматься над ней, оказывается ещё и абсурдной
I
Вот я это запомнил под именем специализация
Не знаю что это/ определение копирнул из викедии
AK
Я не знаю, с чего всё началось, но точка зрения, которую пытается донести Антон, неясна и, при попытке задуматься над ней, оказывается ещё и абсурдной
Что в ней абсурдного? Если фича нужна, у неё высокий приоритиет, если у ней высокий приоритет на неё выделяется больше ресурсов и она быстрее запиливается. Низкий пориритет - мало ресурсов, долгие сроки.
I
Кстати, как там в go хешпами или списки реализованы?
AK
Единственное, что меня самого коробит, что я мог напиздеть когда всё таки старатаунл лум, я где-то читал, что работы над ним идут очень долго - около 10 лет. Но сейчас нашёл инфу, что первый подход к снаряду был только в 2017. Тогда это приоритетный проект и там не только кучка посанов с пульсура. Это дволльно быстро для задачи такой сложности, уже иметь прототип
(
Кстати, как там в go хешпами или списки реализованы?
как захардкоженные части языка
I
Так то дженерики (за исключением коллекций) не особо нужны в прикладных-web-сервисах (смотрю свой код).
Так же Async/CompletableFuture и тд "асинхронны-монадки" в go не нужны.
Хотя уже один Result<T,E> перевернул бы go комюинити
Так же Async/CompletableFuture и тд "асинхронны-монадки" в go не нужны.
Хотя уже один Result<T,E> перевернул бы go комюинити
AK
Кстати, как там в go хешпами или списки реализованы?
никогда не задумыался над этим, но реализация сама вот
https://github.com/golang/go/blob/master/src/runtime/map.go
https://github.com/golang/go/blob/master/src/runtime/map.go
AK
Так то дженерики (за исключением коллекций) не особо нужны в прикладных-web-сервисах (смотрю свой код).
Так же Async/CompletableFuture и тд "асинхронны-монадки" в go не нужны.
Хотя уже один Result<T,E> перевернул бы go комюинити
Так же Async/CompletableFuture и тд "асинхронны-монадки" в go не нужны.
Хотя уже один Result<T,E> перевернул бы go комюинити
резалт да, был бы нужен, можно было лепить railway programming так называемый без кучи всякого валежника if err != nil
I
Пасиб конечно за сорцы, но для меня го как китайский
Давно хочу какие-нибудь курсы по гохе пройти
Давно хочу какие-нибудь курсы по гохе пройти
VP
никогда не задумыался над этим, но реализация сама вот
https://github.com/golang/go/blob/master/src/runtime/map.go
https://github.com/golang/go/blob/master/src/runtime/map.go
А это, видимо, популярная практика использовать goto, да?
VP
Пасиб конечно за сорцы, но для меня го как китайский
Давно хочу какие-нибудь курсы по гохе пройти
Давно хочу какие-нибудь курсы по гохе пройти
Язык простой как сишечка. И код такой же - жонглирование указателями.
AK
А это, видимо, популярная практика использовать goto, да?
ну норм. в goto ничего плохого нет так-то
VP
ну норм. в goto ничего плохого нет так-то
А, ок, вопросов больше нет
(
Единственное, что меня самого коробит, что я мог напиздеть когда всё таки старатаунл лум, я где-то читал, что работы над ним идут очень долго - около 10 лет. Но сейчас нашёл инфу, что первый подход к снаряду был только в 2017. Тогда это приоритетный проект и там не только кучка посанов с пульсура. Это дволльно быстро для задачи такой сложности, уже иметь прототип
одно дело сделать гринтреды для платформы, в которой с её зарождения были браунтреды, а другое - впилить женерики в ссаный язык, у которого компилятор занимается 1000 строк