Я скажу: простые запросы и простые регекспы одинаково хорошо читаются. Сложные запросы также сложно читаются, как и сложные регекспы.
Чуть-чуть схитрил: это с учётом, что большинство движков регулярок поддерживает расширенный синтаксис с пропуском whitespace и комментариями. Классический синтаксис быстро становится нечитаемым с ростом регулярки.
Легко: если встретился минус, а перед ним не было операндов (т.е. начало выражения или перед этим была скобка) то пушим ноль в качестве операнда.
Альтернатива: заводим (внутреннюю) операцию «унарный минус» с соответствующим приоритетом (выше умножения), и пушим её, если не было операнда и был минус.
Конечно, тут приходится новую яйчейку памяти заводить под «не было операндов». А всё потому, что один знак «минус» использован для разных операций. Логически они одинаковые, но имеют разное число аргументов.
С унарными операциями, имеющими свой собственный знак, такой проблемы нет. Правда, нас спасает то, что математические унарные операции - префиксные и имеют высокий приоритет. Благодаря этим свойствам, они вписываются в алгоритм.
Мало того, если поискать интервью по истории C++, то Страуструп рассказывал, что первые версии C++ создавались им для разработки сетевого демона с корутинами. Вряд ли корутины были частью языка, но сам факт.
Именно. Ранние версии Rust имели много общего с Go, и казалось, что они будут конкурировать непосредственно. Но потом направление развития Rust сильно поменялось.
Даже в диссертации по Raft (не в тонкой статье, а в толстой книжке) рассматриваются различные варианты улучшения протокола.
Базовый Raft - это минимально достаточный алгоритм, гарантирующий консенсус. Но когда начинается практическое применение, вылезают узкие места, которые приходится оптимизировать.
Тот же самый Pre-Vote по сути уже уже well-known must-have оптимизация. Уже все знают, что без pre-vote нельзя.
Fencing - интересное дополнение. Не знаю, был описан ли он где до этой статьи.
Смысл рассматривать Raft, как "закостенелый" протокол, нет. Он имеет как описанные в диссертации возможные улучшения, так и "разведанные в бою" пользователями.
Ценность Raft как раз в том, что реально работающих реализаций много. Исходный протокол был достаточно понятен, чтобы появились реализации во многих продуктах. А главное, в open-source и бесплатных продуктах. Сразу выросла пользовательская база, появились разнообразные ситуации применения, вылезли узкие места. И сразу начались доработки, которые тоже попали в open source.
Реализованные протоколы до Raft, такие как Paxos/MultiPaxos/ZAB/etc, были или сложно описаны, или реализованы в единичных opensource продуктах (ZAB в ZooKeeper, Paxos в corosync), либо вообще только закрытых продуктах и экосистемах.
Так что, Raft - это развивающийся протокол на основе проверенной базы. Главное не нарушать базу, и тогда у тебя сохраняются гарантии.
Сперва появились корпорации, которым срочно нужны новые технологии. Имеющиеся специалисты из смежных технологий СОЗДАЛИ эти технологии. Корпорациям нужно было масштабировать эти технологии, и они начали предлагать МНОГО ДЕНЕГ другим специалистам из смежных технологий, чтобы они осваивали новые технологии. А создатели технологий получали ЕЩЁ БОЛЬШЕ ДЕНЕГ, т.к. становились руководителями и носителями знаний.
Когда второе поколение специалистов начинает нанимать третье, а зарплаты ВСЁ ЕЩЁ ВЫСОКИЕ, то, с одной стороны, корпорации понимают, что платить так много накладно, и нужно больше специалистов, готовых на зарплату поменьше. А с другой стороны, этими технологиями начинает интересоваться молодёжь. Эти встречно направленные стремления приводят к появлению обучающих курсов в ВУЗах/колледжах.
И вот тогда у корпораций появляется возможность иметь массу среднеоплачиваемых специалистов, способных выполнять рутинную работу, и небольшой костяк высокооплачиваемых профи, двигающих технологии вперёд.
Но начинается всё с высоких зарплат. Не будет зарплат, не будет первых перебежчиков из смежных областей. Не будет зарплат, не будет второго поколения специалистов. Не будет зарплат, не будет интереса молодёжи и адекватных учебных курсов.
А значит, не будет массы отучившихся, из которой можно будет отсеивать высококлассных специалистов на высокие зарплаты.
Дайте зарплату в 200к, и к вам потянутся энтузиасты, которые сейчас на PIC-ах и ARM-ах клепают домашние поделки. Сделайте курсы ПЛИС со стипендией в 80к, гарантированной стажировкой и зп после испытательного срока в 150к, и к вам потянутся одаренные студенты.
А не хотите вкладывать деньги, так и получите горькое многолетнее растение.
Надежность бывает разная. От механических повреждений SSD точно лучше защищен. Во времена SLC можно было говорить и о времени хранения и о количестве перезаписи.
Последние поколения SSD с QLC уже по количеству перезаписи приближаются (сверху) к HDD. Да и надежность хранения падает, т.к. вероятность битрота при большом числе уровней заряда больше. Алгоритмически это решают добавлением большего объема информации для восстановления, но это полумера. В через какое-то время хранения информации без доступа к ней битрот станет лавинообразно нарастать, т.к. заряд утекает из яйчеек примерно с одинаковой скоростью.
С этим столкнулся Самсунг ещё во времена планарной MLC памяти. Когда они сделали тех-процесс меньше 19нм, на их SSD появился «забавный» эффект: файлы, к которым не обращались давно, читались оооочень медленно. Это потому, что битрот достигал таких масштабов, что микроконтроллеру приходилось жечь электричество на расчёт восстановления по доп.информации.
Индустрию тогда спасла 3D компоновка памяти, позволившая наращивать объем без уменьшения тех.процесса.
Есть проекционные.
На самом деле, я пытался такое представить, и кажется, что неудобно: нужно пальцы в воздухе держать.
Хотя, с датчиками, дающими клик, может и луче будет.
C++
MSVC вроде приравнивает long double к double
Я скажу: простые запросы и простые регекспы одинаково хорошо читаются. Сложные запросы также сложно читаются, как и сложные регекспы.
Чуть-чуть схитрил: это с учётом, что большинство движков регулярок поддерживает расширенный синтаксис с пропуском whitespace и комментариями. Классический синтаксис быстро становится нечитаемым с ростом регулярки.
Если уничтожен ключ шифрования, то данные уже не существуют. Если бэкапы зашифрованы тем же ключом, то и бэкапы уже не существуют.
Но против хакеров аргументов нет. Если данные были украдены в расшифрованном виде заранее, то с этим ни чего не сделаешь.
Легко: если встретился минус, а перед ним не было операндов (т.е. начало выражения или перед этим была скобка) то пушим ноль в качестве операнда.
Альтернатива: заводим (внутреннюю) операцию «унарный минус» с соответствующим приоритетом (выше умножения), и пушим её, если не было операнда и был минус.
Конечно, тут приходится новую яйчейку памяти заводить под «не было операндов». А всё потому, что один знак «минус» использован для разных операций. Логически они одинаковые, но имеют разное число аргументов.
С унарными операциями, имеющими свой собственный знак, такой проблемы нет. Правда, нас спасает то, что математические унарные операции - префиксные и имеют высокий приоритет. Благодаря этим свойствам, они вписываются в алгоритм.
Т.е. загубив 5 поколений выпускников университетов, страна внезапно осознала…
Хотя, боюсь, деньги опять будут пилить эффективные менеджеры, продолжая пытаться нанимать вчерашних студентов за копейки.
Мало того, если поискать интервью по истории C++, то Страуструп рассказывал, что первые версии C++ создавались им для разработки сетевого демона с корутинами. Вряд ли корутины были частью языка, но сам факт.
Чак Норрис не программирует на С++2099. При виде Чака Норриса, С++2099 программирует себя сам.
Именно. Ранние версии Rust имели много общего с Go, и казалось, что они будут конкурировать непосредственно. Но потом направление развития Rust сильно поменялось.
Вообще-то InnoDB - версионник. И при этом, внезапно, пишет новую версию на старое место. Просто старую версию уносит в другое место.
Oracle делает так же.
Даже в диссертации по Raft (не в тонкой статье, а в толстой книжке) рассматриваются различные варианты улучшения протокола.
Базовый Raft - это минимально достаточный алгоритм, гарантирующий консенсус. Но когда начинается практическое применение, вылезают узкие места, которые приходится оптимизировать.
Тот же самый Pre-Vote по сути уже уже well-known must-have оптимизация. Уже все знают, что без pre-vote нельзя.
Fencing - интересное дополнение. Не знаю, был описан ли он где до этой статьи.
Смысл рассматривать Raft, как "закостенелый" протокол, нет. Он имеет как описанные в диссертации возможные улучшения, так и "разведанные в бою" пользователями.
Ценность Raft как раз в том, что реально работающих реализаций много. Исходный протокол был достаточно понятен, чтобы появились реализации во многих продуктах. А главное, в open-source и бесплатных продуктах. Сразу выросла пользовательская база, появились разнообразные ситуации применения, вылезли узкие места. И сразу начались доработки, которые тоже попали в open source.
Реализованные протоколы до Raft, такие как Paxos/MultiPaxos/ZAB/etc, были или сложно описаны, или реализованы в единичных opensource продуктах (ZAB в ZooKeeper, Paxos в corosync), либо вообще только закрытых продуктах и экосистемах.
Так что, Raft - это развивающийся протокол на основе проверенной базы. Главное не нарушать базу, и тогда у тебя сохраняются гарантии.
Нет, не ужасно. Вполне нормально.
Но так может даже и лучше.
В некоторых языках отдельный оператор заводят типа
|>Ну да, это личные пристрастия. Я хоть и не в банке, но всю жизнь, по факту, байтики перекладываю, и мне норм.
Правда, завидую тихо людям, пишущим бизнес-логику на языках высокого уровня. Но кажется, что это не совсем моё.
И да, нормальный вариант.
И опять путаете причину и следствие.
Сперва появились корпорации, которым срочно нужны новые технологии. Имеющиеся специалисты из смежных технологий СОЗДАЛИ эти технологии. Корпорациям нужно было масштабировать эти технологии, и они начали предлагать МНОГО ДЕНЕГ другим специалистам из смежных технологий, чтобы они осваивали новые технологии. А создатели технологий получали ЕЩЁ БОЛЬШЕ ДЕНЕГ, т.к. становились руководителями и носителями знаний.
Когда второе поколение специалистов начинает нанимать третье, а зарплаты ВСЁ ЕЩЁ ВЫСОКИЕ, то, с одной стороны, корпорации понимают, что платить так много накладно, и нужно больше специалистов, готовых на зарплату поменьше. А с другой стороны, этими технологиями начинает интересоваться молодёжь. Эти встречно направленные стремления приводят к появлению обучающих курсов в ВУЗах/колледжах.
И вот тогда у корпораций появляется возможность иметь массу среднеоплачиваемых специалистов, способных выполнять рутинную работу, и небольшой костяк высокооплачиваемых профи, двигающих технологии вперёд.
Но начинается всё с высоких зарплат. Не будет зарплат, не будет первых перебежчиков из смежных областей. Не будет зарплат, не будет второго поколения специалистов. Не будет зарплат, не будет интереса молодёжи и адекватных учебных курсов.
А значит, не будет массы отучившихся, из которой можно будет отсеивать высококлассных специалистов на высокие зарплаты.
Дайте зарплату в 200к, и к вам потянутся энтузиасты, которые сейчас на PIC-ах и ARM-ах клепают домашние поделки. Сделайте курсы ПЛИС со стипендией в 80к, гарантированной стажировкой и зп после испытательного срока в 150к, и к вам потянутся одаренные студенты.
А не хотите вкладывать деньги, так и получите горькое многолетнее растение.
А мне не понятен другой вопрос: раз уж вы избавились от него в коде на Rust, то почему в C++ не перешли на std::unique_ptr?
Случайно минус нажал. Прошу прощения.
Почему подешевеет? Если упал спрос, то упадёт и производство. Цена останется примерно такой же.
Надежность бывает разная. От механических повреждений SSD точно лучше защищен. Во времена SLC можно было говорить и о времени хранения и о количестве перезаписи.
Последние поколения SSD с QLC уже по количеству перезаписи приближаются (сверху) к HDD. Да и надежность хранения падает, т.к. вероятность битрота при большом числе уровней заряда больше. Алгоритмически это решают добавлением большего объема информации для восстановления, но это полумера. В через какое-то время хранения информации без доступа к ней битрот станет лавинообразно нарастать, т.к. заряд утекает из яйчеек примерно с одинаковой скоростью.
С этим столкнулся Самсунг ещё во времена планарной MLC памяти. Когда они сделали тех-процесс меньше 19нм, на их SSD появился «забавный» эффект: файлы, к которым не обращались давно, читались оооочень медленно. Это потому, что битрот достигал таких масштабов, что микроконтроллеру приходилось жечь электричество на расчёт восстановления по доп.информации.
Индустрию тогда спасла 3D компоновка памяти, позволившая наращивать объем без уменьшения тех.процесса.