Сижу в общепознавательных целях пытаюсь заставить Claude реализовать на Golang ГОСТ - понятно криво и приходится все же вычитывать ГОСТ и допиливать руками, статья очень в жилу. Например - то что Дельта и инвертная дельта в ГОСТ которая там в l(...) - это по сути тождественное преобразование (в битах) и только смысл меняется - чтобы операции правильные применялись. Но это... чисто для математиков. Как программисту - я сидел и не мог понять зачем это вообще нужно. А тут в статье - сразу L без всяких там дельта-тета и вуаля.
Но кажись нашел опечатку в этом l в статье - у вас первая константа С1= 019484DD10BD275DB87A486C7276A2E6 но если пересчитать все (остальные константы сходятся, реализаци думаю верная, только одна из 32 не совпала) - то она С1=019484DD10BD275DB87A486C7276A26E - последний байт не E6 а 6E - прошу перепроверить и если что - поправить
Наоборот я при том же понимании и наблюдениях что и у автора (про nil в основном) (про производительность давайте не будем потому что оптимизация до каких-то показаний всегда считалась оверинженирингом, понятно что где-то может быть узкое место, требующее устранения и возможно за счет передачи по значению) - имею совершенно обратное мнение.
использование nil дает каноничный способ передать "используй дефолт", без необходимости проверки передачи "пустой структуры", то есть `if myParam == nil { myParam = getDefaultMyParam()`, то есть семантика "отсутствия чего-то" в таком виде более четкая, проверять на nil не такая уж большая беда, но да runtime контроля не хватает как в Kotlin, но это не выглядит жуткой проблемой
передача указателя по дефолту дает как раз дисциплину считать, что все read-only, не копии, может быть в share и соответственно приучает более осторожно все писать, то есть чтобы переход "на копию" был более внятен. Понятно это противоречит "чистому функциональному подходу", но прикладная разработка на Go она редко про чистую функциональщину
нет пробелмы мнимой копии, когда привычка передавать по значению прячет нюансы общих буферов слайсов, присутствия интерфейсов среди полей (не известно по ссылке или по значению), вложенных структур тоже где-то по указателю, где-то по значению, то есть DEEP COPY пробелма никуда все равно не девается, но когда все на указателях ты и не ждешь, что что-то копируется каждый раз, к тому же снять shallow copy не проблема `var cpyVal MyType = *myObjRef; cpy := &cpyVal;` где действительно вынь да положь нужна эта копия
да, HEAP, GC это все медленее чем копирование и работа через стек, но я напомню что в большинстве случаев это пренебрежимо мало по сравнению с вводом-выводом, на котором строится 90% нагрузки типовых програм, и вот всякие оптимизации это уже история как раз по особым праздникам...
Да что тут особо рассказывать. Чтобы еще и не холиварить. Я лично много на чем успел пописать и поработать, поэтому не было ничего что я бы считал данностью как бы такой, дефолтной. И когда основной стек был Java использовали Spring, потому что по сравнению с Java EE и с его ужасными шаблонами, большими этими сервлет-серверами - Spring был как глоток свежего воздуха. Сам настраиваешь контейнера там, есть на все шаблоны там, готовые бины, все как-то магически заводится.
Потом в какой-то момент просыпаешься ночью в холодном поту и думаешь "а нафига я подключаю NHibernate или JPA чтобы прочитать из базы пару запросов? " и такой голос шепчет "а как же поддержка всех 100500 видов баз, нужен универсальный ORM, а для этого нужна еще специальная конфигурация и мигратор и вот же - на тебе Spring в нем это все есть" - вроде успокаиваешься. Потом у тебя в стоке приложение начинает стартовать по минуте, потом подсасывать на AutoScan столько всего ненужного из всех библиотек, что нет столько в мире аннотаций, чтобы все это понять и задизейблить.
И потом например просто для развлекухи открываешь в стоке ну там гошку и на ванильной гошке пишешь рубленными мазками то же самое, только без всяких ентерпрайз-наворотов и памяти так раз в 100 меньше и на диске без половины интернета. И снова понимаешь, что в чем-то засада и вспоминаешь, что когда до этого работал не с Java/EE/Spring, то вроде как-то спокойно все писалось без 10 уровней якобы обоснованно существующих прокладок. Понимаешь, что без всяких ORM больших спокойно кастовал рекордсеты в структуры, что все равно все время дооплетать до неузнаваемости приходится все эти штатные мидлвары для MVC на спринге. И понимаешь, что ну какой-то бойлерплейт ради бойлерплейта а на флаге написано, что это якобы солиднейший SOLID.
И когда перевели все на Kotlin (как язык) сначала тоже был просто Kotlin а остальное что было на тот момент Maven/Spring и все остальное что всегда в таких случаях тогда была. Ну а где язык - начинаешь смотреть - а что там по экосистеме, а что по библиотекам, куда вообще ветер дует. Ну и совершенно другой стек начинает вырисовываться гораздо ближе по духу к тому что можно видеть в go, - более рубленный ООП без "факторок для создания факторок производящих билдеры", никаких "аспектов", явно управляемые контейнеры зависимостей, микрофреймворки с ручной настройкой для REST/gRPC - и как некогда радовались переходя с EE на Spring, так потом радовались когда и это марево рассеялось )))
Рассеивай не рассеивай. Kotlin все же стал развиваться больше для андроида, чем в Native и в этой своей ипостаси не является конкурентом ни GO ни Rust ни плюсам, пока непонятной успешности эксперимент, а Java не стала лучше - как требовала полинтернета для сборки и немеряно гигабайтищ памяти - так и требует, "микросервисы" получаются совсем не "микро". В итоге как бы мне не нравислся Kotlin как язык - а он у меня шесть лет уже топ 1, очень много новой разработки уже на Golang, хотя Go как язык конечно менее выразительный, хотя тоже не противный, своя прелесть в нем есть. Но экосистема, скорость и прозрачность сборки... Golang-у наверное сейчас нет равных если честно.... А тема все та же - прямые, понятные, рубленные решения в лоб и полный контроль над тем что происходят по факту удобнее любых навороченных средств с 10 слоями прокладок.
От спрингбута уже плохеет если честно. 7 лет назад сменили Java на kotlin. И через год весь этот спринг, и его Бут из стека ушли в небытие. Для экосистемы kotlin полно микро фреймворков и di. Мы используем. Ktor и kodein. Короче тут не про то как выстроить экосистему ориентированную на kotlin и его специфику, а скорее как впихнуть kotlin в этот жутковатый и полный мемов про оверинжениринг шаблон со спрингами и прочим
Ну как бы вот у нас проекты и в них есть баш скрипты,например гит хуки никто не пишет их бат версий. На винду всегда встаёт git и всегда он ставится с мингв башем, idea и vs code тоже и на винде настраиваются на баш в качестве терминала. Причём тут настройка windows? Так что ничего криминального в фразе не вижу. Ну и кроме этого ведь есть ещё маки, не линуксовые юниксы и проч. И дескать к ним тоже применимы идиомы, чем плохо?
Как джавист со стажем скажу, что когда видишь вопрос "почему на клиента 300mb?" и при этом рядом есть слово Java, то ответ сам собой напрашивается )))) Загадка не сложная )))
Вам то чем они так милы. Целое десятилетие было царствование xml, wsdl soap и всё такое, осталось только в мире легаси и кровавых межведомственных систем. Потом типа rest, json это наше всё... Ну и что по сути сейчас наметился возврат к классическим бинарным форматам но там с блэкджеком и прочим, типа протобафа. Json же смещается в более нишевое использование. Форматы, тренды, приходят и уходит. А бессмертная классика типа мейков и башей остаётся независимо от степени мощности своего синтаксиса. Причина одна они чётко знают свою работу и хорошо её делают)))
А как авторы make могли использовать то чего нет. Я вам раскрою может секрет, но xml и json не популярны не только в девопс, но и в обработке данных, так как избыточные и не поточные, там царствуют добрые старые csv и прочие такие форматы.
Xml и json это форматы для сериализации древовидных структур с сохранением (особенно xml) метаданных. Зачем это всё в make, который является сборочным скриптом?
Плохое жвачное кинцо или другой любой масскульт это не ново и думаю в древнем Риме тоже была театральная жвачка с шутками про члены для "плебса" и рядом с ними сложно навороченные постановки Вергилия для "приличной публики". Причём чем ближе был конец величия Рима тем больше было членов и всё меньше Вергилия. Так что этот факт как был так и остался. Но тем не менее есть ощущение, что что-то действительно поменялось и не в лучшую сторону, причём относительно недавно, допустим в 90х. Я думаю что это связано с общей деградацией образования и культуры управления в США, которые по итогам двух войн и распада СССР собственно тождественны культурному мейнстриму, и в целом основной игрок, чьи внутренние проблемы очень быстро становятся всеобщими. Так как россияне в массе своей от американцев отличаются очень мало, не зависимо от того относимся мы к ним как врагам или друзьям, болячки очень схожие. В СССР это компенсировалось во многом искусственно фильтруя совсем низкопробную туфту, но и это выродилось даже не в шутки про члены, фильмы те же 80х - эта бесконечная иносказательная полу политическая чернуха - по мне так ещё больше рушит мозг чем бэтмены. В общем всё это естественные процессы при всяких больших преобразованиях и тянуться они могут поколениями и столетиями. Радуемся, что порой что-то стоящее снимается или пишется, теми же корейскими друзьями, ещё кем то и особо ни на что большее не рассчитываем.
Такие зп вполне попадаются в Екате, Новосибе, Тюмени и уверен что и в каких то ещё городах, ковид сильно подстер разницу. Мантру "только Москва" обычно повторяют москвичи... и неудачники))) мантру "только Питер и Москва" чаще всего говоря питерцы и... неудачники))
Собственно и была целая эра сборщиков декларативных на xml и json. ANT, ms build, xbuild, maven, ... Имя им легион - неудобно, многословно, проблемы с порядком выполнения, уйма тайного знания. Любой кто на этом строит сборки рано или поздно понимает, что даже динозавры типа make удобнее в части управления задачами. Собственно дьявол во всяких плагинах, например в части ракетных менеджеров. Но где этот вопрос решён нормальными консольными командами или прямо встроено в тулчейн опять же проблемы с мейком нет. Как краевед говорю, который 15 лет евангелировал ms build, затем maven и большие проекты с кастомными плагинами на грэдле собирал.
Так вот yaml лучше xml и json, процедурное типа градла лучше декларативного типа мавена, мейк и баш вообще всего лучше решают всё в лоб и по простому и где есть возможность действительно проще быстрее и понятнее сделать на них
Позадавайте этот вопрос поосто в гугле, возьмите топ 10-20 ответов и в них ещё может пару кликов, получите примерно тот же набор готовых примерчиков, готов и ответов на стеке. То есть ГПТ очередная жвачка для ленивых, кто приучен учиться не по книгам, и не решая задачи сам, а по ютьюбу, не понимая, что так материал не усваивается. Используя такие штуки вместо того чтобы писать самому вы только напрочь закроете себе путь в профессию, действительно таких программистов ГПТ заменит))))
Вот из таких представлений масс, как о чем то таинственном и магическом рождается весь хайп. Именно что выхватывание готовых ответов по грамотно обученному на большой базе контекстному поиску. Круто? Да, наверное. Производит впечатление? Да, любые имитирующие людей машины обычно вызывают вау эффект. Принципиально ново? Нет, поисковые движки типа гугла и того же Яндекса изначально были более прорывными.
Сижу в общепознавательных целях пытаюсь заставить Claude реализовать на Golang ГОСТ - понятно криво и приходится все же вычитывать ГОСТ и допиливать руками, статья очень в жилу. Например - то что Дельта и инвертная дельта в ГОСТ которая там в l(...) - это по сути тождественное преобразование (в битах) и только смысл меняется - чтобы операции правильные применялись. Но это... чисто для математиков. Как программисту - я сидел и не мог понять зачем это вообще нужно. А тут в статье - сразу L без всяких там дельта-тета и вуаля.
Но кажись нашел опечатку в этом l в статье - у вас первая константа С1= 019484DD10BD275DB87A486C7276A2E6
но если пересчитать все (остальные константы сходятся, реализаци думаю верная, только одна из 32 не совпала) - то она
С1=019484DD10BD275DB87A486C7276A26E - последний байт не E6 а 6E - прошу перепроверить и если что - поправить
Наоборот я при том же понимании и наблюдениях что и у автора (про nil в основном) (про производительность давайте не будем потому что оптимизация до каких-то показаний всегда считалась оверинженирингом, понятно что где-то может быть узкое место, требующее устранения и возможно за счет передачи по значению) - имею совершенно обратное мнение.
использование nil дает каноничный способ передать "используй дефолт", без необходимости проверки передачи "пустой структуры", то есть `if myParam == nil { myParam = getDefaultMyParam()`, то есть семантика "отсутствия чего-то" в таком виде более четкая, проверять на nil не такая уж большая беда, но да runtime контроля не хватает как в Kotlin, но это не выглядит жуткой проблемой
передача указателя по дефолту дает как раз дисциплину считать, что все read-only, не копии, может быть в share и соответственно приучает более осторожно все писать, то есть чтобы переход "на копию" был более внятен. Понятно это противоречит "чистому функциональному подходу", но прикладная разработка на Go она редко про чистую функциональщину
нет пробелмы мнимой копии, когда привычка передавать по значению прячет нюансы общих буферов слайсов, присутствия интерфейсов среди полей (не известно по ссылке или по значению), вложенных структур тоже где-то по указателю, где-то по значению, то есть DEEP COPY пробелма никуда все равно не девается, но когда все на указателях ты и не ждешь, что что-то копируется каждый раз, к тому же снять shallow copy не проблема `var cpyVal MyType = *myObjRef; cpy := &cpyVal;` где действительно вынь да положь нужна эта копия
да, HEAP, GC это все медленее чем копирование и работа через стек, но я напомню что в большинстве случаев это пренебрежимо мало по сравнению с вводом-выводом, на котором строится 90% нагрузки типовых програм, и вот всякие оптимизации это уже история как раз по особым праздникам...
Ну то есть много альтернативных мнений кроме неугодных. Сколько же г...на в голове у этих америкофилов....
Ты похоже голодаешь? Когда писать в хабры успеваешь?
Да что тут особо рассказывать. Чтобы еще и не холиварить. Я лично много на чем успел пописать и поработать, поэтому не было ничего что я бы считал данностью как бы такой, дефолтной. И когда основной стек был Java использовали Spring, потому что по сравнению с Java EE и с его ужасными шаблонами, большими этими сервлет-серверами - Spring был как глоток свежего воздуха. Сам настраиваешь контейнера там, есть на все шаблоны там, готовые бины, все как-то магически заводится.
Потом в какой-то момент просыпаешься ночью в холодном поту и думаешь "а нафига я подключаю NHibernate или JPA чтобы прочитать из базы пару запросов? " и такой голос шепчет "а как же поддержка всех 100500 видов баз, нужен универсальный ORM, а для этого нужна еще специальная конфигурация и мигратор и вот же - на тебе Spring в нем это все есть" - вроде успокаиваешься. Потом у тебя в стоке приложение начинает стартовать по минуте, потом подсасывать на AutoScan столько всего ненужного из всех библиотек, что нет столько в мире аннотаций, чтобы все это понять и задизейблить.
И потом например просто для развлекухи открываешь в стоке ну там гошку и на ванильной гошке пишешь рубленными мазками то же самое, только без всяких ентерпрайз-наворотов и памяти так раз в 100 меньше и на диске без половины интернета. И снова понимаешь, что в чем-то засада и вспоминаешь, что когда до этого работал не с Java/EE/Spring, то вроде как-то спокойно все писалось без 10 уровней якобы обоснованно существующих прокладок. Понимаешь, что без всяких ORM больших спокойно кастовал рекордсеты в структуры, что все равно все время дооплетать до неузнаваемости приходится все эти штатные мидлвары для MVC на спринге. И понимаешь, что ну какой-то бойлерплейт ради бойлерплейта а на флаге написано, что это якобы солиднейший SOLID.
И когда перевели все на Kotlin (как язык) сначала тоже был просто Kotlin а остальное что было на тот момент Maven/Spring и все остальное что всегда в таких случаях тогда была. Ну а где язык - начинаешь смотреть - а что там по экосистеме, а что по библиотекам, куда вообще ветер дует. Ну и совершенно другой стек начинает вырисовываться гораздо ближе по духу к тому что можно видеть в go, - более рубленный ООП без "факторок для создания факторок производящих билдеры", никаких "аспектов", явно управляемые контейнеры зависимостей, микрофреймворки с ручной настройкой для REST/gRPC - и как некогда радовались переходя с EE на Spring, так потом радовались когда и это марево рассеялось )))
Рассеивай не рассеивай. Kotlin все же стал развиваться больше для андроида, чем в Native и в этой своей ипостаси не является конкурентом ни GO ни Rust ни плюсам, пока непонятной успешности эксперимент, а Java не стала лучше - как требовала полинтернета для сборки и немеряно гигабайтищ памяти - так и требует, "микросервисы" получаются совсем не "микро". В итоге как бы мне не нравислся Kotlin как язык - а он у меня шесть лет уже топ 1, очень много новой разработки уже на Golang, хотя Go как язык конечно менее выразительный, хотя тоже не противный, своя прелесть в нем есть. Но экосистема, скорость и прозрачность сборки... Golang-у наверное сейчас нет равных если честно.... А тема все та же - прямые, понятные, рубленные решения в лоб и полный контроль над тем что происходят по факту удобнее любых навороченных средств с 10 слоями прокладок.
Жесть уже на берегу каются в "предвзятости" алгоритмов глубокого обучения. Да нет позор тебе, позор и порка у столба
От спрингбута уже плохеет если честно. 7 лет назад сменили Java на kotlin. И через год весь этот спринг, и его Бут из стека ушли в небытие. Для экосистемы kotlin полно микро фреймворков и di. Мы используем. Ktor и kodein. Короче тут не про то как выстроить экосистему ориентированную на kotlin и его специфику, а скорее как впихнуть kotlin в этот жутковатый и полный мемов про оверинжениринг шаблон со спрингами и прочим
Ну как бы вот у нас проекты и в них есть баш скрипты,например гит хуки никто не пишет их бат версий. На винду всегда встаёт git и всегда он ставится с мингв башем, idea и vs code тоже и на винде настраиваются на баш в качестве терминала. Причём тут настройка windows? Так что ничего криминального в фразе не вижу. Ну и кроме этого ведь есть ещё маки, не линуксовые юниксы и проч. И дескать к ним тоже применимы идиомы, чем плохо?
Как джавист со стажем скажу, что когда видишь вопрос "почему на клиента 300mb?" и при этом рядом есть слово Java, то ответ сам собой напрашивается )))) Загадка не сложная )))
Да переобуться и без опыта попасть на пристойную работу в ИТ вариантов нет, только всякие чудесные случаи особые.
Ну как бы это же не единственная IDE))))
Точно. Тот же набор
Вам то чем они так милы. Целое десятилетие было царствование xml, wsdl soap и всё такое, осталось только в мире легаси и кровавых межведомственных систем. Потом типа rest, json это наше всё... Ну и что по сути сейчас наметился возврат к классическим бинарным форматам но там с блэкджеком и прочим, типа протобафа. Json же смещается в более нишевое использование. Форматы, тренды, приходят и уходит. А бессмертная классика типа мейков и башей остаётся независимо от степени мощности своего синтаксиса. Причина одна они чётко знают свою работу и хорошо её делают)))
А как авторы make могли использовать то чего нет. Я вам раскрою может секрет, но xml и json не популярны не только в девопс, но и в обработке данных, так как избыточные и не поточные, там царствуют добрые старые csv и прочие такие форматы.
Xml и json это форматы для сериализации древовидных структур с сохранением (особенно xml) метаданных. Зачем это всё в make, который является сборочным скриптом?
Плохое жвачное кинцо или другой любой масскульт это не ново и думаю в древнем Риме тоже была театральная жвачка с шутками про члены для "плебса" и рядом с ними сложно навороченные постановки Вергилия для "приличной публики". Причём чем ближе был конец величия Рима тем больше было членов и всё меньше Вергилия. Так что этот факт как был так и остался. Но тем не менее есть ощущение, что что-то действительно поменялось и не в лучшую сторону, причём относительно недавно, допустим в 90х. Я думаю что это связано с общей деградацией образования и культуры управления в США, которые по итогам двух войн и распада СССР собственно тождественны культурному мейнстриму, и в целом основной игрок, чьи внутренние проблемы очень быстро становятся всеобщими. Так как россияне в массе своей от американцев отличаются очень мало, не зависимо от того относимся мы к ним как врагам или друзьям, болячки очень схожие. В СССР это компенсировалось во многом искусственно фильтруя совсем низкопробную туфту, но и это выродилось даже не в шутки про члены, фильмы те же 80х - эта бесконечная иносказательная полу политическая чернуха - по мне так ещё больше рушит мозг чем бэтмены. В общем всё это естественные процессы при всяких больших преобразованиях и тянуться они могут поколениями и столетиями. Радуемся, что порой что-то стоящее снимается или пишется, теми же корейскими друзьями, ещё кем то и особо ни на что большее не рассчитываем.
Такие зп вполне попадаются в Екате, Новосибе, Тюмени и уверен что и в каких то ещё городах, ковид сильно подстер разницу. Мантру "только Москва" обычно повторяют москвичи... и неудачники))) мантру "только Питер и Москва" чаще всего говоря питерцы и... неудачники))
Собственно и была целая эра сборщиков декларативных на xml и json. ANT, ms build, xbuild, maven, ... Имя им легион - неудобно, многословно, проблемы с порядком выполнения, уйма тайного знания. Любой кто на этом строит сборки рано или поздно понимает, что даже динозавры типа make удобнее в части управления задачами. Собственно дьявол во всяких плагинах, например в части ракетных менеджеров. Но где этот вопрос решён нормальными консольными командами или прямо встроено в тулчейн опять же проблемы с мейком нет. Как краевед говорю, который 15 лет евангелировал ms build, затем maven и большие проекты с кастомными плагинами на грэдле собирал.
Так вот yaml лучше xml и json, процедурное типа градла лучше декларативного типа мавена, мейк и баш вообще всего лучше решают всё в лоб и по простому и где есть возможность действительно проще быстрее и понятнее сделать на них
Очередное Дельфи. Программировать больше не надо так как есть для всего готовые компоненты, которые можно двигать мышью)))
Позадавайте этот вопрос поосто в гугле, возьмите топ 10-20 ответов и в них ещё может пару кликов, получите примерно тот же набор готовых примерчиков, готов и ответов на стеке. То есть ГПТ очередная жвачка для ленивых, кто приучен учиться не по книгам, и не решая задачи сам, а по ютьюбу, не понимая, что так материал не усваивается. Используя такие штуки вместо того чтобы писать самому вы только напрочь закроете себе путь в профессию, действительно таких программистов ГПТ заменит))))
Вот из таких представлений масс, как о чем то таинственном и магическом рождается весь хайп. Именно что выхватывание готовых ответов по грамотно обученному на большой базе контекстному поиску. Круто? Да, наверное. Производит впечатление? Да, любые имитирующие людей машины обычно вызывают вау эффект. Принципиально ново? Нет, поисковые движки типа гугла и того же Яндекса изначально были более прорывными.