И в Java и в C# есть компиляторы в машинный код, так что это языки могут быть и компилируемыми и интерпретируемыми (и вообще, эти языки — в первую очередь спецификации и могут быть реализованы хоть на механических «компах», см. компьютеры из костяшек домино).
Ну смотрите, вы делаете сверхбыстрый веб Фреймворк, при этом:
1. Используете базу данных, которая физически не может вытянуть большое количество пользователей и данных,
2. Каждый раз заново парсите markdown, вместо хранения скомпилированного варианта,
3. Имеете непонятные баги перфоманса, когда страница сильно тормозит,
4. Не кешируете html страницы в памяти или диске для ускорения работы,
У меня был сайт с миллионом просмотров в день на старом медленном PHP и хостинге подобном вашему и он не падал, только потому что там большинство запросов кэшировалось и php просто большинству пользователей отдавал готовый html, а запросы на изменения писались сначала в файл, а потом сразу скидывались из файла в таблицу.
Вы же выигрываете копейки на скорости кода проигрываете тысячи на алгоритмах и архитектуре.
Проблема скорее в прожорливости фреймворка, чем в JVM.
Значит надо не использовать такие фреймворки. Tomcat или Jetty (это веб серверы для Java) требуют около 12Mb памяти и диска, примерно столько же сколько Апач, при этом дают возможность использовать сервлеты и всякие jsp. Для данной задачи этого с головой хватит.
а в Яве из-за широкого использования рефлексии считаю подобную перспективу нереальной
А при чем тут рефлексия и машинный код? Рефлексия это возможность управлять полями классов напрямую, другими словами запрос дай значения поля X, это не требует байт кода, только сохранения метаданных и возможность прямой ссылки на поле или метод.
Вы может быть спутали рефлексию и кодогенерацию в рантайме (динамические загрузчики классов и т.п.), но это широко используется редко и в принципе компилятор в машинный код может и динамически классы грузить. Нет тут проблем.
.NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что
У С# и Java есть возможность компиляции в машинный код напрямую, учитывая оптимизации компиляторов и итераторов тут все неоднозначно. Может быть ситуация автоматически оптимизированный код будет более оптимальным.
Во-первых, на одном конкретном тесте, который не без недостатков.
Во-вторых, лучше писать код как можно быстрее и качественнее, так чтобы он укладывался в нужные рамки производительности. Сама по себе абстрактная производительность никому не нужна.
А «код, который будет работать быстро всегда» это какой-нибудь ассемблер с диким количеством ручных оптимизация под конкретное железо. Да он будет работать быстрее всего в том числе Си, делают так? Крайне редко. Тут все упирается в стоимость разработки и сэкономленное железо, если железо дешевле работу программиста — смысла в быстром коде нет никакого.
В-третьих, если производительность кода на производительность системы не влияет — нужен ли быстрый код?
Ваша Java на таком хостинге, да и на очень многих подобных, даже не запустится
Запустится, Java 8 требует 128 МБ памяти и 126 МБ на диске.
Надо сравнивать технологии с одинаковым стеком
Есть заявление, что на ассемблер все делается легко и просто. И мол зачем вообще нужны высокоуровневые языки. А получается что все делается относительно легко, только если подключать библиотеки из других языков, а никто и никогда не будет делать полноценный стэк подобных технологий на ассемблере (ибо их придется выкинуть при каждой смене архитектуры железа).
Ну да, Java обгонит по производительности Си если подключить библиотеку на ассемблере и делать всю критическую по производительности работу в ней. Только так нечестно сравнивать производительность и нечестно сравнивать скорость разработки ассемблере, если 99% функционала на самом деле будут выполняться на высокоуровневом языке.
Потому что теряется всякий смысл использования ассемблера. Ну подключите вы библиотеку на Java для работы с Excel/Word, базу данных на C++, шаблонизатор на PHP и что останется у вас от ассемблера? Только код не переносимый между процессорами и как бы сайт на ассемблере. Можно вообще весь код написать на C или Java, а потом одним вызовом подключить «библиотеку».
Хорошо, уточню: без хаков с чужими библиотеками, написанными на высокоуровневых языках. На Java можно обойтись библиотеками, созданными только на Java, а на ассемблере?
В целом, как забивание микроскопом гвоздей разработка забавная, но на любом языке (хоть Java) можно сделать лучше, быстрее и даже производительнее.
Производительнее в том плане что используя многопоточность, нормальные базы данных, кэширование получиться отклик страницы намного быстрее чем вы сможете достичь на ассемблере Так как скорость кода вовсе не означает скорости ответа.
я тоже за два дня могу чего нибудь подобное написать — например блог или cms.
Хорошо, а за сколько вы напишите простой сайт онлайн банкинга с транзакциями и необходимой надежностью?
За сколько напишите интеграцию по Rest и Soup с другими сервисами, прикрутите к вашему форуму Ajax, работу с json и xml?
Загрузку и выгрузку в Excel/Word?
Все это грязно и с багами тоже делается на Java за 2 дня (все вместе). А у вас за сколько? Особенно без хаков с чужими библиотеками.
А без веб Фреймуърков?
А это бессмысленно предложение, серлеты, JSP, orm это официальная часть Java технологии, её вам предоставит любой веб.сервер на Java, это равносильно сказать, за сколько вы сделаете свой сайт без вебсервера.Так или иначе, веб фреймворк, хотя бы на уровне серлета (то есть генератора HTML из текста, на Java будет).
На Java, с использованием веб Фреймворков, ORM и т.п., подобный функционал грязно и с багами можно сделать за два дня (за день если очень спешить).
Вылизать все и выдать работающий продукт, то есть работающий на любой базе данных, с сотнями и тысячами unit, интеграционных, e2e и перфоманс тестов, который можно продавать за реальные деньги — может быть будет сравнимо по времени с вашей разработкой, только это совсем другой класс продуктов чем ваш форум. Уж поверьте, ваш форум находится тоже в категории «грязно и с багами», просто потому что его оттестировать по-настоящему долго и дорого.
Только PHP, насколько я знаю, позволяет инлайнить код прямо в HTML, остальным языкам (React не рассматриваем) нужны шаблонизаторы.
Java тоже может, либо в серлетах генерить HTML просто как текст, либо инлайнить код прямо в HTML это JSP технология. Но в большинстве случаев оно не несет особого смысла, так как по сравнению с любым запросом в БД шаблонизатор практически не требует времени и ресурсов.
И ребята которые пилят GCC могут похвастаться подобными знаниями и ровностью рук. То есть GCC будет генерить вам более эффективный код нежели вы напишите руками. Вывод, если мы возьмем подавляющее большинство разработчиков то вариант на Си будет быстрее.
Но это может быть справедливо и дальше: те кто пилит С++/Rust/Java/C# могут похвастаться подобными знаниями и ровностью рук, а значит их компиляторы могут генерить вам более эффективный код нежели вы напишите руками сами на С (а ведь на С очень многое делается руками).
Проблема в том что на кривые руки на любом более низкоуровневом языке могут сделать код хуже чем сделает компилятор на более высокоуровневом и С тут не исключение. Как только все уходит в высокие материи вроде многопоточного программирования, работы с веб протоколами надо иметь очень прямые руки чтобы написать руками тоже что уже есть из коробки в других языках.
Поэтому вывод неверен: без прямых рук и ассемблер и С могут быть медленнее прочих языков.
А по-моему все доходчиво и понятно. Это же не мануал о школьниках и рассказ о собственном проекте. Все равно вряд ли кто-то из читателей пойдет делать управление для карьерных грузовиков, «школьникам» лучше такое не повторять.
Автор, спасибо, очень интересно, хоть я из мира облаков, big data и high load, но кое-что полезное для проектирование «больших» систем я подчерпнул. Жду продолжения.
почему в вашем представлении «настоящие» программисты занимаются лишь облаками, big data, high load
Шутка юмора же (он же сарказм).
Действительно программисты enterprise систем иногда свысока смотрят на тех кто программирует встроенную технику (мол они больше электронщики и вообще что там программировать-то), а тут показано насколько важна такое программирование, ибо цена ошибки — катастрофа с человеческими жертвами.
По скорости работы… ассемблер. По определению быстрее него и прямых рук ничего быть не может.
По скорости разработки… точно не Си.
P.S. Си имеет свои область там где ассемблер слишком долго, а более высокоуровневый язык (даже С++) слишком медленно, но не стоит делать из него серебряную пулю или золотой молоток. Тем более что всякие Rust'ы, D, Go и т.п. переодически пытаются откусить от пирога C/C++.
В Java ни в одной области нет одного общеизвестного решения, десятки вебфреймворков, десятки библиотек работы с JSON и т.д. И это хорошо, так как у каждого проекта свои задачи и цели. Есть огромное количество различных решений работы с БД от JPA и hibernate до jOOQ и Spring's JdbcTemplate. Писать свои велосипеды явно не стоит.
1. Если тесты настроены правильно, то намного лучше если упадет Exception в тестах, чем вдруг исчезнет значения полей в продакшене. Намного логичнее не съедать ошибки, а сделать unit тесты базы, которые при неверном типе колонки просто не дадут собрать билд. Естественно, unit тесты должны покрывать все сущности (например, банально обходит все DAO классы рефликсией и проверять что ни один метод не упадет на тестовой схеме).
2. Exception дорогое удовольствие по производительности, почему не использовать getObject(int columnIndex), а потом уже в рантайме не определять какой тип вы получили? Зачем обязательно все делать через игнорирование SQLException?
На самом деле, проблема скорее в том что многие кто называется 1С программистами, на самом языке почти не работают, а по сути просто настраивают конфигурацию самой программы 1С.
И SQL это язык запросов, а не программирования, уж если на то пошло.
Это вопрос терминологии. SQL — тьюринг полный, а значит он не менее ЯП, чем, скажем, Brainfuck. В вики SQL указывается как функциональный узкоспецилизированный ЯП, в принципе языки запросов и языки программирование это не исключающие друг друга множества. А всякие расширения, типа PL-SQL или Transact-SQL тем более могут считаться ЯП.
1. Используете базу данных, которая физически не может вытянуть большое количество пользователей и данных,
2. Каждый раз заново парсите markdown, вместо хранения скомпилированного варианта,
3. Имеете непонятные баги перфоманса, когда страница сильно тормозит,
4. Не кешируете html страницы в памяти или диске для ускорения работы,
У меня был сайт с миллионом просмотров в день на старом медленном PHP и хостинге подобном вашему и он не падал, только потому что там большинство запросов кэшировалось и php просто большинству пользователей отдавал готовый html, а запросы на изменения писались сначала в файл, а потом сразу скидывались из файла в таблицу.
Вы же выигрываете копейки на скорости кода проигрываете тысячи на алгоритмах и архитектуре.
Значит надо не использовать такие фреймворки. Tomcat или Jetty (это веб серверы для Java) требуют около 12Mb памяти и диска, примерно столько же сколько Апач, при этом дают возможность использовать сервлеты и всякие jsp. Для данной задачи этого с головой хватит.
А при чем тут рефлексия и машинный код? Рефлексия это возможность управлять полями классов напрямую, другими словами запрос дай значения поля X, это не требует байт кода, только сохранения метаданных и возможность прямой ссылки на поле или метод.
Вы может быть спутали рефлексию и кодогенерацию в рантайме (динамические загрузчики классов и т.п.), но это широко используется редко и в принципе компилятор в машинный код может и динамически классы грузить. Нет тут проблем.
Да на здоровье:
1. Native Compilation Tools
2. Excelsior JET
3. JWrapper
В Java это вполне коммерческие продукты за которые платят хорошие деньги.
У С# и Java есть возможность компиляции в машинный код напрямую, учитывая оптимизации компиляторов и итераторов тут все неоднозначно. Может быть ситуация автоматически оптимизированный код будет более оптимальным.
Во-вторых, лучше писать код как можно быстрее и качественнее, так чтобы он укладывался в нужные рамки производительности. Сама по себе абстрактная производительность никому не нужна.
А «код, который будет работать быстро всегда» это какой-нибудь ассемблер с диким количеством ручных оптимизация под конкретное железо. Да он будет работать быстрее всего в том числе Си, делают так? Крайне редко. Тут все упирается в стоимость разработки и сэкономленное железо, если железо дешевле работу программиста — смысла в быстром коде нет никакого.
В-третьих, если производительность кода на производительность системы не влияет — нужен ли быстрый код?
Запустится, Java 8 требует 128 МБ памяти и 126 МБ на диске.
Есть заявление, что на ассемблер все делается легко и просто. И мол зачем вообще нужны высокоуровневые языки. А получается что все делается относительно легко, только если подключать библиотеки из других языков, а никто и никогда не будет делать полноценный стэк подобных технологий на ассемблере (ибо их придется выкинуть при каждой смене архитектуры железа).
Ну да, Java обгонит по производительности Си если подключить библиотеку на ассемблере и делать всю критическую по производительности работу в ней. Только так нечестно сравнивать производительность и нечестно сравнивать скорость разработки ассемблере, если 99% функционала на самом деле будут выполняться на высокоуровневом языке.
Хорошо, уточню: без хаков с чужими библиотеками, написанными на высокоуровневых языках. На Java можно обойтись библиотеками, созданными только на Java, а на ассемблере?
В целом, как забивание микроскопом гвоздей разработка забавная, но на любом языке (хоть Java) можно сделать лучше, быстрее и даже производительнее.
Производительнее в том плане что используя многопоточность, нормальные базы данных, кэширование получиться отклик страницы намного быстрее чем вы сможете достичь на ассемблере Так как скорость кода вовсе не означает скорости ответа.
Хорошо, а за сколько вы напишите простой сайт онлайн банкинга с транзакциями и необходимой надежностью?
За сколько напишите интеграцию по Rest и Soup с другими сервисами, прикрутите к вашему форуму Ajax, работу с json и xml?
Загрузку и выгрузку в Excel/Word?
Все это грязно и с багами тоже делается на Java за 2 дня (все вместе). А у вас за сколько? Особенно без хаков с чужими библиотеками.
А это бессмысленно предложение, серлеты, JSP, orm это официальная часть Java технологии, её вам предоставит любой веб.сервер на Java, это равносильно сказать, за сколько вы сделаете свой сайт без вебсервера.Так или иначе, веб фреймворк, хотя бы на уровне серлета (то есть генератора HTML из текста, на Java будет).
Вылизать все и выдать работающий продукт, то есть работающий на любой базе данных, с сотнями и тысячами unit, интеграционных, e2e и перфоманс тестов, который можно продавать за реальные деньги — может быть будет сравнимо по времени с вашей разработкой, только это совсем другой класс продуктов чем ваш форум. Уж поверьте, ваш форум находится тоже в категории «грязно и с багами», просто потому что его оттестировать по-настоящему долго и дорого.
Java тоже может, либо в серлетах генерить HTML просто как текст, либо инлайнить код прямо в HTML это JSP технология. Но в большинстве случаев оно не несет особого смысла, так как по сравнению с любым запросом в БД шаблонизатор практически не требует времени и ресурсов.
Но это может быть справедливо и дальше: те кто пилит С++/Rust/Java/C# могут похвастаться подобными знаниями и ровностью рук, а значит их компиляторы могут генерить вам более эффективный код нежели вы напишите руками сами на С (а ведь на С очень многое делается руками).
Проблема в том что на кривые руки на любом более низкоуровневом языке могут сделать код хуже чем сделает компилятор на более высокоуровневом и С тут не исключение. Как только все уходит в высокие материи вроде многопоточного программирования, работы с веб протоколами надо иметь очень прямые руки чтобы написать руками тоже что уже есть из коробки в других языках.
Поэтому вывод неверен: без прямых рук и ассемблер и С могут быть медленнее прочих языков.
Автор, спасибо, очень интересно, хоть я из мира облаков, big data и high load, но кое-что полезное для проектирование «больших» систем я подчерпнул. Жду продолжения.
Шутка юмора же (он же сарказм).
Действительно программисты enterprise систем иногда свысока смотрят на тех кто программирует встроенную технику (мол они больше электронщики и вообще что там программировать-то), а тут показано насколько важна такое программирование, ибо цена ошибки — катастрофа с человеческими жертвами.
По скорости работы… ассемблер. По определению быстрее него и прямых рук ничего быть не может.
По скорости разработки… точно не Си.
P.S. Си имеет свои область там где ассемблер слишком долго, а более высокоуровневый язык (даже С++) слишком медленно, но не стоит делать из него серебряную пулю или золотой молоток. Тем более что всякие Rust'ы, D, Go и т.п. переодически пытаются откусить от пирога C/C++.
2. Exception дорогое удовольствие по производительности, почему не использовать getObject(int columnIndex), а потом уже в рантайме не определять какой тип вы получили? Зачем обязательно все делать через игнорирование SQLException?
Есть, есть. Разве кто-то с этим спорил? А вот вакансий XML-Developer или JSON-Developer скорее всего нет или их очень мало (ИМХО)
Это вопрос терминологии. SQL — тьюринг полный, а значит он не менее ЯП, чем, скажем, Brainfuck. В вики SQL указывается как функциональный узкоспецилизированный ЯП, в принципе языки запросов и языки программирование это не исключающие друг друга множества. А всякие расширения, типа PL-SQL или Transact-SQL тем более могут считаться ЯП.