Управляемый код - большой обман или неизбежно необходимая технология настоящего/будущего?

Ну да, не всякой. Всего лишь 99% из них. Можно и пренебречь.

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

Намёка не понял.

Ну выиграет фортран благодаря годам оптимизаций и вылизанным математическим либам. И что?

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

Рассказывай дальше.

Что ж ты все никак не подохнешь-то?

Мне кажется, что это некорректное сравнение.

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

От исключений они не отказались, только назвали их panic/recover почему то и всем говорят, что отказались. Отличить можно, recover() возвращает объект, из-за которого началась паника (исключение), можно посмотреть, что это за объект.

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

Вот-вот. Java это managed язык, а go это native язык. А принципиальной разницы нет.

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

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

Сборка мусора к managed языкам отношения не имеет. Даже в C можно использовать сборщик мусора.

Или ты под «жертвованием производительностью» виртуальную машину подразумевал?

Конечно. В Go нет ничего такого, из-за чего он должен тормозить. Это очень быстрый язык, практически уровня C. Сборщик мусора есть, да, но, опять же подчеркну, это не значит, что он автоматически становится хуже для всех задач. Плюс в Go достаточно активно используется стек (привет, Java 9?).

Отличить можно, recover() возвращает объект, из-за которого началась паника (исключение), можно посмотреть, что это за объект.

Странно как-то. Повторюсь - я Gо не знаю и вряд ли изучать буду, но почему-то все любители языка заявляют, что исключений нет...

Вот-вот. Java это managed язык, а go это native язык. А принципиальной разницы нет.

Начали-то мы с того, что «джава небезопасна», а Go белый и пушистый. Хорошо, что в итоге пришли к общему мнению - одна фигня и разницы нет.

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

Точно так же, виртуальные машины свои преимущества имеют.

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

Начали-то мы с того, что «джава небезопасна», а Go белый и пушистый. Хорошо, что в итоге пришли к общему мнению - одна фигня и разницы нет.

Тут надо понимать, что я отличаю Java как абстрактный язык и JVM как конкретную реализацию. В абстрактном языке Java есть ряд небезопасных операций. JVM делает их безопасными. Я думаю, C тоже можно скомпилировать с миллионами проверок на каждый чих так, что никаких неожиданных падений и порч памяти не будет.

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

D, насколько я знаю, совсем небезопасный и испортить там стек можно за милую душу. Лиспы обычно на виртуальной машине работают и в этом плане их правильнее классифицировать как managed языки. Хаскель да, хороший язык нового поколения, только очень уж академичный, go попрактичней будет, поэтому про него и сказал.

Чистая правда. Более того, есть llvm bytecode, по сути портабельный ассемблер - write/compile once run everywhere без абсурдных недотехнологий типа VM в рантайме и JIT.

То что тебе придется для запуска этого кода тянуть сам llvm который охуенно тяжелый, ты забыл?

Тут надо понимать, что я отличаю Java как абстрактный язык и JVM как конкретную реализацию.

Мне это не кажется корректным. Ты же сам отличный пример про С приводишь. Да, теоретически, можно, но «обычному С», как и «обычной джаве» присущие определённые качества. Ты ведь не будешь обьявлять С безопасным просто потому что его «таким можно сделать»?

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

D, насколько я знаю, совсем небезопасный

Насколько я знаю, там есть просто отдельные «небезопасные конструкции». Есть и аттрибуты @safe и @trusted, хотя мне тоже показалось, что ситуация там похуже, чем в Расте.

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

Да ну? SBCL компилируется. Racket - тоже.

Ну в целом понятно, прекращаю спорить. Просто мне не нравится Gо. (:

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

Да ну? SBCL компилируется. Racket - тоже.

Несмотря на то что sbcl компилирует в машкод, он все же подстраховывает работу получившегося машкода внешним по отношению к нему образом. И в этом смысле является и ВМ, хотя и очень близкой к железу, и управляемым несмотря на то что компилятор :)

Racket, если память мне не врет, просто компилируется в байткод который потом прогоняется через GIT. Чем он при этом будет отличаться от явы которая тоже компилируется, ВМ, и управляемая не ясно.

