.NET / JVM vs Native

Разумеется, native быстрее, а если руки не кривые то ещё и безопаснее.

На современных Core iN, да даже на Core 2 все работает быстро

Лучше для кого? Заказчика, пользователя, программиста, инвестора?

пользователя и программиста

Нативный софт хуже во всех отношениях (кроме редких случаев, когда нужна производительность, но современные JIT-компиляторы камня на камне не оставляют от поделий типа gcc).

А ещё на «нативных» языках нельзя работать со строками. Доказательство: Шок от С. Как склеивать строки?

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

Пользователю, для маленьких программ, лучше native. Для больших монстров типа ms/libre/open office, firefox, visual studio, idea - становится довольно пофиг.

современные тетрисы тормозят даже на Core i7, а на Core 2 вообще слайдшоу

справедливофикс

Как раз-таки для маленьких программ можно использовать что-нибудь питонообразное.

А для больших проектов (ИМХО, естественно) лучше использовать композит:

- перевариваем много данных - C++

- много оперативы и хорошие процы на клиентах - что-то на VM

- мало оперативы и плохие процы на клиентах - опять же C++ с каким-нибудь графическим фреймворком или вообще Web

А хорошие библиотеки и для C++ есть: Qt, GTK, wxWidgets, и что-там виндовое еще есть.

А ещё на «нативных» языках нельзя работать со строками

Толсто

JVM код можно компилировать в нативный

для чего?

Писать на том, на чём принято писать софт под твою платформу.

Windows, Windows Phone - C#.

Linux - C&Gtk или C++&Qt.

OS X, iOS - Objective C.

Android - Java.

GUI писать на Java не стоит изза проблем взаимодействия с Native Libraries которое изза особенностей рализации ведется через JNI.

.Net не имеет такой проблемы, может вызывать Linux/Windows библиотеки напрямую и при желании компилируется в двоичный код CPU на котром собираетесь исполнять.

Если не GUI то без разницы, но Java не умеет разделять(share) библиотеки в памяти, т.е. будет жрать больше памяти с бругой стороны JVM при работе на сервере пожалуй несколько быстрее, хотя и значительно медленнее стартует, за счет лучшей JIT оптимизации.

Безопасность в первую очередь зависит от вас и ваших клиентов.
Хотя Java в последние годы прославилась дырками и превзошла все остальные способы как средство для расспространения малвари, но следуя рекомедациям по безопастности этого можно избежать. Я к примеру ни разу никакую заразу через Java не подхватил, а коллегу 2 раза поимели.

IMHO программировать проще и приятнее на C#

Что же лучше - нативный софт, или софт во всяких JVM и подобном, как на Android?

Вопрос несколько некорректный, так как на Андроид значительное количество Native code особенно игр.

А лучше - тот софт который лучше работает

о, вот и определился - буду писать на шарпе под .net 4.5 под windows 8.1 на visualstudio community
а скоро .net под linux будет?

На чем лучше писать прикладной софт?

На том, за что больше денег платят.

Это Вы где-нибудь в банковском секторе расскажите.

Надеюсь, Вашу шутку юмора оценят.

А пока готовьтесь к ЕГЭ.

Тема: «Постановка запятой при встрече союзов».

http://www.gramota.ru/class/coach/punct/45_188

Уже есть моно http://www.mono-project.com
Несколько медленнее .Net но в целом вполне пригоден для работы и активно перетаскивается полезный код из МС .Net в mono

Если о .Net от MC то в 2015 вместе с .Net Core 5

Не скажу за яву, но россказни про сопоставимую производительность нативных приложений и .net это миф. Во всех тестах, которые обычно приводят в качестве «доказательства» машина «разогрета». В реальности .net приложения люто тормозят на старте и при работе из-за фреймворка как такового. Венда так и норовить слить его части в подкачку при любом удобном случае. Легко можно наблюдать фризы при работе и долгий старт.

Так что .net тебе подойдёт только если

• твоё приложение будет единственным запущенным приложением;
• на тачке море памяти, а своп отключен вообще;
• твоё приложение использует не особо много сторонних библиотек и мало само по себе;
• на самом деле производительность не критична (всякого рода пасьянсы).

GUI писать на Java не стоит изза проблем взаимодействия с Native Libraries которое изза особенностей рализации ведется через JNI

Вы это в Eclipse (SWT) сообществе расскажите.

Или в Oracle или JetBrains (Swing).

Вы это в Eclipse (SWT) сообществе расскажите.

А что им рассказать?
Вы хотите сказать они без JNI работают?

Или в Oracle или JetBrains (Swing).

