На каких задачах Java Script действительно лучше других языков?

А по памяти что? И так же ловок будет GC в граале, как GC у v8, например?

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

Вопрос: какие задачи лучше всего делать на «языке JS» просто потому, что он клёвый? Настолько клёвый, что вот для этой конкретной задачи вы готовы временно сменить язык на него.

Если конкретно по сравнению Java/JS, то те задачи, где требуется прототипное ООП и/или eval.

Например, есть у тебя класс Circle с одними методами и Ellipse с другими. И если у объекта класса Ellipse длины осей совпали, то он стать объектом класса Circle.

Или в описании формата есть язык выражений. Или нужно дать возможность выполнять произвольные плагины, предоставляемый пользователем в виде исходного текста (для Java придётся в поставку программы класть JDK).

И так же ловок будет GC в граале, как GC у v8, например?

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

все языки можно и нужно запускать на JVM.

Почему? Зачем? Почему именно JVM?

Ну, кстати, раз зашла речь об эффективности GC, то JVM не может быть универсальной. Это уже проходили с .NET.

Простой пример. Сборщик мусора GC языка Haskell использует информацию о неизменяемости данных. Буквально, это значит, что старые данные не могут ссылаться на новые. Как заверяют разработчики, это дает значительный бонус сборщику мусора GC при переполнении так называемых «яслей» (в JVM аналогом яслям будет Эдем - ох, уж и названия!). То есть, рантайм языка Haskell заведомо должен быть и, скорее всего, является более эффективным, чем мог бы гипотетически быть рантайм JVM на программах, скомпилированных с языка Haskell.

Думаю, что похожие примеры можно найти и для других языков. Касательно JavaScript, думается, что различные рантаймы яваскрипта также используют какую-то дополнительную информацию.

Это возвращаясь к известному тезису, что «универсальных решений не бывает». А потому сомнительна идея все делать через JVM. Да и этот боксинг с type erasure иногда не то чтобы выбешивают, но дают повод задуматься о выборе платформы программирования

GUI. Ну может еще какие стейт-машины щелкать.

я бы сказал, не слегка. довольно жирный наброс в общем то

В JVM только основных сборщиков мусора сейчас четыре (на самом деле пять, но пятый - он не для продакшена), и ещё незнамо сколько кастомных в разных больших компаниях. Каждый из сборщиков имеет такую тьму параметров, что в некоторых компаниях комбинацию флагов запуска java подбирают машин лёнингом. А использование Truffle (часть Graal - фреймворк для разработки языков) даёт исчерпывающую информацию о языке. Так что, если нужно будет что-то затюнинговать под конкретный язык - всё это сделают.

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

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

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

Это лучше уже чем отрицание что JavaScript победил на сервере на первом слое нестатических фронтендов.

В сам JS коммьюнити в плане достижения высокой производительности будет скоро наклевываться WebAssembly. Суть в том что ты узкое место пишешь на Rust. А потом получается Rust->LLVM->WebAssembly. NodeJS или браузер потом превращает WebAssembly в натив (совсем настоящий натив) и гоняет быстро твое узкое место без всяких сборщиков мусора и байткодов.

Например профита от такого для DOM манипуляций - ноль, но для криптографии, обработки изображений, какого-то матана - запросто. Причем в браузере тоже - например применение фильтров в браузерном фотошопе.

Ни на каких.

Даже в тех областях, где javascript сейчас закрепился, он только создаёт регулярные проблемы и требует кучи костылей и подпорок для хоть какой-то работоспособности. Это я про веб и прочие электроны, что суть одно и то же.

Не, мы напишем узкое место на Java! И потом Java -> WebAssembly :)

Хотя в этом случае, конечно, лучше всё писать сразу на Java. Но будет некоторое время период миграции.

мы

Вы - да. Все остальные в JS community пока движется в сторону WA

Ну вот, надо вначале заманить джаваскриптеров к нам, а потом мы с ними и их языком разберемся... по-свойски :)

Вопрос: какие задачи лучше всего делать на «языке JS» просто потому, что он клёвый? Настолько клёвый, что вот для этой конкретной задачи вы готовы временно сменить язык на него.

Никаких. JS не клёвее Java/C++/C#. Единственное предназначение — разрешать макакам, не осилившим Lua (или имеющим привычку к си-синтаксису) скриптовать нормальные приложения так, чтобы их нельзя было уронить.