То что тебе придется для запуска этого кода тянуть сам llvm который охуенно тяжелый, ты забыл?

Ну, во-первых, «тяжесть» llvm+clang, gcc и openjdk - одного порядка. Во-вторых, llvm не нужен для запуска, только для компиляции биткода под целевую платформу один раз.

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

Ну так тебе и надо будет каждый раз компилировать под целевую платформу. И, да, ллвм значительно тяжелее.

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

А джит это не компиляция в машкод? С каких пор?

Дорогой анаонимный друг в сообщении на которое ты так бессмыслено отвечаешь я говорил немного о другом. Надеюсь когда-нибудь ты сможешь это понять.

А почему паскаль похоронен? Я на нем разработку веду

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

Что значит «каждый раз»?

И, да, ллвм значительно тяжелее.

Врёшь. Он в полтора раза легче openjdk8, например:

% pkg info -s openjdk8-8.25.17_2 llvm35-3.5.0 
openjdk8-8.25.17_2             165MiB
llvm35-3.5.0                   99.8MiB

Врёшь. Он в полтора раза легче openjdk8, например:

А теперь можно вспомнить, что llvm - это в лучшем случае голая виртуальная машина (ещё и, вроде как, не умеющая в исполнение байткода, скомпилированного на другой аппаратной платформе), а с openjdk идёт и куча библиотек, вплоть до графического интерфейса.

Так и с llvm куча библиотек идёт, правда про другое. Непосредственно vm

% du -hs /usr/local/llvm35/bin /usr/local/llvm35/lib/libLLVM-3.5.so.0
4.1M    /usr/local/llvm35/bin
 27M    /usr/local/llvm35/lib/libLLVM-3.5.so.0

Чтобы тебя понимали - выражайся точнее. Если ты не имел ввиду, что джит - это не компиляция в машкод, то и не надо было этого утверждать.

Что значит «каждый раз»?

При каждом запуске, очевидно. Конечно, можешь и кешировать, как например в .net, но это уже несущественно.

Врёшь. Он в полтора раза легче openjdk8, например:

Во-первых, кто вообще говорил о размере? Сегодня этот фактор никого не интересует. Во-вторых - ты сравниваешь разные вещи.

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

При каждом запуске, очевидно. Конечно, можешь и кешировать, как например в .net, но это уже несущественно.

Нет, очевидно что один раз. Никакие костыли от .net тут не нужны.

Во-первых, кто вообще говорил о размере?

Ну начал не я. Теперь вот и слился не я.

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

Компилирует llc, ему для работы нужна только libLLVM.

Нет, очевидно что один раз.

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

Ну начал не я.

А кто начал? Речь была о том что ллвм - очень тяжелая штука, намного тяжелее той же жвм, ты зачемто приплел размеры пакетов??? Какое это вообще имеет отношение к разговору?

Компилирует llc, ему для работы нужна только libLLVM.

Нет.

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

Ты глуповат, похоже. Оттуда же, откуда берётся машкод поле компиляции бинарника из исходников.

А кто начал? Речь была о том что ллвм - очень тяжелая штука, намного тяжелее той же жвм, ты зачемто приплел размеры пакетов???

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

Нет.

Доказывай, чо.

Ты глуповат, похоже. Оттуда же, откуда берётся машкод поле компиляции бинарника из исходников.

После компиляции бинарника из исходников машкод ниоткуда не берется. Он просто уже есть. У тебя же машкода нет - есть файл с биткодом, который нужно скомпилировать. И пока ты его не скомпилируешь (при запуске) машкод ниоткуда не возьмется.

Ты разберись для начала, «сегодня этот фактор никого не интересует» или всё-таки ты готов до посинения доказывать какая она писец тяжёлая.

Еще раз - ллвм охуенно тяжелая, фактор размера никого не ебет. Что тебе тут неясно?

Доказывай, чо.

Может тебе еще доказать что бога нет?

Более того, есть llvm bytecode

Нету. Есть llvm bitcode, который непереносим между платформами, у которых есть хотя бы малейшие отличия в ABI