Смотрю на trends
Неужели java действительно живее всех живых?

Здравствуйте, vaa, Вы писали:

vaa>Неужели java действительно живее всех живых?

А что с ней случится? Очень качественная платформа, очень хорошая экосистема, отличная обратная совместимость, несложный язык, корпоративная поддержка, продолжает развиваться.

Здравствуйте, vaa, Вы писали:

vaa>Смотрю на trends
vaa>Неужели java действительно живее всех живых?
А что не так? Мощнейшая инфраструктура, мощнейшая поддержка библиотеками, кроссплатформенность, неплохая производительность, прекрасные среды разработки. Есть недостатки у самого языка (зачастую такие же как у шарпа), но сама платформа живее всех живых и очень и очень не плоха.

Альтернативы какие? Для масс сейчас python используют. Где со скоростью полная труба, плюс динамика это. Всякие плюсы и расты — скорость разработки будет сильно ниже, с библиотеками сильно хуже, геморроя сильно больше — оно точно того стоит для всяких серверов (я про десктоп не говорю)?

Android. Какие ещё нужны причины?

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Android. Какие ещё нужны причины?

Именно! Не будь этого говна, Жаба ушла бы в небытиё вместе с её устаревшими апологетами.

ЭФ>>Android. Какие ещё нужны причины?

K>Именно! Не будь этого говна, Жаба ушла бы в небытиё вместе с её устаревшими апологетами.

брехня. энтрепрайз тоже наигрался со всеми этими better java и сворачивает набор скалистов и прочих. даже в бигдате спрак написанный на скале начинают в жава массово юзать, жависты сильно дешевле, а выхлоп почти тот же.

Gt_

Здравствуйте, vaa, Вы писали:

vaa>Неужели java действительно живее всех живых?

Нет. Это разложившаяся стюардесса, которую разрабы закапывают, а гугл откапывает и трясёт, мол "Смотрите-смотрите! Она пошевелилась!"

Графики можно рисовать хоть из /dev/random, ЧТО ИМЕННО гугл брал по оси Y? Число поисков? Документов? Имена разрабов? Когда будет точная инфа, уверен, ты сам начнёшь ржать, на чём основывается "живость" Жабы.

Ну и так, по-бытовому рассудить: есть компания, у неё внутренний софт для ведения склада. Самописный, конечно же. Вот кто знает про этот софт? Да никто! А ведь его могли писать долго и натравить на проект человек 10. Опять же, если никто из 10 не публиковал себя на джоб-сайтах, ты даже не узнаешь, что в мире есть целых 10 разрабов на конкретном языке.
Честно скажу, не знаю статистику таких компаний, но они есть — я в таких работал. Причём забавно: сам софт писался на Дельфи, но клиенту выставлялся лишь его покоцаный "скрипт-вариант". Т.е. даже если клиент имеет чужой продукт, он и понятия может не иметь, что там у нутрях.

Так что весьма сложно без честного опроса сказать, сколько в мире жабофилов, сколько написано продуктов и насколько жив курилка.
Ну а так, мнение со стороны: жаба давно уже на свалке истории. Она как была тухлым, тормозным болотом, так и осталась. Я раз 5 предпринимал попытки "запилить мобильный софт", но каждый раз касаюсь это тормозное чучело (JetBrains IDEA или Android Studio) да ещё жду МИНУТАМИ их ублюдочную "систему сборки"... не, такой самолёт не взлетит, закапывайте. Студия даже при всех багах и неудобствах, на порядок лучше любого жабо-поделия.

K> жду МИНУТАМИ

Просто надо использовать современные 5.5 Ghz-процессоры для десктопа, собирать на кластере
и проблем не будет.

А кого волнуют проблемы недоразвитых окраин цивилизации с устаревшими компами?

vaa>Причины популярности java

"Остальные еще хуже"

А> "Остальные еще хуже"

Неправда. JavaScript модный современный язык для создания SPA-приложений под Android.

Точнее не SPA, а не помню как называются те, которые ярлыкоиконками становятся.

ЭФ>Неправда.

Конечно неправда, я пошутил. Почему ява рулит, выше уже сказали.

Здравствуйте, Аноним931, Вы писали:

А>"Остальные еще хуже"

На определенной степени просветления становится понятно, что языки — это всё тлен. Важна платформа, экосистема и библиотеки. И в этом джаву/JRE крайне сложно переплюнуть на поприще серверных приложений. Есть .NET, есть nodejs, есть питон, есть native, но все они немного позади, занимая свою нишу уникальными преимуществами. Но по очкам все равно выигрывает JRE.

Здравствуйте, elmal, Вы писали:

E>А что не так?

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

И выхода не видать.

Это жаву и убьёт. Но пока живет, да.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, elmal, Вы писали:

E>>А что не так?

vsb>Долгое время старта, жруч до памяти, фреймворки все как на подбор один монстрее другого.

vsb>И выхода не видать.

vsb>Это жаву и убьёт. Но пока живет, да.

Не убьет. Какой-нибудь из существующих AOT тулов это пофиксит как станет более развитым и популярным.
У GraalVM есть шанс.

Здравствуйте, vsb, Вы писали:

vsb>Долгое время старта, жруч до памяти, фреймворки все как на подбор один монстрее другого.
Сейчас GraalVM умеет в нейтив, там соответственно стартует шустрее. Да и по памяти вроде как неплохо. Относительно немонструозных фреймворков. Я вот ради эксперимента порядка четырех лет пожил вообще без фреймворков. Если нужно, пользовал чем очень легковесным. И ощущения специфические — мне приходилось в либах пилить зачастую функционал этого фреймворка ASAP чтоб хоть как то работало, ибо легкие фреймворки именно из коробки хоть и шустры, но ни черта не умеют, хочешь комфортной разработки — пили сам библиотеки. И самое поганое что вначале проект махонький, предполагаешь что навороченные фичи не понадобятся. Однако с разрастанием и со временем внезапно оказывается что фичи нужны. И либо юзай тяжелый фреймворк, либо пили библиотеки и сам ручками реализовывай фичи.

Здравствуйте, VladiCh, Вы писали:

VC>Не убьет. Какой-нибудь из существующих AOT тулов это пофиксит как станет более развитым и популярным.
VC>У GraalVM есть шанс.

GraalVM ужасен. Простой проект на кваркусе, почти хелло-ворлд он компилирует минут 5, при этом пожирая какие-то дикие объёмы оперативной памяти. И сомневаюсь, что это уже пофиксят, AOT для галочки есть, а то, что он не юзабелен — кого это волнует. Это не компиляция, это какая-то пародия на неё, особенно после какого-нибудь го.

Здравствуйте, elmal, Вы писали:

vsb>>Долгое время старта, жруч до памяти, фреймворки все как на подбор один монстрее другого.
E>Относительно немонструозных фреймворков. Я вот ради эксперимента порядка четырех лет пожил вообще без фреймворков. Если нужно, пользовал чем очень легковесным. И ощущения специфические — мне приходилось в либах пилить зачастую функционал этого фреймворка ASAP чтоб хоть как то работало, ибо легкие фреймворки именно из коробки хоть и шустры, но ни черта не умеют, хочешь комфортной разработки — пили сам библиотеки. И самое поганое что вначале проект махонький, предполагаешь что навороченные фичи не понадобятся. Однако с разрастанием и со временем внезапно оказывается что фичи нужны. И либо юзай тяжелый фреймворк, либо пили библиотеки и сам ручками реализовывай фичи.

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

Вот взять com.sun.httpserver. Хороший встроенный http-сервер в стандартной библиотеке. Адекватные интерфейсы. Казалось бы — пиши библиотеки, дополняй его всякими фильтрами и прочими вкусняшками по необходимости. А про неё никто даже не знает, нынче легкий http-сервер это netty мегабайтов на 10, который с JVM делает всякое странное ради 1% производительности, которая никому не нужна.

Взять java.util.logging. Хороший встроенный логгинг-фреймворк. Ну может не идеальный, но в целом нормальный. Тем более в эру микросервисов, когда все тупо пишут в stdout и потом сливают в какой-нибудь logstash или что там нынче популярно. Кто его использует? Я вживую не видел. Попробуй поспрашивать на собеседованиях — как его сконфигурировать. Никто не ответит.

И такое по каждому пункту.

И, да, оракл тут тоже частично виноваты, ибо не развивают нормально свой же код. А порой ещё и закапывают.

Здравствуйте, vsb, Вы писали:

vsb>Потому, что на джаве немонструозные фреймворки никто не использует. У них околонулевая популярность и они в том числе поэтому просто плохи.
Что значит плохи? Они на деле весьма и весьма шустры. Например vert.x, jetty. И, например quarkus под капотом вполне использует vert.x. А quarkus вообще то вполне себе альтернатива spring boot, по крайней мере я на нем сейчас сижу и особого дискомфорта не испытываю, хотя все еще привыкаю к особенностям. И хоть он и можно сказать монструозен и все в одном — время старта для моих целей практически мгновенное даже без нейтива. Ранее для прикола сидел почти на голом jetty — достаточно быстро написал обвязку, которая позволяет быстро писать сервисы. Всякие rxjava не такие уж и монструозные на деле, а позволяют избавиться от кучи проблем в виде callback hell и т.д, и хоть я с некоторыми проблемами в свое время с ним столкнулся и сейчас бы наверно взял project reactor — есть выбор между весьма легковесными библиотеками,их довольно легко менять и они от всякой рутины избавляют. Но вот что то я сильно сомневаюсь что на том же rust я бы с легкостью параллелил задачи, асинхронщину легко бы выстраивал в цепочки или переводил в синхронщину, на java я вообще не задумываюсь над многопоточностью — все что нужно или есть из коробки, или есть в библиотеках которые легко подключаются, либо это очень быстро пишется и красиво оборачивается для использования. Если что, я на java не пишу уже более 5 лет, я сначала использовал ceylon и сейчас kotlin — и я реально испытываю удовольствие от работы, ибо у меня получается очень компактно описывать весьма сложные вещи.

Здравствуйте, Эйнсток Файр, Вы писали:

K>> жду МИНУТАМИ

ЭФ>Просто надо использовать современные процессоры

Для жабы, которая ещё для пентиумов разрабатывалась?? перетопчетесь!
Может, нужно просто вынуть плечи из таза и поставить на место? Там глядишь, проект секунд за 10 хотя бы соберут.
Почему ms build работает секунды, а gradle надо ждать как бабу, которой "нечего надеть"??

Здравствуйте, Kolesiki, Вы писали:

ЭФ>>Просто надо использовать современные процессоры
K>Для жабы, которая ещё для пентиумов разрабатывалась?? перетопчетесь!
K>Может, нужно просто вынуть плечи из таза и поставить на место? Там глядишь, проект секунд за 10 хотя бы соберут.
K>Почему ms build работает секунды, а gradle надо ждать как бабу, которой "нечего надеть"??

справедливое замечание

Здравствуйте, 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, а не помню как называются те, которые ярлыкоиконками становятся.

PWA?

Здравствуйте, 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> Всякие плюсы и расты — скорость разработки будет сильно ниже, с библиотеками сильно хуже, геморроя сильно больше — оно точно того стоит ?

Кастую so5steam + CreatorCray в тред.

Здравствуйте, 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>Если дать такое задание плюсовику, то он первым делом подключит буст
Это плохой, негодный плюсовик

Здравствуйте, 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.

Здравствуйте, CreatorCray, Вы писали:

CC>...skipped...

Очевидно пустой спор, Rust победит и яву, и плюсЫ. Когда соответствующие программисты вымрут.

Здравствуйте, Слава, Вы писали:

С>Rust победит и яву, и плюсЫ. Когда соответствующие программисты вымрут.
Ну рази шо
Если, конечно, он сам до этого не вымрет.

Здравствуйте, CreatorCray, Вы писали:

CC>Ах да, точно так же как в жабе — юзаю удобный framework, который позволяет легко прочитать файл, который сжат, зашифрован, и вообще лежит где то там в Google Cloud.

Кто сказал framework? Вот тебе код, без всяких фреймворков:

void sendFile(final SocketChannel socket, final Path path) throws IOException {
    try (FileChannel channel = FileChannel.open(path); final FileLock lock = channel.lock()) {
        channel.transferTo(0, channel.size(), socket);
    }
}

Давай, публикуй свой вариант на С++.

Здравствуйте, cppguard, Вы писали:

C>Кто сказал framework? Вот тебе код, без всяких фреймворков:
Ты для начала получи из этого бинарь, который без многамегабайтного JRE запустится, а потом уже можешь рассказывать про "без всяких фреймворков"

Здравствуйте, CreatorCray, Вы писали:

C>>Кто сказал framework? Вот тебе код, без всяких фреймворков:
CC>Ты для начала получи из этого бинарь, который без многамегабайтного JRE запустится, а потом уже можешь рассказывать про "без всяких фреймворков"
https://blogs.oracle.com/javamagazine/post/pedal-to-the-metal-high-performance-java-with-graalvm-native-image
Только неясно насколько это нафиг всё нужно. Собрал контейнер, а что там лежит внутре — пофиг. При желании полный docker image укладывается мегов в 50 и без нативной компиляции.

Здравствуйте, vsb, Вы писали:

vsb>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.

Нифига себе прикладное программирование. Это скорее системное, mmap-ить файлы есть смысл, например в СУБД. СУБД н яве писать никто не собирается. Прикладное программирование, оно же прогарммирование всяких бизнес логик (для чего ява и создана), это когда у тебя file.Read(buffer) и file.Write(buffer) и всё.

Здравствуйте, smeeld, Вы писали:

vsb>>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.

S>Нифига себе прикладное программирование. Это скорее системное, mmap-ить файлы есть смысл, например в СУБД. СУБД н яве писать никто не собирается. Прикладное программирование, оно же прогарммирование всяких бизнес логик (для чего ява и создана), это когда у тебя file.Read(buffer) и file.Write(buffer) и всё.
Cassandra, Kafka, h2database, куча их.

Здравствуйте, ·, Вы писали:

·>Cassandra, Kafka, h2database, куча их.

Хеллоуворлдных СУБД всяких прикола ради даже на бейсике полно написано. Только вот в проде никто не юзает, если есть требования к производительности.

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, ·, Вы писали:

S>·>Cassandra, Kafka, h2database, куча их.

S>Хеллоуворлдных СУБД всяких прикола ради даже на бейсике полно написано. Только вот в проде никто не юзает, если есть требования к производительности.

Это Cassandra то хеллоуворлдная СУБД? Ты просто не в теме.

Здравствуйте, smeeld, Вы писали:

S>·>Cassandra, Kafka, h2database, куча их.
S>Хеллоуворлдных СУБД всяких прикола ради даже на бейсике полно написано. Только вот в проде никто не юзает,


S>если есть требования к производительности.
Оно офигенно скейлится. mssql-ям такое и не снилось.

Здравствуйте, vaa, Вы писали:

vaa>AOT на net6 blazor wasm template тоже за 10+ минут отрабатывает, при этом еще бинари такого объема, что все теряет смысл.
vaa>Это конечно путь в никуда, либо честный натив, либо нефик мучать попу.

Ну по аналогии с .Net Native та много зависит от использования рефлекшина.
Ну и blazor wasm AOT это конечно не совсем натив. Вернее натив для браузера.
Посмотри NativeAOT

Здравствуйте, ·, Вы писали:

C>>>Кто сказал framework? Вот тебе код, без всяких фреймворков:
CC>>Ты для начала получи из этого бинарь, который без многамегабайтного JRE запустится, а потом уже можешь рассказывать про "без всяких фреймворков"
·>Собрал контейнер, а что там лежит внутре — пофиг. При желании полный docker image укладывается мегов в 50 и без нативной компиляции.
Речь о том, что это всё не заслуга языка а фреймворка, т.е. коллекции либ, которые делают разное. Которые можно практически под любой язык написать.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, vaa, Вы писали:

vaa>>AOT на net6 blazor wasm template тоже за 10+ минут отрабатывает, при этом еще бинари такого объема, что все теряет смысл.
vaa>>Это конечно путь в никуда, либо честный натив, либо нефик мучать попу.

S> Ну по аналогии с .Net Native та много зависит от использования рефлекшина.
S>Ну и blazor wasm AOT это конечно не совсем натив. Вернее натив для браузера.
S>Посмотри NativeAOT
не думаю что это принципиальная разница. ВМ что из дотнета, что из джава не выкинуть.

Здравствуйте, CreatorCray, Вы писали:

CC>Речь о том, что это всё не заслуга языка а фреймворка, т.е. коллекции либ, которые делают разное. Которые можно практически под любой язык написать.
только на плюсах для каждой машины нужно как в первый раз среду разработки настраивать, да и деплой может иногда вызвать недоумение.
в отличии от например экосистемы раста.
но слабость и сила джава именно в ВМ, которая позволяет абсолютно абстрагироваться от верхнего слоя.
у нас просто есть байт-код модуля/класса и мы его выполняем. Если бы не минусы ВМ, это бы все решило в мире софтостроения.
даже в дотнете где тоже своя ВМ, все же нужно думать о том что ты сидишь под ОС. ведь компилится не в чистый байткод, а в сборки.

Здравствуйте, vaa, Вы писали:

vaa>только на плюсах для каждой машины нужно как в первый раз среду разработки настраивать
Ты о чём вообще?

vaa> да и деплой может иногда вызвать недоумение.
Это уже как напишешь

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, vaa, Вы писали:

vaa>>только на плюсах для каждой машины нужно как в первый раз среду разработки настраивать
CC>Ты о чём вообще?

не плюсовик. но был небольшой опыт vs 2017 c++, там чтобы все необходимое для компиляции настроить замучаешься.

