Компания IBM передала некоммерческой организации Eclipse Foundation управление над разработкой проекта J9 (https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/...), в рамках которого развивается реализация виртуальной машины Java (JVM), которая может использоваться в качестве замены виртуальной машине Hotspot в OpenJDK. Организация Eclipse Foundation утвердила приём J9 в число проектов Eclipse и включила новый проект в инкубатор под именем OpenJ9 (http://www.eclipse.org/openj9/). Код проекта открыт (https://github.com/eclipse/openj9) под свободной лицензией EPL 2.0.OpenJ9 может применяться совместно с набором классов и компилятором из состава OpenJDK. Из особенностей OpenJ9 отмечается ориентация на выполнение промышленных Java-проектов, обеспечение высокой производительности, низкое потребление памяти, быстрый запуск и пригодность для выполнения большого числа Java-приложений в облачных окружениях. В основе OpenJ9 лежат проверенные и уже зарекомендовавшие себя технологии, на базе которых построены многие промышленные программные продукты IBM, в том числе линейка продуктов WebSphere.
По сравнению с Hotspot упоминается более совершенный JIT-компилятор и наличие средств тонкой настройки под специфику выполняемых приложений. Например, можно менять режимы работы сборщика мусора, выбирая различные сценарии управления памятью для различных видов нагрузки. Кроме того, имеются средства для привлечения специфичных аппаратных возможностей для ускорения выполнения приложений, такие как вынос некоторых вычислений на плечи GPU.
Предоставляемые в OpenJ9 технологии совместного использования классов и упреждающей компиляции позволяют на 20-40% сократить время запуска Java-приложения, что делает OpenJ9 хорошим решением для облачных систем и задач, в которых требуется запуск большого числа приложений с коротким временем жизни. Для большего сокращения времени запуска также предоставляется режим "-Xquickstart", позволяющий разработчикам без задержек тестировать разрабатываемые проекты.
URL: https://www.reddit.com/r/java/comments/70g52a/ibm_has_open_s.../
Новость: http://www.opennet.me/opennews/art.shtml?num=47220
Процесс набирает обороты и скоро станет необратимым: большие компании начинают избавляться от Явы.
Ура!
Избавляться в пользу чего? Жаба когда-то заменила Cobol. Что заменит жабу?
Brainfuck
Да какая разница? Ну явно же не Лисп с Эрлангом. Так что любое изменение к лучшему...
Да ладно! А ну как на JS начнут всё писать? Тут сложно сказать, что хуже. От конкретного проекта, конечно, зависит
Фактор?
> Жаба когда-то заменила Cobol. Что заменит жабу?Шо ви гоните. Какой нафег Кобол. На него уже начале 90-х все забили,
на жабу до 2000 никто и не смотрел, кроме фанатов Sun Microsystems
Расскажите это тем, кто поддерживал понаписанное за годы использование овнище ещё 10+ лет
> Расскажите это тем, кто поддерживал понаписанное за годы использование овнище ещё 10+ летКакая разница за что бабло получать, если платят?!
Периодически чиню антиквариат из MSDOS и базы FoxPro. Думашь я плачу когда мне деньги переводят?!
"Кому и кобыла - невеста".Сравнил тоже тёплый ламповый DOS и жабу...
> Сравнил тоже тёплый ламповый DOS и жабу...Java заточена под мир RISC, тупое на тупом быстрее работает, чем на x86 писюках.
заточена на RISC?ты на ARM пробовал запускать openjdk?
> заточена на RISC?
> ты на ARM пробовал запускать openjdk?а arm - это risc, затупленный под батарейное питание. для него "не-ява" андроида.
> заточена на RISC?
> ты на ARM пробовал запускать openjdk?И чего дальше-то?
>Периодически чиню антиквариат из MSDOS и базы FoxPro.Мдааааа ... Это что же из бусинес-логик-в-натуре-братки из 90-х до сих пор в продакшене?! Ну - ну реально, что?! И у кого?! 8-о
>Думашь я плачу когда мне деньги переводят?!Думаю да - потому что походу с нищих берешь :)
Жаба заменила кресты. Она вполне официально создавалась как нечто близкое к крестам но в нормальном виде.
Да никогда она не заменит. Хочешь производительность на пару порядков больше - пиши на языке, который после сборки бинарника выполняется на железке без посредников.
> Да никогда она не заменит. Хочешь производительность на пару порядков больше -
> пиши на языке, который после сборки бинарника выполняется на железке без
> посредников.Ой ли? Так что ж вы не соберетесь и не напишите как следует? Что мешает?
Парень видно дурачок, таким нужно переписать ядро Linux на Java (которая по их словам кошерным сям не уступает) и пересадить их всех туда! (может они все деньги на оперативку растратят и с голоду помрут, а мир станет немного лучше:)
Что я должен переписать? Ты сначала узнай в интернетах о разнице elf от jar, а потом уже яростно кнопки нажимай.
>> Хочешь производительность на пару порядков большеМесье заморозился в 1995-96 году?
Перетаскиваю проекты по работе, знаю, о чём пишу, собственно.
Брешешь как шавка. Я вот последний кто скажет в защиту жабы хоть слово. Но - пару порядков ... "Остапа несло" (С) :-р
Ага, ага. Программистам уровня "hello, world" этого не понять.
О как! Ну выкладывай свою нетленку, посмотрим где там ускорение на _два_порядка_ ...
А ты точно знаешь сколько это в разах, а "программист офигенного уровня"? :-)
У программистов порядки двоичные.
Му-ха-ха :) Это - да, уел :)
> Брешешь как шавка. Я вот последний кто скажет в защиту жабы хоть
> слово. Но - пару порядков ... "Остапа несло" (С) :-р
23. Compilation and memoization can yield 100-fold speed-ups. [p. 307]--https://duckduckgo.com/?q=Compilation+and+memoization+can+yi...---Чтобы ускориться в 100 раз,... ...надо сначала _знатно_ притормозить[I]!
Плюсам равных нет.
С Вами все согласны (вопрос только "нет равных в чем?")>>> С++ — кошмарный язык. Его делает ещё более кошмарным тот факт, что множество недостаточно грамотных программистов используют его, до такой степени, что оказывается намного проще выкинуть его как мусор. Откровенно говоря, даже если нет *никаких* причин для выбора Си, кроме того чтобы держать С++-программистов подальше — то одно это уже будет достаточно веским основанием для использования Си.
Это же была сказано в отношении ядра, верно? А в обсуждении выше речь шла о сравнении C++ и Java. Так что не надо подменять понятия.
> Это же была сказано в отношении ядра, верно?Нет, в отношении git.
Вот ведь минусяторы упоролись…From: Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT
О, еще один неосилятор! Да откуда вы лезете то, на плюсах есть множество проектов с чистым красивым кодом написанным по последним стандартам. А товарищи посмотрев (deprecated вперемешку с го*но-кодом) код начинают вопить, кресты го*но. Это не кресты го*но а вы, если программируя и интересуясь языком, вы не читаете его спеки, его нововведения, рекомендации. Ну а некоторые просто не могут осилить паттерны проектирования и соответственно чтение чужого структурированного кода, они продолжают писать свои одно файловые полотенца, и вопят кресты го*но!
Вот о вас Линус и писал. Иди выучи еще пару паттернов.
>на плюсах есть множество проектов с чистым красивым кодом написанным по последним стандартамНу так подключи нас к этому кладезю ништяков! Накидай ссылок на такое чудо-чудное!
...
...
... и тишина :)))
равных в производительности и обьёме памяти ? ну попробуй мне ассемблещику про плюсы что-либо обоснованно доказать в этом плане
>равных в производительности и обьёме памяти? ну попробуй мне ассемблещику про плюсы что-либо обоснованно доказать в этом планеОкей, пишем на спор СУБД уровня MongoDB? Даже ансисишечкины причмокивают когда надо что-то путнее написать. Хотя я сомневаюсь, что ты ассемблерщик, они все уже от старости померли.
Интересно, каким боком объектный язык с виртуальной машиной заменили компилируемый язык с полным отсутствие понятия «стоимость ошибки в коде»? C++ мертворожденный уродец, требующий от своих жертв (зачеркнуто) программистов поклонения. Яве бы оглянуться на что то мирское, на go с его доктриной - проще/лучше и провести полный рефакторинг RTL-а, научиться нормально ликовать и т.д... Да, мечты, мечты...
Зачем делать из жабы го, если уже есть го?
Язык программирования - это совокупность множества факторов. Ява имеет свою нишу и свою кодовую базу. Но она, из-за излишнего использования ООП (или из-за слабенькой JVM, тут как посмотреть), выглюдит монструозно.
А Вы предлагаете потратить чужие деньги на переписывание/переход на go, просто потому что вы "эксперт"?
"из-за излишнего использования ООП" - что-то новое ) можно поподробней?
Иногда абстракция присутствует, а функционал не используется. Это такие антидырявые абстракции - код есть, обвязка есть, структура усложнена (вместо куска памяти дерево, да еще и с индексом, сотня методов и все только для чтения и хранения списка объектов), а вы ничего сделать не можете, потому что для Вас это черный ящик.
Раньше на яве ОС писали (с ядром, как в Обероне), но это оказалось не нужным и не интересным, да и стабильность страдала. Теперь стабильно и жирно
> А Вы предлагаете потратить чужие деньги на переписывание/переход на go, просто потому
> что вы "эксперт"?Нет, этого я не предлагаю. Это товарищ выше предлагал упростить жабу по образу и подобию го, в результате чего действительно пришлось бы тратить эти самые деньги на переписывание существующего кода.
Оправданно ли тянуть легаси-код на жабе — это в каждом отдельном случае надо решать индивидуально. А вот писать на ней что-то с нуля я абсолютно никакого смысла не вижу.
Ыгсперд, чо.
А что писать - тебе по барабану?
Надо же до чего дошёл прогресс! Раньше смотрели чего же надо получить в результате, а потом смотрели каким инструментом это лучше делать.
А теперь главное - выбрать красивый инструмент, чтоб в блестящей обёртке, да? ... а потом "все проблемы начинают выглядеть как гвоздь"?
Да вот же незадача - и это уже было :-\ "Суета сует" (С) Один старый грек
Java и Go в плане приложимости к тем или иным задачам почти идентичны.
:)
Дьявол - в деталях, мою йунный друх ....
> Жаба заменила кресты. Она вполне официально создавалась как нечто близкое к крестам
> но в нормальном виде.Кстати, в подтверждение Вашего тезиса: Брюс Эккель автор "Thinking in c++", потом написавший и "Thinking in Java", почти во всех главах пишет "в плюсах это делается вот так, а теперь смотрите как это сделали нормально в java".
А Мигель де Иказа... Гхм, знаешь, люди иногда по самым разным причинам меняют вкусы, убеждения, принципы. Так бывает. И если Б.Эккель перешёл на Яву, то это значит... да ничего это не значит.
И чо с Мигелюшкой? Писал mc, wine и дрова (предположительно в основном на СИ). Щас пишет mono предположительно на си.
Ну почему же, скоро напишет "Thinking in Phyton" и вы все узнаете где всё сделано по нормальному!
А потом жабаскрипт. А потом ...
Волка ноги кормят, а аффтара - авторские! (С)
Никому не верь и не придётся разочаровываться (С)
Ну шо ви как дети малые?! (С)
>скоро напишет "Thinking in Phyton"Мечты, мечты... Полагаю, что он в "Thinking in Python" напишет как и в сишной книжке, что в жабе лучше.
А работа полученного кода (скорость, потребление памяти) там сравнивается? Или Вам и Вашему Эккелю важна только изящность сырцов?
И давно ты в своём Склад-Магазине с такими проблемами сталкивался?
Хотя конечно, у тебя же хайлоад, как же я мог подумать про такое ... :-)А изящность сорцов выходит что нужна, ибо люди перестали осиливать. А лобастиков из НАСА ты на свой склад-магазин не наймёшь :-\ Оно уже и у НАСы с этим проблемы начались ...
> А работа полученного кода (скорость, потребление памяти) там сравнивается?ОК, давай сравним скорость графовых СУБД, называй полный аналог по фичам neo4j или продвинутых KV-носклей с идеальной масштабируемостью (только не надо про редиску).
> Или Вам и Вашему Эккелю важна только изящность сырцов?
В целом да, когда надо вычитать файл в память, BufferedReader раза в 2 быстрее чем FileUtils.readlines, но это ж на пару строчек дольше писать. Обычно FileUtils.readlines хватает.
Это уже которая по счёту тема, в которой вы показываете, что Вам нечем похвастаться, кроме графовых ДБ? А давайте лучше сравним реляционную ДБ на жабе с постгресом? А давайте сравним веб-сервер на жабе с нжинксом или водой? А давайте сравним почтовый сервер на жабе с постфиксом? А давайте сравним коммутатор VoIP на жабе с FreeSwitch или Asterisk? А давайте любой WebDAV-сервер на жабе сравним с LeoFS?
>нечем похвастаться, кроме графовых ДБОК, по графовым сливу засчитал ;)
>давайте лучше сравним реляционную ДБ
А давайте не будем наступать в Г? Реляционные СУБД отжили своё в 90-х. По NOSQL я уже Кассандру назвал, си-аналогов нет, убогий Scylla не пойдёт.
>веб-сервер на жабе с нжинксом
А давайте не будем наступать в Г? Веб-сервер это очередное понятие из 90-х. Давайте сравним серверы приложений. У меня вся вебня на jboss, у сишников НИЧЕГО подобного нет и не будет.
>почтовый сервер на жабе
ещё сравнить helloworld-ы предложи.
>коммутатор VoIP на жабе с FreeSwitch или Asterisk
Опять какие-то поделки. Телефония должна быть аппаратной. Тчк.
До кучи напомню про полнотекстовый поиск. Все проекты на lucene лепятся, убогий сфинкс никому не нужен кроме сишных фанатиков.
Итого сплошные сливы у могучих сишников... :(((
То есть, кроме "всё это не модно" ответить нечего.
>ОК, давай сравним скорость графовых СУБД,А к стати: https://dgraph.io/ рвёт твою ... как Тузик грелку! (С) LOR
Спасибо за информацию.Я так понимаю, ты в этом вопросе полный ноль, просто бенчмарки от самих дграфов увидел навроде https://blog.dgraph.io/post/benchmark-neo4j/
которые эпичны в своей рукоЖпсти судя по "dgraph 160X faster".При этом shortestPath, а особенно allShortestPaths с кастомным траверсером они не меряли. Зачем, конфуз же выйдет. Всё очень в духе OrientDB с ArangoDB, они тоже рвут Нео4ж как тузики. Пока до реальной эксплуатации не дойдет, а там оказывается, что как тузики они только тяфкают ;)
Вдогонку...https://docs.dgraph.io/faq/
If you’re looking for a stable, mature database, Dgraph wouldn’t be the right fit for youБагтрекер их посмотрел, поплакал...
Всё очень по-сишному - написать глючный прототип с функционалом 20%, который в сферических условиях и влажных мечтах быстрее рабочих программ на других языках и бежать вешать на себя пафосные ярлыки вида "FASTEST GRAPH DATABASE IN THE MARKET".
Очевидно что это будет .Net Core.
> Очевидно что это будет .Net Core.Очевидно, что жаба это очень надолго. Шарпей к тому времени уже завернет ласты.
>> Очевидно что это будет .Net Core.
> Очевидно, что жаба это очень надолго. Шарпей к тому времени уже завернет
> ласты.шарпу без малого 17 лет, куда он и что должен заворачивать?
>>> Очевидно что это будет .Net Core.
>> Очевидно, что жаба это очень надолго. Шарпей к тому времени уже завернет
>> ласты.
> шарпу без малого 17 лет, куда он и что должен заворачивать?Язык и платформа одной компании. Что-то вроде Nokia Symbian. Есть компания - есть платформа. Нет стабильного API, нет мультиплатформенности (только Core - это ниочем), нет UI, нет обратной совместимости.
Java или Qt как открытые платформы переживут кого угодно. Слишком много на них завязано.
Живёт он только потому, что постоянно и активно впаривается. Реклама, книги и прочее. Сфера его применения весьма сужена. Это продукт одной компании с хреновой репутацией. Имхо очевидно, что МС плохой разработчик. У них нет творческих достижений, искры. Вся их стратегия скопировать чужую идею и попытаться перетянуть одеяло на себя. Примеров тому достаточно. Соответсвенно, какой смысл вообще начинать изучать шарпея, тем самым вгонять себя на узку дорожку МС-онли? И не нужно его сравнивать с экосистемой Java. Шарпей навсегда останется полукровкой, потому что когда его зачинали объектоми возбуждения была Java и её успех, а не творческий порыв.Есть разрабы, которым по барабану на чем писАть - ли ж бы платили, и они и не гавкают на жабу и прочее. А есть те, кто сел не на тот поезд и подсознательно разочаровались и устраивают нападки, в попытках оправдать свой неудачный выбор.
Вам ли о нападках говорить? Да и дорожка становится все шире и шире. Лишь в одном вы правы... прибыль - двигатель прогресса. А что до платформы - она просто хороша! Да и назвать С# плохим языком язык не поворачивается. И идите вы со своим творчеством... не в программисты. Один лингвист уже родил такой язык. Со всеми вытекающими последствиями...
Есть же Unity3D в конце-концов. И игры пишутся на C#.
> Да и назвать С# плохим языком язык не поворачивается.Рот занят?
У шарпа есть полезные фичи (value-типы, дженерики без type erasure, linq и пр.), которых у жабы нет и никто не знает, будут ли вообще. Но завязка на MS всё портит.
Ложка меда в бочке дегтя.Правильней говорить Java платформа.
Не устраивает Java как язык, есть другие работающие на JVM - Scala, Ceylon, Kotlin, Closure, Xtend, x10, Fantom, Golo, Gosu и др.
GO.
/s
ну ну.... и переходят на Ruby?Нет альтернативы жаве в ближайшие 5 лет. Ну совсем нет. Да и незачем пока что её делать.
Совершенно верно. Миру достаточно одного языка доведшего ООП до абсурда.
Поясни в каком месте абсурд.
>> большие компании начинают избавляться от Явы. Ура!Большие компании ОКОНЧАТЕЛЬНО ПЕРЕХОДЯТ на Яву.
Свидетельство тому — передача кода.
Вы существуете в бреду, Шталь.
Просто с hotspot все сложнее конкурировать... Да и незачем.
>Просто с hotspot все сложнее конкурироватьОчередное экспертное мнение опеннетчика? Я конечно не гуру по IBMовским шкафам, но сложилось впечатление, что их JVM под mainframe-ы на порядок круче, чем hotspot.
Вопрос только почему?
И вопрос в том, а какие перспективы у их железа, а есть ли чего ещё там допиливать в таких количествах что-бы имело смысл держать контроль за J9 у себя.
> Вопрос только почему?
> И вопрос в том, а какие перспективы у их железа, а есть
> ли чего ещё там допиливать в таких количествах что-бы имело смысл
> держать контроль за J9 у себя.На мейнфреймы конкретно подсажены банки. У нас так почти поголовно из первой ну наверное 20-ки.
За исключением того, что не всякое приложение в традиционном джява-контексте запросто взлетает в их мире. Иногда приходится закатывать рукава и брать напильник покрупнее, а саппорт в плане джявы у ивм-а ... ну ораклиный дб-саппорт даже рядом не стоял... В целом впечатление неплохое, но до ума доводить надо.
Вам крупно повезло:)
У меня есть реальный опыт возни с ними. IBM JVM в смысле. Почти неплохо, но... средств дебагга что произошло, только корки собирать и пытатся самому разбиратся, либо делаем корку и отправвляем в саппорт их:(
первая мысль похожая была, но подумав, скорее понимает что Oracle угробит Яву...Поэтому спасает, дав свежей крови
> В основе OpenJ9 лежат проверенные и уже зарекомендовавшие себя технологии, на базе которых построены многие промышленные программные продукты IBMспасибо, но мы их немного знаем поэтому не надо.
Если есть опция -Xquickstart, то зачем нужен медленный режим? И нет ли опции -Xquickwork?
> Если есть опция -Xquickstart, то зачем нужен медленный режим? И нет ли
> опции -Xquickwork?Это трейдофф между быстро стартовать и относительно "медленнее" ехать ИЛИ медленнее стартовать и быстрее поехать.
Для долгоживущих приложений выгоднее второе. Для приложение которые стартуют на каждый блок данных, затем отключаются - выгоднее первое.
извини, забыл тег закрыть: </сарказм>
Сейчас все используют веб технологии, js и прочие подобное, жава это уже легаси софт. Вот и избавляются от поддержки проектов на ней.
> Сейчас все используют веб технологии, js и прочие подобное, жава это уже легаси софтт.е. ява не используется для веб-технологий? Ой уморил... Для тебя веб-технологии - это только то, что крутится непосредственно в браузере? Т.е. серверная сторона дела к веб-технологиям отношения не имеет? А еще грядет неотвратимое наступление WebAssembly - в него в будущем будет компилироваться куча разных языков программирования, включая, наверняка, и яву и ява-скрипт - тяжело тебе будет классифицировать тот или иной язык как "использованный в веб-технологиях" или неиспользованный
>> Сейчас все используют веб технологии, js и прочие подобное, жава это уже легаси софт
> т.е. ява не используется для веб-технологий? Ой уморил... Для тебя веб-технологии -
> это только то, что крутится непосредственно в браузере? Т.е. серверная сторона
> дела к веб-технологиям отношения не имеет? А еще грядет неотвратимое наступление
> WebAssembly - в него в будущем будет компилироваться куча разных языков
> программирования, включая, наверняка, и яву и ява-скрипт - тяжело тебе будет
> классифицировать тот или иной язык как "использованный в веб-технологиях" или неиспользованныйWebAssembly позволит запускать Legacy-овно в веб-окружении. Ок.
WebAssembly позволит быстрее запускать Unity-игры. Ок.
Для всего остального есть JS.
> Для всего остального есть JS.Конечно, я не экстрасенс и совсем-совсем далеко не гуру в IT, простой средненький быдлoкодер, но мне кажется развитие в этом направлении будет следующим. Сначала реализуют полноценный WebAssembly-движок (WA-движок), работающий в песочнице, аналогичной по доступам и ограничениям песочнице для JS-движка, с не меньшей функциональностью, чем у JS-движка. Какое-то время они будут развиваться параллельно ( WA-движок - развиваться, а JS-движок - поддерживаться). Когда все по WebAssembly устаканится и станет дремучим стандартом - разработчики браузеров напишут прослойки, которые на лету будут принимать сырой JS-код, компилировать его в WA-код и скармливать его WA-движку. И выкинут JS-движок
Зачем ещё одна технология для бэка? Там тоже жс и ли тс достаточно. Если так нужна жвм на бэке то можно юзать кложуре или котлин. Только опять же зачем?
А зачем Ваша эта еще одна js-технология на бэке? И дело не в "жвм на бэке", не жвм главное, а сравнительно богатый выбор серверов приложений (хочешь - открытых и бесплатных, хочешь - коммерческих с поддержкой). Можно не зная JS и хтмл (а только одну яву) писать достаточно сложные веб-приложения (используя многочисленные реализации стандарта JSF или что-нибудь из Spring'а или всякие самостоятельные гибриды типа ZK). Фреймворков полно. Так что конкретно для меня Ваш жс - это "еще одна (лишняя) технология для бека"
Берешь JS и пишешь любое полноценное веб-приложение. Node/Express тебе в помощь, товарищ.
Не полноценное, а целиком на js приложение.
> Берешь JS и пишешь любое полноценное веб-приложение.
> JS
> полноценноеНельзя на ноль делить. Садись - двойка.
Берем JS и быстро фигачим.
А через некоторое время оказывается, что есть веб-приложение,
в котором несколько мегабайт скриптов,
и тривиальный рефакторинг вызывает непредсказуемые последствия в продакшн рантайме.Что дальше делаем?
Фигачим дальше.
>> Можно не зная JS и хтмл (а только одну яву) писать достаточно сложные веб-приложения ...Брал я этот ZK:
Но по "закону дырявых абстракций" всё ок
только пока ZK-компоненты делают ровно то, что задумали их авторы.
А если компонент работает немного не так, то тут уж надо знать хорошо и яву и JS и прикладную магию.Брал я scala.js:
Код намного красивей JS-ового получается.
Только вот сорсмапы слетели, и я уже развлекаюсь отладкой генереного JS.Сейчас взял React на клиенте и сделал синхронизацию vdom-a с сервером на jvm:
https://github.com/conecenter/c4proto
> все используютОтучаемся говорить за всех.
> веб технологии, js и прочие подобноеВ веб-технологиях есть сервер. Сервер на JS - извините, после новостей о малвари в npm-пакетах оставьте себе.
Да всё вокруг *оно*! Почитай новости про струтс\эквифакс, чем это лучше то?
Дафай-дафай - увеличивай бюджет на ИТ, а то сделают больно! ;-)
>после новостей о малвари в npm-пакетах оставьте себе.тебе рассказать почему в других открытых экосистемах нету пакетов с малварью?
Erlang(Flussonic) выдает 20Gbps+ на NVMe, зачем нам нужна Java?
За тем, что есть мощнявый Golang, который может также выжать всю дурь из интернета, как и ерланг, но минус ерланг, что про него уже забыли
А про него вспоминали? У языка нелинейная логика и запредельный порог вхождения. С ним работают только профи. И только там где нужна максимальная надежность и производительность.
это у эрланга производительность?
> это у эрланга производительность?Можете дать ссылку на бенчмарки?
Могу. https://google.gik-team.com/?q=erlang+benchmarks+lang
Доооо... Вычисление числа Пи. Это очень важно.
Таких бенчмарков я пересмотрел десятки, когда выбирал, на какой язык уйти с пыха.
А теперь найдите что-нибудь по запросу "erlang+benchmarks+connections" или "erlang benchmark simultaneous connections", или (раз уж речь в новости о жабе) "erlang vs java benchmark concurrent connections" - только статьи с рассуждениями на тему "как мой любимый язык с хитрыми твиками и новым event-driven фреймворком достиг миллиона соединений". Желательно что-то внятное (с описанием условий эксперимента, таблицами и диаграммами) и достаточно свежее (с использованием версий эрланга, содержащими хотя бы те улучшения, которые упомянуты в Efficiency Guide).
Да. Сам язык медленнее многих оно и понятно. Но он же умеет раскидывать задачи по ядрам. Для большого проекта самое то.
Он один такое умеет? ORLY?!
> Он один такое умеет? ORLY?!А какие ещё есть?
Я бы сказал, что это похоже на автоматическое управление памятью:
В случае другого языка есть подмножество инструментов,
которыми можно решить задачу раскидывания.При этом, в случае другого языка, "любой дятел разрушит галактику" --
Очень просто и естественно выйти из этого подмножества инструментов
и накодить трудноуловимые ошибки.
> А про него вспоминали? У языка нелинейная логика и запредельный порог вхождения.
> С ним работают только профи. И только там где нужна максимальная
> надежность и производительность.Да ладно, ерланг осиливаеться недели за две, а вот русских книг по нему мало. Так что енглишь обязателен. Вообще эрланг один из замечательнейших языков
> А про него вспоминали? У языка нелинейная логика и запредельный порог вхождения.
> С ним работают только профи. И только там где нужна максимальная
> надежность и производительность.Какая у него логика?
С Erlang стоит разобраться хотя бы для того, чтобы понять,
как многое можно (было бы) сделать разумно.Запредельный порог вхождения относителен и определяется:
1) давними привычками входящего писать на js/java/c/etc,
которые специально сделали похожими, чтобы эти привычки не ломать
2) отсутствием книжек "Erlang для самоваров" и "Сайт на Ерлумле за пол часа"Erlang, как язык, очень простой.
> За тем, что есть мощнявый Golang, который может также выжать всю дурь
> из интернета, как и ерланг, но минус ерланг, что про него
> уже забылиЗачем нужен Golang, если Python + Gevent может тоже самое ? только мощность немного поменьше, но на питоне быстрее делать проект
> на питоне быстрее делать проектВообще-то нет.
>> на питоне быстрее делать проект
> Вообще-то нет.Поясните поподробнее, пожалуйста
Поясняю, сложно крутить чеку от гранаты на пальце, если тебе их в детстве отрубило
>Python + Gevent может тоже самоеВообще-то нет. (C)
>> За тем, что есть мощнявый Golang, который может также выжать всю дурь
>> из интернета, как и ерланг, но минус ерланг, что про него
>> уже забыли
> Зачем нужен Golang, если Python + Gevent может тоже самое ? только
> мощность немного поменьше, но на питоне быстрее делать проектНа Питоне не быстрее делать, а вообще ничего делать невозможно. Кроме какие-то свои частные нужды обрабатывать. Питон даже для средней по объёмам командной разработки пыточный инструмент.
Кто-то навязывает?
Например, если вам нужно консолидировать данные с сотни БД, от различных вендоров, в рамках одного запроса. Причём, делать это транзакционно.
Предлагаю тем, кто ругает Java, своё брюзжание начинать со слов: "Я написал проект Такой-то с Таким-то количеством строк кода. И он уже работат Столько-то лет!" Только после этого их мнение можно читать.
> Предлагаю тем, кто ругает Java, своё брюзжание начинать со слов: "Я написал
> проект Такой-то с Таким-то количеством строк кода. И он уже работат Столько-то лет!"Жабку хают те, кто прогает на сях и НЕ прогал никогда на жабке. Пусть хоть миллион строк на сях напишут, их мнение по поводу жабы авторитетным не станет.
Хотя, я даже посредственно зная си, вижу, что эксперты опеннета и си толком не знают. То у них наследование на структах делается, то UB нет и не было. И все дырки появляются из-за злых агентов АНБ...
В первую очередь ругают те, кому приходится поддерживать ваши продукты на Джаве. И кому есть с чем сравнивать. Как язык, мне что Джава что Кресты видятся как ООП головного мозга, но так как я не программист, сравниваю по тому как код работает и как его поддерживают.
Ну эникейщики, которые поддерживают чужие программы, даже клавишу Enter ругают, дескать не так на клавиатуре расположена. Смотрите исходные тексты программы и тогда будет понятно как все работает.
> Смотрите исходные тексты программы и тогда
> будет понятно как все работает.А чо, доков нету? ;)
У г-кодеров все эникeйщики, кто с их кодом работает. Так проще заявить, чем собственное подeлие починить. Всё равно не починишь.>Смотрите исходные тексты программы и тогда будет понятно как все работает.
Как оно написанное на Джаве работает давно известно -- медленно, печально и на кoстылях.
"Одноклассники" целиком живут на Яве, и довольны.Крупнейшие фирмы мира, банки, трейдеры (есть такие) - ява эффективно используется практически во всех сферах ПО (кроме, может, 3D моделирования и игр).
А школота может писать хоть на бреинфаке.
> "Одноклассники" целиком живут на Яве, и довольны.А вконтактик на голых сях и похапе. О чём это говорит? Правильно, ни о чём.
>> "Одноклассники" целиком живут на Яве, и довольны.
> А вконтактик на голых сях и похапе. О чём это говорит? Правильно,
> ни о чём.Это говорит о том, что нельзя хаять технологию, если не хватает мозгов ее использовать.
PHP тоже модно хаять, забывая, какие монстры использут похапе.
Я не люблю ни яву, ни похапе. Но я вынужден признавать, что это состоявшиеся enterprise технологии. И если кто-то их ругает, то это скорее свидетельствует о неготовности "кого-то" к "энтерпрайзу".
(Выше сказанное - общие рассуждения, не относящиеся лично к тебе)
> Я не люблю ни яву, ни похапе. Но я вынужден признавать, что
> это состоявшиеся enterprise технологии. И если кто-то их ругает, то это
> скорее свидетельствует о неготовности "кого-то" к "энтерпрайзу".Что, существует только один "ынтырпрайз", в котором нет языков кроме жабы и похапе, и в котором использовать что-то другое строго-настрого запрещено? Ну значит этот "ынтырпрайз" не готов для нормальных разработчиков и загнётся в не очень далёком будущем.
В еентрерпрейзе используется много чего ещё.Ты немного подменяешь понятия.
Я говорю "нет смысла ругать инструменты, доказавшие свою эффективность".
Что пытаешься сказать ты, я, честно говоря, не понял. Ты понимаешь, что ты сказал?
> Что пытаешься сказать ты, я, честно говоря, не понял. Ты понимаешь, что
> ты сказал?Я сказал, что ты сморозил глупость про "неготовность кого-то к энтерпрайзу".
Если кто-то отрицает эффективность проверенных инструментов, он не готов к "энтерпрайзу".Если ты это отрицаешь, ты говоришь глуппость.
> Я говорю "нет смысла ругать инструменты, доказавшие свою эффективность".У инструмента есть:
- достоинства, которые позволили ему доказать свою эффективность
- недостатки, которые, однако, не смогли утянуть его на дноЕсть смысл указывать на недостатки,
чтобы неосведомленный читатель не принимал их за достоинства
и не ходил по граблям.Нет смысла ругать что-угодно, если от этого никто ничего нового не узнает.
>> "Одноклассники" целиком живут на Яве, и довольны.
> А вконтактик на голых сях и похапе. О чём это говорит?Я плотно работал с АПИ VK, авторитетно заявляю, что его проектировали полные клованы. Что достаточно точно кореллирует с ламерской связкой "голый си + похапе".
Содержимое одноклассников на голову лучше защищено. Мордокнига ещё лучше. Инстаграм примерно как вк.
Из замечаний: всё публичное содержимое ВК выкачивается с одного ip-шника за неделю. Т.к. можно выписать себе любое количество токенов на чужие приложения (id-ы доступны и последовательны), потом оборачиваем в EXECUTE и пачками в любое количество потоков тянем юзеров, списки, дружков (id-ы все доступны и последовательны).
>> "Одноклассники" целиком живут на Яве, и довольны.
> А вконтактик на голых сях и похапе. О чём это говорит? Правильно,
> ни о чём.Вконтактик это, какбэ, не интепрайз ни разу.
>трейдеры (есть такие)Живут, покупают терабайт RAM, отключают GC и живут.
Да, я знаю. Это не отменяет того факта, что, используя яву, они зарабатывают достаточно, чтобы поставить терабайт памяти на каждый сервер, и отметить это на яхте дорогим шампанским и черной икрой (по крайней мере, владельцы бизнеса :-) )
Очень характерная мантра жабо-***ло-кодера :)
Не светят вам яхты!
То на чём ты сидишь с веслом в руках - называется галера :-))))
Я, ты, он - мы все на галерах, не зависимо от используемой технологии.
(я вообще не умею java :-( я тоже на галере :-((( ).И способность кого-то купить себе яхту тоже слабо зависит от используемой им технологии.
Но факт в том, что используя java можно проще организовать толпу гребцов (нас с тобою), чтобы они не поубивали друг друга вёслами. Возможно на маленькой лодке два-четыре гребца могут грести на какой угодно технологии. Когда же галера на две-три сотни гребцов, то вёсла должны быть одной длинны и веса, каждый гребец должен вкладываться равнозначно другим, не ускоряя и не замедляя темп, и им нужен "менеджер", который будет бить в большой барабан.
>>трейдеры (есть такие)
> Живут, покупают терабайт RAM, отключают GC и живут.Кстати, очень многие трейдеры на перле живут! :)
>Живут, покупают терабайт RAM, отключают GC и живут.Сразу видно спеца по жабке. :))))) Я тебе скажу, что обычно даже не переключают на low-pause GC навроде g1 или CMS, а хватает стандартного parallel.
Про терабайт рамы, цитата с сайта undertow "Undertow is extremely lightweight, with the Undertow core jar coming in at under 1Mb. It is lightweight at runtime too, with a simple embedded server using less than 4Mb of heap space."
так что можно утверждать, что nginx жирный, про apache молчу.
В инете можно найти бенчмарки как однин сервер с undertow 1 миллион реквестов сервит.
Без костылей типа редиса, мемкаши итд.
> "Одноклассники" целиком живут на Яве, и довольны.Так то ж твои одноклассники...
> вынос некоторых вычислений на плечи GPUУважаемые модераторы, неужели мой вопрос настолько прост, что не достоин ничего, кроме немедленного удаления? Я всё же позволю себе переспросить: в каком месте у GPU плечи, которые упоминаются в каждой второй новости?
Русский язык для вас не родной и с таким понятием, как образные выражения, вы не знакомы?
Мне он как раз родной, и я понимаю, что GPU — это не «группа лиц или социальный коллектив». Что же до образных выражений, то я не против них в целом, но несколько задалбывает постоянное употребление одного и того же, как будто более подходящих слов не существует.
Для вас есть кнопка "Изменить". Примените свои знания для редактуры.
Энтерпрайз давно и прочно под пятой Java, php c++ это хорошо но не для серьезных огромных эетерпрайз решений, и альтернативы тут нет от слова вообще.
На замену Java придет JS. Он кроссплатформенный, быстрый, шустрый, гибкий. Разработчиков много. Бизнес-задачи выполняет отлично. Есть обвязки для моб.устройств - React Native, есть сервер - Node.JS. Есть клиент - React/Angular, есть Desktop - NW.js/Electron.Я говорю про именно бизнес-задачи. Разработчики JS - универсальны. Язык синтаксически близок C-подобным языкам.
Ну джависты могут и обосраться. Они-то учили всякие интерфейсы, классы, наследование, IoC, "высокие материи", а тут набегут веб-макаки и все им попортят. И набегут, и научатся. И будут вполне сносно разрабатывать код.
Но бизнес думает иначе, чем думают джависты. Бизнесу выгоднее брать JS/Go-разрабов. Пока древние "старперы"-прогеры цепляются за старое (кто бы мог подумать! ИТ-быстроменяющаяся сфера), молодняк учится, пишет код на React и зарабатывает вполне сносные деньги.
Да, много Java-legacy кода, да, java будет востребована еще какое-то время. Но нужно ловить современные тренды. Нельзя игнорировать их.
А все очень просто. Язык компании будет использовать не тот, что нравится программисту лично, а тот, который дает оптимальное соотношение "цена/качество".
Мне лично нравится Clojure, но я головой понимаю, что компании его никогда использовать не будут, разве что крупные и разве что в экспериментальном проекте, который может и не выстрелить.
Все дело в производительности труда и текущей ситуации на рынке труда в конкретной стране. А остальные холивары похожи на детский сад.
> На замену Java придет JS. Он кроссплатформенный, быстрый, шустрый, гибкий. Разработчиков
> много. Бизнес-задачи выполняет отлично. Есть обвязки для моб.устройств - React Native,
> есть сервер - Node.JS. Есть клиент - React/Angular, есть Desktop -
> NW.js/Electron.Это Ваше мнение ;)
Да, приложения на JS пишутся быстрее. Только в поддержке они дороже. И больше багов в продакшене.
Проверить JS можно только через исполнение. В отличии от компилируемых языков.
Серверные приложения на JS пишут те компании, где нет разработчиков чего-то серверного - C#/Java/Go. И, что характерно, когда нанимают кого-то из C#/Java/Go, то JS остается как легаси + на Browser-UI.Важна не только производительность труда, но и стабильность системы в проде.
Для стартапов производительность важнее стабильности. Для банков - наоборот.
Потому в банках чаще Java либо C# (такое тоже бывает). А в новых Web-стартапах PHP и JS ;)
PS хорошо отношусь к Web-UI на JS. JS намного удобнее создания UI на Java :D
>[оверквотинг удален]
> Проверить JS можно только через исполнение. В отличии от компилируемых языков.
> Серверные приложения на JS пишут те компании, где нет разработчиков чего-то серверного
> - C#/Java/Go. И, что характерно, когда нанимают кого-то из C#/Java/Go, то
> JS остается как легаси + на Browser-UI.
> Важна не только производительность труда, но и стабильность системы в проде.
> Для стартапов производительность важнее стабильности. Для банков - наоборот.
> Потому в банках чаще Java либо C# (такое тоже бывает). А в
> новых Web-стартапах PHP и JS ;)
> PS хорошо отношусь к Web-UI на JS. JS намного удобнее создания UI
> на Java :DПожалуйста, есть же TypeScript. Все прекрасно проверяется и компилируется. Java исторически используется. Как и C#.
Опять же, и у вас и у меня свое мнение и свое видение. Карта - не территория. Реальность может отличаться от того, что хочется или видится нам.
Будет WebAssembly - пойдет новый виток компилируемых языков для браузеров. Что и не хорошо, и не плохо в целом. Просто данность.
Иногда Java - легаси, иногда JS. Все же от проекта зависит и от контекста.
Нормальные приложенки можно писать только на TypeScript - подмножестве JS, и там тоже интерфейсы, IoC и т.д. Таже Java, только быстрее и удобнее.
По мне это неплохая попытка сделать из JS подобие C#.
> Нормальные приложенки можно писать только на TypeScript - подмножестве JS, и там
> тоже интерфейсы, IoC и т.д. Таже Java, только быстрее и удобнее.ТС раз в 10 удобнее жавы жля веба.
Удобнее чем?Про скорость: https://benchmarksgame.alioth.debian.org/u64q/javascript.html
Ну и одно дело готовить браузерную VM, другое — серверную. У JVM в этом плане несравнимо больше накопленного в нее опыта. Ну и более тяжелые фичи Jav-ы как security, изоляции, шикарную многопоточность и множество уже построенных инструментов забывать не надо.
На серверах JavaScript если и может с кем конкурировать — только если с PHP.
> Удобнее чем?Тем, что язык один, барьера внутри приложения нету.
Так что тем, кому тяжелые фичи не нужны -- удобнее.(У меня JVM, мне нужны :-)
>> Удобнее чем?
> Тем, что язык один, барьера внутри приложения нету.
> Так что тем, кому тяжелые фичи не нужны -- удобнее.
> (У меня JVM, мне нужны :-)Не, ну так это для UI-ного web-а, а выше, я так понимаю, в принципе, про ынтерпрайз говорили. А это далеко не только web.
Мое мнение — для non-web enterprise, где не нужен high performance и high reliability — Java является лучшим выбором. Там, где они нужны — надо смотреть case by case, во многих случаях Java также лучший выбор. Но уже не всегда.
Для web — тоже case by case. Для сложных и business/mission-critical приложений я бы все равно выбирал Java, просто хотя бы за счет того, что это мастодонт — с огромнейшей экосистемой инструментов и лучших практик для построения подобных приложений.
А можно указать ссылку на стравнение языков по критериям "быстрый, шустрый, гибкий"? Молодняку бы книжки почитать, а не тренды придумывать.
> Критерии устарели. Сейчас важны многоплатформенность, стоимость (= скорость) разработки
> и стоимость поддержки.Кому это сейчас важна многоплатформенность? Сейчас, во времена WSL и линуксовых контейнеров, работающих даже на винде? Все на неё плюют и пихают свои подeлия в докер, будь они написаны хоть на сях, хоть на жабе, хоть на питоне. Соляру зарыли, бздю забыли. (Нет, мне это не нравится, но я пытаюсь объективно оценивать происходящее вокруг.)
Стоимость разработки равна скорости? Вообще-то она равна числу человекочасов, помноженному на цену рабочего времени программиста. И, заметь, стоимость поддержки тоже, вот только в её случае число человекочасов находится в обратной зависимости от трудозатрат на разработку (важна продуманная архитектура и удобочитаемость кода). ЯП тут далеко не главная составляющая.
Так о том и речь. Архитектура - да. Поддержка - да. Но надо задуматься вот о чем - кто вам платит деньги? И что важно этому человеку?
Человеку, который платит мне деньги, важно заплатить как можно меньше. Но при этом он всё же знает, что скупой платит дважды.
Ну он и наймет 3-х JS-еров вместо одного жабиста. И сделает в 2 раза больше работы.
Вы первый раз за день близки к правде. Да один "жабист" стит "3-х JS-еров" по деньгам. И следуя из слов "И сделает в 2 раза больше работы" - 1.5 по производительности (3 человека сделали в два раза больше работы а не в три, как следовало ожидать). На самом деле, он 2-х по эффективнотсти стоит, как минимум.
> 2 раза больше работы" - 1.5 по производительности (3 человека сделали в два раза больше работыФантасты в треде 8)))) чтобы два прогера прогали в 2 раза быстрее, чем один. А три в три раза. Так даже процы не умеют 8))))
Два прогера на одной задаче прогают на 10% быстрее :))) Три - на 30%... Как-то так.
Ну, ещё индивидуальные особенности человека как бэ роляют плюс минус километр.
Вывод: один fullstack жабист по скорости разрывает целую команду жабоскриптеров. Про качество результата молчу (если жабист умеет jЕЕ).
>Вывод: один fullstack жабист по скорости разрывает целую команду жабоскриптеров. Про качество результата молчу (если жабист умеет jЕЕ).Мдааа ...
Паника у жаб. Вот смотрите на этот экземпляр - у него же просто батхерт.
Они вдруг как то стали не то чтобы совсем не нужны ... но так ...
Вы, жабшики, уже всио - "герои вчерашних дней"(С)МашинаPS: Я тоже считаю жабу меньшим злом по сравнению с жабаскриптом. Но толку то, от того, что в интернете кто то имеет мнение?
> Вывод: один fullstack жабист по скорости разрывает целую команду жабоскриптеров. Про качество
> результата молчу (если жабист умеет jЕЕ).В общем, да, как-то так и есть. Да UI будет не таким кавайно-модненьким (хотя может быть и таким), но прогер JEE один заменяет команду из 10--15 всяких "скриптеров".
сравнение "платформ" https://www.techempower.com/benchmarks/
90% жизненного цикла это поддержка и интеграция. Т.е. средства сборки, тестирования, и, да-да, всё той же интеграции. А ещё нужны: модульная версионность, стандартизация интерфейсов и каркасов, хорошие средства командной разработки и нормальная многоплатформенность. Ни один из модных в среды ското-кодеров языков ничем этим не обладает даже в зачатке.
Так оно только для Linux.
так а зачем оно на Win/OSX?
Вот, например, собранное OpenJ9 для win32 (в обертке OpenJdk8):
https://ci.adoptopenjdk.net/view/work in progress/job/openjdk8_openj9_build_x86-32_windows/
(Приложение со Swing запускается, JavaFX в этом комплекте нет).Ссылка взята с https://github.com/AdoptOpenJDK/openjdk-build/issues/342