Несмотря на то, что я в расте новичок, готов утверждать, что с безопасностью (а точнее со способами выстрелить себе в ногу) у раста всё существенно лучше, чем в плюсах. В safe rust получить UB/segfault/data races не проще чем в каких-нибудь Java/Python/C#. Статический анализ тут не причём, это именно проверка валидности программа с точки зрения компилятора. Для сравнения — вы получаете в Джаве ошибку, когда класс имплементит интерфейс, но не реализует его метод. Такая ситуация может быть валидна синтаксически, но интерпретатор ваш код отвергнет.
При этом в Safe Rust, наверное, можно сделать всё что угодно, кроме FFI-вызовов. А Unsafe же приходится использовать весьма редко. Например я попробовал посмотреть в https://github.com/openethereum/openethereum — и там на ~120000 строк rust-кода нашлось 22 вхождения слова unsafe (из которых некоторые даже не относятся к коду). Так что если у вас всё же что-то пойдёт не так, то есть довольно мало мест, на которые надо обратить пристальное внимание.
К сожалению (или к счастью) у меня не мак, а Dell с пластиковым корпусом, да ещё и все розетки в доме и вилка ноутбука с заземлением. В общем, без шансов повторить эксперимент.
В любом случае я отвечал вам на комментарий о принципиальной невозможности подобного, рассчитывая внести для вас немного ясности в то, как работает электричество. Потому как для меня самого это тема не самая простая, и такие вот объяснения на пальцах мне лично помогают разобраться
Если объяснять на пальцах, то как-то будет как-то так:
Вольты — это разность потенциалов. Т.е. мера двух объектов относительно друг друга, а не независимая величина. И в случае питания от сети у вас объектов три: два контакта на БП и земля. Вот между контактами на БП у вас 20 вольт. А между любым из них и землёй — 110.
Я вот новичок в расте, но немного освоившийся. На данный момент ощущения от синтаксиса у меня такие
Привычные: <T> — дженерики везде одинаковы; {} — ура, скобочки (надоел Python); . — доступ к полям объекта тоже как и везде; &, * — хоть я плюсы только в учебнике видел, но операторы запомнил
Знакомые: -> — return тип в таком виде встречается; => — ну паттерн матчинг понятие новое, но такие стрелочки в жизни я встречал в каких-то похожих контекстах;
Изящные: ? — отличное решение проброса ошибки вместо эксепшнов; print! — сначала ощущение, что на тебя кричат, но вообще удобно отличать макрос от функции
Напрягающие: ?Sized — выглядит как костыль (почему не UnSized какой-нибудь?); dyn Trait — вся концепция какая-то мутная, неизящная, ещё и постоянно юзается как Box<dyn Trait> как бы подчёркивая кривизну; @ — тут явно чё-то перемудрили с выбором синтаксиса для, имхо, редкоюзаемой фичи
Мозговзрывающие: a..=b — автоматически читается как a= a..b с фатал эррором в голове при поиске оператора .. (для тех кто не знает раст — это, упрощённо, range a..b только включая b); ||{} — лямбды хоть и знакомы из руби, всё равно ощущаются инородно, расту больше бы какая-то стрелочка здесь подошла (надо было у паттерн-матчинга отнять).
Вовочка: 'a — конечно же лайфтаймы, глаза автоматически пытаются искать закрывающую кавычку. Считаю это самым худшим решением в синтаксисе раста, учитывая что лайфтаймы не так и редко нужны и — что ещё хуже — используются подряд в большом количестве, делая максимально нечитаемыми определения функций. Лучше б уж сюда @ присобачили.
Я понимаю, что ещё наверное пара месяцев игр с растом, и я ко всему привыкну, но тут обсуждалось чем синтаксис может оттолкнуть новичков, так что думаю я встрял вовремя)
P.S. Насчёт ключевых слов (fn, trait, impl, struct). Считаю, что у раста с этим всё очень хорошо. С одной стороны они довольно знакомы и очевидны, с другой — дают понять, что struct это вам не class, а trait — не совсем interface.
Можно почитать «Записки юного врача» Булгакова. Будет вполне достаточно для того, чтобы сложить представление о сифилисе и способах его передачи на начало 20го века.
Если релизы каждый день, то вешать тэги руками будет несколько неудобно. Автоматике значительно удобнее деплоить из релизной ветки по автодетекту ченжей
По первой ссылке в статье написано 2900 смертей на 6.4млн больных. Это 0,045% смертность.
У короновируса сейчас 427 смертей на 20700 заболевших. Это уже 2%, что очень немало, при этом большинство все ещё больны и в какую сторону качнутся эти 2% — тот ещё вопрос.
Мне кажется, или это называется «подключить библиотеку пакетным менеджером»?
Понятное дело, что очень ограниченно работает для компонент на разных языках программирования, но там без сериализации данных в любом случае не обойтись.
Нашёл статью 1992-го года, в которой описывается эквивалентность утверждений про кубический граф и про чувствительность функции www.sciencedirect.com/science/article/pii/0097316592900608
Там ещё пара страниц доказательства, которые я пожалуй пока не осилю)
Если я вас правильно понял, то немного не совсем так. Не от входа корень считается, потому что например функция-константа имеет размер входа n, но чувствительность ноль.
Правильная формулировка такая: чувствительность не меньше корня из deg(f) (степени функции).
А что такое степень надо говорить отдельно.
Любую булеву функцию можно представить в виде полинома. Я не уверен, что прав, но вроде бы имеется в виду Полином Жегалкина. Собственно deg(f), т.е. степень функции — это степень этого полинома, т.е. максимальная степень его слагаемых.
Вообще парень доказал штуку, которая довольно просто формулируется в терминах графов. В n-мерном кубическом графе любой подграф степени 2^(n-1)+1 (т.е. имеющий больше половины вершин исходного графа) имеет вершину степени не меньше чем sqrt(n).
Правда я понятия не имею, как из этой теоремы следует теорема чувствительности, но вроде как это известный переход, на который ссылается автор. Только разобраться надо.
В биткоине размер комиссии не зависит от суммы. Зависит от размера в байтах (фактически от количества входов/выходов) и от загруженности сети. Так что очень большая комиссия — это не по меркам фиатных денег, а по меркам крипты
Извините, но тут вы неправы. Объекты в JS — это хэш таблицы, а хэш таблицы хранятся не так как вы говорите — там нет никакой сортировки. Создаётся массив бакетов. Далее каждый ключ у объекта хэшируется в некоторое число N, и вместе со своим значением скидывается в бакет по индексу N. Чтобы получить значение по ключу делается то же самое — берется хэш от ключа, и совершается «прыжок» в нужное место за O(1).
Где тут подвох? Подвох в том, что хэши могут повторяться, и в бакетах может быть заметно больше одного элемента. Но даже в этом случае получить ассимптотически что-то большее чем O(1) можно только специально подбирая данные.
На синтетических тестах теория подтверждается практикой — чтение из объектов размером 100 имеет такой же перфоманс как и чтение из объектов размером 10М. Гугл подкинул мне вот такую ссылку stackoverflow.com/questions/12241676/javascript-objects-as-hashes-is-the-complexity-greater-than-o1, но думаю можно и лучше поискать
Все объекты класса Кетер
Подросли на целый метр.
И какой теперь длины?
[ДАННЫЕ УДАЛЕНЫ]
Несмотря на то, что я в расте новичок, готов утверждать, что с безопасностью (а точнее со способами выстрелить себе в ногу) у раста всё существенно лучше, чем в плюсах. В safe rust получить UB/segfault/data races не проще чем в каких-нибудь Java/Python/C#. Статический анализ тут не причём, это именно проверка валидности программа с точки зрения компилятора. Для сравнения — вы получаете в Джаве ошибку, когда класс имплементит интерфейс, но не реализует его метод. Такая ситуация может быть валидна синтаксически, но интерпретатор ваш код отвергнет.
При этом в Safe Rust, наверное, можно сделать всё что угодно, кроме FFI-вызовов. А Unsafe же приходится использовать весьма редко. Например я попробовал посмотреть в https://github.com/openethereum/openethereum — и там на ~120000 строк rust-кода нашлось 22 вхождения слова unsafe (из которых некоторые даже не относятся к коду). Так что если у вас всё же что-то пойдёт не так, то есть довольно мало мест, на которые надо обратить пристальное внимание.
К сожалению (или к счастью) у меня не мак, а Dell с пластиковым корпусом, да ещё и все розетки в доме и вилка ноутбука с заземлением. В общем, без шансов повторить эксперимент.
В любом случае я отвечал вам на комментарий о принципиальной невозможности подобного, рассчитывая внести для вас немного ясности в то, как работает электричество. Потому как для меня самого это тема не самая простая, и такие вот объяснения на пальцах мне лично помогают разобраться
Если объяснять на пальцах, то как-то будет как-то так:
Вольты — это разность потенциалов. Т.е. мера двух объектов относительно друг друга, а не независимая величина. И в случае питания от сети у вас объектов три: два контакта на БП и земля. Вот между контактами на БП у вас 20 вольт. А между любым из них и землёй — 110.
Я вот новичок в расте, но немного освоившийся. На данный момент ощущения от синтаксиса у меня такие
<T>— дженерики везде одинаковы;{}— ура, скобочки (надоел Python);.— доступ к полям объекта тоже как и везде;&,*— хоть я плюсы только в учебнике видел, но операторы запомнил->— return тип в таком виде встречается;=>— ну паттерн матчинг понятие новое, но такие стрелочки в жизни я встречал в каких-то похожих контекстах;?— отличное решение проброса ошибки вместо эксепшнов;print!— сначала ощущение, что на тебя кричат, но вообще удобно отличать макрос от функции?Sized— выглядит как костыль (почему не UnSized какой-нибудь?);dyn Trait— вся концепция какая-то мутная, неизящная, ещё и постоянно юзается какBox<dyn Trait>как бы подчёркивая кривизну;@— тут явно чё-то перемудрили с выбором синтаксиса для, имхо, редкоюзаемой фичиa..=b— автоматически читается какa= a..bс фатал эррором в голове при поиске оператора..(для тех кто не знает раст — это, упрощённо, range a..b только включая b);||{}— лямбды хоть и знакомы из руби, всё равно ощущаются инородно, расту больше бы какая-то стрелочка здесь подошла (надо было у паттерн-матчинга отнять).Вовочка:'a— конечно же лайфтаймы, глаза автоматически пытаются искать закрывающую кавычку. Считаю это самым худшим решением в синтаксисе раста, учитывая что лайфтаймы не так и редко нужны и — что ещё хуже — используются подряд в большом количестве, делая максимально нечитаемыми определения функций. Лучше б уж сюда@присобачили.Я понимаю, что ещё наверное пара месяцев игр с растом, и я ко всему привыкну, но тут обсуждалось чем синтаксис может оттолкнуть новичков, так что думаю я встрял вовремя)
P.S. Насчёт ключевых слов (fn, trait, impl, struct). Считаю, что у раста с этим всё очень хорошо. С одной стороны они довольно знакомы и очевидны, с другой — дают понять, что struct это вам не class, а trait — не совсем interface.
По первой ссылке в статье написано 2900 смертей на 6.4млн больных. Это 0,045% смертность.
У короновируса сейчас 427 смертей на 20700 заболевших. Это уже 2%, что очень немало, при этом большинство все ещё больны и в какую сторону качнутся эти 2% — тот ещё вопрос.
Понятное дело, что очень ограниченно работает для компонент на разных языках программирования, но там без сериализации данных в любом случае не обойтись.
ipv6 = 2^(2^7)
7-5 = 2
Я нашёл эти два порядка.
Там ещё пара страниц доказательства, которые я пожалуй пока не осилю)
Правильная формулировка такая: чувствительность не меньше корня из deg(f) (степени функции).
А что такое степень надо говорить отдельно.
Любую булеву функцию можно представить в виде полинома. Я не уверен, что прав, но вроде бы имеется в виду Полином Жегалкина. Собственно deg(f), т.е. степень функции — это степень этого полинома, т.е. максимальная степень его слагаемых.
Вообще парень доказал штуку, которая довольно просто формулируется в терминах графов. В n-мерном кубическом графе любой подграф степени 2^(n-1)+1 (т.е. имеющий больше половины вершин исходного графа) имеет вершину степени не меньше чем sqrt(n).
Правда я понятия не имею, как из этой теоремы следует теорема чувствительности, но вроде как это известный переход, на который ссылается автор. Только разобраться надо.
В биткоине размер комиссии не зависит от суммы. Зависит от размера в байтах (фактически от количества входов/выходов) и от загруженности сети. Так что очень большая комиссия — это не по меркам фиатных денег, а по меркам крипты
Где тут подвох? Подвох в том, что хэши могут повторяться, и в бакетах может быть заметно больше одного элемента. Но даже в этом случае получить ассимптотически что-то большее чем O(1) можно только специально подбирая данные.
На синтетических тестах теория подтверждается практикой — чтение из объектов размером 100 имеет такой же перфоманс как и чтение из объектов размером 10М. Гугл подкинул мне вот такую ссылку stackoverflow.com/questions/12241676/javascript-objects-as-hashes-is-the-complexity-greater-than-o1, но думаю можно и лучше поискать