про синтаксис и ошибки компилятора лучше вообще промолчу.
вот сообщения нормального компилятора(F#):

> open type System.Console;;
> Wri 1;;

  Wri 1;;
  ^^^

stdin(2,1): error FS0039: Значение или конструктор "Wri" не определены. Возможно, требуется одно из следующих:
   Write

> wRitel 32
- ;;

  wRitel 32
  ^^^^^^

stdin(3,1): error FS0039: Значение или конструктор "wRitel" не определены. Возможно, требуется одно из следующих:
   Write
   WriteLine

>

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

Здравствуйте, vaa, Вы писали:

S>>Посмотри NativeAOT
vaa>не думаю что это принципиальная разница. ВМ что из дотнета, что из джава не выкинуть.
Ну из .Net Native то выкидывают. Там только сборщик мусора
https://docs.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation

.NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.

Здравствуйте, CreatorCray, Вы писали:

CC>>>Ты для начала получи из этого бинарь, который без многамегабайтного JRE запустится, а потом уже можешь рассказывать про "без всяких фреймворков"
CC>·>Собрал контейнер, а что там лежит внутре — пофиг. При желании полный docker image укладывается мегов в 50 и без нативной компиляции.
CC>Речь о том, что это всё не заслуга языка а фреймворка, т.е. коллекции либ, которые делают разное. Которые можно практически под любой язык написать.
Можно, конечно, дело остаётся за малым — таки написать коллекции либ. И заслуга языка в том, что под него коллекции таки написали. Платформа — очень дружелюбна к написанию и использованию либ.

Здравствуйте, Skorodum, Вы писали:

S>Артём, ты так говоришь, как будто для микросервисов требуются какие-то особые библиотеки.

Иногда вполне требуются. К примеру — https://kubernetes.io/docs/reference/using-api/client-libraries/ . Или вот https://cdk8s.io/ .

Здравствуйте, scf, Вы писали:

scf>На определенной степени просветления становится понятно, что языки — это всё тлен. Важна платформа, экосистема и библиотеки.

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

Здравствуйте, vsb, Вы писали:

vsb>У жавы очень ограниченный доступ к системному API. Ты или с жавой мало работал, или не договариваешь. Там на любой чих надо писать свою DLL-ку на JNI (на C/C++, ага). Банальный макосовский xattr (для доступа к extended file attributes) я в жаве не нашел, например.

Серьезно?

vsb>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.

sun.nio.ch.DirectBuffer.cleaner()?

Здравствуйте, VladiCh, Вы писали:

S>>Хеллоуворлдных СУБД всяких прикола ради даже на бейсике полно написано. Только вот в проде никто не юзает, если есть требования к производительности.
VC>Это Cassandra то хеллоуворлдная СУБД? Ты просто не в теме.

Она, конечно, не хеллоуволдная, но ведущие собаководы предпочитают сциллу.

Здравствуйте, ·, Вы писали:

S>>если есть требования к производительности.
·>Оно офигенно скейлится. mssql-ям такое и не снилось.

При чем тут mssql? Опу с пальцем сравниваешь.

Здравствуйте, vaa, Вы писали:

vaa>даже в дотнете где тоже своя ВМ

Это довольно спорный вопрос, есть ли в дотнете ВМ.

Здравствуйте, vaa, Вы писали:

vaa>не плюсовик. но был небольшой опыт vs 2017 c++, там чтобы все необходимое для компиляции настроить замучаешься.
А что там надо было из "необходимого для компилятора" настраивать?

vaa>про синтаксис и ошибки компилятора лучше вообще промолчу.
Я под винду давно не пользуюсь микрософтовским, но у Intel ошибки всегда вменяемые и каких то WTF moments за последний десяток лет не припомню.
Clang похуже будет но тоже довольно лаконично показывает где что не так.

Здравствуйте, ·, Вы писали:

·>И заслуга языка в том, что под него коллекции таки написали.
Это заслуга совсем не языка а компаний, которые их писали. Причём совсем не по доброте душевной.

Здравствуйте, CreatorCray, Вы писали:

CC>·>И заслуга языка в том, что под него коллекции таки написали.
CC>Это заслуга совсем не языка а компаний, которые их писали. Причём совсем не по доброте душевной.
А почему писали именно на этом языке? Ты причину и следствие попутал.

Здравствуйте, ·, Вы писали:

·>А почему писали именно на этом языке?
Потому что им не хватало либ под этот язык.

Здравствуйте, CreatorCray, Вы писали:
CC>Это заслуга совсем не языка а компаний, которые их писали. Причём совсем не по доброте душевной.
Неа. В первую очередь — это заслуга платформы, как гаранта совместимости ABI, и языка, как способа выражать модульность предсказуемым образом.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, vaa, Вы писали:

vaa>>не плюсовик. но был небольшой опыт vs 2017 c++, там чтобы все необходимое для компиляции настроить замучаешься.
CC>А что там надо было из "необходимого для компилятора" настраивать?

хотел сейчас глянуть че как(сносил студию). при открытии умная предложила скачать что-то типа MFC\etc 1.5Г и 5Г на диске.
чет лень качать проверять. но! факт в разработке все таки библиотеки джава поменьше. плагин простейший: блочное шифрование потока байт.
т.е. и зависимостей то не должно быть. вообщем, я в этом не особо разбираюсь.
из хидеров всего то:

#include <winsock2.h>
#include <windows.h>
#include <atlbase.h>
#include <atlstr.h>
#include <wincrypt.h>

в proj интересности такие(правда все эти тулзы нужны?):

        <Configuration
            Name="Debug|Win32"
            OutputDirectory="..\..\..\Bin\$(PlatformName)\$(ConfigurationName)"
            IntermediateDirectory="..\..\trash\$(ProjectName)\$(PlatformName)\$(ConfigurationName)."
            ConfigurationType="2"
            UseOfMFC="1"
            UseOfATL="1"
            CharacterSet="1"
            >
            <Tool
                Name="VCPreBuildEventTool"
            />
            <Tool
                Name="VCCustomBuildTool"
            />
            <Tool
                Name="VCXMLDataGeneratorTool"
            />
            <Tool
                Name="VCWebServiceProxyGeneratorTool"
            />
            <Tool
                Name="VCMIDLTool"
            />
            <Tool
                Name="VCCLCompilerTool"
                Optimization="0"
                PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;CRYPT_EXPORTS"
                MinimalRebuild="true"
                BasicRuntimeChecks="3"
                RuntimeLibrary="1"
                UsePrecompiledHeader="2"
                WarningLevel="3"
                Detect64BitPortabilityProblems="true"
                DebugInformationFormat="4"
            />
            <Tool
                Name="VCManagedResourceCompilerTool"
            />
            <Tool
                Name="VCResourceCompilerTool"
            />
            <Tool
                Name="VCPreLinkEventTool"
            />
            <Tool
                Name="VCLinkerTool"
                LinkIncremental="2"
                ModuleDefinitionFile=""
                GenerateDebugInformation="true"
                SubSystem="2"
                RandomizedBaseAddress="1"
                DataExecutionPrevention="0"
                TargetMachine="1"
            />
            <Tool
                Name="VCALinkTool"
            />
            <Tool
                Name="VCManifestTool"
            />
            <Tool
                Name="VCXDCMakeTool"
            />
            <Tool
                Name="VCBscMakeTool"
            />
            <Tool
                Name="VCFxCopTool"
            />
            <Tool
                Name="VCAppVerifierTool"
            />
            <Tool
                Name="VCPostBuildEventTool"
            />
        </Configuration>

Здравствуйте, vaa, Вы писали:

vaa>плагин простейший: блочное шифрование потока байт.
vaa>т.е. и зависимостей то не должно быть.
Зависимости будут в основном от platform libs, но это всё всегда в комплекте.

vaa>вообщем, я в этом не особо разбираюсь.
С этого ващета надо было начинать

vaa>#include <winsock2.h>
Нужен для WSAStartup/WSACleanup
Поди плагин ещё и в network ходит зачем то.

vaa>#include <windows.h>
Это главное

vaa>#include <atlbase.h>
vaa>#include <atlstr.h>
Без этого можно и обойтись, нафига в шифровалке MFC/ATL?

vaa>#include <wincrypt.h>
Это собственно для того чтоб заюзать готовый encryption alogrithm, системную имплементацию.

vaa>в proj интересности такие(правда все эти тулзы нужны?):
Какие тулзы? Там ж вообще ничего нет, совершенно пустой базовый конфиг с настройками только для компилятора и линкера.
Можешь эти пустые теги поудалять — ничего не изменится.

CC>·>А почему писали именно на этом языке?
CC>Потому что им не хватало либ под этот язык.

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

Gt_

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, cppguard, Вы писали:

C>>Если дать такое задание плюсовику, то он первым делом подключит буст
CC>Это плохой, негодный плюсовик
А что сделает хороший плюсовик?

Здравствуйте, CreatorCray, Вы писали:

CC>·>А почему писали именно на этом языке?
CC>Потому что им не хватало либ под этот язык.
А под brainfuck либ всем хватает. Верно.

Здравствуйте, CreatorCray, Вы писали:

CC>Ты о чём вообще?
Наверное, речь про файлы проектов, управление зависимостями от сторонних библиотек и опции сборки.

CC>Это уже как напишешь
Ну это вообще универсальный ответ
Написать более-менее хорошую инсталяшку, с интеграцией в процесс сборки в облаках, с подписью и т.п. занимает время.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>>если есть требования к производительности.
НС>·>Оно офигенно скейлится. mssql-ям такое и не снилось.
НС>При чем тут mssql? Опу с пальцем сравниваешь.
Я не знаю что с чем он сравнивает по требованиям к производительности. Но, вот, например, на том же SO вместо "супербыстрого" mssql для поиска воткнули elasticsearch. Т.е. заменив опу на палец удовлетворили требования к производительности.
Мой поинт в том, что производительность можно получить не только вылизыванием кода на "быстрых языках", но и простым скейлингом софта на "медленной" java.

Здравствуйте, scf, Вы писали:

scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.
Тут много есть
Мне обычно Qt хватает.

Здравствуйте, ·, Вы писали:

·>Но, вот, например, на том же SO вместо "супербыстрого" mssql для поиска воткнули elasticsearch.

И? FTS, мягко говоря, это не основной функционал сиквела.

·>Мой поинт в том, что производительность можно получить не только вылизыванием кода на "быстрых языках", но и простым скейлингом софта на "медленной" java.

Но сравнивать то кассандру надо не с сиквелом, а с той же сциллой.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Но, вот, например, на том же SO вместо "супербыстрого" mssql для поиска воткнули elasticsearch.
НС>И? FTS, мягко говоря, это не основной функционал сиквела.
И? В чём твой поинт-то? Что FTS это бизнес-логика? Ознакомься

Автор: smeeld
Дата: 21.05.22

с контекстом обсуждения, прежде чем отвечать на вопросы.

НС>·>Мой поинт в том, что производительность можно получить не только вылизыванием кода на "быстрых языках", но и простым скейлингом софта на "медленной" java.
НС>Но сравнивать то кассандру надо не с сиквелом, а с той же сциллой.
По каким критериям и с какой целью сравнивать?

Здравствуйте, ·, Вы писали:

НС>>И? FTS, мягко говоря, это не основной функционал сиквела.
·>И? В чём твой поинт-то? Что FTS это бизнес-логика?

Поинт в том что хорошей производительности FTS у сиквела никто и не обещал.

НС>>·>Мой поинт в том, что производительность можно получить не только вылизыванием кода на "быстрых языках", но и простым скейлингом софта на "медленной" java.
НС>>Но сравнивать то кассандру надо не с сиквелом, а с той же сциллой.
·>По каким критериям и с какой целью сравнивать?

Только вот в проде никто не юзает, если есть требования к производительности.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>И? FTS, мягко говоря, это не основной функционал сиквела.
НС>·>И? В чём твой поинт-то? Что FTS это бизнес-логика?
НС>Поинт в том что хорошей производительности FTS у сиквела никто и не обещал.
Т.е. mssql fts "в проде никто не юзает, если есть требования к производительности", а используют "медленные" java-решения. Так что тезис опровергнут, можно сворачивать обсуждеине.

НС>>>·>Мой поинт в том, что производительность можно получить не только вылизыванием кода на "быстрых языках", но и простым скейлингом софта на "медленной" java.
НС>>>Но сравнивать то кассандру надо не с сиквелом, а с той же сциллой.
НС>·>По каким критериям и с какой целью сравнивать?
НС>

НС>Только вот в проде никто не юзает, если есть требования к производительности.

Кассандру в проде много кто использует, в том числе для удовлетворения требований к производительности. Более того, этот тезис был не о кассандре конкретно, а для вообще "СУБД на яве". Так что я до сих пор не понимаю какой именно тезис ты пытаешься отстоять.

Здравствуйте, ·, Вы писали:

·>Кассандру в проде много кто использует, в том числе для удовлетворения требований к производительности. Более того, этот тезис был не о кассандре конкретно, а для вообще "СУБД на яве". Так что я до сих пор не понимаю какой именно тезис ты пытаешься отстоять.

Я намекаю на то, что попытка этот тезис аргументировать сравнением с сиквелом, да еще и не с ним самим, а с его FTS — ну так себе.

Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>>У жавы очень ограниченный доступ к системному API. Ты или с жавой мало работал, или не договариваешь. Там на любой чих надо писать свою DLL-ку на JNI (на C/C++, ага). Банальный макосовский xattr (для доступа к extended file attributes) я в жаве не нашел, например.

НС>Серьезно?

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

vsb>>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.

НС>sun.nio.ch.DirectBuffer.cleaner()?

Тогда уж sun.misc.Unsafe#invokeCleaner но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Кассандру в проде много кто использует, в том числе для удовлетворения требований к производительности. Более того, этот тезис был не о кассандре конкретно, а для вообще "СУБД на яве". Так что я до сих пор не понимаю какой именно тезис ты пытаешься отстоять.
НС>Я намекаю на то, что попытка этот тезис аргументировать сравнением с сиквелом, да еще и не с ним самим, а с его FTS — ну так себе.
Ну ок. Если я сравню elasticsearch c mssql fts, придирки останутся?

Здравствуйте, ·, Вы писали:

НС>>Я намекаю на то, что попытка этот тезис аргументировать сравнением с сиквелом, да еще и не с ним самим, а с его FTS — ну так себе.
·>Ну ок. Если я сравню elasticsearch c mssql fts, придирки останутся?

Останутся, но другие. Для первого это основной функционал, а для второго — сбоку припека. Хочешь сравнить эластик — сравни со сфинксом.

Здравствуйте, vsb, Вы писали:

НС>>Серьезно?
vsb>Я про стандартную библиотеку.

А это не стандартная? И в исходном сообщении ты ничего про стандартность не говорил. И звучит оно в таком раскладе уже совсем иначе — мало ли чего там в стандартной библиотеке нет.

vsb>>>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.
НС>>sun.nio.ch.DirectBuffer.cleaner()?
vsb>Тогда уж sun.misc.Unsafe#invokeCleaner

Это хак через рефлекшен. А вот то что я привел — вполне себе публичный АПИ.

vsb> но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.

Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.

Здравствуйте, vsb, Вы писали:

НС>>Серьезно?
vsb>Я про стандартную библиотеку. В которой, между прочим, есть нужные интерфейсы, но реализовать их никто не потрудился. Вот такой системный язык.
Оказывается потрудились. Уже доступно в 17-й версии.

Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>> но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.
НС>Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.
Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, vsb, Вы писали:

НС>>>Серьезно?
vsb>>Я про стандартную библиотеку.

НС>А это не стандартная

JNA? нет, не стандартная.

vsb>>>>Ещё есть забавный прикол. Для mmap в жаве есть интерфейсы. Но закрыть MappedByteBuffer невозможно.
НС>>>sun.nio.ch.DirectBuffer.cleaner()?
vsb>>Тогда уж sun.misc.Unsafe#invokeCleaner

НС>Это хак через рефлекшен. А вот то что я привел — вполне себе публичный АПИ.

sun.* это внутренний API, а с включенными модулями вообще недоступен. Ну или напиши полный код, а то я тебя не очень понимаю пока. Вот пример моего кода:

        var path = Path.of("/Users/user/Downloads/ticket.pdf");
        var fileChannel = FileChannel.open(path);
        var mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_ONLY, 0, fileChannel.size());

        var b0 = mappedByteBuffer.get(0);
        System.out.println(b0);

        var theUnsafeField = Unsafe.class.getDeclaredField("theUnsafe");
        theUnsafeField.setAccessible(true);
        var unsafe = (Unsafe) theUnsafeField.get(null);
        
        unsafe.invokeCleaner(mappedByteBuffer);

        var b1 = mappedByteBuffer.get(1);
        System.out.println(b1);