Чтобы скриптовать Java-приложение (== реализовывать логику самого высокого уровня) лучше варианта не придумать, так как JS-движок являетсячастью платформы.

В сам JS коммьюнити в плане достижения высокой производительности будет скоро наклевываться WebAssembly

JS невозможно скомпилировать в WASM, так что к «JS коммьюнити» WASM отношения никакого не имеет (к фронтенд-разработчикам к целом - возможно)

QML

JS невозможно скомпилировать в WASM

Потому что ты так сказал?

У меня один вопрос. В последние пару недель чрезвычайно много тредов по JS. Где в них anonimus? Я никак не сумел отследить его активность. Неужели он пропустил столь эпичные беседы?

Где в них anonimus?

Anonimus уже давно пропал куда-то.

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

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

Я думаю что будут стремиться к унификации. А значит мы увидим много WASM в ноде как универсального безопасного байткода

Я не привык. Хотя неплохо разобрался с canvas и скопами.

имеющим привычку к си-синтаксису

Повторюсь:
===, '1'+1
А, ещё хипстерская часть требует не ставить ;

но тогда 1.придется писать два интерпретатора на двух языках.

Нет. Возьмём любимый python: в wtforms всё уже реализовано, декларируешь модель (в рамках ORM же), а он валидирует.
А вот многочисленные валидаторы форм на яваскрипте настолько угробищные (и в 2017 году требуют jQuery по-любому), что пришлось велосипедить. Ну и вообще не понимаю, как даже в рамках JS и на фронтенде, и на бэк-энде унифицировать валидацию: ибо на фронт-энде основная часть кода - попапы и подсказки на инвалидные поля, а на бэк-энде - очистка от того, что мамкины какиры поытаются в них засунуть.

т.е. самая лучшая библиотека решающая эту задачу - она на ЖС например.

Может, я отстал, всегда были c++ или c#. Причём, с C# на питон вообще легко портануть.

Когда писал на Java, для скриптования какие-то частей использовал Groovy. Очень хорошо летело. Почему не рассматриваете Groovy ? Его можно динамически подгружать и исполнять в контексте программы в своей песочнице.

Биндинги платформозависимы в отличии от wasm байткода.

JS как язык, если нужен язык сценариев. Писать сценарии на полновесной Java может быть сложно, JS знают больше людей и сам язык попроще для простых вещей. Хотя зависит от аудитории, и чистая Java может быть предпочтительней, если юзеры её знают, и Kotlin может зайти и Lua и Python.

JS VM как технология (например V8), если нужна песочница. Альтернативы есть (java sandbox, lua), но, имхо, джаваскриптовые песочницы на порядок надёжней, хотя бы потому, что работают на миллиардах браузеров и в них вложено больше всего усилий.

Но что произойдёт, когда этим всерьёз начнёт заниматься контора, отвечающая за стандарты языка и за jvm? Они увидят, что в js какие-то вещи не очень эффективно (скажем, в сравнении с другими вещами, потому что эффективность виртуальной машины с автоматическим сборщиком мусора вообще сомнительна — это не камень в твой огород, а факт, но у явы есть и достоинства) и появится соблазн добавить новые «фичи» в jvm, чтобы откомпилированный js-код работал быстрее и ел меньше памяти.

Например invokedynamic из Java 7 :)

Реальный случай на реальном производственном проекте:

Надо было по набору параметров, заголовков и самого запроса определять и отдавать правильную(оптимальную) сборку приложения, код представлял собой развесистый набор различных типов табличных и ветвистых переходов. Чтоб, при нахождении очередной ветви, не делать полную пересборку и выкладку вебприложения, вынесли код в javascript из динамически загружаемой конфигурации, в принципе подошёл бы любой скриптовый движок, но проект джавовский, а JS встроен в JDK, так что его успешно и заиспользовали.

Были ещё внедрения подобной модели в других, но потом выпилили, в пользу своих DSL, там вместо людей конфиг менеджеры правили, у них с javascript туго.

Только из-за многопоточности и лелею надежду разобраться с JRuby, но отсутствие нормальной работы с ActiveRecord (который в JRuby скрещивается с JDBC) меня бъёт по голове, и мне становится лень.

Что касается Graal (то есть, truffleruby), то