Вот именно изза проблем с JNI и приходится GUI рисаовать на Java ещё более раздувая потребляемую память и замедляя запуск приложения.

Не скажу за яву, но россказни про сопоставимую производительность нативных приложений и .net это миф.

Я работаю и с Java и с C/C++ и с .Net/C#
могу вас заверить, что росказни о сопоставимой производительности не миф.

Да, сопоставимая не значит одинаковая.
Значит в пределах достаточных для разумного сопоставления.

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

Во всех тестах, которые обычно приводят в качестве «доказательства» машина «разогрета».

Откомпилируйте в двоичный код.
mono AOT уже лет 5-7 работает без проблем.
.Net Native на днях выйдет.

Так что .net тебе подойдёт только если
твоё приложение будет единственным запущенным приложением;
на тачке море памяти, а своп отключен вообще;
твоё приложение использует не особо много сторонних библиотек и мало само по себе;
на самом деле производительность не критична (всякого рода пасьянсы).

Этот бред вообще не поддаётся разумному обсуждению.

Этот бред вообще не поддаётся разумному обсуждению.

Я тоже считаю, что такое поведение это бред. Однако же это печальный факт.

Я тоже считаю, что такое поведение это бред. Однако же это печальный факт.

Бред который вы написали - плод вашего воображения.
Давайте за пол часика напишет проект по анализу ~100mb xml файла и сравним на чем оно работает быстрее, мой C# на или ваш и сравним.

Опять таки не забывайте, что количество людей, которые могут освоить и НОРМПЛЬНО писать на С++ на порядок меньше чем тех кому и на Java трудно.
Java собственно и придумали чтобы утилизировать массу не способную нормально писать на С++, что заметно по огромному количеству глюков в ПО 15 лет назад и кчественному улучшению надёжности ПО после того как их перевели на Java.

1. Речь шла о прикладном софте. Я акцентировал внимание на падении производительности на старте и из-за свопа. Как раз на всяких калькуляторах и т.п. разница видна невооруженным глазом.

2. При чём тут ява? Я про неё ничего не писал.

все, жду кор

GUI писать на Java не стоит изза проблем взаимодействия с Native Libraries которое изза особенностей рализации ведется через JNI.

Мсье не в курсе про JNA? Никаких мучений с прослойками, обертками итд. Всех дел - написать на яве один интерфейс.

Хотя Java в последние годы прославилась дырками и превзошла все остальные способы как средство для расспространения малвари, но следуя рекомедациям по безопастности этого можно избежать.

Угу, например можно не запускать байткод из непроверенных источников. Что собственно и происходит в 99% проектах на ней. Наружу торчит только http и фиг чего такого с ним сделаешь.

1. Речь шла о прикладном софте.

А я о каком?
так будем сравнивать или нет?

Я акцентировал внимание на падении производительности на старте и из-за свопа.

У меня 16Гб памяти, запущен Eclipse, VS, Oracle sqldeveloper, 3 юраузера, скайп и много чего другого.
Свопа не запечал ни разу, даже если он был.

падение производительности на старте изза свопа - плод вашей фантазии или ковыряния в настройках ОС.

Как раз на всяких калькуляторах и т.п. разница видна невооруженным глазом.

Т.е. вы сделали меньше рассчетов за час на калькуляторе написанном на .Net?
На сколько меньше?

2. При чём тут ява? Я про неё ничего не писал.

Java при том, что разговариваем, на лучше начать писать и продолжать в будущем, в котором придётся утилизоровать программистов для которых даже Java слишком сложный ЯП.

При этом C# является компромиссом между простотой и гибкостью и позволяет писать программы значительно быстрее, кторые работают несколько медленнее, чем на C++ при этом оставляя возможность вынести вручную оптимизированный код во внешнюю библиотеку и использовать без потерь произвоительности, характерных для Java при вызове native library.

У меня 16Гб памяти

Так и порешим: минимальные требования к .net приложениям 16Гб оперативки.

Т.е. вы сделали меньше рассчетов за час на калькуляторе написанном на .Net?
На сколько меньше?

Тормоза интерфейса легко обнаруживаются при малейшем простое приложения. Извольте открыть SQL management studio и клацнуть правой кнопкой по дереву. Сраная менюшка вылазит с заметной задержкой. Причём непостоянной задержкой.

Мсье не в курсе про JNA? Никаких мучений с прослойками, обертками итд. Всех дел - написать на яве один интерфейс.

Ещё раз повторяю для тех, до кого не доходит с первого раза:
- .Net позволяет вызывать Native Library без всяких обёрток вроде JNA

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

Наружу торчит только http и фиг чего такого с ним сделаешь.