vsb>> но этот способ в будущих ждк отрубят, и сейчас по-моему надо специальные флаги прописывать, чтобы оно работало. С "невозможно" написал некорректно, невозможно сделать "правильно", без хаков.

НС>Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Я намекаю на то, что попытка этот тезис аргументировать сравнением с сиквелом, да еще и не с ним самим, а с его FTS — ну так себе.
НС>·>Ну ок. Если я сравню elasticsearch c mssql fts, придирки останутся?
НС>Останутся, но другие. Для первого это основной функционал, а для второго — сбоку припека. Хочешь сравнить эластик — сравни со сфинксом.
Ну сравни, посмеёмся. Например, elasticsearch в проде используют на порядки больше, чем сфинкс. А если ещё Solr добавить, то сфинкс и в микроскоп не видно, типичный legacy.

Господи, они фильтруют атрибуты и возвращают только те, которые начинаются на "user."

            List<String> attrNames = list(fd, MIN_LISTXATTR_BUF_SIZE);
            return attrNames.stream()
                    .filter(s -> s.startsWith(USER_NAMESPACE))
                    .map(s -> s.substring(USER_NAMESPACE.length()))
                    .toList();

Системный язык, блин.

Здравствуйте, vsb, Вы писали:

vsb>Господи, они фильтруют атрибуты и возвращают только те, которые начинаются на "user."
Ну так user-defined атрибуты

