Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, vaa, Вы писали:
vaa>>Неужели java действительно живее всех живых?
K>Нет. Это разложившаяся стюардесса, которую разрабы закапывают, а гугл откапывает и трясёт, мол "Смотрите-смотрите! Она пошевелилась!"
K>Графики можно рисовать хоть из /dev/random, ЧТО ИМЕННО гугл брал по оси Y? Число поисков? Документов? Имена разрабов? Когда будет точная инфа, уверен, ты сам начнёшь ржать, на чём основывается "живость" Жабы.
K>Ну и так, по-бытовому рассудить: есть компания, у неё внутренний софт для ведения склада. Самописный, конечно же. Вот кто знает про этот софт? Да никто! А ведь его могли писать долго и натравить на проект человек 10. Опять же, если никто из 10 не публиковал себя на джоб-сайтах, ты даже не узнаешь, что в мире есть целых 10 разрабов на конкретном языке. K>Честно скажу, не знаю статистику таких компаний, но они есть — я в таких работал. Причём забавно: сам софт писался на Дельфи, но клиенту выставлялся лишь его покоцаный "скрипт-вариант". Т.е. даже если клиент имеет чужой продукт, он и понятия может не иметь, что там у нутрях.
K>Так что весьма сложно без честного опроса сказать, сколько в мире жабофилов, сколько написано продуктов и насколько жив курилка. K>Ну а так, мнение со стороны: жаба давно уже на свалке истории. Она как была тухлым, тормозным болотом, так и осталась. Я раз 5 предпринимал попытки "запилить мобильный софт", но каждый раз касаюсь это тормозное чучело (JetBrains IDEA или Android Studio) да ещё жду МИНУТАМИ их ублюдочную "систему сборки"... не, такой самолёт не взлетит, закапывайте. Студия даже при всех багах и неудобствах, на порядок лучше любого жабо-поделия.
Java кончено не айс, но конкретная ситуация.
сейчас все сервисы предоставляют openapi со схемой.
я пробовал для нескольких сгенерить C#-клиента.
на большинстве, ломается даже NSwag который якобы заточен под C#,
Другие могут сгенерить частично и на том спасибо.
После этого пробуешь сгенерить для java. Вуаля. Еще проще для js или python.
И тогда осознаешь, что в java на порядок больше бесплатного и качественного софта, чем в C#.
Хотя вот на днях был блиц-тест по шарпу и джаве, у шарпа было больше "звезд",
но это видимо потому что шарп "стильно, модно, молодежно",
т.к. хабр все же больше для зеленых хипстеров.
C# изначально позиционировался как Winforms. asp.net до корки был весьма тяжелым, и глючным.
Будет ли когда-то такое кол-во нормальных библиотек для шарпа?
Грустные мысли поэтому поводу приходят.
Здравствуйте, Эйнсток Файр, Вы писали:
А>> "Остальные еще хуже"
ЭФ>Неправда. JavaScript модный современный язык для создания SPA-приложений под Android.
ЭФ>Точнее не SPA, а не помню как называются те, которые ярлыкоиконками становятся.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, VladiCh, Вы писали:
VC>>Не убьет. Какой-нибудь из существующих AOT тулов это пофиксит как станет более развитым и популярным. VC>>У GraalVM есть шанс.
vsb>GraalVM ужасен. Простой проект на кваркусе, почти хелло-ворлд он компилирует минут 5, при этом пожирая какие-то дикие объёмы оперативной памяти. И сомневаюсь, что это уже пофиксят, AOT для галочки есть, а то, что он не юзабелен — кого это волнует. Это не компиляция, это какая-то пародия на неё, особенно после какого-нибудь го.
Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz 2.30 GHz 8,00 ГБ (доступно: 7,90 ГБ)
AOT на net6 blazor wasm template тоже за 10+ минут отрабатывает, при этом еще бинари такого объема, что все теряет смысл.
Это конечно путь в никуда, либо честный натив, либо нефик мучать попу.
ЭФ>> JavaScript модный современный язык для создания SPA-приложений под Android. ЭФ>> Точнее не SPA, а не помню как называются те, которые ярлыкоиконками становятся.
vaa>PWA?
Здравствуйте, elmal, Вы писали:
E> Всякие плюсы и расты — скорость разработки будет сильно ниже, с библиотеками сильно хуже, геморроя сильно больше — оно точно того стоит ?
Здравствуйте, elmal, Вы писали:
E>Альтернативы какие? Для масс сейчас python используют. Где со скоростью полная труба, плюс динамика это. Всякие плюсы и расты — скорость разработки будет сильно ниже, с библиотеками сильно хуже, геморроя сильно больше — оно точно того стоит для всяких серверов (я про десктоп не говорю)?
Для чего нет библиотек на плюсах?
Сама по себе разработка плюс-минус одно и тоже, а вот управление проектом и зависимостями, сборка для разных платформ — намного сложнее.
Здравствуйте, Skorodum, Вы писали:
S>Для чего нет библиотек на плюсах?
Для микросервисов.
S>Сама по себе разработка плюс-минус одно и тоже,
Игрушка потекла, упала, перезапустил- и пофиг. Или по тухлому указателю сходила. В случае с микросервисом, downtime крайне нежелателен. Ну и чисто исторически, невзлюбили C++ в веб.
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, Skorodum, Вы писали:
S>>Для чего нет библиотек на плюсах? Аё>Для микросервисов.
Артём, ты так говоришь, как будто для микросервисов требуются какие-то особые библиотеки. Прикладную задачу назови. Например, работа с датами или разбор строк. Как я понимаю с этим в Java из коробки было намного лучше лед дцать назад и немного лучше сейчас.
Аё>Игрушка потекла, упала, перезапустил- и пофиг. Или по тухлому указателю сходила. В случае с микросервисом, downtime крайне нежелателен.
Вообще-то ровно наоборот. Микросервис может быть дублирован, распараллелен и легко обновлен, в отличии от игрушки.
Здравствуйте, Skorodum, Вы писали:
S>>>Для чего нет библиотек на плюсах? Аё>>Для микросервисов. S>Артём, ты так говоришь, как будто для микросервисов требуются какие-то особые библиотеки. Прикладную задачу назови. Например, работа с датами или разбор строк.
Нет. Вот это например https://spring.io/guides/gs/service-registration-and-discovery/.
Аё>>Игрушка потекла, упала, перезапустил- и пофиг. Или по тухлому указателю сходила. В случае с микросервисом, downtime крайне нежелателен. S>Вообще-то ровно наоборот. Микросервис может быть дублирован, распараллелен и легко обновлен, в отличии от игрушки.
Ога, легко. Blue-green, да. Только в теории это легко и гладко.
Здравствуйте, vaa, Вы писали:
vaa>Смотрю на trends vaa>Неужели java действительно живее всех живых?
На данный момент Java это единственный нормальный язык системно-прикладного уровня. Последнее, мною выдуманное слово означает, что можно открыть файл, запросив эксклюзивный доступ, открыть сокет, принять запрос на соединение и отправить содержимое файла в сокет, минуя процессор (DMA). И всё это из стандартной библиотеки, безопасно относительно доступа к памяти и с точки зрения возникновения исключительных ситуаций. Если дать такое задание плюсовику, то он первым делом подключит буст, а потом пол года будет его собирать. Другие пол года его коллега будет разбираться, что означает const auto& foo = boost::fucking_magic<network::tag, memory_allocator<super_safe>, move_semantics<fuck, this, shit>>::instance(). Есть ещё вариант подождать стандарта C++2032, в котором, наконец-то, реализуют всё то, что есть в Java 1.4.
Здравствуйте, cppguard, Вы писали:
C>На данный момент Java это единственный нормальный язык системно-прикладного уровня. Последнее, мною выдуманное слово означает, что можно открыть файл, запросив эксклюзивный доступ, открыть сокет, принять запрос на соединение и отправить содержимое файла в сокет, минуя процессор (DMA). И всё это из стандартной библиотеки, безопасно относительно доступа к памяти и с точки зрения возникновения исключительных ситуаций. Если дать такое задание плюсовику, то он первым делом подключит буст, а потом пол года будет его собирать. Другие пол года его коллега будет разбираться, что означает const auto& foo = boost::fucking_magic<network::tag, memory_allocator<super_safe>, move_semantics<fuck, this, shit>>::instance(). Есть ещё вариант подождать стандарта C++2032, в котором, наконец-то, реализуют всё то, что есть в Java 1.4.
У жавы очень ограниченный доступ к системному API. Ты или с жавой мало работал, или не договариваешь. Там на любой чих надо писать свою DLL-ку на JNI (на C/C++, ага). Банальный макосовский xattr (для доступа к extended file attributes) я в жаве не нашел, например.
Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно. И пока он не уничтожен сборщиком мусора (что может произойти через секунду или через час или никогда), жава держит ссылку на соответствующий файл, что предотвращает его удаление. То бишь можно поймать забавный баг: на компьютере кончается память на диске. При этом через du -hs ничего аномального не находится и нифига не понятно. А дело в том, что рядом крутится жава, которая создает большой файл, делает mmap, работает с ним, потом типа закрывает и удаляет его, но по факту в файловой системе inode остаётся, только невидимый и пока сборщик мусора не запустится, места на диске больше не станет. Вот такие вот абстракции иногда протекают.
А ценность отправки файла в сокет, в эпоху повсеместного HTTPS, достаточно спорна.
Здравствуйте, vsb, Вы писали:
vsb>У жавы очень ограниченный доступ к системному API. Ты или с жавой мало работал, или не договариваешь. Там на любой чих надо писать свою DLL-ку на JNI (на C/C++, ага). Банальный макосовский xattr (для доступа к extended file attributes) я в жаве не нашел, например.
Ну да, и нет доступа к API принтера HP M14a. Вот беда. Хотя стоп — у C, C++, Python и вообще всех остальных тоже нет доступа ни к принтеру, ни к xattr, потому что его обеспечивает SDK, а не язык. И что касается POSIX, то Java тут имеет достаточно полное отображение.
vsb>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно. И пока он не уничтожен сборщиком мусора (что может произойти через секунду или через час или никогда), жава держит ссылку на соответствующий файл, что предотвращает его удаление. То бишь можно поймать забавный баг: на компьютере кончается память на диске. При этом через du -hs ничего аномального не находится и нифига не понятно. А дело в том, что рядом крутится жава, которая создает большой файл, делает mmap, работает с ним, потом типа закрывает и удаляет его, но по факту в файловой системе inode остаётся, только невидимый и пока сборщик мусора не запустится, места на диске больше не станет. Вот такие вот абстракции иногда протекают.
Ок. Давай теперь вспомним auto_ptr в С++, который был полезен... никода. Я разве говорил, что Java идеально спроектирован? Я сказал, что он удобен для прикладного программирования — можно за 5 минут написать работающий код. На С++ ты так не сделаешь. Даже работа с файлами на С++ это мешанина из С++, iostream и системных возовов. Можно быстро прочитать файл на питоне, но там обработка двоичных данных это боль.
vsb>А ценность отправки файла в сокет, в эпоху повсеместного HTTPS, достаточно спорна.
Это был лишь пример простого приложения. Придумай любую другую задачу, и я покажу, что на Java код для неё будет написан быстрее и безопаснее.
Здравствуйте, vsb, Вы писали:
vsb>Ещё есть забавный прикол
Это всё сделано не просто так. Java по дизайну кросплатформенна, поэтому странно от неё ожидать поддержки специфичных для платформы вещей. DLL в 21 веке никто не пишет, они либо написаны до нас, либо JNA позволяет вызвать нативный метод из длл без возни с плюсами.
MappedByteBuffer невозможно закрыть из клиентского кода, т.к. тогда память, на который он ссылается, будет деаллоцирована и другие потоки, работающие с этой памятью, могут крашнуть jvm.
Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.
Здравствуйте, scf, Вы писали:
vsb>>Ещё есть забавный прикол scf>Это всё сделано не просто так. Java по дизайну кросплатформенна, поэтому странно от неё ожидать поддержки специфичных для платформы вещей. DLL в 21 веке никто не пишет, они либо написаны до нас, либо JNA позволяет вызвать нативный метод из длл без возни с плюсами. scf>MappedByteBuffer невозможно закрыть из клиентского кода, т.к. тогда память, на который он ссылается, будет деаллоцирована и другие потоки, работающие с этой памятью, могут крашнуть jvm.
Да, оказывается интересный случай. Ещё и потенциальная дыра в безопасности https://bugs.openjdk.java.net/browse/JDK-4724038
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, vsb, Вы писали:
vsb>>У жавы очень ограниченный доступ к системному API. Ты или с жавой мало работал, или не договариваешь. Там на любой чих надо писать свою DLL-ку на JNI (на C/C++, ага). Банальный макосовский xattr (для доступа к extended file attributes) я в жаве не нашел, например.
C>Ну да, и нет доступа к API принтера HP M14a. Вот беда. Хотя стоп — у C, C++, Python и вообще всех остальных тоже нет доступа ни к принтеру, ни к xattr, потому что его обеспечивает SDK, а не язык. И что касается POSIX, то Java тут имеет достаточно полное отображение.
Неправда. В C я могу написать setxattr и оно будет работать. Потому, что все системные апи пишутся для С. Не знаю, что там у API принтера, но уверен на 100% — в ОС есть функции, вызвав которые этот принтер начнет печатать. А вот есть ли в жаве соответствующие биндинги — не уверен.
vsb>>А ценность отправки файла в сокет, в эпоху повсеместного HTTPS, достаточно спорна.
C>Это был лишь пример простого приложения. Придумай любую другую задачу, и я покажу, что на Java код для неё будет написан быстрее и безопаснее.
docker, например. Там весь код это обёртка вокруг cgroup API. Ну условно обёртка, конечно. Или проект systemd, самый, что ни на есть, системный код.
Да что там говорить. Ты попробуй жава программу демонизировать. По всем юниксовым правилам, я уж не помню детали, типа форкнуться, закрыть хендлы. Банального форка в жаве нет.
Здравствуйте, scf, Вы писали:
vsb>>Ещё есть забавный прикол
scf>Это всё сделано не просто так. Java по дизайну кросплатформенна, поэтому странно от неё ожидать поддержки специфичных для платформы вещей. DLL в 21 веке никто не пишет, они либо написаны до нас, либо JNA позволяет вызвать нативный метод из длл без возни с плюсами.
Да я не спорю, просто я не считаю, что жаву можно называть системным софтом. Системный софт, по крайней мере в моём понимании, это софт, который работает с системой. С конкретной системой. И это как бы антитезисно самому понятию кроссплатформенности. Как можно написать кроссплатформенный докер? Ничего общего в контейнерном API между линуксом и виндой нет, а в макоси понятия контейнеров даже нет. Системный софт можно писать либо на C, либо на языке, из которого очень легко вызывать код на С, например C++. И, да, я в курсе, что докер на го написан, и считаю это ошибкой.
scf>MappedByteBuffer невозможно закрыть из клиентского кода, т.к. тогда память, на который он ссылается, будет деаллоцирована и другие потоки, работающие с этой памятью, могут крашнуть jvm.
Это отмазки. Разыменование нулевой ссылки не крашит jvm, могли бы и тут что-нибудь придумать. А если не смогли — значит и нефиг делать кривой API. Кому надо — пусть через JNI пользуют, на свой страх и риск. В принципе по ссылке выше уже всё написано — делайте unmap и помечайте память специальным образом, кто в неё будет обращаться, тот получит sigsegv, а дальше уже обработчик сигнала преобразует это в JVM exception. 2 файла на одну память мапить не нужно, у нас 64 бита, виртуальных адресов хватит для всего. Ну а GC пусть уже при сборке снимает эту метку памяти. Может эта отмазка была актуальна, когда 32-битные системы использовали, современную жаву оракл под 32 бита по-моему даже не пытается собирать.
scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.
Я по жаве больше, какие там в плюсах библиотеки, я не знаю. Я бы посмотрел в сторону nginx и apache httpd, есть ли там какая-то выделенная сетевая часть, которую можно вытащить и заюзать как библиотеку. По-моему в апаче есть. Но может есть и более удачная библиотека. Это для сервера, для клиента точно знаю, что libcurl хорош.
Здравствуйте, cppguard, Вы писали:
C>Ну да, и нет доступа к API принтера HP M14a. Вот беда. Хотя стоп — у C, C++, Python и вообще всех остальных тоже нет доступа ни к принтеру, ни к xattr, потому что его обеспечивает SDK, а не язык.
Ну так и доступ к RDMA тоже обеспечивает система а не Java
C>Я сказал, что он удобен для прикладного программирования — можно за 5 минут написать работающий код.
Удобство не в языке а в огромном framework который идёт паравозиком к языку, в которых насрали за годы всемогуторов на разные темы.
C>На С++ ты так не сделаешь.
Вот именно с точки зрения языка С++ от Java тут ничем не отличается.
C>Даже работа с файлами на С++ это мешанина из С++, iostream и системных возовов.
Гм, странно, у меня С++ и там никакого iostream и прямых системных вызовов
Как же я это делаю?
Ах да, точно так же как в жабе — юзаю удобный framework, который позволяет легко прочитать файл, который сжат, зашифрован, и вообще лежит где то там в Google Cloud.
Здравствуйте, Слава, Вы писали:
С>Rust победит и яву, и плюсЫ. Когда соответствующие программисты вымрут.
Ну рази шо
Если, конечно, он сам до этого не вымрет.
Когда будет точная инфа, уверен, ты сам начнёшь ржать, на чём основывается "живость" Жабы.
не, такой самолёт не взлетит, закапывайте. Студия даже при всех багах и неудобствах, на порядок лучше любого жабо-поделия.
