The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз 19.3.0 виртуальной машины GraalVM и реализаций Python, JavaScript, Ruby и R на её основе

21.11.2019 00:14

Компания 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.

GraalVM предоставляет JIT-компилятор, который может на лету выполнять в JVM код любых скриптовых языков, включая JavaScript, Ruby, Python и R, а также даёт возможность запускать нативный код в JVM, преобразованный в биткод LLVM. Предоставляемый GraalVM инструментарий включает независимые от языков программирования отладчик, систему профилирования и анализатор распределения памяти. GraalVM даёт возможность создавать комбинированные приложения с компонентами на разных языках, позволяя обращаться к объектам и массивам из кода на других языках. Для языков на базе JVM имеется возможность создания скомпилированных в машинный код исполняемых файлов, которые можно выполнять напрямую с минимальным потреблением памяти (управление памятью и потоками реализовано через подключение фреймворка Substrate VM).

Изменения в GraalJS:

  • Обеспечена совместимость с Node.js 12.10.0;
  • Отключены по умолчанию нестандартные глобальные свойства и функции: global (заменено на globalThis, для возвращения предусмотрена настройка js.global-property), performance (js.performance), print и printErr (js.print);
  • Реализованы Promise.allSettled и nullish coalescing proposal, которые доступны в режиме ECMAScript 2020 ("--js.ecmascript-version=2020");
  • Обновлены зависимости ICU4J до 64.2, ASM до 7.1.



Изменения в GraalPython:

  • Добавлены заглушки gc.{enable,disable,isenabled}, реализованы charmap_build, sys.hexversion и _lzma;
  • Обновлена стандартная библиотека Python 3.7.8;
  • Добавлена поддержка NumPy 1.16.4 и Pandas 0.25.0;
  • Добавлена поддержка timeit;
  • socket.socket доведён до состояния, позволяющего запускать "graalpython -m http.server" и загружать нешифрованные (без TLS) http-ресурсы;
  • Исправлены проблемы, связанные с выводом объектов pandas.DataFrame, некорректной обработкой кортежей в bytes.startswith, деструктурирующим присвоением итераторов и использованием dict.__contains__ для словарей;
  • Добавлена поддержка ast.PyCF_ONLY_AST, которая позволила обеспечить работу pytest;
  • Добавлена поддержка PEP 498 (интерполяция строк в литералах);
  • Реализован флаг "--python.EmulateJython" для импорта JVM-классов с помощью нормального Python-синтаксиса import и ловли JVM-исключений из кода на Python;
  • Улучшена производительность парсера, кеширования исключений, доступа к объектам Python из JVM-кода. Улучшены результаты в тестах производительности для кода python и нативных расширений (исполнение нативных расширений поверх llvm подразумевает, что bitcode llvm передаётся GraalVM для JIT-компиляции).



Изменения в TruffleRuby:

  • Для компиляции нативных расширений теперь применяется встроенный инструментарий LLVM, создающий и нативный код, и биткод. Это значит, что больше нативных расширений должны компилироваться из коробки, позволяя решить большинство проблем, связанных с компоновкой;
  • Отдельная установка LLVM для установки нативных расширений в TruffleRuby;
  • Для установки C++ расширений на TruffleRuby теперь не требуется установка libc++ и libc++abi;
  • Лицензия обновлена до EPL 2.0/GPL 2.0/LGPL 2.1, как и в недавнем JRuby;
  • Добавлена поддержка опциональных аргументов в GC.stat;
  • Реализован метод Kernel#load с обёрткой и Kernel#spawn с :chdir;
  • Добавлен rb_str_drop_bytes, замечательный тем, что его использует OpenSSL;
  • Включены расширения предустановленных gem-ов, нужные для rails new в Rails 6;
  • Для компиляции нативных расширений задействованы флаги, как в MRI;
  • Внесены оптимизации производительности и сокращено потребление памяти.



