Почему Java сейчас наиболее востребованный ЯП?

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

Это не так.

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

Это да.

чем указатели на указатель на функцию возвращающую указатель.

Зачем так писать?

Значит, ни о какой востребованности не может идти речи. Вот на C# куча вакансий, есть и ASP.NET (в основном), и GUI на WPF, и мобилки, и геймдев с Unity.

Питон же.

wikipedia: Python[2] (МФА: [ˈpʌɪθ(ə)n]; в русском языке распространено название пито́н[3])

Можно и так и так. Я привык к англоязычной транскрипции.

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

Зависит от приложения. Если это какой-нибудь научный расчёт — согласен. Если это система обработки более-менее независимых друг от друга запросов, чаще всего просто возвращается ответ со статусом «Ошибка сервера». При этом само приложение продолжает работать и обрабатывать другие запросы.

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

Как раз таки исключения обычно делают достаточно безопасной работу после ошибки. Это в каком-нибудь C можно бояться — а проверят ли код возврата наверху? А может лучше молча сделать abort(), чем рисковать тем, что не проверят. В Java нужны специальные усилия, чтобы погасить исключение. Обычно оно нормально улетает наверх, где есть код, который может его поймать и предпринять какие то действия. Всякие файловые дескрипторы будут нормально закрыты, память будет нормально освобождена, транзакции будут нормально откачены. Да, может остаться какой-нибудь временный файл неудалённым, но это не очень страшно.

Кто тебе такое сказал? Сейчас JavaScript лезет изо всех дыр.

утечки памяти,

Можно подумать жабакод не течет. То-то в каждой второй жабо-программе в уголке указывается объем зохаванной памяти, и счетчик только увеличивается.

нет нативного GUI

Жабогуем можно только людей пугать.

потому что гладиолус

Не знаю.

Ещё один неосилятор удобнейшего руби.

Хм, может и мне на жабку перейти :) ? Я как-то потыкал ее палочкой, сделал пару фрикций, вроде юзабельно :)

Монти Пайтон же

Смотря какие у тебя задачи. Почти для любой задачи можно найти более подходящий язык. Но в то же время почти для любой задачи Java будет достаточно хорошим выбором.

Скриптовые язычки, вроде пхп и питона с руби - нет многопоточности

В пыхе давно решается через форк. Правда с php-fpm это проблематично :(

И чо? Я должен пойти гуглить какую-то хрень ради того, чтобы это доказать? Нет, спасибо. Евангелистом языка я себя не называл.

Имхо, если ты не старпер и действительно энтузиаст ЯП, то на такие заковыристые вопросы с удовольствием поищешь ответы, просто j4f. Но я не про тебя лично.

Задачи в данный момент и в перспективе на ближайшие годы - бекенд веба. Интересы - бекенд любых клиент-серверных приложений.

Если это система обработки более-менее независимых друг от друга запросов

То есть будет работать в простейших случаях. Например, из последнего, в той же apache kafka мы ловили None.get (это аналог обращения к null в scala), который приводил к остановке тредов-обработчиков сети. Да, приложение работает, но уже не может обслуживать клиентов. Почему оно возникает не знают даже разрабы кафки (тикет в jira, естественно, завели), как восстанавливаться, тоже х.з., так как там довольно нетривиальный код инициализации структур, поэтому просто обложили try/catch/Runtime.halt и стало всё зашибись — если возникнет, то упадет, переподнимется, опять будет обслуживать клиентов.

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

В идеальном мире так и будет, а в реальности потекут и дескрипторы и объекты и транзакции, если нет обработчиков в блоке finally.

То есть будет работать в простейших случаях. Например, из последнего, в той же apache kafka мы ловили None.get (это аналог обращения к null в scala), который приводил к остановке тредов-обработчиков сети. Да, приложение работает, но уже не может обслуживать клиентов. Почему оно возникает не знают даже разрабы кафки (тикет в jira, естественно, завели), как восстанавливаться, тоже х.з., так как там довольно нетривиальный код инициализации структур, поэтому просто обложили try/catch/Runtime.halt и стало всё зашибись — если возникнет, то упадет, переподнимется, опять будет обслуживать клиентов.

Ты распространяешь сложный случай на все случаи. В вашем случае видимо проще стопать. Но это знак того, что код написан не очень хорошо, а не того, что NPE каким то образом плохо влияет на работу приложения. Он по сути ничем не отличается от, например, NumberFormatException. Пользователь ввёл вместо числа букву — будем падать?

Мой поинт в том, что JRE никак не зависит от NPE. Вылетело — JRE продолжает работу в штатном режиме. То, что логика конкретного кода ломается при неожиданном исключении, это другой вопрос. JRE программу за программиста не напишет. Странно ей предъявлять какие-либо претензии.

Этим Java отличается, например, от C. Хотя конкретно разыменование null-а в C, наверное, тоже вполне безопасно, но можем ли мы этот факт узнать в обработчике сигнала? А если там было разыменовано что-то другое, тут уже точно лучше упасть. Кто его знает, что там происходит. Раскрутить стек мы не можем.

В идеальном мире так и будет, а в реальности потекут и дескрипторы и объекты и транзакции, если нет обработчиков в блоке finally.

Ну если дескрипторы обрабатываются не через finally, это просто плохо написанный код. В таком коде всё будет течь и так, могу по опыту сказать. Сталкивался, к сожалению. Проще в полночь всё перезапускать. Всё же идиоматичный код на Java обрабатывает ресурсы через finally (try-with-resources в Java 7+). То же с транзакциями.

Задачи в данный момент и в перспективе на ближайшие годы - бекенд веба. Интересы - бекенд любых клиент-серверных приложений.

Ну в таком случае Java неплохо подходит. Для веба в ней всё есть.

Ну если дескрипторы обрабатываются не через finally, это просто плохо написанный код.

Не обязательно. Это может быть асинхронный код, где освобождение ресурсов должно идти в другом месте. Типичный пример: код с использованием библиотеки akka. В случае с C++ нас спасают shared_ptr и деструкторы, а в случае с java надо обвешиваться счетчиками/метриками и мониторить каждый чих программы, иначе потом концов не найдешь.

Но веб-проектов на жабке мало,

Да и в питоне есть. Multiprocessing модуль, плюс внешние модули, написанные на гитхабе, битбакете.

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

Это идиотизм. Легионер все правильно сказал, нужно только понять, что все эти преимущества заключаются в одном (!) языке, а не «си умеет N, руби умеет M, а жаба нинужна».

Есть еще один язык, программы на котором работают вообще на всем, от восьмибитного контроллера в пылесосе (с сотней байт памяти), до суперкомпьютеров, для которых он является основным языком написания операционной системы. И этот язык в обоих своих ипостасьях язык тоже вроде бы один и тот же.

Про Memory Model не слышал?

В жава утечки памяти случаются намного реже и очевиднее.

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

Не знаю, может в приличном обществе о этом не принято говорить. Мне не нравятся вот эти штуки:

get..., get..., get..., set..., set...,set...,add...,add...,add..., ...

но ведь никто не заставляет их использовать, да?

Да. А что делать с уже написанными кем-то библиотеками и всякими рукоотрубателями, и ссаными тряпкаметателями?

Заставляют. Как с контейнерами работать будешь? :)

а операторов-то нет

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

Java — основной язык, используемый для разработки Android-приложений.

И бекэндов для серьезных сайтов.