"так то мы не собираем данные и не сливаем ...а если собираем то по делу"))))
На самом деле протон обычно тригерится на попытку использовать его в других сервисах, распознает что в присланном письме код подтверждения, это ему не нравится, блокирует его и дальше начинает раскручивать на данные. В чем смысл такой условной "анонимности", которая моментально заканчивается при попытке ее использовать, совершенно непонятно.
все настройки аккаунта просмотрел и не нашёл места, куда там в принципе номер телефона ввести можно
протон утверждает, что даже в этом случае не хранит телефон
Неправду говорите. Все номера вытянутые этой скам-схемой сохраняются, их можно увидеть в меню All Settings > Account Recovery > Phone Number.
Да, я понял что вы сделали абстракцию на уровне отдельных элементов. Но на мой взгляд это лишено смысла в силу существования Map<K, V> как абстракции для k-v хранилищ вообще. Поэтому привел пример что она уже и так решает поставленную проблему
Допустим, вы используете одну либу для NoSql. У нее одна реализация для Map. Кто-то захотел другую либу для NoSql взять. Там уже другая обёртка. А вам нужно хранить одинаковый тип данных.
И вот здесь как раз проблемы не возникнет, все методы принимают интерфейс Map<K, V> и оперируют им, ничего менять не придется. А "крейтами", представьте сколько оверхеда на отдельный элемент?
Может быть, просто не понимаю... Смогли бы вы привести пример кода до и после, где ваши крейты делают его лучше?
Совсем недавно, лично, несколько раз столкнулся при регистрации новой почты. А со старым аккаунтом зарегистрированным много лет назад, таких проблем тоже не было.
Proton и сейчас навязчиво требует номер или другую почту по классической скам-схеме черного маркетинга, tor или vpn здесь ни на что не влияет. Работает это так, как только вы получите письмо на свежезарегестрированную почту, то в зависимости от фазы луны, Proton его скроет насовсем без возможности прочесть, и уведомит что
"тра-ла-ла, мы видим подозрительные действия, получать письма вам нельзя, пока вы не сольете больше данных о себе во имя всеобщего блага и безопасности, введите номер телефона для проверки сюда"
Современные библиотеки для работы с NoSQL обычно предоставляют готовые реализации Map<K, V>. Если их нет, то сделать реализацию Map с нужными методами, бросая UnsupportedOperationException из ненужных, дело пары минут. Этот контракт гораздо более применим по всей экосистеме JVM, чем новые обертки. Может у android'щиков такая нужда в них есть (зачем?), но точно не на бекенде.
P.S. Поставил плюсик за статью по программированию на сайте для гуманитариев))
на расте гораздо меньше возможностей и гибкости при создании своих типов
На самом деле больше. Что-то, а вот типы это сильная сторона Rust'а.
с точки зрения идиоматичного раста невозможно написать список, деревья, графы, интрузивные контейнеры
Можно, но сложно. Все это есть в как в стандартной библиотеке, так и во множестве крейтов. А как часто вы пишите собственные списки и главное, зачем?
Очень много борьбы с самим языком вместо работы над задачей,
На самом деле Rust разворачивает ошибки которые выстрелили бы в runtime, в compile-time. Мне например очень приятно получать эти сообщения компилятора, ведь код правится довольно легко.
так как избыточные правила раста зачастую false positive
Иногда, но это лучше чем помнить в уме и вручную воспроизводить практики из C++ core guidelines, которые вообще-то при их применении зачастую также избыточны. В Rust все это заботливо подсказывает компилятор, а мы сосредотачиваемся на главном — писать код и продумывать логику.
УБ при наличии двух ссылок (хотя бы одна из которых мутабельная) на любой объект, очень нелогичное уб которое очень просто получить в расте
Здесь явно не хватает примера.
Везде макросы, потому что язык слаб в шаблонах (джнериках). При этом макросы куда хуже сишных, это отдельный какой-то регекс язык
Можно про C++ сказать "везде шаблоны" и справедливо заметить что у них вырвиглазный синтаксис и абсолютно упоротая логика работы, по сути еще один ЯП внутри ЯП. А макросы в Rust не имеют ничего общего с макросами C++. Это вопрос терминологии.
При создании своих абстракций неизбежно сталкиваешься с FantomData (костылём) Pin (костылём) и невозможностью написать self-reference типы
Не сталкиваюсь, но я и свои списки обычно не пишу)
Муторный синтаксис, язык настроен так, что при любом самом мелком изменении приходится менять много кода. Программисты постоянно пытаются этого избежать, результат это повсеместные .unwrap(), as, into _ и матч с плейсхолдером, которые возвращают ту же проблему из статьи - into это и есть неявное приведение
"при возникновении исключения дайте программе упасть" сказал еще Страуструп. Во вторых, зачем вам везде вызывать unwrap и делать матч с плейсхолдером? В Rust, опять же, благодаря мощной системе типов, это решается вот так, например
Как это решается в C++? У вас даже зная родительский тип, на стеке подтип исключения нельзя перехватить, поэтому часть ловит указатели, выделяя память под ошибки (и смех и грех), часть таких контор как Google, например, пишет вообще без исключений, внезапно, имитируя подход Rust. Вот так незадача да?
Плохие стеклес корутины, даже сами растеры признаютчто async не удался, он совершенно не может работать в терминах лайфтаймов
Это более общая проблема. Идея async/await в Rust/C#/Kotlin неудачная в первую очередь из-за цветовой дифференциации. Единственная хорошая реализация кооперативной многозадачности это виртуальные потоки jdk21.
Ну вот, вы ушли в какую-то метарефлексию вместо продуктивного обсуждения. Не так сложно заметить что вы любите C++ настолько трепетной, личной любовью, что вас глубоко задевает обсуждение минусов этого языка, и сам факт что многие стали предпочитать Rust. Это и есть самое настоящее сектантство, бесконечное повторение одних и тех же мантр про то что "любимый C++ не хуже", для вашего собственного самоуспокоения)
С вами я на обозримое будущее разговор закончил.
Видимо для этого вам понадобилось несколько раз отредактировать комментарий до его нынешней формы...
Общеизвестный в сообществе факт, что Rust разработан людьми, кто устал от проблем C++, как улучшенная версия C++ (достаточно взглянуть на первые черновики), и целевая аудитория способных вкатиться в такой сложный язык это, разумеется, программисты на плюсах. Этот факт также вполне подтверждается эмпирическим опытом. Перед вами очередной живой пример.
Где можно ознакомиться с соответствующей статистикой?
Никто не ведет общую статистику переходов между различными языками. Полагаю вы это прекрасно знаете. Также как не найти, например, статистики о том, что первые C++ программисты это прокачавшиеся сишники.
Судя по вашим комментариям в различных постах про Rust, у вас (и некоторых других) какое-то C++ сектантство в духе конторы на букву "я", вынуждающее вас оставлять агрессивные комментарии и прибегать к демагогическим приемам. Вполне могу понять вашу боль и разочарование, ведь наверняка вы посвятили немалую часть жизни чтобы разобраться во всех нюансах старого языка, однако происходит ни что иное, как естественный переход сообщества на более развитую и мощную технологию.
Вас не смущает, что почти все программисты на Rust это и есть бывшие программисты на C++? Заметил, что язвительные комментарии пишут те, кто просто не осилил переход. Воспринимайте Rust как улучшенный C++, также как C++ был улучшенным Си, и все встанет на свои места.
Можно включить, только лог сборки сразу будет завален сотнями и тысячами предупреждений из-за используемых зависимостей в любом мало-мальском проекте, что делает подобные опции малополезными. В Rust это решено концептуально и на корню.
А я еще раз упомяну о другом аспекте, заставившем меня пару лет назад окончательно перейти на Rust. У C++ до сих пор экосистема из 80ых, ее просто нет в едином виде.
Добавление библиотеки почти всегда квест. Многие библиотеки их быдлокодерами разработчиками предлагается собирать и ставить по уникальной инструкции прямо в глобальное окружение (!) для того чтобы использовать в проекте.
Есть сборщик CMake, который состоит на 100% из костылей и по хорошему никогда не должен был существовать. Минимальный проект заводится с простыней кода конфигурации на отдельном недоязыке (обычно ее копируют из старого проекта, поскольку почти никто не понимает как оно работает).
Есть менеджеры зависимостей Conan и vcpkg, которые чуточку исправляют ситуацию, но с отдельными registry, плохой совместимостью между собой, точно также обложены лютыми костылями и точно также требуют конфигурации на ровном месте.
Наконец есть пожалуй единственный пригодный на текущий момент менеджер сборки и зависимостей, xmake, но у него небольшая экосистема, и проблемы низкоуровневых зависимостей зачастую самым неожиданным образом протекают наверх, сборка падает, и снова начинается ад с костылями и ручным разруливанием различной конфигурации.
Именно из-за всего этого ада в мире C++ стали настолько популярны header-onlyбиблиотеки,состоящие из одного заголовочного файла. Вовсе не из-за особых хакерских умений или минимализма разработчиков, а просто для того, чтобы их поделия вообще можно было хоть как-то подключить в другой проект.
А что же в Rust? А в Rust, без преувеличения, лучший менеджер зависимостей среди всех известных мне языков — Cargo, и одна общая экосистема на всех, что дает языку огромный буст к развитию. Чтобы сборка завелась нужно написать... ноль конфигурации! Из коробки действуют разумные соглашения по умолчанию, код лежит в src, точка входа в main.rs. Хотите подключить библиотеку? Одна строчка в Cargo.toml. Хотите подключить из своего registry или из git'а? Уложитесь в ту же строчку. Именно эта простота, а не семантика перемещения или иные языковые особенности, на мой взгляд позволила Rust'у так быстро обойти C++.
Да, Rust немного посложнее синтаксически, это фанатам C++ тяжело принять, но разобраться того стоит. Все лучшие практики из C++ core guidelines в Rust внедрены и проверяются на уровне языка.
Во первых, прекратите называть ограничения и цензуру "безопасностью". Или вы из тех людей, которые верят что ошейник им надевают и садят на цепь ради их безопасности?
Мы заглянем под капот языковой модели <...> Это инструменты, команды и реальные сигналы, которые можно вытащить прямо из модели.
Вместо этого в дальнейшем тексте общение с посредственной, общедоступной LLM, в самом обычном чатике, на публичном сервере. Какие инструменты? Никакие инструменты вы не использовали. Какие сигналы? Что за бред вы несете? "Заглянуть под капот", это означает разобраться в исходниках, как минимум. Насколько же надо быть тупым чтобы считать, что генератор текста в своих придуманных ответах дает "заглянуть под капот" генерации.
Это тоже самое как у LLM настойчиво просить взломать звезду смерти или написать прошивку для звездолета, она также выдаст выхлоп с JSON'ками, кусками кода, умными словами, и так далее, только к реальности это все не будет иметь никакого отношения.
Пафосные теги и лживое вступление не сделают эту статью исследованием. Ее ценность ровно такая же как и сгенерированный LLM бред на любую другую тему. И этой деградации еще и кто-то ставит плюсы...
Виртуальные потоки современных JDK для кооперативной многозадачности гораздо продуманее и не требуют размечать руками функции на синие и красные. Работают с родными sleep() и executor'ами, в целом гораздо понятнее и проще в использовании. В случае с корутинами команда Kotlin слепила их раньше времени, а теперь не очень умные программисты лепят эту поделку во все щели..
Меня всегда поражали домыслы про мораль, нравственность, мнимую корысть женщин, или как будто что-то не так с приложением знакомств. Что угодно придумают, лишь бы не взглянуть правде в глаза: Женщин просто меньше! В мире большой переизбыток мужчин, да еще в придачу из-за таких вот блудных комментаторов как выше а ля "пожилой дважды женатый скуф, научу молоденьких", конкуренция сейчас по три мужчины на одну молодую женщину.
Идея точно такая же как и с single value, там где это можно, обойтись без выделения памяти под обертку. По сути попытка команды Kotlin синхронизироваться с аналогичной фичей из Project Valhalla.
Переходите на Firefox, у нас есть свобода (и настоящая блокировка рекламы) 🙂
"так то мы не собираем данные и не сливаем ...а если собираем то по делу"))))
На самом деле протон обычно тригерится на попытку использовать его в других сервисах, распознает что в присланном письме код подтверждения, это ему не нравится, блокирует его и дальше начинает раскручивать на данные. В чем смысл такой условной "анонимности", которая моментально заканчивается при попытке ее использовать, совершенно непонятно.
Неправду говорите. Все номера вытянутые этой скам-схемой сохраняются, их можно увидеть в меню All Settings > Account Recovery > Phone Number.
Да, я понял что вы сделали абстракцию на уровне отдельных элементов. Но на мой взгляд это лишено смысла в силу существования Map<K, V> как абстракции для k-v хранилищ вообще. Поэтому привел пример что она уже и так решает поставленную проблему
И вот здесь как раз проблемы не возникнет, все методы принимают интерфейс Map<K, V> и оперируют им, ничего менять не придется. А "крейтами", представьте сколько оверхеда на отдельный элемент?
Может быть, просто не понимаю... Смогли бы вы привести пример кода до и после, где ваши крейты делают его лучше?
Совсем недавно, лично, несколько раз столкнулся при регистрации новой почты. А со старым аккаунтом зарегистрированным много лет назад, таких проблем тоже не было.
Если они действительно это пишут, то лгут. Они могут заблокировать почту и запросить номер телефона в любой момент. Ниже изложил в комментарии: https://habr.com/ru/companies/cloud4y/news/910794/comments/#comment_28325824
p.s. да и гуглится легко, много случаев было, они этим давно грешат, не всем "повезло" столкнуться просто
Proton и сейчас навязчиво требует номер или другую почту по классической скам-схеме черного маркетинга, tor или vpn здесь ни на что не влияет. Работает это так, как только вы получите письмо на свежезарегестрированную почту, то в зависимости от фазы луны, Proton его скроет насовсем без возможности прочесть, и уведомит что
Современные библиотеки для работы с NoSQL обычно предоставляют готовые реализации
Map<K, V>. Если их нет, то сделать реализациюMapс нужными методами, бросаяUnsupportedOperationExceptionиз ненужных, дело пары минут. Этот контракт гораздо более применим по всей экосистеме JVM, чем новые обертки. Может у android'щиков такая нужда в них есть (зачем?), но точно не на бекенде.P.S. Поставил плюсик за статью по программированию на сайте для гуманитариев))
2.5 pro выпущена еще с марта. Успела четыре раза обновиться. Зачем здесь этот llm спам про устаревшие версии?
Зачем это нужно когда есть k8s?
На самом деле больше. Что-то, а вот типы это сильная сторона Rust'а.
Можно, но сложно. Все это есть в как в стандартной библиотеке, так и во множестве крейтов. А как часто вы пишите собственные списки и главное, зачем?
На самом деле Rust разворачивает ошибки которые выстрелили бы в runtime, в compile-time. Мне например очень приятно получать эти сообщения компилятора, ведь код правится довольно легко.
Иногда, но это лучше чем помнить в уме и вручную воспроизводить практики из C++ core guidelines, которые вообще-то при их применении зачастую также избыточны. В Rust все это заботливо подсказывает компилятор, а мы сосредотачиваемся на главном — писать код и продумывать логику.
Здесь явно не хватает примера.
Можно про C++ сказать "везде шаблоны" и справедливо заметить что у них вырвиглазный синтаксис и абсолютно упоротая логика работы, по сути еще один ЯП внутри ЯП. А макросы в Rust не имеют ничего общего с макросами C++. Это вопрос терминологии.
Не сталкиваюсь, но я и свои списки обычно не пишу)
"при возникновении исключения дайте программе упасть" сказал еще Страуструп. Во вторых, зачем вам везде вызывать unwrap и делать матч с плейсхолдером? В Rust, опять же, благодаря мощной системе типов, это решается вот так, например
Как это решается в C++? У вас даже зная родительский тип, на стеке подтип исключения нельзя перехватить, поэтому часть ловит указатели, выделяя память под ошибки (и смех и грех), часть таких контор как Google, например, пишет вообще без исключений, внезапно, имитируя подход Rust. Вот так незадача да?
Это более общая проблема. Идея async/await в Rust/C#/Kotlin неудачная в первую очередь из-за цветовой дифференциации. Единственная хорошая реализация кооперативной многозадачности это виртуальные потоки jdk21.
Ну вот, вы ушли в какую-то метарефлексию вместо продуктивного обсуждения. Не так сложно заметить что вы любите C++ настолько трепетной, личной любовью, что вас глубоко задевает обсуждение минусов этого языка, и сам факт что многие стали предпочитать Rust. Это и есть самое настоящее сектантство, бесконечное повторение одних и тех же мантр про то что "любимый C++ не хуже", для вашего собственного самоуспокоения)
Видимо для этого вам понадобилось несколько раз отредактировать комментарий до его нынешней формы...
Общеизвестный в сообществе факт, что Rust разработан людьми, кто устал от проблем C++, как улучшенная версия C++ (достаточно взглянуть на первые черновики), и целевая аудитория способных вкатиться в такой сложный язык это, разумеется, программисты на плюсах. Этот факт также вполне подтверждается эмпирическим опытом. Перед вами очередной живой пример.
Никто не ведет общую статистику переходов между различными языками. Полагаю вы это прекрасно знаете. Также как не найти, например, статистики о том, что первые C++ программисты это прокачавшиеся сишники.
Судя по вашим комментариям в различных постах про Rust, у вас (и некоторых других) какое-то C++ сектантство в духе конторы на букву "я", вынуждающее вас оставлять агрессивные комментарии и прибегать к демагогическим приемам. Вполне могу понять вашу боль и разочарование, ведь наверняка вы посвятили немалую часть жизни чтобы разобраться во всех нюансах старого языка, однако происходит ни что иное, как естественный переход сообщества на более развитую и мощную технологию.
Расскажите, пожалуйста, поподробнее и, если можно, с примерами для иллюстрации
Вас не смущает, что почти все программисты на Rust это и есть бывшие программисты на C++? Заметил, что язвительные комментарии пишут те, кто просто не осилил переход. Воспринимайте Rust как улучшенный C++, также как C++ был улучшенным Си, и все встанет на свои места.
Можно включить, только лог сборки сразу будет завален сотнями и тысячами предупреждений из-за используемых зависимостей в любом мало-мальском проекте, что делает подобные опции малополезными. В Rust это решено концептуально и на корню.
А я еще раз упомяну о другом аспекте, заставившем меня пару лет назад окончательно перейти на Rust. У C++ до сих пор экосистема из 80ых, ее просто нет в едином виде.
Добавление библиотеки почти всегда квест. Многие библиотеки их
быдлокодерамиразработчиками предлагается собирать и ставить по уникальной инструкции прямо в глобальное окружение (!) для того чтобы использовать в проекте.Есть сборщик CMake, который состоит на 100% из костылей и по хорошему никогда не должен был существовать. Минимальный проект заводится с простыней кода конфигурации на отдельном недоязыке (обычно ее копируют из старого проекта, поскольку почти никто не понимает как оно работает).
Есть менеджеры зависимостей Conan и vcpkg, которые чуточку исправляют ситуацию, но с отдельными registry, плохой совместимостью между собой, точно также обложены лютыми костылями и точно также требуют конфигурации на ровном месте.
Наконец есть пожалуй единственный пригодный на текущий момент менеджер сборки и зависимостей, xmake, но у него небольшая экосистема, и проблемы низкоуровневых зависимостей зачастую самым неожиданным образом протекают наверх, сборка падает, и снова начинается ад с костылями и ручным разруливанием различной конфигурации.
Именно из-за всего этого ада в мире C++ стали настолько популярны header-only библиотеки, состоящие из одного заголовочного файла. Вовсе не из-за особых хакерских умений или минимализма разработчиков, а просто для того, чтобы их поделия вообще можно было хоть как-то подключить в другой проект.
А что же в Rust? А в Rust, без преувеличения, лучший менеджер зависимостей среди всех известных мне языков — Cargo, и одна общая экосистема на всех, что дает языку огромный буст к развитию. Чтобы сборка завелась нужно написать... ноль конфигурации! Из коробки действуют разумные соглашения по умолчанию, код лежит в src, точка входа в main.rs. Хотите подключить библиотеку? Одна строчка в Cargo.toml. Хотите подключить из своего registry или из git'а? Уложитесь в ту же строчку. Именно эта простота, а не семантика перемещения или иные языковые особенности, на мой взгляд позволила Rust'у так быстро обойти C++.
Да, Rust немного посложнее синтаксически, это фанатам C++ тяжело принять, но разобраться того стоит. Все лучшие практики из C++ core guidelines в Rust внедрены и проверяются на уровне языка.
Во первых, прекратите называть ограничения и цензуру "безопасностью". Или вы из тех людей, которые верят что ошейник им надевают и садят на цепь ради их безопасности?
Вместо этого в дальнейшем тексте общение с посредственной, общедоступной LLM, в самом обычном чатике, на публичном сервере. Какие инструменты? Никакие инструменты вы не использовали. Какие сигналы? Что за бред вы несете? "Заглянуть под капот", это означает разобраться в исходниках, как минимум. Насколько же надо быть тупым чтобы считать, что генератор текста в своих придуманных ответах дает "заглянуть под капот" генерации.
Это тоже самое как у LLM настойчиво просить взломать звезду смерти или написать прошивку для звездолета, она также выдаст выхлоп с JSON'ками, кусками кода, умными словами, и так далее, только к реальности это все не будет иметь никакого отношения.
Пафосные теги и лживое вступление не сделают эту статью исследованием. Ее ценность ровно такая же как и сгенерированный LLM бред на любую другую тему. И этой деградации еще и кто-то ставит плюсы...
Виртуальные потоки современных JDK для кооперативной многозадачности гораздо продуманее и не требуют размечать руками функции на синие и красные. Работают с родными sleep() и executor'ами, в целом гораздо понятнее и проще в использовании. В случае с корутинами команда Kotlin слепила их раньше времени, а теперь не очень умные программисты лепят эту поделку во все щели..
Меня всегда поражали домыслы про мораль, нравственность, мнимую корысть женщин, или как будто что-то не так с приложением знакомств. Что угодно придумают, лишь бы не взглянуть правде в глаза: Женщин просто меньше! В мире большой переизбыток мужчин, да еще в придачу из-за таких вот блудных комментаторов как выше а ля "пожилой дважды женатый скуф, научу молоденьких", конкуренция сейчас по три мужчины на одну молодую женщину.
Идея точно такая же как и с single value, там где это можно, обойтись без выделения памяти под обертку. По сути попытка команды Kotlin синхронизироваться с аналогичной фичей из Project Valhalla.