Вот насколько мне нравится Rust, по крайней мере когда начинаешь на нём писать, там прям каждая мелочь продуманной кажется. Настолько мне кажется уродливым го. Прям всё раздражает в нём. Аргх.
fmt.Errorf не добавляет стектрейса. Есть всякие старые пакеты, которые добавляют, но они типа unmaintainable. В общем гоферам стектрейсы не нужны. Что им мешает сделать какой-нибудь GO_FMT_ERRORF_ADD_STACKTRACE_PRETTY_PLEASE=IUNDERSTANDPERFORMANCEIMPLICATIONS я не понимаю.
:= абсолютно упоротая конструкция. Зачем она нужна в текущем виде — я вообще не понимаю.
Вот только что столкнулся. Угадайте, чем отличается log.Print от log.Println. На стековерфлу не подглядывать, только в godoc-и:
func Print(v ...any)
Print calls Output to print to the standard logger. Arguments are handled in the manner of fmt.Print.
func Println(v ...any)
Println calls Output to print to the standard logger. Arguments are handled in the manner of fmt.Println.
ответ
Нет, не тем, что Println ставит перевод строки. Они оба ставят перевод строки. Print ставит пробелы между аргументами, если только один из аргументов не является строкой. Println всегда ставит пробелы между аргументами.
Меня так раздражает только жаваскрипт. Но там — ладно, его делали левой ногой перед дедлайном как сайд-проект, который не должен был взлететь, понять можно.
Здравствуйте, smeeld, Вы писали:
vsb>>fmt.Errorf не добавляет стектрейса.
S>Просто сначала подучи go, и уж потом мнение имей.
It is generally true that if you can fool developers into thinking they are "mastering" something hard (as opposed to learning tolerance for something badly designed), you can build a fiercely loyal priesthood.
Здравствуйте, vsb, Вы писали:
vsb>А &self.n вынести в переменную не даст borrow checker?
Я думал об этом когда писал этот участок. С borrow checker для &self.n там нету проблем. Но в итоге поленился написать let n = &self.n; )) Я лишь хочу донести мысль, что использование перегруженных операторов в расте в коде выглядит коряво из-за необходимости периодически писать &, чтобы переменная не мувнулась
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, T4r4sB, Вы писали:
TB>>Здесь кажется & нахрен не нужно
AD>Точно! Спасибо за ревью Убрал & с ux и выше с gx. Но всё равно сильно меньше & не стало
По моим прикидкам, можно оставить только 4 амперсанда, где передаются в self.modpow
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали: TB>По моим прикидкам, можно оставить только 4 амперсанда, где передаются в self.modpow
Проверил. Больше нигде & не убрать. На плюсах вообще конфетка получается:
конфетка без &
auto x = get_user_hash(salt);
auto gx = g.modpow(x, n);
auto kgx = (k * gx) % n;
auto bkgx =
server_public_key > kgx
? server_public_key - kgx
: n + server_public_key - kgx;
auto diff = bkgx % n;
auto ux = (u * x) % n;
auto aux = (client_private_key + ux) % n;
auto secret = diff.modpow(aux, n);
Никакие & не засоряют код. Я не сказал бы, что в расте это прямо вымораживает, но после плюсов кажется корявым
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, T4r4sB, Вы писали:
TB>>По моим прикидкам, можно оставить только 4 амперсанда, где передаются в self.modpow
AD>Проверил. Больше нигде & не убрать.
if server_public_key > &kgx {
?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, ArtDenis, Вы писали:
AD>Ну да. "Нам нужно больше *"
Ну так-то да, символов меньше не становится, я чисто по смыслу имею в виду, что раз там подразумеваются объекты а не ссылки, то лучше передавать в оператор именно объекты.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, vsb, Вы писали:
vsb>fmt.Errorf не добавляет стектрейса. Есть всякие старые пакеты, которые добавляют, но они типа unmaintainable. В общем гоферам стектрейсы не нужны. Что им мешает сделать какой-нибудь GO_FMT_ERRORF_ADD_STACKTRACE_PRETTY_PLEASE=IUNDERSTANDPERFORMANCEIMPLICATIONS я не понимаю.
fmt.Errorf является нормальным уровнем логирования, почему он должен добавлять трассировку стека? log.Panic выбросит панику и у тебя будет стек вызовов. Зачем тебе на каждой ошибке стек?
vsb>:= абсолютно упоротая конструкция. Зачем она нужна в текущем виде — я вообще не понимаю.
:= конструкция создания объекта, эквивалентом будет new, let, var в других языках.
vsb>Меня так раздражает только жаваскрипт. Но там — ладно, его делали левой ногой перед дедлайном как сайд-проект, который не должен был взлететь, понять можно.
auto x = ...
auto gx = ...
auto kgx = ...
auto bkgx = ...
auto diff = ...
auto ux = ...
auto aux = ...
auto secret = ...
А что за мода везде auto пихать? Всё настолько плохо что нет понимания какой тип будет у переменной?
Нет, я понимаю что тот же тип итератора может полторы строки занимать, но есть же typedef или даже #define в конце концов.
Почему auto? Почему код запутываете специально?
Здравствуйте, Sheridan, Вы писали:
S>А что за мода везде auto пихать?
Не мода, а необходимость ради упрощение кода
S>Всё настолько плохо что нет понимания какой тип будет у переменной?
Ого как задело См выше + auto ставится там, где сразу понятно какой тип у переменной и auto не создаёт когнитивной нагрузки.
S>или даже #define в конце концов.
Ну да, начал за здравие, а кончил за упокой. Macro MUST DIE!!!
S>Почему auto?
Потому что это означает автовывод значение переменной. Ваш КО.
S>Почему код запутываете специально?
Если кто-то тупит перед авто, значит либо 1) плюсы не для него, 2) он красноглазит и не ставит себе нормальную IDE и вообще ССЗБ
Здравствуйте, ArtDenis, Вы писали:
S>>А что за мода везде auto пихать? AD>Не мода, а необходимость ради упрощение кода
S>>Всё настолько плохо что нет понимания какой тип будет у переменной? AD>Ого как задело См выше + auto ставится там, где сразу понятно какой тип у переменной и auto не создаёт когнитивной нагрузки.
личное имхо, таки создает.
чтобы понять, какой тип у переменной, ты должен вникнуть в контекст.
имея перед глазами конкретный тип сделать это проще.
