Специалисты АНБ США посоветовали разработчикам по возможности использовать при написании ПО языки программирования, которые более безопасны с точки зрения доступа к памяти. В агентстве считают, что вместо таких языков, как C или C++, следует отдавать предпочтение C#, Rust, Go, Java, Ruby или Swift.
Специалисты АНБ США посоветовали разработчикам по возможности использовать при написании ПО языки программирования, которые более безопасны с точки зрения доступа к памяти. В агентстве считают, что вместо таких языков, как C или C++, следует отдавать предпочтение C#, Rust, Go, Java, Ruby или Swift.
В сообщении АНБ говорится, что злоумышленники могут использовать проблемы управления памятью, возникающие при применении языков C и C++ — например переполнение буфера или ошибки распределения памяти, — для получения несанкционированного доступа к целевым системам.
Как альтернативу им рекомендуется использовать языки, чьи механизмы проверки автоматически предотвращают появление в коде ошибок, которые могут превратиться в уязвимости.
В сентябре отказаться от создания новых проектов на C/C++ ради «безопасности и надёжности» призвал технический директор Microsoft Azure Марк Руссинович.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Ruby? Они серьезно? Дайте ему уже умереть :)
Откопали г мамонта :)
видимо о количестве заказов из Запада вы не в курсе) это радует
Пишу не на одном языке, но конкретно руби какой-то корявый, если так можно выразиться :)
А легаси, да есть. Но это не значит, что нужно тянуть в новые проекты. Я пробовал и мне не понравилось :)
не вы один пишите на разных языках, но подозреваю, что вы не понимаете саму идеологию языка, любопытно как вы пишете тогда на разных языках. Мне нечего доказывать, просто рад, что конкуренция несильная)
Пользователь отредактировал комментарий 13 ноября 2022, 23:48
По всем рейтингам руби умирает: количество репозитариев, популярность, «любимость» разработчиками и тд. По любимости скриптовый руби в конце, что говорит о его косяках.
Пытались сделать модный язык, а получился почти Perl 2 :)
ну он же написал в конце главную причину, со временем получать будет больше, потому что язык умирает
LOL! Чот я вот не помню когда последний раз на плюсах врукопашную в буферах ковфырялся или память выделял, всё завёрнуто, всё на автомате.
Ну это говорит не более чем об ограниченности вашей области дейтельности. Бабка на вахте даже не знает как может выгладеть язык программирования, но это не значит что их ни кто не использует.
язык с++ имеет два плюса, по сравненю с остальными языками программирования, и он все в названии
Имхо как язык, т.е. синтаксически С++ это полное убожество, впихнуть в Си с десяток костылей поверх и назвать это языком это нужно ещё постараться. Единственная причина его успеха это популярность Си который пресеклась с популярностью ООП в момент появления С++, что собственно и было причиной его задумки.
Но как высокопроизводительная платформа в которую вложено очень много сил это безусловно лидер.
К сожалению сегодня альтернатив нет. Rust не вижу причин что бы взлетел, потому что из за наличия трэйтов в языке и стремления программистов к оверинженерингу все что полявляется на этом языке - тихий ужас с которым может работать только автор уверовавший в гениатность своего перетипизированного кода. D там же, слишком переусложненный. Хотелось бы что-то вроде низкоуровневого Go без GC, лучше бы с автоматической проброской ошибок что бы без ужаса в виде if err != nil..
Вообще статья странная где С/С++ а где языки со сборщиком мусора, сегодня это разные цели, суть первых уменьшение потребления памяти, в первую очередь, и как в таких случая можно заменить С/С++ не понятно.)
Пользователь отредактировал комментарий 14 ноября 2022, 05:38
GC никак не связан с увеличенным потреблением памяти (с точностью до оверхеда на счетчики ссылок). Скорее наоборот: когда автоматика за программиста думает о высвобождении памяти вовремя, в среднем потребление ниже.
Не очень понимаю как вы себе представляете язык с ручным управлением памяти и одновременно с исключениями. А память кто будет освобождать, когда исключение выкинуло нас в стеке вниз на 10 функций?
Интересно, что вы называете го низкоуровневым, хотя он проектировался наоборот как максимально простой высокоуровневый язык для студентов, который позволит им гонять джсоны без понимания как работает память, треды, кооперативная многозадачность, системные вызовы и т.д.
Также интересно, что вы плюетесь от трейтов раста, но при этом почему-то ничего не сказали про интерфейсы в го или плюсах. Мне кажется, рядом же называя код на расте перетипизированным, вы путатете унаследованную из ocaml/haskell алгебру типов в трейтами. Но даже здесь спешу вас разочаровать: чем дальше будет двигаться мейнстрим-индустрия, тем активнее будут использоваться языки с развитой системой типов, и в первую очередь - с алгеброй типов. И чем точнее типами описана программа, тем доказано меньше в ней потенциальных багов. Вплоть до формально верифицированных программ в каких-нибудь coq/idris, где верификация работает как раз на тотальном знании компилятора о теореме, описанной через систему типов. Короче говоря, с типами придется смириться :)
В статье не только языки со сборщиком мусора, есть и сравнимые с плюсами по методу работы с памятью.
прежде чем писать много букв нужно почитать букварь джонлепихин
Пользователь отредактировал комментарий 14 ноября 2022, 08:55
слив засчитан.
Ну только если ваш самослив в некомпетентности по базовым понятиям.)
Жду конструктива.
Например, как вы себе представляете низкоуровневый язык без gc, очевидно без плюсовых умных указателей (и без растового доказательства безопасности памяти), но с исключениями? Вы осознаёте какой неуправляемый адище с malloc/free ждет программиста, когда исключение в любой вызванной функции создаёт в нашей пусть даже синхронной функции весь букет UB? Никакие defer не спасут.
В общем, расскажите своё видение, может я правда чего-то не понимаю.
Почему очевидно без этого, у вас фантазия разыгралась или это по вашему GC?)
Точто такой же как поставить return до очищения памяти. По этому в том числе, и придумали сборщик мусора. Что бы не забывали очищать память.
Пользователь отредактировал комментарий 15 ноября 2022, 16:06
Вас не смущает, что shared_ptr в плюсах – это примитивный сборщик мусора? Только в большинстве языков, где GC официально заявлен, free() вызывается не сразу при исчезновении последней ссылки на объект, а для оптимизации периодически и массово, что позволяет бороться в т.ч. и с фрагментацией памяти.
Если хотите "что-то вроде низкоуровневого Go без GC", то давайте заодно хотите и без shared_ptr.
Ну мы уже убедились что вы специалист по выдумывают собственных смыслов четко определенным понятиям. У вас и байт код интерпретируется и умный указатель это примитивный GC.))
Вы самостоятельно ставите авторские границы определений понятий, а потом я должен что-то вам доказать используя их?) Можете дальше утверждать что C++ это язык со встроенным сборщиком мусора. Я все же буду исходить из общепринятых определений, в который умный указатель и др. подобные техники не являются сборщиком мусора.
А, ну да, язык с трейсингом/rc всех значений в куче - это язык без GC. Ага. Передайте привет фрагментированной памяти в своем языке мечты! Потом не забудьте дописать в него полновесные gc cycle, иначе сильно быстрее php работать не получится, увы.
Про байткод вы конечно прекрасно написали. А мужики-то не знали.
Вы фантазер или читать не умеете не пойму.) Где у меня написано про трэйсинг?
Возвращение кода ошибки в Си/Go это типичная операция, которая есть в каждом коде. Но поскольку вы очевидно не программировали на Си/Go и т.п, об этом не знаете. Автоматизация возврата ошибки никак фундаментально не меняет язык, это все уже сейчас реализовано на макросах и используется в многих проектах, но жутко не удобно по этому хотелось бы иметь удобный механиз в дизайне языка. LOL.)
Как говориться не знаешь, не понимаешь, лучше тихо и молча читать теорию и практиковаться.))
Трейсинг - одна из техник GC. Рассуждение про него идёт в контексте GC, если вы не обратили внимание.
Никто не мешает нахерачить поддержку исключений хоть в голый цэ. Не задумывались почему этого никто до сих пор не сделал за 50 лет? Вот подумайте. Подсказка: посмотрите исходник ядра линукса, найдите там распространенный паттерн с goto exit_bla_bla_bla, где по метке free() и return. Подумайте.
Джони вы в порядке?) Вы либо не умеете внимательно читать либо что-то додумываете. То что вы описали мною не предлагалось. Вы сами выдумали эту проблему и пытаетесь доказать её.
Попробуйте написать что-то на Си может поймете что подразумевается под возвратом кода ошибки.))
Поскольку вы пытаетесь доказать что у общепринятых определений есть альтернативное, известное только вам определени, а так же приписываете мне утверждения которые придумали сами у себя в голове, т.е. которые я не писал, больше я вам отвечать не буду потому обсуждать есть смысл только с тем кто основывается на логическом мышлении и фактах а не занимается софизмом, сам того не осознавая.
Слив засчитан.
Спасибо кэп! :)
Чем точнее описаны типы, тем меньше багов добавят разработчики :)
Типа того. Только люди, рассуждающие в рамках классических интов, строчек и классов с интерфейсами и темплейтами, не осознают глубину этой кроличьей норы.
А на практике тем временем все обстоит по другому, чем больше разботчик пишет типов тем больше багов приносит в код, ну и как сложно не добавить - делает код нечитаемым.
Гладко было на бумаге, да забыли про овраги.)
Вы сейчас про какую систему типов? В моем мире противоположный опыт. Ocaml за деньги с 2007, хаскель для души с 2011(?), раст за деньги с 2019. Во всех этих языках ADT, и везде активная эксплуатация типов упрощала жизнь, особенно на больших проектах.
У С++ нет конкурентов сегодня и видимо еще долго не появится.
Rust, если не заниматься на нем кододро#ерством :)
Хотя, как писали выше, трейты выглядят как зло, но GC они красиво выпилили :) Но нужно немного привыкнуть.
Проблема раста, в том что сторонними библиотеками невозможно пользоваться. Элементарная бибилиотека в которой должно быть пару функций на Rust будет из 10-100 трэйтов, мне проще взять С/С++ либу и проверить её 10 раз и написать тесты чем разбираться с очередным шедевром на Rust.
Все остальное в языке более менне, хотя работа с памятию через механиз владения вызывает тоже сомнения потому что с ней тоже очень много гемороя, хотя есть более простые решения в виде умных указателей.
Это тот у которого ни инфраструктуры, ни инструментов. И на котором за столько его лет так до сих пор ничего толкового и не написали. А то что есть от двух землекопов для трёх лесорубов и версии пре-пре-пре-пре-альфа.
Спасибо, ржавейте сами.
но с классами! :)
Так там и так есть все что нужно.)) Чем вам структуры не устраивают?)
уверен что компилируются они в тот же c++, так что можно и на c++ все писать нормально)
Хорошо бы кроме уверенности ещё иметь минимально знаний. )
Уверен что вы не программист а какой то левый выхухоль, ну не может человек который освоил ЯП с такой периодичностью писать чушь. Должна быть хотя бы минимально развита логика. Может вам на онлайнер вернуться и не засорять этот форум своим "мнением"?
Пользователь отредактировал комментарий 14 ноября 2022, 14:35
а с чего взял что ты обладаешь большими знаниями чем я?)
Просто прочитал ваши комментари, из которого следуе что вы обладаете околонулевым уровенем зананий. Пример. - "уверен что компилируются они в тот же c++."
Во первых, элементарно и по определению не может ЯП компилироваться в другой язык. Во вторых в тех ЯП которые мы обсуждаем так не происходит. Применять слова не задумываясь на их смыслом это первый признак "большого" обьема зананий.
На этом пожалуй уроки по информатике я вам больше давать не буду, есть дела поважнее чем подтягивать те кто в университете не учился.))
Пользователь отредактировал комментарий 14 ноября 2022, 21:18
а вот тут ты не прав и сам показал себя что ты полный ноль:
Компилятор это программа, которая переводит из более высокого языка в более низкий. Так что наверняка переводят в C или C++, врятли там будет Pascal или Basic
Подловили себя вы и очередной раз, так и не удосужившись поискать и прочитать суть термина, компилятор и отличие от термина транслятор. Все приходится вас учить элементарному.)
Пользователь отредактировал комментарий 14 ноября 2022, 23:55
о5, профакапился и пытаешься выйти.
Транслятор просто переводит на одинаковом уровне языки, например Java -> C#
а вот Typescript -> Javascript это уже компилятор
Всё ещё круче :)
Транслятор - общее название для любых программ, которые что-то делают с исходным кодом.
Компилятор - вариант транслятора, который компилирует исходник в машинный код или байткод.
Транспилятор - вариант транслятора, который преобразует исходный код одного языка в исходный код на другом равнозначном языке.
И например интерпретатор - это тоже вариант транслятора, который исполняет исходный код as is. В свою очередь, он может сначала распарсить в AST и ходить уже по асту (большинство современных интерпретируемых языков, которые не компилят в байткод), либо парсить и исполнять построчно (большинство шелл-интерпретаторов).
Т.е. вы fallinmyhand настолько дубовый что продолжаете утвержать что термин компилятор, означает не то что вы пишете, вместо того что бы прочитать определение?)
Нет, Typescript в Javascript это не компилятор.)
Никто не компилирует в c++, это не имеет практического смысла.
java компилируется в байткод jvm и затем в jre выполняется. Как есть, инструкция в инструкцию.
ruby последние ндцать лет компилируется в байткод их виртуальной машины, и ей исполняется.
swift компилируется в llvm байткод, который затем llvm-компилятором компилируется в машинный код.
go имеет свой компилятор, но дополнительно имеет экспериментальные фронтенды gcc и llvm.
rust аналогично swift, но также экспериментально поддерживает фронтенд gcc.
ну Java и тому подобные, компилируются в байткод для кроссплатформенности, а потом в интерпретаторе выполняются - вот тут и теряют в производительности по сравнению с c++
У вас в голове полная каша из понятий. Нет байт код не интерпретируется, по определению. ))
Байткод интерпретируется (исполняется) виртуальной машиной. Последовательно, от инструкции к инструкции. Он всё правильно написал.
Ну вам тогда советую все же выучить базовые термины а затем уже пытаться что то писать публично по теме)). Для простоты скину ссылку на вики как самый простой и понятный источник.
In computer science, an interpreter is a computer program that directly executes instructions written in a programming or scripting language, without requiring them previously to have been compiled into a machine language program. https://en.wikipedia.org/wiki/Interpreter_(computing).
Байт код это машинный код, хоть и для виртуальной машины. Он то что так же как машинный, выполняется от инструкции к инстукии. А у понятия интерпритатор есть строгое определение. Надеюсь понятно или дальше будете доказывать что определение не правильное?)
Ну собственно что можно обсуждать с людьми которые жонглируют терминами как хотят, при этом раздувая щеки экспертностью.))
Пользователь отредактировал комментарий 15 ноября 2022, 17:48
Байткод НЕ МАШИННЫЙ код.
МАШИННЫЙ код - это mov ax bx, add 0x34, jmp и все прочие инструкции, знакомые ПРОЦЕССОРУ. Машинный код как есть отдается процессору, без промежуточной обработки.
БАЙТКОД - это incr(i), goto(1000) и что угодно ещё, что придумается инженеру птичьего "ассемблера" для своей виртуальной машины. Эти инструкции выполняются ИНТЕРПРЕТАТОРОМ байткода, либо в некоторых случаях компилируются в МАШИННЫЙ код JIT-компилятором.
Машинным кодом байткод становится с физическим изобретением процессора, способного исполнять инструкции этого байткода. Как например в 1970-80-х появлялись лисп-машины для исполнения байткода, скомпилированного из лиспа.
Грамотей, блин.
Так вы все же утверждаете что общеопределнное в computer science, понятие термина интерпретации не правильное - executes instructions written in a programming or scripting language, а то что вы себе придумали правильное я так понимаю?)
Почитайте хоть статью на которую сами ссылаетесь. Хоть до 4-й строчки.
Из альтернатив не предложили реального ничего. Что собственно и ожидалось. Как бы не кусалось но аналогов C и C++ нет. Всё названное просто ниочём как по возможностям так и по инфраструктуре.
Лучше бы посоветовали правильных книжек и читать стандарты. В современном C++ всех этих проблем уже нет сто лет в обед. Надо только стандарт открыть и убедиться.