читая это сообщение, не мог отделать от впечатления, что текст сгенерирован очень умным ИИ.

Кажется Ваша шизофрения, представления о том что вы дипломированный психолог, таки имеют место. Либо давайте пруфы? :)

Почему не собрать приложение под все возможные архитектуры процессоров?

ещё не изобретённые тоже?

Там либо ARM, либо x86

и внутри каждой свой зоопарк, да и другие архитектуры никуда не делись.

ну и вообще, что делать с динамическими языками?

А я не претендую на специалиста в этой области. Я спросил с точки зрения разработчика.

Контролируются ошибки типа переполнения буфера и т.п., все это выбрасывает исключения, но не приводит к передаче управления на внедренный код либо к падению системы.

всегда удивляло как смело на подобные темы пишут люди, чьи компании 19 лет имели баг «покидания песочницы»

LLVM IR не портабельный

Тем лучше. В остальном ты сам себя охарактеризовал.

Повторяю для тупых ничтожеств: ты - идиот и отродье дешевой прошмандовки.

Никакой исходный код не решит тебе задачу защиты твоего процесса от поведения стороннего модуля из потенциально ненадежного источника.

А теперь подохни уже наконец, грязная проблядь.

Господи, какое же ты ничтожество :)

Управляемый код -

это модный баззворд.

Впрочем, возможно уже не сильно модный.

Хотя, не понимаю, чем тот же Pascal уступает?

Напомни, в скольких реализациях Pascal есть тот же async/await. Ну или LINQ.

Если отбросить вопросы синтаксиса

или неуродливые лямбды.

больше хамства богу хамства

Управляемый код компактный, и дает ништяки типа песочниц, верификации, интроспекции, оптимизаций в рантайме. Сборка мусора и борьба с переполнением буферов не связаны с ним жестко, но с ним они упрощаются, как и, например, зеленые треды и горячая замена кода.

Хотя вообще это write/compile once run everywhere - огромная ловушка и повод зажимать исходники.

Без специальных обфускаторов байткод очень прозрачен и все алгоритмы легко вытаскиваются. Поэтому проблему защиты интеллектуальной собственности байткод сам по себе не решает.

В то же время открытые исходники решают оригинальную задачу на ура.

Байткод оптимальней исходников, т.к. компиляция идёт быстрей, да и места меньше занимает. Но к управляемому коду байткод прямого отношения не имеет. Можно C преобразовывать в байткод, например, тупо распарсив язык и сериализовав AST в компактном виде. А байткод уже потом прочитать и провести дальнейшую компиляцию.

После бурного обсуждения, пришел к выводу, что управляемый код таки имеет право на существование и является благом. Всем Спасибо за участие.

разрешаешь? спасибо.

Всё очень просто. Ты работаешь месяц инструментом Г и получаешь за работу две буханки хлеба. Или ты работаешь инструментом А один день и получаешь две буханки хлеба.

Странно что не вспомнили Ada. Минобороны США деньги вкладывали, к gcc фронтенд есть, нет подавай им джаву...

Странно что не вспомнили Ada. Минобороны США деньги вкладывали, к gcc фронтенд есть, нет подавай им джаву...

Ада успешно используется там, где надо.

У тебя вместо фактов — домыслы, а вместо логических выводов — ассоциативные ряды. Я боюсь. Но попробую.

Посредничество между кодом и процессором нужно чуть ли не каждому из десятка уровней абстракции, ниже которых ты, аналитик, заглянуть уже не в состоянии, да и не пытаешься.

Слоев между кодом и «железными командами» становится все больше и это нормально. Однако твердо сказать «второе» я могу, так как слои эти простираются аж до микрокода процессора и так уж вышло, что весь код уже «управляемый». Ты опоздал. Прости.

Управляемый код в своё время был отличным способом создать безопасные программы на небезопасном языке.

И в чём опасность джавы, например?

Go
не жертвуя производительностью

Ага, конечно.

Без специальных обфускаторов байткод очень прозрачен и все алгоритмы легко вытаскиваются. Поэтом у проблему защиты интеллектуальной собственности байткодсам по себе не решает.

Во-первых, это ложь - он не прозрачнее ассемблера. Во-вторых, сами же сказали - обфускаторы. В-третьих, а на самом деле во-первых и в-единственных, он не даёт адекватной возможности изменять код по своему усмотрению, как позволяют исходники, и никак заменить их не может.

Байткод оптимальней исходников, т.к. компиляция идёт быстрей, да и места меньше занимает.

Это спички. Кросс-платформенный софт может распространяться только в исходниках, но байткод создаёт ощущение что это не обязательно. Полностью ложное, в чём и посыл. Никаких преимуществ при этом не давая.

Контролируются ошибки типа переполнения буфера и т.п., все это выбрасывает исключения, но не приводит к передаче управления на внедренный код либо к падению системы.

Это легко может быть реализовано и без «управляемого» кода.

это и верификация байткода при загрузке, и полный запрет на арифметику указателей, и контроль за границами массивов. Все это невозможно без VM.

Выделенное возможно.

Ну и мейнстримовые менеджед языки вполне позволяют поиграться с указателями и выстрелить себе в ногу.

А вот с байткодом ты можешь как угодно анально огородить права подгруженного кода и его возможности нагадить твоему процессу.чес

Можно подробнее? Например, в джаве возможно загружать классы. Как проверить, что класс внутри не делает ничего «ужасного» через Unsafe?

Или это просто «теоретическая возможность»?

И в чём опасность джавы, например?

Разыменование null-а, висящие ссылки, переполнение стека.

Все было и прошло.

Во-первых, это ложь - он не прозрачнее ассемблера.

На порядок прозрачнее. Я не раз пользовался JAD - он показывает исходный код на Java по заданному .class-файлу. Кроме локальных переменных и комментариев ничего не теряется вообще.