Мы говорим о десктопах.
Вы, надеюсь не возражаете, что Java сейчас является главным средством для расспространения малвари?

Так и порешим: минимальные требования к .net приложениям 16Гб оперативки.

Вы для себя можете решать что угодно, но это не сделает это ваше решение скольнибудь разумным или верным

Тормоза интерфейса легко обнаруживаются при малейшем простое приложения.

Необоснованные глупости.

Извольте открыть SQL management studio и клацнуть правой кнопкой по дереву.

Изволил

Сраная менюшка вылазит с заметной задержкой. Причём непостоянной задержкой.

1. Враньё.
2. SQL Management Studio написан на С++

Тьфу ты. Да ты школотролль. Чего это я раньше не заметил.

SQL Management Studio написан на С++

Твой уровень знаний .net сразу и вылез. А зачем тогда на сайте микрософта пишут

Перед установкой среды SSMSE необходимо установить платформу .NET Framework 2.0

Всё с тобой ясно.

Ещё раз повторяю для тех, до кого не доходит с первого раза:
- .Net позволяет вызывать Native Library без всяких обёрток вроде JNA

Он магией что-ли вызывает эти нативные библиотеки, что оно происходит быстрее? Разница только в том, что в .net-е удобный механизм вызова встроен в стандартную библиотеку, а в яве приходится подцеплять еще одну мелкую зависимость к проекту.

Вы, надеюсь не возражаете, что Java сейчас является главным средством для расспространения малвари?

Возражаю. Я ее на десктопах установленной, и уж тем более включенной в браузере не видел ни у одного человека, кроме тех, кто на ней пишет софт.

Он магией что-ли вызывает эти нативные библиотеки, что оно происходит быстрее?

Для программиста который кроме Java ничего не знает прямой вызов Native Library может показаться магией :)

Разница только в том, что в .net-е удобный механизм вызова встроен в стандартную библиотеку, а в яве приходится подцеплять еще одну мелкую зависимость к проекту.

Для особо тугодумов, посторю в 3й раз:
- .Net может вызывать Native library без всяких обёрток и прослоек вроде JNI, JNA встроенных в стандартную библиотеку или внешних

Возражаю.

Желательно аргументировано.
Я на ЛОРе постил новость о том, что Java превзошла все остальные способы расспространения малвари вместе взятые, можете поискать.

Если у вас есть другие аналитические статьи, пожалуйста приведите.

Перед установкой среды SSMSE необходимо установить платформу .NET Framework 2.0

Очевидно, потому, что в SQL Server можно использовать .Net и для отладки он вам понадобится.

Даже Visual Studio до псоледнего времени было pure C++

Даже Visual Studio до псоледнего времени было pure C++

Ядро VS и сейчас почти что pure C++, хотя морда по большей части C# + WPF.

- .Net может вызывать Native library без всяких обёрток и прослоек вроде JNI, JNA встроенных в стандартную библиотеку или внешних

Чувак, не тупи пожалуйста, очень тебя прошу. Вызов нативной библиотеки - это пихнуть параметры/указатели в стек и сделать jump по нужному адресу, если не особо вдаваться в подробности. Кто это делает - встроенная или стороняя библиотека - глубоко похрену.

Желательно аргументировано.

Я тебе привел аргумент. Ява сейчас уже практически ни у кого не стоит на десктопе.

Если под Windows - то .NET однозначно.

В Linux сложилось так что десктоп приложения часто пишут например на Python, но с активным использованием каких-то нативных платформ, например Qt или Gir (Gtk, Glib, etc). Рекомендую второе. Если обертка не кривая, то программист обычно защищен от утечек памяти, при этом в распоряжении одновременно высокоуровневый язык и высокая производительность нативных библиотек. При этом количество используемой памяти в традиционных интерпретаторах в разы меньше чем например при использовании Java. Если хочется избавиться от интерпретатора, но при этом писать на Gtk, то во избежание мучений рекомендую байндинг для С++ - Gtkmm, там тоже есть специальные смарт поинтеры, которые дружат с Gtk, потому в плане управления памятью получаем подобный к интерпретируемым языкам автоматизм

Вызов нативной библиотеки - это пихнуть параметры/указатели в стек и сделать jump по нужному адресу, если не особо вдаваться в подробности.

Странно что для вас не доходит с трех раз.
Не думаю что повторение в 4й раз чем-то улучшит вашу сообразительность.

