В данном примере ревьюер предложил улучшения, которые касаются обработки граничных случаев о чем не предусмотрел разработчик, эти изменения сделали код более эффективным.
Это изменение не дает ничего, код и так вернет 0 для n < 1. А вот проверки на переполнение тут нет, и ревьювер это пропустил. От такого ревью пользы никакой
В чем недостаток? Это известное поведение стандартной бибилиотеки, и в подавляющем большинстве случаев оно вполне приемлемо. Если я пишу какой-нибудь REST, то понимаю, что работа с БД все равно намного медленнее, ну так и какой мне смысл придумывать супербыструю обработку JSONов, если я на этом выиграю в лучшем случае около 1%, зато потеряю в читаемости кода и увеличу возможность сделать ошибку? Вот если мне нужен сервис, который перелопачивает многомегабайтные JSONы и это его основная задача, то тут да, имеет смысл поискать альтернативы стандартной библиотеке и пожертвовать простотой кода. Но как часто такое нужно?
Я имел возможность посмотреть и даже немного пописать софт для летательных аппаратов. Там такие жесткие стандарты кодирования, что NULL (в C нет nullptr, если что) просто не может появиться. И более сурового code review я в жизни не видел. Уверен, что если ошибки были вызваны бортовым софтом (непонятно, о каких катастрофах говорит автор, так что не могу проверить), то это наверняка не были классические сишные проблемы с переполнением буфера или дереференсом NULL'а, а логические ошибки, которые возможны в любом языке.
Не надо передёргивать и нагло вырывать фразу из контекста.
Тогда стоит постараться, чтобы нормально доносить контекст. В данном случае это выглядит как попытка вынести обобщенное суждения о людях, сгруппированных по возрасту, но когда такое же суждение о твоей группе выносит условный представитеть поколения альфа, это почему-то не нравится.
Я в свое время провел эксперимент - убрал из CV весь опыт до 2000 года (года рождения там и не было). Количество откликов от HR выросло в разы! Вообще ощущение, что в наше время самое сложное - пройти фильтр HR, на техническом собеседовании общаешься уже с инженерами, которым по фиг твое образование и возраст.
Это каким-то образом отменяет то, что я написал? Термина "липкая лицензия" нет, а к "вирусной" уже все привыкли, и этот термин по большей части потерял свою оригинальную негативную коннотацию
В большинстве случаев (пожалуй, только кроме AGPL) код надо раскрывать только при РАСПРОСТРАНЕНИИ производного продукта. И нет такого понятия "липкая лицензия", есть понятие "вирусная" - https://ru.wikipedia.org/wiki/Вирусная_лицензия
Да, можно форкнуть проект и самим его мейнтейнить, но тогда чем дальше, тем сильнее форк будет отличаться от главной ветки, в него не будут попадать фиксы и новые фичи из апстрима. То есть вы просто добавите себе работы. Не говоря уж о том, что это неэтичное поведение - если вы используете что-то общественное, то надо также и отдавать что-то обществу.
С опенсорсом будет точно также - если и возьмут, то поддерживать будут сами и никаких PR никто никуда отправлять не будет. Потому что дефект надо закрыть в кратчайшее время, а ждать пока согласуют PR времени ждать нет. А если не согласуют, то откатывать назад никто тут не станет и начнется расхождение в версиях.
Не надо натягивать сову. Зачем ждать, когда примут PR? Исправили - установили фикс у себя, когда его примут в апстрим, тогда примут. Если это нормальный фикс, то наверняка его примут, почему нет? Мейнтейнер рад, когда исправляют баги.
Это изменение не дает ничего, код и так вернет 0 для
n < 1. А вот проверки на переполнение тут нет, и ревьювер это пропустил. От такого ревью пользы никакойВ чем недостаток? Это известное поведение стандартной бибилиотеки, и в подавляющем большинстве случаев оно вполне приемлемо.
Если я пишу какой-нибудь REST, то понимаю, что работа с БД все равно намного медленнее, ну так и какой мне смысл придумывать супербыструю обработку JSONов, если я на этом выиграю в лучшем случае около 1%, зато потеряю в читаемости кода и увеличу возможность сделать ошибку?
Вот если мне нужен сервис, который перелопачивает многомегабайтные JSONы и это его основная задача, то тут да, имеет смысл поискать альтернативы стандартной библиотеке и пожертвовать простотой кода. Но как часто такое нужно?
К тому же когда мы десериализуем объект в структуру, используется reflect, а он весьма медленный
сайт у них конечно не очень удобно организован, но при желании найти DEB тоже можно: https://slack.com/downloads/instructions/linux?ddl=1&build=deb
У меня для вас плохие новости...
ага, и домен getbox.ru на продажу выставлен. Непонятно, то ли это толстоватый троллинг, то ли какой-то неизящный скам
Мне кажется, тут просто обязательно надо упомянуть pass (https://www.passwordstore.org/)
Круто, с
defaut-features = falseкомпилится в Wasm и даже работает, спасибо!Таки это, именно в этом и было дело
Мне кажется, этот я тоже пробовал, и он у меня не захотел в wasm32-wasi компилиться, но я еще раз попробую. В любом случае спасибо
А для самого обычно zip нет нормальной pure Rust либы, чтобы можно было спокойно в Wasm скомпилить :(
Я имел возможность посмотреть и даже немного пописать софт для летательных аппаратов. Там такие жесткие стандарты кодирования, что NULL (в C нет nullptr, если что) просто не может появиться. И более сурового code review я в жизни не видел.
Уверен, что если ошибки были вызваны бортовым софтом (непонятно, о каких катастрофах говорит автор, так что не могу проверить), то это наверняка не были классические сишные проблемы с переполнением буфера или дереференсом NULL'а, а логические ошибки, которые возможны в любом языке.
Автор, судя по тексту, отнюдь не бумер, а миллениал (https://ru.wikipedia.org/wiki/Поколение_Y)
Тогда стоит постараться, чтобы нормально доносить контекст. В данном случае это выглядит как попытка вынести обобщенное суждения о людях, сгруппированных по возрасту, но когда такое же суждение о твоей группе выносит условный представитеть поколения альфа, это почему-то не нравится.
С этим полность согласен.
То есть самому относиться презрительно к предыдущему поколению - нормально, а когда к тебе так, то вдруг что-то не нравится?
Я в свое время провел эксперимент - убрал из CV весь опыт до 2000 года (года рождения там и не было). Количество откликов от HR выросло в разы! Вообще ощущение, что в наше время самое сложное - пройти фильтр HR, на техническом собеседовании общаешься уже с инженерами, которым по фиг твое образование и возраст.
Согласен
Это каким-то образом отменяет то, что я написал? Термина "липкая лицензия" нет, а к "вирусной" уже все привыкли, и этот термин по большей части потерял свою оригинальную негативную коннотацию
В большинстве случаев (пожалуй, только кроме AGPL) код надо раскрывать только при РАСПРОСТРАНЕНИИ производного продукта. И нет такого понятия "липкая лицензия", есть понятие "вирусная" - https://ru.wikipedia.org/wiki/Вирусная_лицензия
Да, можно форкнуть проект и самим его мейнтейнить, но тогда чем дальше, тем сильнее форк будет отличаться от главной ветки, в него не будут попадать фиксы и новые фичи из апстрима. То есть вы просто добавите себе работы. Не говоря уж о том, что это неэтичное поведение - если вы используете что-то общественное, то надо также и отдавать что-то обществу.
Не надо натягивать сову. Зачем ждать, когда примут PR? Исправили - установили фикс у себя, когда его примут в апстрим, тогда примут. Если это нормальный фикс, то наверняка его примут, почему нет? Мейнтейнер рад, когда исправляют баги.