Во-вторых, сами же сказали - обфускаторы.

Обфусцировать можно и исходники.

В-третьих, а на самом деле во-первых и в-единственных, он не даёт адекватной возможности изменять код по своему усмотрению, как позволяют исходники, и никак заменить их не может.

Легко даёт. Я сам менял и перекомпилировал, всё отлично работает.

Это спички.

Отнюдь.

Кросс-платформенный софт может распространяться только в исходниках, но байткод создаёт ощущение что это не обязательно. Полностью ложное, в чём и посыл. Никаких преимуществ при этом не давая.

Не согласен с этим утверждением. Байткод идентичен исходникам и ничем не хуже для распространения.

Я знаю о наличии уровней ниже, но,признаюсь, не учел этого факта.

Были бы, я думаю, если бы язык был в мейнстриме.

Не согласен с этим утверждением. Байткод идентичен исходникам и ничем не хуже для распространения.

Legioner как всегда авторитетен, категоричен и некомфортно себя чувствует онлайн без попыток сплотить против себя побольше народу.

ARM - это не одна архитектура, а общее название для целого ряда наборов инструкций.

Базовый набор-то общий. Ты часто собираешь приложения отдельно для i3-i7, отдельно для amd-шных продуктов, отдельно для Xeon-ов?

ЯННП

Ну давай посмотрим как «современный» и «безопасный» Gо справляется с этим.

Разыменование null-а

Хуже, чем в джаве - перехватить ведь нельзя?

переполнение стека.

Гугл подсказывает, что и с этим всё отлично, например:

runtime: goroutine stack exceeds 250000000-byte limit

fatal error: stack overflow

Хорошо хоть про производительность упорствовать не стал. В бенчмарках джава и то быстрее.

Я не раз пользовался JAD

Попробуйте натравить его на коммерческий продукт, сильно удивитесь и больше бреда про то что «байткод идентичен исходникам» писать не будете.

Базовый набор-то общий.

Что общего между arm режимом и thumb2? Укурился?

Что общего между arm режимом и thumb2? Укурился?

А кто-то заставляет thumb2 юзать? Процессор по дефолту в нём стартует?

Интересненько. Запизделся и обосрался ты, но при этом ничтожество - не ты? Болеешь, убогонький?

Ты, выблядок, ебанулся на почве швабодки. Подохни уже.

Кастомным class loader-ом можно выстраивать любые анальные заграждения.

Ололошки. Одних только floating point ABI там хоть жопой жри.

Не всякой программе они же нужны

Попробуйте натравить его на коммерческий продукт, сильно удивитесь и больше бреда про то что «байткод идентичен исходникам» писать не будете.

Ещё раз повторю, пробовал и делал. Если исходники не обфусцировались, всё прекрасно работает.

Кастомным class loader-ом можно выстраивать любые анальные заграждения.

Я в джаве нуб, так что можешь подробнее рассказать как это работает? На рефлексии?

Опять же, интересно можно ли как-то «вносить сложности» для желающих вводить ограничения.

Ну давай посмотрим как «современный» и «безопасный» Gо справляется с этим.

Разыменование null-а

Хуже, чем в джаве - перехватить ведь нельзя?

https://play.golang.org/p/aCwje3H75i - легко можно.

переполнение стека.

Гугл подсказывает, что и с этим всё отлично, например:

runtime: goroutine stack exceeds 250000000-byte limit

И это скорее всего можно.

Хорошо хоть про производительность упорствовать не стал. В бенчмарках джава и то быстрее.

Нет ничего глупее, чем обсуждать производительность языков. Как минимум надо обсуждать конкретные реализации на конкретном железе и конкретных задачах.

легко можно.

Ок. Я в Gо не не разбираюсь. Но насколько знаю, они от исключений отказались и defer работает иначе. То есть, невозможно отличить из-за чего у нас всё грохнулось?

В любом случае, принципиальной разницы с джавой нет. И говорить, что нет проблем с разыменованием нулевого указателя некорректно. Вон в расте с этим реально что-то сделали, а Gо ничем не лучше «опасныx языков».

Нет ничего глупее, чем обсуждать производительность языков.

Есть. Например, утверждать, что в Gо нет «накладных расходов» от сборщика мусора. Или ты под «жертвованием производительностью» виртуальную машину подразумевал?

про остальные архитектуры я не в курсе

У Андроида есть официальный порт на MIPS

есть llvm bytecode

llvm b*i*tcode

в io-bound задачах корутины рвут всех как тухик грелку. так что тем, кто не осилил реализовать их на нормальном языке, gc сильно не помешает

Нет ничего глупее, чем обсуждать производительность языков.

давай обсудим microsoft word 5.0 на 8086. работает так же как и 2013-й на i7.

в io-bound задачах корутины рвут всех как тухик грелку. так что тем, кто не осилил реализовать их на нормальном языке, gc сильно не помешает

Спорить не буду. Изначально зацепился за фразу Легионера о Го «без накладных расходов». В моём понимании это что-то типа декларируемого принципа С++ - «не платишь за то, что не используешь». ГЦ в эту схему не вписывается. Особенно забавно противопоставление Го менеджед языкам. Да, он не использует виртуальную машину, но как будто это что-то хорошее/плохое.

я на крестах уже больше 20 лет пишу, но тем не менее проведём эксперимент. представим себе среднестатистического погромиста на крестах умножающего матрицы... и сравним его с фортранщиком. в среднем, он соснёт хуйцов... и язык здесь ни причём. в рамках спецолимпиады, он может наговнокодить всяких оптимизаций, которые из-за его безблагодатности будут нещадно глючить...

и после этого мы, возвращаясь к топику, будем хаять языки с рантаймом?!