Компания Oracle опубликовала выпуск универсальной виртуальной машины GraalVM 19.3.0, поддерживающей запуск приложений на JavaScript (Node.js), Python, Ruby, R, любых языках для JVM (Java, Scala, Clojure, Kotlin) и языках, для которых может формироваться биткод LLVM (C, C++, Rust). Ветка 19.3 отнесена к категории выпусков с длительным сроком поддержки (LTS) и примечательна поддержкой JDK 11, в том числе с возможностью компиляции Java-кода в исполняемые файлы (GraalVM Native Image). Код проекта распространяется под лицензией GPLv2. Одновременно выпущены новые версии использующих GraalVM реализаций языков Python, JavaScript, Ruby и R - GraalPython, GraalJS, TruffleRuby и FastR...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51906
Чем это лучше чем pypy для python?
ничем
> GraalVM даёт возможность создавать комбинированные приложения с компонентами на разных языкахКак минимум. За остальным или читайте новость (для начала) или идите на офф. сайт.
Можно подумать и без него нельзя этого делать
И что это дает в реальном проекте? Можно использовать мешанину языков в одном моно приложении? Кому это надо?
Вопрос был именно для пайтон. Пишу я вот на нем и зачем нужен граал, если есть pypy?
Просто могут в Oracle писать виртуалки и вот хвастают, но как показала Java в целом, то они ничего кроме и не сделали. Все эти гигантские комбайны скорее потому деньги и связи, а не потому что лучше и быстрее..
> Просто могут в Oracle писать виртуалки и вот хвастают, но как показала Java в целом, то они ничего кроме и не сделали.не вышло ни чего хорошего в JVM потому что одной только виртуальки НЕ достаточно для целей "букета" языков.
у теоретиков абстракция потекла почти что на ровном месте. :-)
проблемы-то ведь нужно решать в том числе и на этапе копиляции:
вот например:
УМЕЕТ код на Scala работать дружественно вместе с кодом на Java -- внезависимости от того кто для кого (из них) является зависимым (или одновременно оба друг от друга взаимозависмы).
и код на Koltin УМЕЕТ работать дружественно вместе с кодом на Java -- внезависимости от того кто для кого (из них: Koltin <=> Java) является зависимым (или одновременно оба друг от друга взаимозависмы).
а код Scala <=> Koltin -- НЕ умеют дружественно работать друг с другом -- в ситуациях когда оба они являются взаимозавимыми (Koltin-классы ссылаются на Scala-классы и при этом одновременно Scala-классы ссылаются на Koltin-классы).
в теории это должно было бы работать -- но про процесс компиляции забыли подумать! оказывается ведь компиляцию нужно запускать в определённых порядках.. а в каком порядке запускать Scala-компилятор а в каком порядке Koltin-компилятор, если произошла взаимозависимость?
ведь общий граф взаимозавимостей Scala+Koltin составить невозможно -- для так для этого нужно было бы объединённое сотрудничество обоих компиляторов. а они каждый по своему составляют свои независимые графы зависимостей, и сразу ИСПОЛНЯЮТ(!).
при этом в Groovy для успешного решения этой же проблемы придумали дополнительную (ранюю) стадию формирования классов-заглушек. классы-заглушки создаются на самам самом раннем этапе компилирования (ПЕРЕД запуском настоящих компиляторов), и заглушки (в отличии от своих настоящих классов) НЕ зависят ни от каких других классов. а затем уже позднее -- заглушки заменяются на настоящие классы. таким образом проблема порядка запуска компиляторов решается: JVM-язык который зависит от Groovy-классов -- будет связывать свой код с заглушками и поэтому НЕ требует запуск настоящего Groovy-компилятора ранее своего запуска.
> Просто могут в Oracle писать виртуалки и вот хвастают, но как показала
> Java в целом, то они ничего кроме и не сделали.Вообще-то, Земноводное вместе с его Воображаемой Машиной – создано Солнцем Мелких Систем, еще задолго до покупки Прорицателем в 2010 году.
>Можно использовать мешанину языков в одном моно приложении? Кому это надо?Тем кто раньше писал на Jython, например (или JRuby, если не ограничиваться змеюкой)
Вопрос был именно для пайтон. Пишу я вот на нем и зачем нужен граал, если есть pypy?>В pypy такой же GIL, как и в cpython
Есть огроменное количество библиотек для JVM. И вам придётся либо их переписать на питон, либо отказаться от питона вообще и писать всё на языках под jvm, либо попрощаться с jit и использовать средства для вызова jvm-кода из питона, которые скомпилированы как нативные библиотеки, специфичные дшя cpython, такие как
JPype. GraalVM позволяет не прощаться с jit и использовать interoperability. Более того, можно миксовать все языки со всеми. В случае же cpython вам пришлось бы поставить либу для работы с R и либу для работы с явой, и если надо ява-коду переслать коллбэк на R, то пришлось бы этот коллбэк завернуть в питон, с потерей производительности на каждой границе.
Ну, например, был такой подход - разрабатывать веб-портал с портлетами. Собственно, сам каркас - Java, а портлеты - на чём угодно. Ruby, например, как самый развитый не-JVM язык на JVM платформе. https://www.liferay.com/downloads-community
O_O
Мораль сей басни такова: «языков программирования» наплодили столько, что приходится изобретать для них универсальные виртуальные машины-запускалки и прочие свистелки и перделки. А ведь куда проще было бы завезти телегу палок и творчески применять их к говнокодерам. Но ущербная установка «время программиста стоит дороже» превращает всё в прах и страдания.
Есть ещё такая установка, что действительно необходимо иногда что-то быстро реализовать, иначе, например, нишу захватит конкурент. Слышали про родить за месяц девятью девушками?
Ты ведь не понимаешь, аноним, о чём я писал в своём комментарии. Увы, подобных тебе — 95%.
Очень толсто, попробуйте еще раз.
> Очень толсто, попробуйте еще раз.Вообще продукт должен по уму создаваться чтобы решать задачи пользователей, а не задачу "заколотить бабок разработчикам". В итоге мы имеем "ниши" забитые "продуктами", которые слеплены из говна и опилок, а вместо решения задач пользователей за из же деньги вешают геморрой им на жопу. Зато иконка красивая.
> Слышали про родить за месяц девятью девушками?мы слышали, что это пока еще ни одному прожор-менеджеру не удавалось.
А вот угробить проект, заодно загадив поляну так, что ничего тут больше не вырастет и через десять лет, методом херак-херак в продакшн - очень даже многим и не раз.
>> Слышали про родить за месяц девятью девушками?
> мы слышали, что это пока еще ни одному прожор-менеджеру не удавалось.
> А вот угробить проект, заодно загадив поляну так, что ничего тут больше
> не вырастет и через десять лет, методом херак-херак в продакшн -
> очень даже многим и не раз.Надо спешить, а то ведь нишу займут! Займут нишу. Жители ниши обеспокоены.
Типа .DA что ли?
Теперь холивары типа "кто быстрей - бидон или нода" приобретут новую площадку - который язык быстрее в Граале?
Неосиляторы джавы теперь могут писать для jvm на своих язычках.
Это, не для изучения Java, а для предоставления конечному пользователю, которому-то и JS со стороны представляется колдовскими заклинаниями, мало мальской автоматизации приложения написанного на Java посредством скриптов поддерживаемых GraalVM.
Интерпретатор js в джаву встроен уже лет 15. Graalvm изначально писался как jit компилятор для джавы на джаве. Но потом оказалось что на нормальном языке можно написать эффективный универсальный jit компилятор, и понеслось
>на нормальном языкес плюсов на на си что ли переписали?
Просто возможность использовать интеграционный язык для связывания компонентов. Ruby гораздо удобнее Java в этом смысле, а под GraalVM получает доступ к объектам Java. То есть пишешь на Ryby, а Java-объекты становятся для него как родные с возможностью переопределения классов, методов и пр.
Ну и почему бы сразу не писать на джава и использовать компоненты джава? Ответ неосилили джаву.А про Руби это вообще жесткая хохма. Руби уже давно на свалке лежит на нем только жесткое легаси.
> А про Руби это вообще жесткая хохма. Руби уже давно на свалке лежит на нем только жесткое легаси.Это можно сказать про любой язык с возрастом более 10 лет, особенно про те, у которых слились идеологи разработки. Тем не менее, модель Ruby пока ещё никто не превзошел и с целостностью команды проблем нет. Популярность популярностью, а Ruby реально удобен.
Такое можно сказать еще про Перл, ну и Паскаль. Остальные вроде норм себя ведут. И даже сейчас можно найти человека что скажет что Перл удобен. И даже проект на сопровождении покажет. Но тем не менее время Перла тоже ушло.
Желающих начать новый проект на перле сейчас вряд ли найдёте. А на Ruby - запросто. Программистов достаточно. Язык развивается, сообщество живое.
Никак нихт. Даже гитхаб вот такую картинку выдает. https://www.opennet.dev/opennews/pics_base/0_1573187777.png
Даже один процент от миллиона - это очень много. Не сомневайтесь, рубисты есть. К тому же, в большинстве своём, они с опытом. Именно потому, что хайпа уже давно нет.
> Ну и почему бы сразу не писать на джава и использовать компоненты
> джава? Ответ неосилили джаву.а почему бы сразу не писать на обычном Ruby, и использовать бинарные native-библиотеки в качестве компонентов.
в какое место тут Java пихать
Не для всякого проекта подойдет. Динамическая типизация затрудняет сопровождение и рефакторинг больших проектов.
Ну потому, что на Java написана куча софта под бизнес. Из под JRuby/Graal, можно подключать любые Java-библиотеки. Они для Ruby-кода выглядят почти как родные. Это, как раз, и задача интеграционного языка программирования.Собственно, одно из достоинств Ruby - удобно на нём писать DSL/DSeL без лишних скобок
> на Java написана куча софта под бизнессофт под бизнес это что за хрень? -- утилита для подсказывания серъёзных слов? :-)
на самом деле весь бизнес держится на обычных программах (т е не Java, разумеется). если только у тебя нет цели выбрать решение как можно хуже.
>> весь бизнес держится на обычных программах (т е не Java, разумеется).Ок, если весь бизнес у вас держится на продаже решений для студенческих лабораторок.
На руби есть кукумбер, например (тестфреймворк), который довольно широко и успешно используют в ИТ. Так что не надо - руби еще жив, не умер.
А потом прибежит сан и потащит тебя в суд, как гугля. Во все, вплоть до верховного. Ну нах такие риски. Лучше вообще не иметь дел ни с жабой, ни с jvm, ни вообще с ссанками.
Лучше уж они чем Майки с их C#.
> Лучше уж они чем Майки с их C#.C# отличный язык. Что вам не понравилось? Ах, Дотнет… Ну, тут уж или Жабба, или Дотнет. Выбирайте по вкусу.
На Жабе можно написать бек, приложение на мобилку и вообще все что захочешь, а на C# только то что Майки тебе разрешат.
и что же из того что вы захотели, мы вам "не разрешили" ?P.S. фантазировать, конечно, тоже не запрещали...
Еще 5 лет назад я кодил на шарпе под линь и никакие майки мне не мешали. Замарин на шарпе кодил под андроид еще до того, как их купили за дохренилион денег - и им тоже никакие майки (с никакими гуглями) не мешали.Вы там совсем долбанулись в своем манямирке, анонимы опеннетовские?
В подробностях рассказывай как запустил Visual Studio не code под Линуксом. Манямирок ты наш виндузятнический.
MonoDevelop существует уже столько лет, что мне и памяти не хватает вспомнить, когда он появился.
Конечно, это проблемы моей памяти, что я на пятнадцать лет назад плохо помню.
Пока Xamarin его не забросил...
О, еще один анонимный лох слился, monodevelop сто лет под линуксом есть, как уже отписали выше.
Покукарекай еще!
Monodevelop который больше не поддерживается Xamarin, который даже в Unity поменяли на Visual Studio Community? Ржу в голосинеу с Си шарперов. Винда конечно влияет на мозг, но чтобы на столько.
Ржи дальше,линуксоидный баран, не умеющий читать.
Ответ был какой IDE использовали на Линуксе 5 лет назад, чтобы писать на шарпе.
И 5 лет назад movodevelop поддерживался.
> Visual Studio не codeВы наверное имели в виду тот лаунчер для решарпера? Так есть же rider.
> На Жабе можно написать бек, приложение на мобилку и вообще все что захочешь, а на C# только то что Майки тебе разрешат.Сисярп так-то помощнее будет, можно каие-то аргументы? И не надо пожалуйста толковать про то, что win-специфичные gui недоступны вне win: майки понимают, что десктоп приложения в привычном виде практически мертвы, и тащить а потом поддерживать кучу кода из венды на не винды ради универсального гуя смысла нет.
Основной аргумент всё тот же, что и обычно: сисярп - закрытый проект, в котором разработки вроде GraalVM появятся только в оффтопике, и лишь через много лет, если окажутся никому не нужны, будут открыты и портированы в нормальные системыВ OpenJDK всё ровно наоборот: ZeroGC был разработан только под линукс. Виндузятникам предложено было портировать его за свои средства (до сих пор никто не портирован, что кстати демонстрирует мощь вуенды как серверной платформы).
Ещё один анонимный лох слился в своём манямирке!!
Майкрософт давно открыла исходники шарпа.
https://github.com/dotnet/roslyn
Любой желающий даже может коммитить им в репу на гитхабе.
Какие же вы поехавшие идиоты все же - линуксоиды.
Всегда кудахчете о том, чего не знаете.
Вопрос был про ZeroGC
Где?
Зачем все эти "универсальные виртуальные машины", когда есть HolyC с JIT-компиляцией, интроспекцией и... анимированными картинками непосредственно в исходном коде на HolyC?
И возвращается ветер на круги своя...
Нормально, теперь можно под видом Java-разработки писать на нормальных языках, а потом и яву можно закопать будет.
которые запускаются из GraalVM контекста в JVM. хотя есть еще вариант запуска из отдельной команды - graaljs/graalpython и тд
Подскажите плиз, свежая Ubuntu 19.10 swap по умолчанию создаёт в отдельном разделе на винте или в swap файле на том же разделе где и основная файловая система или где-то ещё?
Непонятно что вот эта запись из fstab значит/dev/mapper/xubuntu--vg-swap_1
не могу понять где физически swap находится, в файле или в отдельном разделе hdd
man 5 fstab
man 8 lvmsudo vgs
sudo pvs
sudo lvsКогда последний раз ставил Ubuntu и отказался от swap раздела, обнаружил swap файл в корневой папке, но я не пользуюсь lvm на домашней тачке.
.NET переизобрели
не .NET, а CLR. JVM языки уже давно существуют. Graal от них отличается принципиально
>Компания OracleС этими лучше не связываться.
жаль что нет PHP