Ты придуриваешься или правда такой? По-твоему буфер в 128 и 4096 байт одно и то же? Самое смешное, что тут даже голову особо включать не нужно было. Достаточно было загуглить и добавить BufferedStream.
Хорошо, если действительно представляешь, что ты измеряешь. Тогда ответь на такой простой вопрос: какой смысл в том чтобы сравнивать буферизированное чтение в Java версии с небуферизированным чтением в C# версии?
Ты можешь, конечно, мне не поверить, но при сравнении производительности действительно нужно нагружать мозг. Хотя бы для того чтобы понимать, что ты измеряешь то, что хотел, а не то что получилось. И что вся эта затея вообще имеет хоть какой-то
практический смысл.
У самого Microsoft, конечно же, такого желания не возникнет, т. к. не понятно как на этом можно заработать денег. Так что остается надеяться только на open source. Например, есть многобещающий проект github.com/AvaloniaUI/Avalonia
Да ладно! Я думаю подавляющее большинство этих расширений все равно на .net написано. Вряд ли в них много платформо зависимого кода. В конце концов на .net core (где надо портировать все библиотеки) они решились, а портировать visual studio не могут решиться уже столько лет. Так что тут дело точно не в расширениях.
«Я просто хочу сделать свою работу, а не ковыряться со всякими...»
Так в этом изначальный посыл и идея языка заключается, что С++ тоже хотели сделать более безопасным и удобным, чем С. Придумали кучу «полезняшек»: 4 типа кастов, шаблоны, множественное наследование и т. п. А в итоге получился огромный монстр для которого во многих проектах от большей части функциона просто отказываются конвенциями.
Вот так и выходит, что просто сделать свою работу на системном языке не получается…
Java тоже не такой уж прям «отличный язык» в своей среде. Иначе бы не появилось куча других языков java-заменителей типа scala, ceylon, kotlin и т. д. Которые тоже статически типизированные, тоже под jvm, но только лучше чем java.
«Я готов пожертвовать 100%-й безопасностью памяти в обмен на отсутствие лишней возни и оверхеда.»
Я надеюсь, что большинства программистов все же более прагматичный подход. Помимо safe-defaults хорошо бы иметь safe все остальное (на сколько это возможно), а в месте выбранного trade-off'а указать более явно какое решение принято, а в идеале еще и что послужило причиной такого выбора (но кто пишет коменты? правда?).
Вполне возможно, что вы хотите себя чувствовать джедаем и это просто не ваш путь язык, а другие хотят меньше задумываться о железе, а больше решать проблемы которые перед ними стоят, но при этом все-таки писать качественный стабильный софт. Если большую часть рутинной работы по проверке можно переложить на машины, почему бы не сделать это?
Х-М условия монтонности, конечности рекурсии и лайфтаймы тоже умеет выводить? Я имменно это «магией» называл.
Хотя вывод типов даже для приватных функций на уровне модуля, по-моему, перебор. Это действительно усложняет и замедляет понимание что происходит внутри функции.
Так и изменить саму схему тоже не проблема. А вот потом поддерживать ее использование в актуальном состоянии статическая система типов поможет, а динамическая нет. Почему? Просто потому что у нее нет этой информации.
В том то и дело, что написать код совсем не проблема (IDE с автокомплишеном, сниппетами и прочими плюшками очень в этом помогают). А вот разбираться в коде где у тебя «голые» вызовы функций без явного указания их ограничений — это геморой.
«А сейчас, есть у меня подозрения, что JavaScript в недалёком будущем производительностью не будет уступать C++»
А чем это лучше java'ого jit'a? Кроме того что java — это статически типизированный язык, а javascript — динамический и llv8 еще сложнее это все будет правильно выводить и делать какие-нибудь предположения для серьезной оптимизации.
Что-то мне не верится, что даже джавовые БД-шки будут в обозримом будущем конкурировать по производительности с С/С++-ными, а тем более javascript'овыми.
«Современный уровень этой технологии позволяет ограничится описанием типа модуля. Остальное можно вывести автоматически»
Вас не пугает то количество «магии», которое будет «под капотом» у этого компилятора? Тут я имею в виду даже не столько сложность самого компилятора или его время работы, а то что, если компилятор (или программист) сделает/напишет не так и конечная программа будет работать медленно или не правильно, то какому богу после этого молиться? Ведь надо будет всю эту компиляторную магию выполнить в голове, потому что вменяемую и достаточно быстро работающую IDE-шку для такого сложного языка вряд ли получится сделать.
«Но дальнейшее перепроектирование и переписывание алгоритмов управления ресурсами даются непросто. Да и потом, нормальный статический анализ кода может все эти эффекты просто вычислить.»
Но для того чтобы программа оставалась корректной логику ее работы все равно приходится переделывать и не немного, а очень сильно вне зависимости от того используете ли вы GC и/или статический анализатор.
Вы не верите в дальнейшее развитие Rust на этом поприще только из-за сложности разработки на нем?
По идее, Rust очень молодой язык программирования с новыми/революционными концепциями (по крайней мере, для mainstream'a). Мне кажется, со временем эти новые концепции должны вполне нормально осесть в головах у разработчик + появятся специализированные для Rust'a tool'ы для разработки. Это должно уменьшить порог входа и упрость понимание и разработку программ на Rust. Как дополнительный бонус, выполнение программы становится более детерминированным и язык провоцирует писать корректные и оптимальные в плане используемых ресурсов программы.
Как вы себе это представляете, когда оптимальный алгоритм GC зависит от решаемой задачи? В этом же и проблема, что универсального решения еще не нашли. Как только найдут, то, думаю, практически сразу появятся такие харварные решения.
«Помню дикую боль при разработке веб-морды на старой Java, когда для каждой долбаной кнопки нужно было создавать свой класс с единственным перегруженным методом онклик. А потом создавать экземпляр этого класса. Зачем?»
Это всего лишь вопрос синтаксического сахара для удобства разработки. Принципиальных проблем тут нет. Что касается именно Java, то это консервативный язык. Он долго перенимает инновации, поэтому к нему легко придираться в таких холиварных обсуждениях.
практический смысл.
Вместо него есть Option с гораздо более явной семмантикой, чем null.
Так в этом изначальный посыл и идея языка заключается, что С++ тоже хотели сделать более безопасным и удобным, чем С. Придумали кучу «полезняшек»: 4 типа кастов, шаблоны, множественное наследование и т. п. А в итоге получился огромный монстр для которого во многих проектах от большей части функциона просто отказываются конвенциями.
Вот так и выходит, что просто сделать свою работу на системном языке не получается…
Java тоже не такой уж прям «отличный язык» в своей среде. Иначе бы не появилось куча других языков java-заменителей типа scala, ceylon, kotlin и т. д. Которые тоже статически типизированные, тоже под jvm, но только лучше чем java.
Я надеюсь, что большинства программистов все же более прагматичный подход. Помимо safe-defaults хорошо бы иметь safe все остальное (на сколько это возможно), а в месте выбранного trade-off'а указать более явно какое решение принято, а в идеале еще и что послужило причиной такого выбора (но кто пишет коменты? правда?).
Вполне возможно, что вы хотите себя чувствовать джедаем и это просто не ваш
путьязык, а другие хотят меньше задумываться о железе, а больше решать проблемы которые перед ними стоят, но при этом все-таки писать качественный стабильный софт. Если большую часть рутинной работы по проверке можно переложить на машины, почему бы не сделать это?Хотя вывод типов даже для приватных функций на уровне модуля, по-моему, перебор. Это действительно усложняет и замедляет понимание что происходит внутри функции.
А чем это лучше java'ого jit'a? Кроме того что java — это статически типизированный язык, а javascript — динамический и llv8 еще сложнее это все будет правильно выводить и делать какие-нибудь предположения для серьезной оптимизации.
Что-то мне не верится, что даже джавовые БД-шки будут в обозримом будущем конкурировать по производительности с С/С++-ными, а тем более javascript'овыми.
Вас не пугает то количество «магии», которое будет «под капотом» у этого компилятора? Тут я имею в виду даже не столько сложность самого компилятора или его время работы, а то что, если компилятор (или программист) сделает/напишет не так и конечная программа будет работать медленно или не правильно, то какому богу после этого молиться? Ведь надо будет всю эту компиляторную магию выполнить в голове, потому что вменяемую и достаточно быстро работающую IDE-шку для такого сложного языка вряд ли получится сделать.
Но для того чтобы программа оставалась корректной логику ее работы все равно приходится переделывать и не немного, а очень сильно вне зависимости от того используете ли вы GC и/или статический анализатор.
Вы не верите в дальнейшее развитие Rust на этом поприще только из-за сложности разработки на нем?
По идее, Rust очень молодой язык программирования с новыми/революционными концепциями (по крайней мере, для mainstream'a). Мне кажется, со временем эти новые концепции должны вполне нормально осесть в головах у разработчик + появятся специализированные для Rust'a tool'ы для разработки. Это должно уменьшить порог входа и упрость понимание и разработку программ на Rust. Как дополнительный бонус, выполнение программы становится более детерминированным и язык провоцирует писать корректные и оптимальные в плане используемых ресурсов программы.
Это всего лишь вопрос синтаксического сахара для удобства разработки. Принципиальных проблем тут нет. Что касается именно Java, то это консервативный язык. Он долго перенимает инновации, поэтому к нему легко придираться в таких холиварных обсуждениях.