Не знаю си, но уверен что навязываемых проверок в си нет. Верим "массив не будет пуст и можно смело брать элемент" - и можно и не проверять. Rust же заставит обработать вероятную ситуацию, тем самым добавив лишние if.
Тут 2 стула. Либо "проверять тут нечего, ситуация не возникнет - и потом в рантайме получаем ой", либо "делаем доп проверки на каждый чих, но в реале они никогда не сработают и будут зря кушать такты".
Судя по количеству ошибок в сишном коде вариант "мамой клянусь тут ошибок нет" работает не очень.
Никому не нравится, но нужно быть реалистами — заменять не на что. А чтобы заменить… Ну тут сильно здорово нужно подумать и времени это займет нереально.
создать абсолютно новую архитектуру процессора, который не умеет в спекулятивное выполнение, но при этом не уступает по скорости.
Отладить эту новую архитектуру. Ну чтобы снова потом не начинать все с самого начала по гарантии из-за ошибок проектирования новой архитектуры.
Построить производственную линию. Причем несколько — под разные сокеты (материнские платы ведь менять нельзя)
Выпустить большое количество процессоров и доставить их потребителю
Например, они активно используются в jetpack compose в Modifier. В зависимости от текущего скоупа у Modifier доступны те или иные методы расширения. Если у нас BoxScope, то нам доступны дополнительно Modifier.aling() и Modifier.matchParentSize(), где они имеют смысл. И не путаются под ногами в других местах.
Также возможность элегантно расширить контрол, в котором авторы не додумали сделать нужное. Без этого в jetpack compose пришлось бы изворачиваться как в swiftUI (хотя там тоже неплохо, но не так гибко).
Ну а Flow<> своими методами как иначе расширять?!
Конечно гибкость вида "подключили библиотеку и у нас появились дополнительные методы" обладает обратной стороной "скопировал код с so и все горит красным, не пойму что импортировать и где искать".
Нет никакой желтизны. В заголовке речь идет о 12гб версии, которая имела не только меньше памяти, а вот ту самую начинку, что сейчас как 4070ти подают. Можете даже спеки сравнить.
match greeting:
case "":
print('Hello my friend')
case _:
print(f'Hello {greeting}')
в случае с wildcard хоть работает ожидаемо. А в случае с case name — переменная name может существовать выше, а позже быть переименована и case name начинает работать как wildcard с именем? Стрельба в ногу какая-то.
И все равно непонятно причем тут захват. name это переменная, которая существует до match greeting и ее видно в print(f'Hello {name}'), что ожидаемо, ведь match это просто переписанная иначе цепочка if. Так что куда захватывается?
Принимается. Как средство, что позволит откатить по горячим следам. Мне этого не всегда достаточно, но это уже мои личные проблемы и потому я избегаю гит.
вот я об этом выше и говорил, а мне начали доказывать что гит хуже)))
Ну вы даете. Товарищ явно написал, что его переход на git был обоснован не личными качествами git, а потому что гитхаб.
Перемотайте в начала ветки и посмотрите с чего начался наш спор )))
Да так. Небольшой оффтоп. Просто вы необходимость чтения документации в плюсы к причинам популярности гит записали.
На этом предлагаю закруглиться. Почему? Вместо ответа я лучше скопипастю цитату с того же хабра
Не хвататься за оголенные провода несложно.
Понять, почему на обычном рабочем месте изоляция на проводах отсутствует, гораздо сложнее.
Еще сложнее понять тех, кто продает все это как достоинства инструмента.
Вы действительно считаете, что тулз, для работы с которым нужно читать тонны документации, спрашивать коллег или на форумах и при всем при этом все равно иметь урезанные возможности (пресловутое «нам это не нужно») — это хороший тулз?
Это объективное мнение или субъективное
Первое конечно. Продуманный инструмент всегда проще в освоении, чем тот, где нужно тщательно читать много документации. Как по вашему, насколько интуитивен отсоединенный комит? Насколько интуитивно то, что ваши комиты считают мусором?
Концепт подхода гита к веткам отличается от привычного. Имеет право на жизнь, почему ж нет. Но в остальном косяки вызывают недоумение.
Исходя из ваших слов вы не проводили опытное сравнение с альтернативами. Вы выбрали гит, потому что он «на слуху» или «более популярен». А популярность гиту обеспечил авторитет автора и гитхаб. Так что «начал только в прошлом году» не является аргументом.
Но что рандомное или убогое средство
Если сравнивать гит с другими по принципу «давать программисту как можно больше, а мешать как можно меньше», то гит выглядит как любительская поделка. Но ко всему можно привыкнуть. Любой инструмент можно освоить и не стрелять себе в ногу. Вот и гит там же. И то что альтернативы проще (в освоении, а не в фичах), удобнее и безопаснее — роли уже не играет, ведь «уже освоился и привык, зачем мне альтернатива»
Вот только хорошим и удобным оказался не git, а GitHub, что и определило выбор. И выбирали не гит, а GitHub. А далее и вовсе не выбирали, ибо считать выбором «везде требуют гит, потому выбираем гит» просто наивно.
Угадывание происходит также при rebase/merge. И если не угадал, то есть шанс, что он молча вольет левые изменения не туда. Спасает git только то, что у такой ситуации малая вероятность (нужно чтобы файлы были похожи и место вливания похожи).
Слухи про неизменность истории в меркуриал очень давно устарели.
Для переписывания истории там не один инструмент (rebase, histedit, mq, evolve), но, в отличие от git (а может и вообще всех остальных) позволяет делать это безопасно (evolve). Более того, существуют даже официально переписываемые публично ветки (topic). Попробуйте переписать публичную ветку в git, когда вы в ней не один. А в меркуриал это не приносит проблем.
Разве?.. По логике вещей идет обычное планирование продолжения в ThreadPool и сначала будут сделаны запланированные ранее задачи, чем дело дойдет до этого продолжения. Иначе не будет разницы между обычными потоками без await. Нет никакой гарантии выполнения в том же потоке при ConfigureAwait(false), да и ConfigureAwait(true) тоже, если нет контекста, который жестко прибьет гвоздями продолжение к какому-то потоку.
Может тяготеть исполнять в том же потоке — да, но это не гарантируется.
Не знаю си, но уверен что навязываемых проверок в си нет. Верим "массив не будет пуст и можно смело брать элемент" - и можно и не проверять. Rust же заставит обработать вероятную ситуацию, тем самым добавив лишние if.
Тут 2 стула. Либо "проверять тут нечего, ситуация не возникнет - и потом в рантайме получаем ой", либо "делаем доп проверки на каждый чих, но в реале они никогда не сработают и будут зря кушать такты".
Судя по количеству ошибок в сишном коде вариант "мамой клянусь тут ошибок нет" работает не очень.
В rust же все эти многочисленные unwrap/expect/? разворачиваются в дополнительные проверки, которые повышают безопасность за счет производительности.
Например, они активно используются в jetpack compose в Modifier. В зависимости от текущего скоупа у Modifier доступны те или иные методы расширения. Если у нас BoxScope, то нам доступны дополнительно Modifier.aling() и Modifier.matchParentSize(), где они имеют смысл. И не путаются под ногами в других местах.
Также возможность элегантно расширить контрол, в котором авторы не додумали сделать нужное. Без этого в jetpack compose пришлось бы изворачиваться как в swiftUI (хотя там тоже неплохо, но не так гибко).
Ну а Flow<> своими методами как иначе расширять?!
Конечно гибкость вида "подключили библиотеку и у нас появились дополнительные методы" обладает обратной стороной "скопировал код с so и все горит красным, не пойму что импортировать и где искать".
Нет никакой желтизны. В заголовке речь идет о 12гб версии, которая имела не только меньше памяти, а вот ту самую начинку, что сейчас как 4070ти подают. Можете даже спеки сравнить.
в случае с wildcard хоть работает ожидаемо. А в случае с case name — переменная name может существовать выше, а позже быть переименована и case name начинает работать как wildcard с именем? Стрельба в ногу какая-то.
Перемотайте в начала ветки и посмотрите с чего начался наш спор )))
На этом предлагаю закруглиться. Почему? Вместо ответа я лучше скопипастю цитату с того же хабра
Остальное можно списать на «будь внимательнее», но «делай бэкапы» я за решение не считаю
Первое конечно. Продуманный инструмент всегда проще в освоении, чем тот, где нужно тщательно читать много документации. Как по вашему, насколько интуитивен отсоединенный комит? Насколько интуитивно то, что ваши комиты считают мусором?
Концепт подхода гита к веткам отличается от привычного. Имеет право на жизнь, почему ж нет. Но в остальном косяки вызывают недоумение.
Если сравнивать гит с другими по принципу «давать программисту как можно больше, а мешать как можно меньше», то гит выглядит как любительская поделка. Но ко всему можно привыкнуть. Любой инструмент можно освоить и не стрелять себе в ногу. Вот и гит там же. И то что альтернативы проще (в освоении, а не в фичах), удобнее и безопаснее — роли уже не играет, ведь «уже освоился и привык, зачем мне альтернатива»
Вот только хорошим и удобным оказался не git, а GitHub, что и определило выбор. И выбирали не гит, а GitHub. А далее и вовсе не выбирали, ибо считать выбором «везде требуют гит, потому выбираем гит» просто наивно.
Угадывание происходит также при rebase/merge. И если не угадал, то есть шанс, что он молча вольет левые изменения не туда. Спасает git только то, что у такой ситуации малая вероятность (нужно чтобы файлы были похожи и место вливания похожи).
Для переписывания истории там не один инструмент (rebase, histedit, mq, evolve), но, в отличие от git (а может и вообще всех остальных) позволяет делать это безопасно (evolve). Более того, существуют даже официально переписываемые публично ветки (topic). Попробуйте переписать публичную ветку в git, когда вы в ней не один. А в меркуриал это не приносит проблем.
Набросал бенч на коленке сериализацию и десериализацию и получилось:
core 2.2.2
Newtonsoft: 1 (allocated 35.48 MB)
Velo: 0.43 (allocation 12.36 MB)
SpanJson: 0.18 (allocation 2.75 MB)
Newtonsoft: 1 (allocated 25.45 MB)
Velo: 0.36 (allocation 5.93 MB)
SpanJson: 0.27 (allocation 4.4 MB)
Может тяготеть исполнять в том же потоке — да, но это не гарантируется.