Но намекну
-в .Net/С#/Managed C++ существеут арифметика указателей в Java - нет
-в .Net/С#/Managed C++ существуют value type, т.е. данные переданные из Native Lib можно использовать сразу без заворачивания их объекты
- много других полезных нововведений о которых вожете прочитать при желании
т.е. в .Net нет overhead при вызове Native Lib
Надеюсь до вас дойдёт.

Ява сейчас уже практически ни у кого не стоит на десктопе.

Глупости.
Все компьютеры в пределах досягаемости имеют Java.
кроме того существует официальная статистика.

Странно что для вас не доходит с трех раз.

Странно, что ты не можешь объяснить, что же такого магического делает дотнет по сравнению с jna.

Все компьютеры в пределах досягаемости имеют Java.

In a fairy world?

Странно, что ты не можешь объяснить, что же такого магического делает дотнет по сравнению с jna.

Попробую повторить .NET / JVM vs Native (комментарий)
намекну

-в .Net/С#/Managed C++ существеут арифметика указателей в Java - нет
-в .Net/С#/Managed C++ существуют value type, т.е. данные переданные из Native Lib можно использовать сразу без заворачивания их объекты
- много других полезных нововведений о которых вожете прочитать при желании
т.е. в .Net нет overhead при вызове Native Lib

Надеюсь до вас дойдёт.

In a fairy world?

Не.
Я к вам, эльфам не собираюсь.
В реальном мире.
У клиента в офисе и у меня дома.

-в .Net/С#/Managed C++ существеут арифметика указателей в Java - нет

sun.misc.Unsafe вполне себе позволяет поиграться с указателями.

-в .Net/С#/Managed C++ существуют value type

А в яве value types уже отменили? И в jna никто не запрещает использовать их использовать.

много других полезных нововведений о которых вожете прочитать при желании

Каких конкретно то, именно в разрезе вызова native api?

Все мои задеплоеные образы windows идут с джавой
На линукс всегда ставлю Oracle Java
На BSD стоит OpenJDK (оракл вроде не может в линуксятор)
На маках стоит Java
А на хромбуке я развлекаюсь

Попробуйте для себя выяснить, почему Java рисует UI самостоятельно а .Net вызывает внешние библиотеки. Сомневаюсь, что Гугл вам поможет, но я вам точно уже помочь не смогу

т.е. в .Net нет overhead при вызове Native Lib

Всё у тебя просто. А про управление памятью ты что-нибудь слышал?

Есть Qt Jambi

Попробуйте для себя выяснить, почему Java рисует UI самостоятельно а .Net вызывает внешние библиотеки.

Вот у меня в данный момент запущена Эклипс и она вызывает внешние библиотеки для отрисовки GUI. Какой из этого вывод? Ты плохо представляешь о чем пишешь.

Вот у меня в данный момент запущена Эклипс и она вызывает внешние библиотеки для отрисовки GUI. Какой из этого вывод?

Простой.

Ты плохо представляешь о чем пишешь.

Для Eclipse сделали прослойку, локализовав overhead в одном месте( SWT ).
Но вы можете продолжать верить в свои фантазии.

Да, оверхед оказался таким, что SWT так и не получил должного расспространения, так как был не намного быстрее костылей с рисованием UI средствами Java.

А лет 10-15 назад идея казалсь прогрессивной и все верили что наконец-то появятся не тормозные и не уродливые дестоп приложения на Java.

Попробуйте для себя выяснить, почему Java рисует UI самостоятельно а .Net вызывает внешние библиотеки.

Потому что в swing пытались следовать принципу write once, run anywhere. Насколько оно хорошо получилось - отдельный вопрос.

Не нравится - можно посмотреть в сторону swt, работающего через те самые native api.

В какие ещё фантазии? SWT это не более чем стандартизованный интерфейс ко внешним библиотекам. Если ты вызываешь диалог печати, например, то SWT преобразует это в вызов соответсующей нативной библиотеки добавляя по пути недостающую реализацию, если это необходимо на конкретной платформе. Но гуй отрисовывается именно средствами платформы, а не средствами джава. И именно поэтому в SWT есть хитрый механизм управления ресурсами, позволяющий обходить GC и реализовывать нечто вроде деструкторов. И тут мы возвращаемся к первому моему вопросу: слышал ли ты что-нибудь про управление памятью перед тем, как писать про отсутсвие оверхеда при вызове нативных библиотек в дотнете?

Да, оверхед оказался таким, что SWT так и не получил должного расспространения, так как был не намного быстрее костылей с рисованием UI средствами Java.

Ты ври да не завирайся. Во-первых этот гуй на SWT на практике работает даже шустрее AWT или свинга. Во-вторых есть такая штука, как RCP, которая довольно сильно распространена. Просто ты об этом не знаешь.