We do run Rails, and pass the majority of the Rails test suite. But we are missing support for OpenSSL, Nokogiri, and ActiveRecord database drivers which makes it not practical to run real Rails applications at the moment.

Но тут ключевое слово «at the moment». Теоретически поддерживаются нативные расширения, и это уже сделано для JS и npm. Там просто кто-то должен вложиться в разработку драйверов БД для AR. (может быть, это будешь ты? :) )

Это же всё равно лучше чем всякие begin/end. Но костылей могло бы быть и поменьше, да.

Не, мы напишем узкое место на Java! И потом Java -> WebAssembly :)

А там будет особая джава без сборщика мусора? Если со сборщиком, то лучше Rust -> WebAssembly или Си -> WebAssembly Хотя если специально для WebAssembly завезут ручное управление в Java... Но это вряд ли.

Зачем? Будет сборка мусора в джаве

begin/end IDE обычно умеет. И если выбирать между костылями и многословностью, лучше многословность.

Знаешь, именно после js я возлюбил begin/end. Сишный синтаксис хорош для (внезапно) си, ну может жава еще в него влазит. Уже на крестах видно какой это ужос на самом деле. Скобочки конечно были изящным решением в эпоху текстовых терминалов, но сейчас это смотрится как карго-культ.

А значит мы увидим много WASM в ноде как универсального безопасного байткода

В существующем виде WASM не пригоден для JS, так что это пока влажные мечты

Потому что ты так сказал?

Тебя в гугле что ли забанили?

https://github.com/WebAssembly/design/issues/219#issuecomment-114675346

На этом ресурсе иногда упоминают lua, но как-то постоянно в фоне и в списке рядом с другими языками, что обидно. Между тем, мне казалось, что lua уникален именно идеологией «всё есть таблица», почему он очень хорошо подходит для постреляционных, многомерных моделей данных. Как, теоретически, идеология Ruby «всё есть объект» должна хорошо ложится на документоориентированную модель. Сам по себе язык же не может существовать. Всё равно он обрабатывает какие-то данные. Вот по способу организации данных - понятно как подбирать язык их обрабатывающий. (Опять же - мне так казалось всегда). Тот же Си потому и Царь, что обрабатывает данные максимально близко к тому, как они представлены в ЭВМ на аппаратном уровне, они родные для него.
JavaScript, PHP - просто отличные языки сценариев широкого применения без ориентированности на конкретные модели. Зачем в них понатолкали ООП категорически не понятно. Ладно, эти хоть популярные в массах. Смотрел недавно как там сто лет забытый Kix поживает - оказывается и в него ООП умудрились втолкнуть.

Дом строю. Очень много операций выполняю болгаркой. Даже те, для которых она не предназначена. Наловчился. Мне удобно. Но я же это для себя. Поэтому понимание, что использую инструмент не по делу особо не мешает удовольствию от процесса. И уж тем более никому рекомендовать и навязывать эти странные и противоестественные приёмы не стану.

Итого: JavaScript действительно лучше других языков там, где он встроен в качестве обработчика пошагового сценария интерпретации входных данных. Вышел, сказал «кушать подано», ушел. Хорошая, нужная, понятная роль.

Зачем JS компилировать в WASM? Вроде C++/Rust предлагалось

Писать веб на C++? Не, ну можно было догадаться что извращенцы в конце концов к этому прийдут. Наиболее естественный язык для мастурбирующих макакиев, конечно же.

Вот тебе пример. Ты пишешь Фотошоп в браузере. Тебе нужно применить сложный фильтр к большому изображению. WASM сделает это быстро и безопасно для пользователя. Это на клиенте, но на сервере.

Альтернатива - попробовать WebCL, но спектр применения намного уже.

Фотошоп в браузере

Но зачем? По-моему wasm придумали не для этого, а просто чтобы насовать тебе бинарных зондов да побольше. Тут и без C++ думаю справятся.

По-моему wasm придумали не для этого, а просто чтобы насовать тебе и мне бинарных зондов да побольше

Да, пора переходить на links.

Удачи. elinks лучше.

Мне вообще w3m больше нравится. Классный html-пейджер. Буду по рецепту Столмана качать вгетом, потом смотреть в w3m. А еще у меня есть скрапбук «с кучей ништяков». Шах и мат, чекисты.