Дело не в "ТЗ". Дело в том что Вы не поняли код, который принялись критиковать. Это говорит о том, что Вы понятия не имеете что такое монады, для чего они нужны и как работают.
Спасибо за ответ. Мне тоже непонятно что такое «ненастоящая монада». Или что имелось в виду.
Просто не раз уже подобные утверждения слышал, хотел узнать подробнее.
Можете подробнее объяснить почему ReaderT, например, не настоящая монада? Или на примере — что настоящая монада, а что нет.
Спрашиваю из интереса, не ради спора. Если можно — простое объяснение, пожалуйста.
Странные рассуждения. В монадах ничего сложного нет. Плюс позволяют они гораздо больше, чем Вы описываете. А именно — это отличный синтаксис для DSL. Мне, например, в Java очень нехватает чего-то вроде скаловского Slick, который устроен гораздо проще и понятнее чем тот-же hibernate. Так что где тут overengineering — я бы поспорил.
Понимание практического смысла давно есть — всякие вещи вроде корутин, теперь можно реализовывать не на уровне компилятора, а описывать непосредственно на языке программирования.
Ну это уже сто раз обсуждали. Та же самая причина, по которой Google тратит десятки миллионов на «допил» llvm, но не пользует ICC: даже существенная экономия на серерах недостаточна, чтобы «особый» toolchain поддерживать.
Не очень понимаю, как это связано с Java. Не все компании — гугл. Да и на практике всё в основном упирается в алгоритмы, а не в оптимизации. Посмотрите хотя-бы techempower. Java там быстрее C++.
Десятки гигабайт я видел только на C/C++, но простая логика говорит о том, что если кто-то понапишет столько кода, что результирующий бинарник, как у моих знакомых, не уместится в 2GB (есть у clang/gcc такое ограничение), то промежуточные данные легко могут десятки гигабайт занять. Собственно в момент LTO ведь уже все страшные конструкции языка обработаны, там уже только биткод остаётся к этому моменту…
Не представляю себе бинарник такого размера. Подозреваю что дело в кодогенерации(шаблоны)? Тогда это специфичный для плюсов случай.
Любой, если вы будете делать анализ порядка выполнения на большом модуле делать. Чудовищные объёмы памяти (в десятки гигабайт) возникают не просто от C++ — они от LTO над целыми программами возникают… то есть там, где можно больше всего выиграть.
О, у Вас есть опыт сборки программ(не С/С++), когда компиляторы заполняли бы десятки гигабайт оперативной памяти? Расскажите. Сколько в таком случае длится компиляция?
Для jvm это конечно смысла не имеет, т.к. там как раз локальный анализ и локальная компиляция.
Ничем, кроме здравого смысла. Но вообще у разработчиков JIT'а эта дилемма «сгенерировать хорогий код» vs «не слишком сильно замедлить собственно выполнение программы» — проходит красной нитью во всём, что они делают.
Просто рассуждения о кэше процессора _как правило_ ничем не подкреплены, не вижу смысла об этом говорить.
Поэтому jvm и не компилирует всё, а только нагруженные участки.
AOT PGO уже есть в GraalVM. Только, думаю, в реальных случаях это не особо быстрее JIT(для серверов). Плюс JVM и так достаточно быстрая для большинства кейсов(да и выбирают Java не столько за скорость), а упирается часто всё в БД.
А какой компилятор, кроме плюсовых требует такого огромного количества ресурсов?
Какой-нибудь ghc довольно много жрет, но там много уходит на статические проверки системы типов. Это можно разрулить во время компиляции в промежуточный код.
Плюс jvm далеко не всё компилирует.
Ваши рассуждения о кэше чем-нибудь подкреплены?
Если говорить о производительности — у подхода WASM преимущество для UI. Меньше время запуска, не надо ждать пока «прогреется» вм, оптимизации доступны сразу итд. Но вот вопрос какие отпимизации в итоге качественнее — в теории, именно рантайм оптимизации. Т.к. у среды исполнения больше информации чем у компилятора. Так что, думаю, на серверах java будет жить как обычно. Для остального может развиваться в сторону AOT-компиляции.
А вообще мне близка идея компиляции всего что только возможно, высокоуровневые языки с сильной системой типов. И wasm для такого выглядит неплохо.
В techempower и java с java в разы отличаются. Всё потому что разные модели многопоточности используются, разные алгоритмы. Думаю в среднем .NET core должен быть побыстрее.
Насколько я понимаю, байткод jvm(clr не знаю), позволяет делать много разных оптимизаций, но всё это делается в рантайме(в т.ч. динамический инлайнинг, размещение объектов на стеке, «обход» ненужных точек синхронизации).
WASI особо не изучал, думаю там больше расчёт на compile-time. Но в compile time нельзя понять, например, насколько часто используются методы что-бы их заинлайнить или какие синхронизированные методы используются только из одного потока, что-бы «выключить» синхронизацию.
Тогда откуда взялись ваши же слова про недопустимость падения?
Недопустимость означает лишь то, что такая ситуация — совсем не норма. И если ошибку можно обработать в штатном режиме — то лучше так и сделать.
Знаете — эту сказку про белого бычка пора кончать. Про это Джоел уже тоже писал. Если вы — «средней руки бизнес» и не можете себе позволить качественный софт, то вы берёте условного «дешёвого индуса», Java и получаете… что-то. Оно кривое, косое, неудобное и глючит — но оно дёшево стоило, а это для вас главное.
Ну во первых — у бизнеса просто может не быть денег и времени.
А если бизнес действительно может позволить себе качество — то он и нанимает хороших программистов. Даёт им хороший инструмент(Java), и спит спокойно, не думая о том что у него завтра будет глобальный ДОС из-за того, что С++ бог где-то обратился по битой ссылке(как бонус — потенциальная уязвимость к новым классам атак). А софт можно поддерживать и быстро менять под требования бизнеса.
И реальность в нашем мире — именно такая. Рыночек уже порешал, это и есть «очевидное». Веб серверами на java бизнес пользуется давно и повсеместно.
На самом деле меня во многом Java не устраивает, но это не относится к vm, gc, производительности и возможностям отладки.
И да — Java не только красноречивый стектрейс выдаст, а всю последовательность ошибок(caused by). Плюс можно отладочной инфы приложить — id сессии, активности итд.
А как у Вас это решается? Просто интересно стало, не для спора и не как аргумент.
Да. Если, вдруг, компьютер выдаст кому-то, как у Хайнлайна, «чек на 10 000 000 000 000 185,15 долларов-купонов» — то, во-первых, по этому чеку никто никому ничего не выдаст, а во-вторых — это будет немедленно поводом начать разбираться в том, что у нас тут в системе происходит.
Ваш тезис звучит как: лучше врезаться с разгону в столб, чем приехать не туда. Что-ж — бейтесь, Вам никто не мешает.
Во-первых с чего вы решили, что когда программа закрешится — там не будет стектрейса. Во-вторых — какая паника? Запрос пошлют три раза, после чего тому, кто его инициировал, покажут сообщение об ошибке и всё. Три упавших сервера как легли, так и поднимутся.
Т.е. у вас один пользователь только что 3 сервера положил, и неизвестно сколько данных повредил. А что если ошибка начала возникать с какой-то периодичностью у всех пользователей? Вот Вам и ответ — почему Java.
Это извините, у вас он будет терять деньги если вы всё завязали на один instance одного сервера и он, несмотря на все костыли, упадёт. У нас — об инциденте никто и не узнает, кроме тех, кому нужно будет код чинить.
Вы сами себе это придумали. У меня не один инстанс, и даже если бы был один я бы(бизнес, который меня нанял) деньги бы не терял.
Это почему вы так в этом уверены? Вы когда-нибудь читали о том, что где-то данные Gmail стали недоступны из-за того, что ему кабель в Орегоне перерезали? Нет? А почему нет? Подумайте над этим.
И если ваш ответ: «этого не произошло потому что их датацентры никто никогда не отключал»… то ответ неверный. Мы точно знаем, что это случалось — просто потому что это тоже тестируется.
У Вас какое-то странное представление о бизнесе. Конечно, первое что предпримет средней руки организация — начнёт скупать ЦОДы по всему миру и нанимать С++-богов, которые наклепают им профессиональный софт, который крешится и повреждает данные на каждый чих.
Дальше — беда: как известно в программировании есть только две сложные вещи: инвалидация кэша и наименование сущностей. Мы с первой проблемой не справились и продолжаем где-то держать ссылку на курсы валют, которые были загружены при первом образщении. А сервис обновления мастер-таблицу периодически в памяти обновляет и старые данные стирает.
Зачем держать множество ссылок, если можно ссылаться на один объект, и его модифицировать(или менять через прокси)?
Так вот в C++ в этом месте образуется «висячая ссылка», программа упадёт и мы её починим. А в Java — мы будет пересчитывать данные по курсу годичной давности, пока это аудит не заметит и нам штраф не выпишут…
С++ позволит Вам вычислить по прошлогоднему курсу, позапрошлогоднему, вообще любому курсу. Стало намного лучше?
Сегофолт будет, когда fortify обнаружит «битые» данные.
Мы читаем, какие битые данные?
Как раз невозможность корректно обработать ошибку наблюдается в вашей «ынтырпрайз системе» на Java. Вот тут:
Неожиданное завершение Java программы — недопустимо(речь о enterprise и серверах).
Никакой С++ вас от падения цода не спасёт.
Другое дело когда Ваша супер надёжая прога крешится и все в панике с дебагером в зубах начинают искать ошибку, а на Java в кибане появляется красноречивый стектрейс. И пока Вы ищите, бизнес теряет деньги.
Дальнейшие рассуждения(про железо) пропущу что-бы не разводить полемику(по моему мнению никакого отношения к реальности они не имеют).
Запустите на процессоре где-нибудь в 200-300MHz, потом говорите. Аккуратно написанный C++ код на таком «летает».
А зачем? У меня есть замечательный телефон, на котором прекрасно работают приложения.
А к чему это имеет отношение? Вы вообще когда-либо видели хоть от кого-нибудь задание «сделать так, чтобы программы выдала чёрт-знает-что, не важно что, главное чтобы не упала»?
Вы, похоже, сами с собой спорите. Объясните нормально задачу. Из того что я понял: есть таблица, в ней поменяли данные. Почему должна была поменяться ссылка мне непонятно. Возможно, таблица иммутабельная, тогда что значит «обновление», если ссылка не изменилась?
В любом случае — здесь Java максимум вернёт устаревшие данные. С++ же сокорее вернёт устаревшие, может вернуть вообще рандом. Да и сегфолда тут не будет.
Если у вас «enterprise» — это «нам нужно не дорого, а очень дорого», тогда да.
Что это значит? Такое поведение по дефолту на Java сервере.
Т.е. Вы считаете что невозможность корректно обработать ошибку — преимущество С++?
Здесь речь о поддержке одного конкретного эффекта — IO. Как быть, если нужно разграничить эффекты?
Дело не в "ТЗ". Дело в том что Вы не поняли код, который принялись критиковать. Это говорит о том, что Вы понятия не имеете что такое монады, для чего они нужны и как работают.
Статические методы это функции в пространстве имен класса. Такого понятия как статические функции не припомню.
Видимо, речь о статических методах?
А чем статические функции отличаются от обычных?
Просто не раз уже подобные утверждения слышал, хотел узнать подробнее.
Да, точно. Вопрос тогда — точно ли будет? И какая есть "не монада", скрывающаяся за личиной монады.
Может у Вас есть идеи?
Спрашиваю из интереса, не ради спора. Если можно — простое объяснение, пожалуйста.
Понимание практического смысла давно есть — всякие вещи вроде корутин, теперь можно реализовывать не на уровне компилятора, а описывать непосредственно на языке программирования.
Не представляю себе бинарник такого размера. Подозреваю что дело в кодогенерации(шаблоны)? Тогда это специфичный для плюсов случай.
Для jvm это конечно смысла не имеет, т.к. там как раз локальный анализ и локальная компиляция.
Просто рассуждения о кэше процессора _как правило_ ничем не подкреплены, не вижу смысла об этом говорить.
Поэтому jvm и не компилирует всё, а только нагруженные участки.
AOT PGO уже есть в GraalVM. Только, думаю, в реальных случаях это не особо быстрее JIT(для серверов). Плюс JVM и так достаточно быстрая для большинства кейсов(да и выбирают Java не столько за скорость), а упирается часто всё в БД.
А какой компилятор, кроме плюсовых требует такого огромного количества ресурсов?
Какой-нибудь ghc довольно много жрет, но там много уходит на статические проверки системы типов. Это можно разрулить во время компиляции в промежуточный код.
Плюс jvm далеко не всё компилирует.
Ваши рассуждения о кэше чем-нибудь подкреплены?
А вообще мне близка идея компиляции всего что только возможно, высокоуровневые языки с сильной системой типов. И wasm для такого выглядит неплохо.
Насколько я понимаю, байткод jvm(clr не знаю), позволяет делать много разных оптимизаций, но всё это делается в рантайме(в т.ч. динамический инлайнинг, размещение объектов на стеке, «обход» ненужных точек синхронизации).
WASI особо не изучал, думаю там больше расчёт на compile-time. Но в compile time нельзя понять, например, насколько часто используются методы что-бы их заинлайнить или какие синхронизированные методы используются только из одного потока, что-бы «выключить» синхронизацию.
Ну во первых — у бизнеса просто может не быть денег и времени.
А если бизнес действительно может позволить себе качество — то он и нанимает хороших программистов. Даёт им хороший инструмент(Java), и спит спокойно, не думая о том что у него завтра будет глобальный ДОС из-за того, что С++ бог где-то обратился по битой ссылке(как бонус — потенциальная уязвимость к новым классам атак). А софт можно поддерживать и быстро менять под требования бизнеса.
И реальность в нашем мире — именно такая. Рыночек уже порешал, это и есть «очевидное». Веб серверами на java бизнес пользуется давно и повсеместно.
На самом деле меня во многом Java не устраивает, но это не относится к vm, gc, производительности и возможностям отладки.
И да — Java не только красноречивый стектрейс выдаст, а всю последовательность ошибок(caused by). Плюс можно отладочной инфы приложить — id сессии, активности итд.
А как у Вас это решается? Просто интересно стало, не для спора и не как аргумент.
Т.е. у вас один пользователь только что 3 сервера положил, и неизвестно сколько данных повредил. А что если ошибка начала возникать с какой-то периодичностью у всех пользователей? Вот Вам и ответ — почему Java.
Вы сами себе это придумали. У меня не один инстанс, и даже если бы был один я бы(бизнес, который меня нанял) деньги бы не терял.
У Вас какое-то странное представление о бизнесе. Конечно, первое что предпримет средней руки организация — начнёт скупать ЦОДы по всему миру и нанимать С++-богов, которые наклепают им профессиональный софт, который крешится и повреждает данные на каждый чих.
Зачем держать множество ссылок, если можно ссылаться на один объект, и его модифицировать(или менять через прокси)?
С++ позволит Вам вычислить по прошлогоднему курсу, позапрошлогоднему, вообще любому курсу. Стало намного лучше?
Мы читаем, какие битые данные?
Никакой С++ вас от падения цода не спасёт.
Другое дело когда Ваша супер надёжая прога крешится и все в панике с дебагером в зубах начинают искать ошибку, а на Java в кибане появляется красноречивый стектрейс. И пока Вы ищите, бизнес теряет деньги.
Дальнейшие рассуждения(про железо) пропущу что-бы не разводить полемику(по моему мнению никакого отношения к реальности они не имеют).
Вы, похоже, сами с собой спорите. Объясните нормально задачу. Из того что я понял: есть таблица, в ней поменяли данные. Почему должна была поменяться ссылка мне непонятно. Возможно, таблица иммутабельная, тогда что значит «обновление», если ссылка не изменилась?
В любом случае — здесь Java максимум вернёт устаревшие данные. С++ же сокорее вернёт устаревшие, может вернуть вообще рандом. Да и сегфолда тут не будет.
Что это значит? Такое поведение по дефолту на Java сервере.
Т.е. Вы считаете что невозможность корректно обработать ошибку — преимущество С++?