Здравствуйте, ·, Вы писали:

НС>>Ну так вроде тебе сказали почему. Хотя вот в дотнете сделать у MMF Dispose это не помешало.
·>Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.

Оно и в яве unmanaged. В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.
НС>Оно и в яве unmanaged.
Это неверно.

НС>В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.
Тоже пилят: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, ·, Вы писали:

S>·>Cassandra, Kafka, h2database, куча их.

S>Хеллоуворлдных СУБД всяких прикола ради даже на бейсике полно написано. Только вот в проде никто не юзает, если есть требования к производительности.

требования к производительности
http://h2database.com/html/performance.html
Честно, ни в одном языке(кроме си ) не видел такого количеств СУБД на самом ЯП.
Пользовал h2 и derby, проблем никогда не было,
в отличии от ms sql который любит базу помечать как испорченную и не вывозит, если оперативы меньше чем сама база.
Так что не знаю, не пробовал не значит что ничего нет.

Здравствуйте, ·, Вы писали:

НС>>·>Потому что в дотнете оно unmanaged memory и гарантий безопасности как в яве нет.
НС>>Оно и в яве unmanaged.
·>Это неверно.

Верно.

НС>>В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.
·>Тоже пилят: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html

Ну пусть пилят. В дотнете то давно напилено.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Это неверно.
НС>Верно.
С чего ты взял? Обращения к MappedByteBuffer в java — безопасны.