Изменения в FastR:

  • Обеспечена совместимость с R 3.6.1;
  • Добавлена предварительная поддержка исполнения нативных расширений на основе LLVM. При сборке нативных пакетов R FastR сконфигурирован для использования встроенного в GraalVM инструментария LLVM. Результирующие бинарные файлы будут содержать и нативный код и LLVM-биткод.

    Предустановленные пакеты также собраны этим образом. FastR загружает и запускает нативный код расширений по умолчанию, но, когда запущен с опцией "--R.BackEnd=llvm", будет использоваться биткод. LLVM бэкэнд можно использовать избирательно для некоторых R пакетов, указывая "--R.BackEndLLVM=pkg1,pkg2". В случае проблем при установке пакетов, можно вернуть всё назад, вызвав fastr.setToolchain("native") или вручную подредактировав файл $FASTR_HOME/etc/Makeconf;

  • В этом релизе FastR поставляется без библиотек GCC runtime;
  • Исправлены утечки памяти;
  • Исправлены проблемы при работе с большими векторами (>1GB);
  • Реализован grepRaw, но только для fixed=T.


  1. Главная ссылка к новости (https://www.graalvm.org/docs/r...)
  2. OpenNews: Компания Oracle представила универсальную виртуальную машину GraalVM
  3. OpenNews: Выпуск интегрированной среды разработки Apache NetBeans 11.1
  4. OpenNews: Проекты по созданию компиляторов из Java в JavaScript и исполняемые файлы
  5. OpenNews: Компания Oracle опубликовала Java SE 10 и прекратила поддержку Java SE 9
  6. OpenNews: Выпуск интегрированной среды разработки Apache NetBeans 11.2
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51906-graalvm
Ключевые слова: graalvm, llvm, jvm, java, python, ruby, javascript
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (67) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Annnon (?), 08:12, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Чем это лучше чем pypy для python?
     
     
  • 2.2, Аноним (2), 08:29, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • –6 +/
    ничем
     
  • 2.6, asdasd (?), 09:12, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > GraalVM даёт возможность создавать комбинированные приложения с компонентами на разных языках

    Как минимум. За остальным или читайте новость (для начала) или идите на офф. сайт.

     
     
  • 3.11, Аноним (11), 09:59, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Можно подумать и без него нельзя этого делать
     
  • 3.21, Annnon (?), 11:24, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И что это дает в реальном проекте? Можно использовать мешанину языков в одном моно приложении? Кому это надо?
    Вопрос был именно для пайтон. Пишу я вот на нем и зачем нужен граал, если есть pypy?
     
     
  • 4.33, Аноним (33), 12:27, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Просто могут в Oracle писать виртуалки и вот хвастают, но как показала Java в целом, то они ничего кроме и не сделали. Все эти гигантские комбайны скорее потому деньги и связи, а не потому что лучше и быстрее..
     
     
  • 5.35, X4asd (ok), 14:06, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Просто могут в Oracle писать виртуалки и вот хвастают, но как показала Java в целом, то они ничего кроме и не сделали.

    не вышло ни чего хорошего в JVM потому что одной только виртуальки НЕ достаточно для целей "букета" языков.

    у теоретиков абстракция потекла почти что на ровном месте. :-)

    проблемы-то ведь нужно решать в том числе и на этапе копиляции:

    вот например:

    УМЕЕТ код на Scala работать дружественно вместе с кодом на Java -- внезависимости от того кто для кого (из них) является зависимым (или одновременно оба друг от друга взаимозависмы).

    и код на Koltin УМЕЕТ работать дружественно вместе с кодом на Java -- внезависимости от того кто для кого (из них: Koltin <=> Java) является зависимым (или одновременно оба друг от друга взаимозависмы).

    а код Scala <=> Koltin -- НЕ умеют дружественно работать друг с другом -- в ситуациях когда оба они являются взаимозавимыми  (Koltin-классы ссылаются на Scala-классы и при этом одновременно  Scala-классы ссылаются на Koltin-классы).

    в теории это должно было бы работать -- но про процесс компиляции забыли подумать! оказывается ведь компиляцию нужно запускать в определённых порядках.. а в каком порядке запускать Scala-компилятор а в каком порядке Koltin-компилятор, если произошла взаимозависимость?

    ведь общий граф взаимозавимостей Scala+Koltin составить невозможно -- для так для этого нужно было бы объединённое сотрудничество обоих компиляторов. а они каждый по своему составляют свои независимые графы зависимостей, и сразу ИСПОЛНЯЮТ(!).

    при этом в Groovy для успешного решения этой же проблемы придумали дополнительную (ранюю) стадию формирования классов-заглушек. классы-заглушки создаются на самам самом раннем этапе компилирования (ПЕРЕД запуском настоящих компиляторов), и заглушки (в отличии от своих настоящих классов) НЕ зависят ни от каких других классов. а затем уже позднее -- заглушки заменяются на настоящие классы. таким образом проблема порядка запуска компиляторов решается: JVM-язык который зависит от Groovy-классов -- будет связывать свой код с заглушками и поэтому НЕ требует запуск настоящего Groovy-компилятора ранее своего запуска.

     
  • 5.37, Аноним84701 (ok), 14:18, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Просто могут в Oracle писать виртуалки и вот хвастают, но как показала
    > Java в целом, то они ничего кроме и не сделали.

    Вообще-то, Земноводное вместе с его Воображаемой Машиной – создано Солнцем Мелких Систем, еще задолго до покупки Прорицателем в 2010 году.

     
  • 4.47, Аноним (47), 17:29, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Можно использовать мешанину языков в одном моно приложении? Кому это надо?

    Тем кто раньше писал на Jython, например (или JRuby, если не ограничиваться змеюкой)

     
  • 4.48, Аноним (47), 17:31, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вопрос был именно для пайтон. Пишу я вот на нем и зачем нужен граал, если есть pypy?>

    В pypy такой же GIL, как и в cpython

     
     
  • 5.55, Аноним (55), 21:07, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Есть огроменное количество библиотек для JVM. И вам придётся либо их переписать на питон, либо отказаться от питона вообще и писать всё на языках под jvm, либо попрощаться с jit и использовать средства для вызова jvm-кода из питона, которые скомпилированы как нативные библиотеки, специфичные дшя cpython, такие как
    JPype. GraalVM позволяет не прощаться с jit и использовать interoperability. Более того, можно миксовать все языки со всеми. В случае же cpython вам пришлось бы поставить либу для работы с R и либу для работы с явой, и если надо ява-коду переслать коллбэк на R, то пришлось бы этот коллбэк завернуть в питон, с потерей производительности на каждой границе.
     
  • 4.51, Аноним (51), 18:03, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, например, был такой подход - разрабатывать веб-портал с портлетами. Собственно, сам каркас - Java, а портлеты - на чём угодно. Ruby, например, как самый развитый не-JVM язык на JVM платформе. https://www.liferay.com/downloads-community
     
  • 2.44, граалец (?), 16:27, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    O_O
     

  • 1.4, Anonymoustus (ok), 08:59, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Мораль сей басни такова: «языков программирования» наплодили столько, что приходится изобретать для них универсальные виртуальные машины-запускалки и прочие свистелки и перделки. А ведь куда проще было бы завезти телегу палок и творчески применять их к говнокодерам. Но ущербная установка «время программиста стоит дороже» превращает всё в прах и страдания.
     
     
  • 2.15, anonoymous (?), 10:44, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Есть ещё такая установка, что действительно необходимо иногда что-то быстро реализовать, иначе, например, нишу захватит конкурент. Слышали про родить за месяц девятью девушками?
     
     
  • 3.16, Anonymoustus (ok), 10:49, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ты ведь не понимаешь, аноним, о чём я писал в своём комментарии. Увы, подобных тебе — 95%.
     
     
  • 4.22, мое правило (?), 11:37, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Очень толсто, попробуйте еще раз.
     
     
  • 5.42, HyC (?), 15:50, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Очень толсто, попробуйте еще раз.

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

     
  • 3.28, Аноним (28), 12:00, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Слышали про родить за месяц девятью девушками?

    мы слышали, что это пока еще ни одному прожор-менеджеру не удавалось.

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

     
     
  • 4.30, Anonymoustus (ok), 12:18, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Слышали про родить за месяц девятью девушками?
    > мы слышали, что это пока еще ни одному прожор-менеджеру не удавалось.
    > А вот угробить проект, заодно загадив поляну так, что ничего тут больше
    > не вырастет и через десять лет, методом херак-херак в продакшн -
    > очень даже многим и не раз.

    Надо спешить, а то ведь нишу займут! Займут нишу. Жители ниши обеспокоены.

     

  • 1.7, Анонимчег (?), 09:20, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Типа .DA что ли?
     
  • 1.10, Аноним (10), 09:51, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь холивары типа "кто быстрей - бидон или нода" приобретут новую площадку - который язык быстрее в Граале?
     
  • 1.14, Аноним (14), 10:26, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Неосиляторы джавы теперь могут писать для jvm на своих язычках.
     
     
  • 2.17, Ydro (?), 10:59, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это, не для изучения Java, а для предоставления конечному пользователю, которому-то и JS со стороны представляется колдовскими заклинаниями, мало мальской автоматизации приложения написанного на Java посредством скриптов поддерживаемых GraalVM.
     
     
  • 3.18, Анонимус2 (?), 11:13, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Интерпретатор js в джаву встроен уже лет 15. Graalvm изначально писался как jit компилятор для джавы на джаве. Но потом оказалось что на нормальном языке можно написать эффективный универсальный jit компилятор, и понеслось
     
     
  • 4.29, Аноним (29), 12:15, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >на нормальном языке

    с плюсов на на си что ли переписали?

     
  • 2.23, Аноним (23), 11:43, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Просто возможность использовать интеграционный язык для связывания компонентов. Ruby гораздо удобнее Java в этом смысле, а под GraalVM получает доступ к объектам Java. То есть пишешь на Ryby, а Java-объекты становятся для него как родные с возможностью переопределения классов, методов и пр.
     
     
  • 3.25, Аноним (14), 11:48, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну и почему бы сразу не писать на джава и использовать компоненты джава? Ответ неосилили джаву.

    А про Руби это вообще жесткая хохма. Руби уже давно на свалке лежит на нем только жесткое легаси.

     
     
  • 4.32, Аноним (51), 12:25, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А про Руби это вообще жесткая хохма. Руби уже давно на свалке лежит на нем только жесткое легаси.

    Это можно сказать про любой язык с возрастом более 10 лет, особенно про те, у которых слились идеологи разработки. Тем не менее, модель Ruby пока ещё никто не превзошел и с целостностью команды проблем нет. Популярность популярностью, а Ruby реально удобен.

     
     
  • 5.40, Аноним (40), 15:39, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Такое можно сказать еще про Перл, ну и Паскаль. Остальные вроде норм себя ведут. И даже сейчас можно найти человека что скажет что Перл удобен. И даже проект на сопровождении покажет. Но тем не менее время Перла тоже ушло.
     
     
  • 6.50, Аноним (51), 17:59, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Желающих начать новый проект на перле сейчас вряд ли найдёте. А на Ruby - запросто. Программистов достаточно. Язык развивается, сообщество живое.
     
     
  • 7.54, Аноним (40), 19:56, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Никак нихт. Даже гитхаб вот такую картинку выдает. https://www.opennet.ru/opennews/pics_base/0_1573187777.png
     
     
  • 8.56, Аноним (23), 21:20, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Даже один процент от миллиона - это очень много Не сомневайтесь, рубисты есть ... текст свёрнут, показать
     
  • 4.36, X4asd (ok), 14:18, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну и почему бы сразу не писать на джава и использовать компоненты
    > джава? Ответ неосилили джаву.

    а почему бы сразу не писать на обычном Ruby, и использовать бинарные native-библиотеки в качестве компонентов.

    в какое место тут Java пихать

     
     
  • 5.39, Аноним (39), 15:02, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не для всякого проекта подойдет. Динамическая типизация затрудняет сопровождение и рефакторинг больших проектов.
     
  • 5.49, Аноним (51), 17:57, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну потому, что на Java написана куча софта под бизнес. Из под JRuby/Graal, можно подключать любые Java-библиотеки. Они для Ruby-кода выглядят почти как родные. Это, как раз, и задача интеграционного языка программирования.

    Собственно, одно из достоинств Ruby - удобно на нём писать DSL/DSeL без лишних скобок

     
     
  • 6.71, Xasd (ok), 20:09, 23/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > на Java написана куча софта под бизнес

    софт под бизнес это что за хрень? -- утилита для подсказывания серъёзных слов? :-)

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

     
     
  • 7.75, Аноним (23), 11:35, 28/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> весь бизнес держится на обычных программах (т е не Java, разумеется).

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

     
  • 4.38, Урри (?), 14:50, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На руби есть кукумбер, например (тестфреймворк), который довольно широко и успешно используют в ИТ. Так что не надо - руби еще жив, не умер.
     

  • 1.24, Аноним (24), 11:46, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А потом прибежит сан и потащит тебя в суд, как гугля. Во все, вплоть до верховного. Ну нах такие риски. Лучше вообще не иметь дел ни с жабой, ни с jvm, ни вообще с ссанками.
     
     
  • 2.26, Аноним (14), 11:49, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лучше уж они чем Майки с их C#.
     
     
  • 3.31, Anonymoustus (ok), 12:21, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше уж они чем Майки с их C#.

    C# отличный язык. Что вам не понравилось? Ах, Дотнет… Ну, тут уж или Жабба, или Дотнет. Выбирайте по вкусу.

     
     
  • 4.41, Аноним (40), 15:41, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На Жабе можно написать бек, приложение на мобилку и вообще все что захочешь, а на C#  только то что Майки тебе разрешат.
     
     
  • 5.45, MS (??), 16:43, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    и что же из того что вы захотели, мы вам "не разрешили" ?

    P.S. фантазировать, конечно, тоже не запрещали...

     
  • 5.52, Урри (?), 18:52, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Еще 5 лет назад я кодил на шарпе под линь и никакие майки мне не мешали. Замарин на шарпе кодил под андроид еще до того, как их купили за дохренилион денег - и им тоже никакие майки (с никакими гуглями) не мешали.

    Вы там совсем долбанулись в своем манямирке, анонимы опеннетовские?

     
     
  • 6.53, Аноним (40), 19:52, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В подробностях рассказывай как запустил Visual Studio не code под Линуксом. Манямирок ты наш виндузятнический.
     
     
  • 7.57, funny.falcon (?), 21:41, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    MonoDevelop существует уже столько лет, что мне и памяти не хватает вспомнить, когда он появился.
    Конечно, это проблемы моей памяти, что я на пятнадцать лет назад плохо помню.
     
     
  • 8.68, Аноним (68), 10:22, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пока Xamarin его не забросил ... текст свёрнут, показать
     
  • 7.58, Аноним (58), 21:47, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    О, еще один анонимный лох слился, monodevelop сто лет под линуксом есть, как уже отписали выше.
    Покукарекай еще!
     
     
  • 8.67, Аноним (68), 10:22, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Monodevelop который больше не поддерживается Xamarin, который даже в Unity помен... текст свёрнут, показать
     
     
  • 9.70, Аноним (70), 15:56, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ржи дальше,линуксоидный баран, не умеющий читать Ответ был какой IDE использова... текст свёрнут, показать
     
  • 7.72, Илья (??), 22:57, 23/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Visual Studio не code

    Вы наверное имели в виду тот лаунчер для решарпера? Так есть же rider.

     
  • 5.61, leap42 (ok), 03:45, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > На Жабе можно написать бек, приложение на мобилку и вообще все что захочешь, а на C#  только то что Майки тебе разрешат.

    Сисярп так-то помощнее будет, можно каие-то аргументы? И не надо пожалуйста толковать про то, что win-специфичные gui недоступны вне win: майки понимают, что десктоп приложения в привычном виде практически мертвы, и тащить а потом поддерживать кучу кода из венды на не винды ради универсального гуя смысла нет.

     
     
  • 6.64, Аноним (64), 05:49, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Основной аргумент всё тот же, что и обычно: сисярп - закрытый проект, в котором разработки вроде GraalVM появятся только в оффтопике, и лишь через много лет, если окажутся никому не нужны, будут открыты и портированы в нормальные системы

    В OpenJDK всё ровно наоборот: ZeroGC был разработан только под линукс. Виндузятникам предложено было портировать его за свои средства (до сих пор никто не портирован, что кстати демонстрирует мощь вуенды как серверной платформы).

     
     
  • 7.65, Аноним (65), 06:44, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ещё один анонимный лох слился в своём манямирке!!
    Майкрософт давно открыла исходники шарпа.
    https://github.com/dotnet/roslyn
    Любой желающий даже может коммитить им в репу на гитхабе.
    Какие же вы поехавшие идиоты все же - линуксоиды.
    Всегда кудахчете о том, чего не знаете.
     
     
  • 8.74, Аноним (74), 18:50, 26/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос был про ZeroGC Где ... текст свёрнут, показать
     

  • 1.27, Аноним (27), 12:00, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Зачем все эти "универсальные виртуальные машины", когда есть HolyC с JIT-компиляцией, интроспекцией и... анимированными картинками непосредственно в исходном коде на HolyC?
     
  • 1.34, Аноним (34), 13:38, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И возвращается ветер на круги своя...
     
  • 1.43, vitalif (ok), 15:57, 21/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Нормально, теперь можно под видом Java-разработки писать на нормальных языках, а потом и яву можно закопать будет.
     
     
  • 2.46, граалец (?), 16:49, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    которые запускаются из GraalVM контекста в JVM. хотя есть еще вариант запуска из отдельной команды - graaljs/graalpython и тд
     

  • 1.59, Аноним (59), 00:30, 22/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подскажите плиз, свежая Ubuntu 19.10 swap по умолчанию создаёт в отдельном разделе на винте или в swap файле на том же разделе где и основная файловая система или где-то ещё?
     
     
  • 2.60, Аноним (59), 00:35, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Непонятно что вот эта запись из fstab значит

    /dev/mapper/xubuntu--vg-swap_1

    не могу понять где физически swap находится, в файле или в отдельном разделе hdd

     
     
  • 3.62, leap42 (ok), 03:49, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    man 5 fstab
    man 8 lvm

    sudo vgs
    sudo pvs
    sudo lvs

    Когда последний раз ставил Ubuntu и отказался от swap раздела, обнаружил swap файл в корневой папке, но я не пользуюсь lvm на домашней тачке.

     

  • 1.63, j3t (?), 04:49, 22/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    .NET переизобрели
     
     
  • 2.66, граалец (?), 09:11, 22/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    не .NET, а CLR. JVM языки уже давно существуют. Graal от них отличается принципиально
     

  • 1.69, Аноним (69), 12:06, 22/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Компания Oracle

    С этими лучше не связываться.

     
  • 1.73, Аноним (73), 08:12, 24/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    жаль что нет PHP
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру