Если бы все задачи были такими простыми как в этимх выражениях. Представьте, что одна из функций прочитала базу и вернула "1" вместо 1, а другая взяла 1 из другого места и сложила с результатом первой функции. Вы в коде нигде 1 + "1" не увидите и за руку не поймате. А действие выполняется и на выходе "11". Это всё можно объяснить студенту, но это займет время, а значит снизит эффективность. Я бы, была б моя воля, запретил к прямому использованию js (сарказм). Вот есть ts - кстати, того же автора, что и Delphi, вот им и пользуйтесь и студентов можно обучать вполне.
Кстати, ChatGPT довольно верно сказал что нужно при соискании позиции SDE в AWS, но это относится ко второй части, а первая - technical assesment - там только умение решать задачи, как правило несложные, если имеются познания в DP.
Китайские резисторы. Что могло пойти не так? Да, всё что могло, то и пошло. Перегрузка - да, температурные перепады - тоже, но, скорее всего просто технологический процесс - делают в подвале вне нормальных условий производства.
Что касается нагрузочного тестирования, то формально, с соблюдением процесса, мы его не проводили.
Печально. Но тогда выши утверждения про предсказуемую память - не основаны ни на чем. Проведите и посмотрите.
Если что, под "предсказуемой памятью" я подразумевал следующее: нам нужно в памяти иметь дерево на, скажем, 100 миллионов узлов. Тогда мы точно знаем, сколько оно займет памяти,
Позвольте, но реализация алгоритма на любом языке загрузит фиксированное дерево потратив один и тот же объем памяти. Разница может начаться в зависимости от того как осуществляется освобождение и сколько параллельных запросов вы можете себе позволить на одной ноде. Вы запустите 5 конкурентных запросов и у вас потребность в памяти возратет в 5 раз. Это предсказуемо, но объем никак не фиксированный.
Что сначала нужно найти бизнес-модель, а потом - масштабироваться
Бизнес модель и дизайн системы идут в начале, и дизайн отвечает требованиям бизнес модели и диктует как должно быть построено приложение. Если у вас 1 пользователь и нет и никогда не прдевидится 1000 или больше, то наверное монолитное решение ок. Но если и вдруг масштабирование предвидится в какой-то пусть и отдаленной перспективе, то монолитное решение не годится и нужно заново делать дизайн и заново переписывать почти всё. Поэтому "а потом масштабироваваться" - это ошибка. Дизайн закладывает как вы будете масштабироваться.
И что с поиском бизнес-модели и места на рынке микросервисы никак не помогают, а сложность вносят
Я не настаиваю на микросервисах. Мискросервисы не единственное горизонтально масштабируемое решение. Даже если у вас монолит, но построен по MCV принципам, обычно проблемы с запуском параллельных инстансов (нод) не возникает. Вопрос обычно - как вы распараллеливаете разработку межджу членами команжы. Толкаться локтями в одном монолите обычно сложнее, чем писать разные микросервисы. Т.е. это вопрос масштабирования разработки тоже. Второе - если вы имеете часть системы, которая довольно простая и отвечает за какой-то функционально законченный блок, ее легче оттестировать, легче обслуживать, находить сбой, и легче рефакторить. Т.о. это не усложние, а упрощение.
и ресурсы тратят.
Всё тратит ресурсы. И монолит тоже. Если нагрузки нет, то монолит может дать преимущество. Если есть, то это большой вопрос. С микросервисами вы имеете возможность масштабировать нагруденные участки (сервивисы) и остальное не масштабировать, а с монолитом вы вынуждены масштабировать весь монолит, запуская его целиком на всех нодах, даже если узкое место в какой-то его конкретной части. Пример на пальцах - допустим у вас 1 узкое место. Чтобы работало под нагрузкой вам нужно иметь 10 запушенных экземпляров . 10 запущенных монолиров потребуют больше ресурсов, чем если вы разрежете монолит на, допустим 5 микросервисов, так что то узкое место будет лишь в одном из них и отмастштабируете это 1 место в 10 раз.
Я реально много времени провел в DotTrace, и, боюсь, что в случае с пайтоном и тайпскриптом приемлемой скорости я бы не добился
Возможно. Возражений против С# у меня нет и не было. Были лишь высказаны опасения про платформу .NET, если вы на ней, а не на Mono или какой-то другой альтернативе, которая в меньшей степени привязана к бизнеспрактикам коммерческих компаний.
Скорость системы зависит от многих факторов - не только от языка. Язык важен лишь если у вас CPU-bound или Memory-bound задача. Если у вас именно такой случай, то да, не спорю, С# может быть хорошим выбором. И да, если вы не хотите тратить время на изучение других языков, то и единственным. А я бы посмотрел в сторону GoLang и Rust в таком случае, оставив пайтон или тайпскрипт для задач по data-moving с минимальными трансформациамяи.
Ну нашли к чему докопаться.Т.е. вы согласны с остальным и не возражаете - а там намного больее важные ссоображения чем кроссплатформенность.
По поводу платформ - хорошо, я объясню. Для вас вся кроссплатформенность сводится к 2м плафтормам - Windows и Linux? А не деле существует масса других платформ, например FreeBSD. Вы собирали .NET под FreeBSD? Наверное нет, потому что совместимые бинарники можно получить только в линукс-эмуляторе. Никаких других способов пока нет / мне не известны / не найдено. Нет способов получить под RT операционными системами, нет для NetBSD, OpenBSD, нет для Solaris и т.п.
Риск в том, что Микрософт - это коммерческая компания, движимая коммерческими интересами и в любой момент может пересмотреть свое отношение к своим продуктам. Это происходило уже не раз - продукты выпускались и прекращались. Кроме того, иногда коммерческие компании идут в суд и отстаивают свои лицензии, как например Oracle идет в суд против Google/android в отношении Java. Это добавляет риск, а не снижает его.
Mono в этом смысле выглядит более практичным выбором, но для ее развития нужен консорциум. Это бы придало большую стабильность продукту и позволило бы планировать в терминах LTS и кроссплатформенность в этом случае совершенно натуральная, как мы наблюдаем в случае open jdk.
Но это всё просто ничто по сравнению с выбором способа масштабирования (вертикального вместо горизонтального), заблуждений по поводу предсказуемости памяти в случае .NET, забдуждений по поводу удобства отладки и т.п.
Обычно это заблуждение про "предсказуемую память" довольно быстро развеивается как только вы начинаете прогонять нагрузочные и пен тесты. Надеюсь вы их провели и убедились что всё в порядке прежде чем делать такие заявления.
.NET не плохой выбор, но я не вполне понимаю чем конкретно тот же пайтон или тайпскрип или джава были бы хуже. Да, прожорливавее, возможно, на пару мегабайт. Да, чуть тормознее, на пару миллисекунд. Но на разработку вы потратили бы в несколько раз меньше времени, не были бы привязаны к платформе, а сэкономленное время могли бы потратить на развитие и масштабируемость системы. (извините, если прозвучало как ворчание старого деда)
Поэтому мы не используем микросервисы, брокеры сообщений, шины данных и прочие инфраструктурные зависимости: они мешают отладке, они выбивают из потока, всем нужно держать в голове известные особенности их работы, и разбираться, столкнувшись с неизвестными.
Добро пожаловать в мир WorldWide или корпоративных проектов, где 1000 одновременно работающих клиентов - просто ничто. Нет, не спорю, можно вертикально масштабировать систему и покупать всё более дорогое железо, чтобы поддерживать растущую нагрузку. А когда вы упретесь в пределы возможностей монолитных решений, то, надеюсь сообразите, что все эти брокеры сообщений и микросервисы придуманы вовсе не для того чтобы затруднить вам отладку. Скорее наоборот - вы можете приписать каждому микросервису контракт и протестировать его на соответствие контракту. Чем хороши микросервисы - вы их можете запустить в любом количестве экземляров - для горизонтального масштабирования. И, кроме того, вы можете работать в команде, где у каждого есть своя доля работы и никто никого локтями не толкает, работая над одним клубком.
Там контекст - это в компании, которая не яндекс от слова совсем. В маленьких компаниях, если они интересные, обычно народ надо разгонять, чтобы они уходили с работы, а не сидели до поздна. Но isadora-6th прав, возможность работать на удаленке - это скорее конкрурентное преимущество. Если встает вопрос контроля - это уже скорее надо к паталогоанатому - бизнес скорее мертв. Неужели сложно устроить стендапы по утрам? Мелкие, согласно скраму, на 15-20 минут. Всё давно уже придумано. Если чел должен что-то сказать про то что он делал - это заставляет задуматься что же он делал. Это уже само по себе работает как самоконтроль.
Еесть компании, где работают сотрудники, плохо умеющие привлекать новых сотрудников интересными вызовами, а тех, которых смогли нанять не умеют увлечь. А потом берут, лежащее на поверхности - "это такие сотрудники нам достались, со своими неправильными целями, потому что всех хороших забрал большой конкурент", и начинают верить в это. Из моей практики - увлекает вызов - сотрудник решаете такую проблему, что никто кроме него не решал на этом месте. Где-то там, наверняка, решали другие, но тут и конкретно эта проблема - никто. А если то же самое преподнести как рутину и долбасить каждый день вопросами "ну когда ты ее решишь?", то да, быстро надоедает и интереса нет.
Если сотрудники увлеклись своими делами - это значит, что работодатель не смог увлечь своими, нужными для дел компании. Плохая организация - обычно это признак или отсутствия опыта или наличие плохого опыта руководства. А компания так и останется маленькой, потому что большой ее делают сотрудники, не руководство. Руководство лишь выбирает куда, а тягловая сила - это сотрудники. Еще одно заблуждение - что конкуренция вредит. Конкуренция создает рынок и придает динамизм продуктам. Решение проблемы - образование. Никогда не поздно поучить матчасть - как организовать рабкрин хороший процесс.
Целевая аудитория не та, и реакция была бы совсем не та, на которую вы говорите запад хотел бы рассчитывать, если бы они начал резать доступ физикам. Думаю, выборы тут не при чем. А вот то что у СофтЛайна дела идут не очень - догадка напрашивается. Однако, даже если это всё так, это не исключает, что реально ограничат.
Меня терзают смутные сомнения -- а был ли мальчик? В изначальной новости, которая ссылалась на Softline, речь шла и про AWS и про Гугл и про Микрософт и про облачные продукты и про сами облачные сервисы. Сейчас всё редуцировалось до Микрософта и списка из десятка продуктов, только для предприятий и дата тоже поплыла. В подтверждение правдивости приводилось письмо, якобы из Микрософта, но без загловков - без подписи, без сервера и даты когда и кем было отправлено. Учитывая, что Микрософт - американская компания, а санкции, на которые ссылаются - европейские, скорее всего речь может идти об обслуживании клиентов европейским офисом Микрософта.
В планах -- некоторых корпов от некоторых программ везде, в т.ч. в облаках. Доступ к облакам, скорее всего, им оставят. Про физиков речи не шло изначально.
Доклад вообще-то представил офис директора по национальной кибербезопасности https://www.whitehouse.gov/oncd/ Это просто подразделение Белого Дома, считайте как один из комитетов исполнительной власти. Вам стоит почитать детали если хотите покритиковать https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf И нет, они не указывают как людям программировать. Но на основании доклада, думаю будут выпушены регуляции и в федеральных институтах перестанут начинать новые проекты на небезопасных языках и будут работать над заменой в ранее начатых. В коммерческом секторе, в облаках, уже давно С++ не в фаворе, но С еще практикуют. Посмотрим что получится в итоге.
в сущности emplace - это костыль для insert, который не способен создать на месте. Ему надо создать, переместить, убить. Вот чтобы исключить создать-убить - и сделан emplace(). Кроме обрамляющего создать-убить у insert, у них больше нет никакой разницы, они оба используют один и тот же метод в векторе _M_realloc_insert() - считайте "private emplace()"
Например этим создать-убить плох vector<string> v; v.insert(v.cbegin(), move(string(5, '-'))) и этого создать-убить нет в vector<string> v; v.emplace(v.cbegin(), 5, '-'). Я могу углубиться в детали с использованием g++, с оптимизацией и разбором ассемблера что из этого получилось и почему. Т.е. это я пока в поддержку вашей правильной идеи о хорошести emplace().
Теперь о Rust. В Rust изначально нет этого косяка, там нет такой семантики такого копирования, поэтому нет и фикса с семантикой move. Там move изначально. Может, просто не стоит пытаться пофиксить то, что не нуждается в фиксе? ;)
Да, возможность создания объекта сразу в нужном месте, без лишних копирований - это технологическое преимущество.
Согласен. Это хорошее дело, но его как раз не было в С++ с самого начала. Всю дорогу были копирования - вы добавляете (push) объект в контейнер и он делает для вас копию. Вы делаете resize вектора и он начинает делать то же самое для всех объектов. И лишь через 13 лет появляется move сематника, при которой копируют сырые данные объекта на новое место и обнуляют их в источнике. Оптимизатор может позволить и это убрать, чтобы сразу создавалось где надо. Но язык, еще раз, изначально этог не делал и для backward compatibility поддерживается весь зоопарк - что было до, и что стало после С++11. Вы видимо не застали те счастливые годы, когда не было = delete и приходилось объявлять private оператор присваривания и конструктор копирования в больших объектах, чтобы копилятор явно ругался там, где подразумевается неявное компирование. Это С++.
В Rust есть явная передача владением. Эта концепция похожа на move.
Пишут на нем и firmware, и драйвера. Если вы об этом не знаете, то это не значит, что этого нет.
Сколько драйверов Linux или *BSD написано на С++? Сколько boot firmware в материнских платах написано на C++? Да, есть исключения. Вы отрубаете exceptions в опциях компилятора, врубаете статическую линковку и делаете прочие приседания типа оборачивания всего внешнего в extern "C", скрываете все символы по-умолчания, чтобы С++ стал максимально подобен С и по поведению и по API и тогда можно писать firmware и драйвера. Но это надругательство над средой с большим overhead. Поэтому это не стало mainstream. Люди просто используют C в таких случаях.
Ну так пусть развивается уже, а то функционал, который в плюсах уже был ещё в лохматые года, до сих пор отсутствует
У нас с вами разные лохматые года. У меня - это конец 80х, когда я начинал кодировать и никакого С++ в помине не было. А 2011й год с C++11 это было буквально вчера. К тому же он вошел в обиход и стал стабильным примерно в 2013м. И с 1998-99 по 2013 приходилось лавировать в С++ чтобы избежать копирования или чтобы оптимизировать цепочки вызовов. При том ведь не было даже unique_ptr или shared_ptr, никаких стандартных потоков или объектов синхронизации. Все тащилось через библиотеки из ОС. А Бьёрн утерждал с пеной у рта что так и должно быть. Что язык должен быть чист от таких особенностей некоторых (всех) ОС. Язык сделал огромный рывок в 2011 создав комитет, который принял все эти инновации. Всё идет значительно лучше с тех пор. Но право речь не об этом, а о том, что всё старое осталось и любой залетевший дятел может всё порушить. Вы работаете в коллективе из 8+ человек, где есть и синьоры и джуниоры. Не приходилось разбирать последствия "инноваций" новичков? Ведь так легко и незателиво рушиться не должно. Правильное дело когда синтаксис построен так, что компилятор имеет возможность обнаруживать косяки во время компиляции, задолго до рантайма. Это же клево! Чем больше таких языков, тем лучше. Может сделают подобное Rust, но проще типа GoLang - буду только рад. Что касается Rust - я не вполне понимаю что у вас не получилось в нем?
Конструирование объектов в контейнере, если я правильно понимаю о чем вы - это было всегда, с С98 -- определяете вектор, например строк, и говорите что нужно иметь длину 50, например, элементов и resize() сам создаст все строки дефолтовым конструктором вызывая T::T(). Делов то. Это прям магия, большое технологическое преимнущество дедушки С++? Или речь об inplace new операторах? C++ не зашел в ядра операционок. На нем не строят API ни к чему кроме С++, строят на С. С++ не используется в firmware, на нем не пишут драйвера, на нем не пишут обработчки пакетов (DPDK). А на Rust всё это уже пишут. Ну как бы там ни было, речь не идет о том, чтобы все стройными рядами шли в сторону Rust. Я упомянул лишь для сравнения и причина понятна - в Rust гораздо меньше багажа, низкая база и отсюда большая скорость развития. Но я отнюдь и я не апологет парадигмы one-fits-all. Есть и другие языки, безопасные при работе с памятью. Это всё и нужно развивать.
Страуструп, конечно, молодец, и цели хорошие ставил. Он ведь не отказывается, что ставил их? Он просто не упоминает, что цели не достигнуты.
То что С++ -- не С это он пусть зеркалу объясняет. Берем любую С программу, компилируем С++ компилятором и оно работает в 99% случаев. В 1% не соберется из-за необноходимости переименовать зарезервированные слова, которых в С++ побольше, чем С.
Бьярн прав, конечно, что безопастность работы с памятью - это не единственная проблема языка, но не прав, пытаясь увести в сторону, потому что это самая зияющая проблема языка Да, С++ предоставляет механизмы, всё ок с ними (кроме сложности). Но механизмы работают только если и когда ими пользуются и пользуются правильно. А раз старые С-шные конструкции работают и механизмы не совсем законченные, то любой случайно залетевший дятел рушит цивилизацию. Мы эту шутку все знаем. И указатели там живут, и ссылки могут ссылаться на несуществующие объекты и смарт укзаатели пришлось переписывать, чтобы со второго подхода они стали чуть умнее, и контейнеры, которые за 13 лет научислись перемещать объекты и поддержка файловой системы через 19 лет и корутины через 22. Темпы развития поражают воображение. Так через 50 лет можно ожидать unsafe блоки, как в Rust были добавлены лет 9 назад. С++ надо объявить трупом и перестать улучшать труп. Дедушка С++ был хорошим, мы все будем поминать его добрым словом.
Первый вариант - не работает на практике. Как только этот IP кто-то опубличит и им начнут пользоваться существенное количество пользователей, его заблокируют.
CDN - да примерно так и должно быть. Паша Дуров довольно долго бегал через CloudFront - суть тот же CDN (хотя и не только) и попробуй его заблокировать, а имена хостов в нем - дело сугобо личное и TLS-защищенное. Но сам CDN - если приложение его находит по именам, то нужен DNS, а его нет. В общем замкнутый круг курица-яйцо. Схема, разрывающая этот порочный круг может выглядеть так -- актуальные адреса в большом количестве вшиваются в текущую версию дистрибутива и сидят в нем в зашифрованном виде. Приложение открывает первый блок используя встроенный ключ и начинает работать с адресами из него. Если получается, то оно получает ключ для расшифровки второго блока и этот ключ приходит из этих сервисов первого блока. Суть этих сервисов лишь проверить аутентичность приложения и выдать ключ для второго блока. А дальше второй блок - это уже endpoints сервисов выдачи актуальной новой версии приложения, где могут быть обновленные адреса, -- ее надо скачать и поставить если сейчас работает устаревшая версия. Дальше следующий ключ и следующий блок дает доступ к доменным именам, по которым находятся текущие endpoints VPN сервисов. Чем гибче схема, тем дольше ее разматывать и блокировать. Но я не видел где, кроме телеги, подобное реализовано. Впрочем, может быть Паша сподобится добавить и VPN в телегу.
речь про компании. Персональые лиценции не попадают под ограничения, но в самих продуктах может ограничиваться объем данных и доступные фукнции по сравнению с enterprise лиенциями
Может хватит уже повторять ерунду? Никакие сервсы пока не блокируются. Блокируют доступ к некоторым приложениям. Вы разницу понимаете между поездом и пассажиром поезда? Или между страной и гражданином? Вот такая же разница между облачным сервисом и одним из приложений, к которым доступ предоставляется через облачный сервис. Сервис предоставляет доступ к практически любым приложениям и к много каким функциям, которые не совсем приложения или совсем не приложения. Вот в этом посте https://habr.com/ru/news/800639/ - вы правильно назвали это приложениями. А тут что помешало?
Если бы все задачи были такими простыми как в этимх выражениях. Представьте, что одна из функций прочитала базу и вернула "1" вместо 1, а другая взяла 1 из другого места и сложила с результатом первой функции. Вы в коде нигде 1 + "1" не увидите и за руку не поймате. А действие выполняется и на выходе "11".
Это всё можно объяснить студенту, но это займет время, а значит снизит эффективность. Я бы, была б моя воля, запретил к прямому использованию js (сарказм). Вот есть ts - кстати, того же автора, что и Delphi, вот им и пользуйтесь и студентов можно обучать вполне.
Кстати, ChatGPT довольно верно сказал что нужно при соискании позиции SDE в AWS, но это относится ко второй части, а первая - technical assesment - там только умение решать задачи, как правило несложные, если имеются познания в DP.
Китайские резисторы. Что могло пойти не так?
Да, всё что могло, то и пошло. Перегрузка - да, температурные перепады - тоже, но, скорее всего просто технологический процесс - делают в подвале вне нормальных условий производства.
Печально. Но тогда выши утверждения про предсказуемую память - не основаны ни на чем. Проведите и посмотрите.
Позвольте, но реализация алгоритма на любом языке загрузит фиксированное дерево потратив один и тот же объем памяти. Разница может начаться в зависимости от того как осуществляется освобождение и сколько параллельных запросов вы можете себе позволить на одной ноде. Вы запустите 5 конкурентных запросов и у вас потребность в памяти возратет в 5 раз. Это предсказуемо, но объем никак не фиксированный.
Ничего страшного. Не все знают всё. Но почитайте на всякий случай как проводят тестирование https://en.wikipedia.org/wiki/Penetration_test
Ох. Почитайте сколько CVE с RCE в .NET приложениях было открыто. Вот вам просто один пример https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36788 Не делаейте таких bold утверждений.
Бизнес модель и дизайн системы идут в начале, и дизайн отвечает требованиям бизнес модели и диктует как должно быть построено приложение. Если у вас 1 пользователь и нет и никогда не прдевидится 1000 или больше, то наверное монолитное решение ок. Но если и вдруг масштабирование предвидится в какой-то пусть и отдаленной перспективе, то монолитное решение не годится и нужно заново делать дизайн и заново переписывать почти всё. Поэтому "а потом масштабироваваться" - это ошибка. Дизайн закладывает как вы будете масштабироваться.
Я не настаиваю на микросервисах. Мискросервисы не единственное горизонтально масштабируемое решение. Даже если у вас монолит, но построен по MCV принципам, обычно проблемы с запуском параллельных инстансов (нод) не возникает. Вопрос обычно - как вы распараллеливаете разработку межджу членами команжы. Толкаться локтями в одном монолите обычно сложнее, чем писать разные микросервисы. Т.е. это вопрос масштабирования разработки тоже. Второе - если вы имеете часть системы, которая довольно простая и отвечает за какой-то функционально законченный блок, ее легче оттестировать, легче обслуживать, находить сбой, и легче рефакторить. Т.о. это не усложние, а упрощение.
Всё тратит ресурсы. И монолит тоже. Если нагрузки нет, то монолит может дать преимущество. Если есть, то это большой вопрос. С микросервисами вы имеете возможность масштабировать нагруденные участки (сервивисы) и остальное не масштабировать, а с монолитом вы вынуждены масштабировать весь монолит, запуская его целиком на всех нодах, даже если узкое место в какой-то его конкретной части. Пример на пальцах - допустим у вас 1 узкое место. Чтобы работало под нагрузкой вам нужно иметь 10 запушенных экземпляров . 10 запущенных монолиров потребуют больше ресурсов, чем если вы разрежете монолит на, допустим 5 микросервисов, так что то узкое место будет лишь в одном из них и отмастштабируете это 1 место в 10 раз.
Возможно. Возражений против С# у меня нет и не было. Были лишь высказаны опасения про платформу .NET, если вы на ней, а не на Mono или какой-то другой альтернативе, которая в меньшей степени привязана к бизнеспрактикам коммерческих компаний.
Скорость системы зависит от многих факторов - не только от языка. Язык важен лишь если у вас CPU-bound или Memory-bound задача. Если у вас именно такой случай, то да, не спорю, С# может быть хорошим выбором. И да, если вы не хотите тратить время на изучение других языков, то и единственным. А я бы посмотрел в сторону GoLang и Rust в таком случае, оставив пайтон или тайпскрипт для задач по data-moving с минимальными трансформациамяи.
Ну нашли к чему докопаться.Т.е. вы согласны с остальным и не возражаете - а там намного больее важные ссоображения чем кроссплатформенность.
По поводу платформ - хорошо, я объясню. Для вас вся кроссплатформенность сводится к 2м плафтормам - Windows и Linux? А не деле существует масса других платформ, например FreeBSD. Вы собирали .NET под FreeBSD? Наверное нет, потому что совместимые бинарники можно получить только в линукс-эмуляторе. Никаких других способов пока нет / мне не известны / не найдено. Нет способов получить под RT операционными системами, нет для NetBSD, OpenBSD, нет для Solaris и т.п.
Риск в том, что Микрософт - это коммерческая компания, движимая коммерческими интересами и в любой момент может пересмотреть свое отношение к своим продуктам. Это происходило уже не раз - продукты выпускались и прекращались. Кроме того, иногда коммерческие компании идут в суд и отстаивают свои лицензии, как например Oracle идет в суд против Google/android в отношении Java. Это добавляет риск, а не снижает его.
Mono в этом смысле выглядит более практичным выбором, но для ее развития нужен консорциум. Это бы придало большую стабильность продукту и позволило бы планировать в терминах LTS и кроссплатформенность в этом случае совершенно натуральная, как мы наблюдаем в случае open jdk.
Но это всё просто ничто по сравнению с выбором способа масштабирования (вертикального вместо горизонтального), заблуждений по поводу предсказуемости памяти в случае .NET, забдуждений по поводу удобства отладки и т.п.
Обычно это заблуждение про "предсказуемую память" довольно быстро развеивается как только вы начинаете прогонять нагрузочные и пен тесты. Надеюсь вы их провели и убедились что всё в порядке прежде чем делать такие заявления.
.NET не плохой выбор, но я не вполне понимаю чем конкретно тот же пайтон или тайпскрип или джава были бы хуже. Да, прожорливавее, возможно, на пару мегабайт. Да, чуть тормознее, на пару миллисекунд. Но на разработку вы потратили бы в несколько раз меньше времени, не были бы привязаны к платформе, а сэкономленное время могли бы потратить на развитие и масштабируемость системы. (извините, если прозвучало как ворчание старого деда)
Добро пожаловать в мир WorldWide или корпоративных проектов, где 1000 одновременно работающих клиентов - просто ничто. Нет, не спорю, можно вертикально масштабировать систему и покупать всё более дорогое железо, чтобы поддерживать растущую нагрузку. А когда вы упретесь в пределы возможностей монолитных решений, то, надеюсь сообразите, что все эти брокеры сообщений и микросервисы придуманы вовсе не для того чтобы затруднить вам отладку. Скорее наоборот - вы можете приписать каждому микросервису контракт и протестировать его на соответствие контракту. Чем хороши микросервисы - вы их можете запустить в любом количестве экземляров - для горизонтального масштабирования. И, кроме того, вы можете работать в команде, где у каждого есть своя доля работы и никто никого локтями не толкает, работая над одним клубком.
Там контекст - это в компании, которая не яндекс от слова совсем. В маленьких компаниях, если они интересные, обычно народ надо разгонять, чтобы они уходили с работы, а не сидели до поздна. Но isadora-6th прав, возможность работать на удаленке - это скорее конкрурентное преимущество.
Если встает вопрос контроля - это уже скорее надо к паталогоанатому - бизнес скорее мертв. Неужели сложно устроить стендапы по утрам? Мелкие, согласно скраму, на 15-20 минут. Всё давно уже придумано. Если чел должен что-то сказать про то что он делал - это заставляет задуматься что же он делал. Это уже само по себе работает как самоконтроль.
Еесть компании, где работают сотрудники, плохо умеющие привлекать новых сотрудников интересными вызовами, а тех, которых смогли нанять не умеют увлечь. А потом берут, лежащее на поверхности - "это такие сотрудники нам достались, со своими неправильными целями, потому что всех хороших забрал большой конкурент", и начинают верить в это.
Из моей практики - увлекает вызов - сотрудник решаете такую проблему, что никто кроме него не решал на этом месте. Где-то там, наверняка, решали другие, но тут и конкретно эта проблема - никто.
А если то же самое преподнести как рутину и долбасить каждый день вопросами "ну когда ты ее решишь?", то да, быстро надоедает и интереса нет.
Если сотрудники увлеклись своими делами - это значит, что работодатель не смог увлечь своими, нужными для дел компании. Плохая организация - обычно это признак или отсутствия опыта или наличие плохого опыта руководства.
А компания так и останется маленькой, потому что большой ее делают сотрудники, не руководство. Руководство лишь выбирает куда, а тягловая сила - это сотрудники.
Еще одно заблуждение - что конкуренция вредит. Конкуренция создает рынок и придает динамизм продуктам.
Решение проблемы - образование. Никогда не поздно поучить матчасть - как организовать
рабкринхороший процесс.Целевая аудитория не та, и реакция была бы совсем не та, на которую вы говорите запад хотел бы рассчитывать, если бы они начал резать доступ физикам. Думаю, выборы тут не при чем. А вот то что у СофтЛайна дела идут не очень - догадка напрашивается. Однако, даже если это всё так, это не исключает, что реально ограничат.
Меня терзают смутные сомнения -- а был ли мальчик?
В изначальной новости, которая ссылалась на Softline, речь шла и про AWS и про Гугл и про Микрософт и про облачные продукты и про сами облачные сервисы.
Сейчас всё редуцировалось до Микрософта и списка из десятка продуктов, только для предприятий и дата тоже поплыла.
В подтверждение правдивости приводилось письмо, якобы из Микрософта, но без загловков - без подписи, без сервера и даты когда и кем было отправлено. Учитывая, что Микрософт - американская компания, а санкции, на которые ссылаются - европейские, скорее всего речь может идти об обслуживании клиентов европейским офисом Микрософта.
В планах -- некоторых корпов от некоторых программ везде, в т.ч. в облаках. Доступ к облакам, скорее всего, им оставят. Про физиков речи не шло изначально.
Доклад вообще-то представил офис директора по национальной кибербезопасности https://www.whitehouse.gov/oncd/
Это просто подразделение Белого Дома, считайте как один из комитетов исполнительной власти. Вам стоит почитать детали если хотите покритиковать
https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
И нет, они не указывают как людям программировать. Но на основании доклада, думаю будут выпушены регуляции и в федеральных институтах перестанут начинать новые проекты на небезопасных языках и будут работать над заменой в ранее начатых.
В коммерческом секторе, в облаках, уже давно С++ не в фаворе, но С еще практикуют. Посмотрим что получится в итоге.
в сущности emplace - это костыль для insert, который не способен создать на месте. Ему надо создать, переместить, убить. Вот чтобы исключить
создать-убить- и сделан emplace(). Кроме обрамляющегосоздать-убитьу insert, у них больше нет никакой разницы, они оба используют один и тот же метод в векторе _M_realloc_insert() - считайте "private emplace()"Например этим
создать-убитьплох vector<string> v; v.insert(v.cbegin(), move(string(5, '-'))) и этогосоздать-убитьнет в vector<string> v; v.emplace(v.cbegin(), 5, '-'). Я могу углубиться в детали с использованием g++, с оптимизацией и разбором ассемблера что из этого получилось и почему. Т.е. это я пока в поддержку вашей правильной идеи о хорошести emplace().Теперь о Rust. В Rust изначально нет этого косяка, там нет такой семантики такого копирования, поэтому нет и фикса с семантикой move. Там move изначально. Может, просто не стоит пытаться пофиксить то, что не нуждается в фиксе? ;)
Согласен. Это хорошее дело, но его как раз не было в С++ с самого начала. Всю дорогу были копирования - вы добавляете (push) объект в контейнер и он делает для вас копию. Вы делаете resize вектора и он начинает делать то же самое для всех объектов.
И лишь через 13 лет появляется move сематника, при которой копируют сырые данные объекта на новое место и обнуляют их в источнике. Оптимизатор может позволить и это убрать, чтобы сразу создавалось где надо. Но язык, еще раз, изначально этог не делал и для backward compatibility поддерживается весь зоопарк - что было до, и что стало после С++11. Вы видимо не застали те счастливые годы, когда не было = delete и приходилось объявлять private оператор присваривания и конструктор копирования в больших объектах, чтобы копилятор явно ругался там, где подразумевается неявное компирование. Это С++.
В Rust есть явная передача владением. Эта концепция похожа на move.
Сколько драйверов Linux или *BSD написано на С++? Сколько boot firmware в материнских платах написано на C++? Да, есть исключения. Вы отрубаете exceptions в опциях компилятора, врубаете статическую линковку и делаете прочие приседания типа оборачивания всего внешнего в extern "C", скрываете все символы по-умолчания, чтобы С++ стал максимально подобен С и по поведению и по API и тогда можно писать firmware и драйвера. Но это надругательство над средой с большим overhead. Поэтому это не стало mainstream. Люди просто используют C в таких случаях.
У нас с вами разные лохматые года. У меня - это конец 80х, когда я начинал кодировать и никакого С++ в помине не было. А 2011й год с C++11 это было буквально вчера. К тому же он вошел в обиход и стал стабильным примерно в 2013м. И с 1998-99 по 2013 приходилось лавировать в С++ чтобы избежать копирования или чтобы оптимизировать цепочки вызовов. При том ведь не было даже unique_ptr или shared_ptr, никаких стандартных потоков или объектов синхронизации. Все тащилось через библиотеки из ОС. А Бьёрн утерждал с пеной у рта что так и должно быть. Что язык должен быть чист от таких особенностей некоторых (всех) ОС. Язык сделал огромный рывок в 2011 создав комитет, который принял все эти инновации. Всё идет значительно лучше с тех пор. Но право речь не об этом, а о том, что всё старое осталось и любой залетевший дятел может всё порушить. Вы работаете в коллективе из 8+ человек, где есть и синьоры и джуниоры. Не приходилось разбирать последствия "инноваций" новичков? Ведь так легко и незателиво рушиться не должно. Правильное дело когда синтаксис построен так, что компилятор имеет возможность обнаруживать косяки во время компиляции, задолго до рантайма. Это же клево! Чем больше таких языков, тем лучше. Может сделают подобное Rust, но проще типа GoLang - буду только рад.
Что касается Rust - я не вполне понимаю что у вас не получилось в нем?
<del>
Конструирование объектов в контейнере, если я правильно понимаю о чем вы - это было всегда, с С98 -- определяете вектор, например строк, и говорите что нужно иметь длину 50, например, элементов и resize() сам создаст все строки дефолтовым конструктором вызывая T::T(). Делов то. Это прям магия, большое технологическое преимнущество дедушки С++? Или речь об inplace new операторах?
C++ не зашел в ядра операционок. На нем не строят API ни к чему кроме С++, строят на С. С++ не используется в firmware, на нем не пишут драйвера, на нем не пишут обработчки пакетов (DPDK). А на Rust всё это уже пишут.
Ну как бы там ни было, речь не идет о том, чтобы все стройными рядами шли в сторону Rust. Я упомянул лишь для сравнения и причина понятна - в Rust гораздо меньше багажа, низкая база и отсюда большая скорость развития. Но я отнюдь и я не апологет парадигмы one-fits-all. Есть и другие языки, безопасные при работе с памятью. Это всё и нужно развивать.
Страуструп, конечно, молодец, и цели хорошие ставил. Он ведь не отказывается, что ставил их? Он просто не упоминает, что цели не достигнуты.
То что С++ -- не С это он пусть зеркалу объясняет. Берем любую С программу, компилируем С++ компилятором и оно работает в 99% случаев. В 1% не соберется из-за необноходимости переименовать зарезервированные слова, которых в С++ побольше, чем С.
Бьярн прав, конечно, что безопастность работы с памятью - это не единственная проблема языка, но не прав, пытаясь увести в сторону, потому что это самая зияющая проблема языка Да, С++ предоставляет механизмы, всё ок с ними (кроме сложности). Но механизмы работают только если и когда ими пользуются и пользуются правильно. А раз старые С-шные конструкции работают и механизмы не совсем законченные, то любой случайно залетевший дятел рушит цивилизацию. Мы эту шутку все знаем. И указатели там живут, и ссылки могут ссылаться на несуществующие объекты и смарт укзаатели пришлось переписывать, чтобы со второго подхода они стали чуть умнее, и контейнеры, которые за 13 лет научислись перемещать объекты и поддержка файловой системы через 19 лет и корутины через 22. Темпы развития поражают воображение. Так через 50 лет можно ожидать unsafe блоки, как в Rust были добавлены лет 9 назад.
С++ надо объявить трупом и перестать улучшать труп. Дедушка С++ был хорошим, мы все будем поминать его добрым словом.
Первый вариант - не работает на практике. Как только этот IP кто-то опубличит и им начнут пользоваться существенное количество пользователей, его заблокируют.
CDN - да примерно так и должно быть. Паша Дуров довольно долго бегал через CloudFront - суть тот же CDN (хотя и не только) и попробуй его заблокировать, а имена хостов в нем - дело сугобо личное и TLS-защищенное. Но сам CDN - если приложение его находит по именам, то нужен DNS, а его нет. В общем замкнутый круг курица-яйцо.
Схема, разрывающая этот порочный круг может выглядеть так -- актуальные адреса в большом количестве вшиваются в текущую версию дистрибутива и сидят в нем в зашифрованном виде. Приложение открывает первый блок используя встроенный ключ и начинает работать с адресами из него. Если получается, то оно получает ключ для расшифровки второго блока и этот ключ приходит из этих сервисов первого блока. Суть этих сервисов лишь проверить аутентичность приложения и выдать ключ для второго блока. А дальше второй блок - это уже endpoints сервисов выдачи актуальной новой версии приложения, где могут быть обновленные адреса, -- ее надо скачать и поставить если сейчас работает устаревшая версия. Дальше следующий ключ и следующий блок дает доступ к доменным именам, по которым находятся текущие endpoints VPN сервисов. Чем гибче схема, тем дольше ее разматывать и блокировать. Но я не видел где, кроме телеги, подобное реализовано. Впрочем, может быть Паша сподобится добавить и VPN в телегу.
речь про компании. Персональые лиценции не попадают под ограничения, но в самих продуктах может ограничиваться объем данных и доступные фукнции по сравнению с enterprise лиенциями
Может хватит уже повторять ерунду? Никакие сервсы пока не блокируются. Блокируют доступ к некоторым приложениям. Вы разницу понимаете между поездом и пассажиром поезда? Или между страной и гражданином? Вот такая же разница между облачным сервисом и одним из приложений, к которым доступ предоставляется через облачный сервис. Сервис предоставляет доступ к практически любым приложениям и к много каким функциям, которые не совсем приложения или совсем не приложения.
Вот в этом посте https://habr.com/ru/news/800639/ - вы правильно назвали это приложениями. А тут что помешало?