НС>>>В дотнете, по крайней мере, Memory<T> есть, а в джаве только JNI.
НС>·>Тоже пилят: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html
НС>Ну пусть пилят. В дотнете то давно напилено.
Это стандартный API, а так direct buffers там доступны давным давно.

Здравствуйте, ·, Вы писали:

НС>>·>Это неверно.
НС>>Верно.
·>С чего ты взял? Обращения к MappedByteBuffer в java — безопасны.

Это не managed pool, это unsafe кусок памяти.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Верно.
НС>·>С чего ты взял? Обращения к MappedByteBuffer в java — безопасны.
НС>Это не managed pool, это unsafe кусок памяти.
С т.з. публичного API — обращение к нему безопасно. А как оно там устроено вунутре — детали имплементации. В шарпе ошибки с Unmanaged memory роняют всё непредсказуемо.

Здравствуйте, ·, Вы писали:

·>С т.з. публичного API — обращение к нему безопасно. А как оно там устроено вунутре — детали имплементации. В шарпе ошибки с Unmanaged memory роняют всё непредсказуемо.

Ничего там непредсказуемо при работе с MMF не роняется, не переживай. Точно так же все завернуто в safe обертку.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>С т.з. публичного API — обращение к нему безопасно. А как оно там устроено вунутре — детали имплементации. В шарпе ошибки с Unmanaged memory роняют всё непредсказуемо.
НС>Ничего там непредсказуемо при работе с MMF не роняется, не переживай. Точно так же все завернуто в safe обертку.
Вот эта переменная не volatile. Значит thread может писать в закрытый другим тредом аксессор до порчи хз какого адреса памяти. Чудес не бывает.
Понимаю, индусне в микрсофте плевать на такие мелочи, но java заботится о безопасности.

Здравствуйте, scf, Вы писали:

scf>Что касается сокетов — много ли в плюсах кросплатформенных, быстрых, асинхронных сетевых библиотек, поддерживающих HTTP(S) полноценно, со всеми плюшками? И которыми можно пользоваться без содрогания.

В кути вобще не задумывался об этом

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>С т.з. публичного API — обращение к нему безопасно. А как оно там устроено вунутре — детали имплементации. В шарпе ошибки с Unmanaged memory роняют всё непредсказуемо.
НС>Ничего там непредсказуемо при работе с MMF не роняется, не переживай. Точно так же все завернуто в safe обертку.
Да, ты прав. Оно не роняется, а просто безбожно тормозит. По сравнению с java на микробенчмарке putLong(getLong() + 1) работает в ~20 раз медленнее (2.5ns vs 45ns). Т.к. там каждое обращение к буферу идёт через обёртку SafeHandle с ref-counter через volatile, тогда как java просто пишет в область памяти напрямую. По-моему, это на корню убивает идею MMF — когда обращение к замапленной области должна быть просто обращением к физ.памяти. Индусы.

	java
	import java.nio.*; import java.nio.channels.*; import java.nio.file.*; public class Program { public static void main(String []args) throws Exception { try(var fc = FileChannel.open(Paths.get("file.data"), StandardOpenOption.READ, StandardOpenOption.WRITE)) { var buf = fc.map(FileChannel.MapMode.READ_WRITE, 0, 16); var t = new Thread(() -> { long stopWatch = System.nanoTime(); for(long i = 0; i < 10_000_000_000L; ++i) { long val = buf.getLong(0); buf.putLong(0, val + 1); if(i % 1_000_000_000L == 0) { long stopWatchElapsed = System.nanoTime() - stopWatch; System.out.println(String.format("i=%s, val=%s, ns=%s", i, val, stopWatchElapsed)); stopWatch = System.nanoTime(); } } }); t.setDaemon(true); t.start(); System.out.println("started"); Thread.sleep(15000); } System.out.println("closed"); Thread.sleep(1000); } }

	c#
	using System; using System.Diagnostics; using System.IO; using System.IO.MemoryMappedFiles; using System.Runtime.InteropServices; class Program { static void Main(string[] args) { using (var mmf = MemoryMappedFile.CreateFromFile(@"file.data", FileMode.Open)) { // Create a random access view, from the 256th megabyte (the offset) // to the 768th megabyte (the offset plus length). using (var accessor = mmf.CreateViewAccessor(0, 16)) { var t = new Thread(() => { var stopWatch = Stopwatch.StartNew(); for(int i = 0; i < 1_000_000_000; ++i) { long val = accessor.ReadInt64(0); accessor.Write(0, val + 1); if(i % 100_000_000 == 0) { stopWatch.Stop(); Console.WriteLine("i={0}, val={1}, elapsed={2}", i, val, stopWatch.Elapsed); stopWatch = Stopwatch.StartNew(); } } }); t.Start(); System.Threading.Thread.Sleep(15000); } } System.Threading.Thread.Sleep(1000); } }