Comments 74
Так и стращают, хочется променять js.
Что после мешает компилировать строго-типизированный Dart в быстрый ASM?
Если у нас есть гарантированно быстрый asm.js, я могу сделать транслятор пайтона в этот asm.js и всё
Вообще ничего не мешает. главное, чтобы транслятор в C был, дальше emscripten, который генерит asm.js
Текущая скорость выполнения — в два раза медленее С.
Вообще ничего не мешает. главное, чтобы транслятор в C был, дальше emscripten, который генерит asm.js
Текущая скорость выполнения — в два раза медленее С.
Транслятор Python в asm.js сделать проблематично, потому что единственное, что в asm.js удобно компилировать, это низкоуровневые статически типизированные языки типа C/C++. Нету ни поддержки сборки мусора, ни возможности положится на адаптивные оптимизации предоставляемые низлежащей виртуальной машиной. Как следствие языки типа Python или даже Dart никакой пользы от asm.js в той форме, в которой его Mozilla специфицировала сейчас, не получают.
Есть, конечно, экспериментаторы, которые берут и целую виртуальную машину (написанную на языке типа C) компилируют в asm.js, как результат у нас получается GC, реализованный на asm.js, исполняющийся на виртуальной машине, которая имеет свой собственный более эффективный GC. Замечательно. Особые умельцы при этом могут даже реализовать для скомпилированной виртуальной машины JIT-backend, который выдает asm.js вместо машинного кода… Пример pypy.js. Правда ирония заключается в том, что согласно его последним цифрам pypy.js быстрее работает на V8, которая не поддерживает asm.js специальным образом, а не на SpiderMonkey, которая для asm.js имеет AOT-компилятор: twitter.com/rfkelly/status/409787571703529472
Есть, конечно, экспериментаторы, которые берут и целую виртуальную машину (написанную на языке типа C) компилируют в asm.js, как результат у нас получается GC, реализованный на asm.js, исполняющийся на виртуальной машине, которая имеет свой собственный более эффективный GC. Замечательно. Особые умельцы при этом могут даже реализовать для скомпилированной виртуальной машины JIT-backend, который выдает asm.js вместо машинного кода… Пример pypy.js. Правда ирония заключается в том, что согласно его последним цифрам pypy.js быстрее работает на V8, которая не поддерживает asm.js специальным образом, а не на SpiderMonkey, которая для asm.js имеет AOT-компилятор: twitter.com/rfkelly/status/409787571703529472
Для Питона GC не нужен, у него все равно своя семантика (с подсчетом ссылок) — и что бы ни говорила спецификация по поводу того, что это implementation detail, на практике на него полагается слишком много кода.
Проблема в том, что, насколько мне известно, на asm.js и произвольный сишный код тоже не особо удобно портировать. В частности, если нужна работа с кучей, то под неё нужно заранее выделять массив заданного размера.
Проблема в том, что, насколько мне известно, на asm.js и произвольный сишный код тоже не особо удобно портировать. В частности, если нужна работа с кучей, то под неё нужно заранее выделять массив заданного размера.
Подсчет ссылок это разновидность GC строго говоря. Суть в том, что низлежащая VM обычно уже имеет свой собственный сборщик мусора и достаточно эффективный (потому что он имеет доступ к голому железу и параллелизму), и выстраивая свой собственный GC мы теряем в производительности.
Я понимаю. Проблема в том, что низлежащая VM в данном случае имеет GC, семантика которого не соответствует тому, что ожидает увидеть типичный код на питоне — поэтому использовать его в любом случае неудобно.
Кстати, если исходить из того, что asm.js по производительности реально близок к нативному коду — почему свой собственный сборщик мусора будет сильно медленнее стандартного?
Кстати, если исходить из того, что asm.js по производительности реально близок к нативному коду — почему свой собственный сборщик мусора будет сильно медленнее стандартного?
PyPy как-то живет с этим различием. Я не большой специалист по Python, но если нативные расширения и __del__ не использовать, то особо ничего ведь заметно не должно быть.
Он, конечно, не обязательно будет сильно медленнее, но просто будет медленнее. Основное ограничение это, конечно, однопоточность, хорошему GC неплохо бы параллелить все что можно, а еще лучше быть concurrent. Далее если у нас двигающий сборщик мусора, то неплохо бы чтобы копирование (и инициализация памяти) было реализовано наиболее быстрым образом для машины, на которой мы исполняемся (а это значит где-то может даже через xmm регистры надо изголяться память копировать). В asm.js нету паттерна, который бы распознался как «копирование памяти», значит будет циклик. Ну в заключение в сборщиках еще часто есть всякая инфраструктура написанная руками на ассемблере (e.g. write/read barriers), но да это относится к тому же разряду, что и JIT код — просто так на asm.js не переводится.
Самое главное мне просто непонятно, зачем воротить свой собственный GC, когда GC уже есть готовый :)
Он, конечно, не обязательно будет сильно медленнее, но просто будет медленнее. Основное ограничение это, конечно, однопоточность, хорошему GC неплохо бы параллелить все что можно, а еще лучше быть concurrent. Далее если у нас двигающий сборщик мусора, то неплохо бы чтобы копирование (и инициализация памяти) было реализовано наиболее быстрым образом для машины, на которой мы исполняемся (а это значит где-то может даже через xmm регистры надо изголяться память копировать). В asm.js нету паттерна, который бы распознался как «копирование памяти», значит будет циклик. Ну в заключение в сборщиках еще часто есть всякая инфраструктура написанная руками на ассемблере (e.g. write/read barriers), но да это относится к тому же разряду, что и JIT код — просто так на asm.js не переводится.
Самое главное мне просто непонятно, зачем воротить свой собственный GC, когда GC уже есть готовый :)
Cython. Ну а дальше вы поняли.
Суть в том, что это не будет транслятор Python в asm.js. Это будет виртуальная машина языка Python транслированная в asm.js со всеми вытекающими.
тьфу, Cython. это не CPython. Прошу прощения. Ну, конечно, если взять статически типизированный язык то все работает.
люди говорят, что писать на дарте вне предлагаемого редактора сложно
Вот тут почитал: gist.github.com/khoomeister/4976475
Что такое идиоматический JavaScript?
А, это у них в буржунетах баззворд такой. Они вообще любят к месту и ни к месту употреблять «idiomatic», «semantic», «intristic», «imperative» и тому подобное.
Это Ализар, лучше читать оригинал news.dartlang.org/2014/01/dart-11-features-up-to-25-faster.html
Кусок из середины, вырванный из контекста (где слово используется для того чтобы отделить просто js от dart2js), попал в заголовок.
Кусок из середины, вырванный из контекста (где слово используется для того чтобы отделить просто js от dart2js), попал в заголовок.
JavaScript который выглядит как JavaScript. Грубо говоря если у вас есть 100 точек, которые вы хотите показать на карте, то это может быть или JavaScript-массив из 100 JavaScript-объектов или Float64Array на 200 элементов.
Первое — «идиоматический JavaScript» (медленно, но может быть воспринято человеком), второе — обычно результат работы транслятора xxx2js (в тяжёлых случаях в конечном итоге у вас в программе пяток типизированных массивов и больше вообще ничего, вся работа идёт через индексы и все объекты исчезли на стадии компиляции в JS… если они вообще когда-либо были).
Первое — «идиоматический JavaScript» (медленно, но может быть воспринято человеком), второе — обычно результат работы транслятора xxx2js (в тяжёлых случаях в конечном итоге у вас в программе пяток типизированных массивов и больше вообще ничего, вся работа идёт через индексы и все объекты исчезли на стадии компиляции в JS… если они вообще когда-либо были).
Ну, судя по наблюдениям, Dart поклонники GWT с нетерпением ждут, а то им JavaScript-де учить страшно. Только вот Дарт припозднился сильно, а в JS тем временем всяких MVC-фреймворков наделали. Так что большинство из ждущих товарищей, как мне кажется, уже не дождались.
Ну, гуглу он плох тем, что имеется множество независимых реализаций движка, не привязанных к гугловой платформе.
Подаётся под соусом «нормальное ООП вместо прототипно-ориентированного» и «статическая типизация вместо динамической», а также неназванных проблем производительности и масштабируемости.
Подаётся под соусом «нормальное ООП вместо прототипно-ориентированного» и «статическая типизация вместо динамической», а также неназванных проблем производительности и масштабируемости.
Я от вас много раз пытался добиться, что же такого в Dart привязанного «к гугловой платформе», но так как-то не получается. Если оно работает нормально в Firefox и скажем лежит на Heroku, а стандартизацией языка занимается комитет в ECMA (TC-52), то где здесь привязка к чему либо?
Далее было бы очень прикольно, если бы Mozilla разработала свою собственную Dart VM. Потому что конкуренция порождает прогресс :-)
Я вам также уже говорил, что Dart не статически типизированный, поэтому не может подаваться под соусом «статическая типизация вместо динамической».
Что касается нормального ООП, то это чистая правда. ООП действительно в Dart нормальное, но что главнее всего оно уже есть в языке, а не эмулируется каждым программистом в меру потребностей этого программиста и в зависимости от его предпочтений.
Далее было бы очень прикольно, если бы Mozilla разработала свою собственную Dart VM. Потому что конкуренция порождает прогресс :-)
Я вам также уже говорил, что Dart не статически типизированный, поэтому не может подаваться под соусом «статическая типизация вместо динамической».
Что касается нормального ООП, то это чистая правда. ООП действительно в Dart нормальное, но что главнее всего оно уже есть в языке, а не эмулируется каждым программистом в меру потребностей этого программиста и в зависимости от его предпочтений.
Далее было бы очень прикольно, если бы Mozilla разработала свою собственную Dart VM.
Зачем мозилле разрабатывать Dart VM, у них же был какой-то свой язык, если я ничего не путаю.
> Я от вас много раз пытался добиться, что же такого в Dart привязанного «к гугловой платформе», но так как-то не получается.
Вы не могли бы освежить мою память и напомнить, например, предыдущие три раза, когда вы пытались от меня добиться ответа на этот вопрос.
> Если оно работает нормально в Firefox и скажем лежит на Heroku, а стандартизацией языка занимается комитет в ECMA (TC-52), то где здесь привязка к чему либо?
Оно НЕ работает ни в Firefox, ни на Heroku (только через трансляцию в JS). Ни один вендор не сообщал о намерении поддерживать Dart LLVM (см. en.wikipedia.org/wiki/Dart_%28programming_language%29#Browser_adoption).
Комитет TC-52 был организован аж месяц назад (13 декабря 2013 года, news.dartlang.org/2013/12/ecma-forms-tc52-for-dart-standardization.html) и сделал пока примерно ничего.
Смысл ваших аргументов мне неясен. Существование open-source Chromium и Android никак не мешает гуглу извлекать профит из привязки пользователя к платформе.
Ну и лучше Брендана Эйка мне не сказать
> Я вам также уже говорил, что Dart не статически типизированный, поэтому не может подаваться под соусом «статическая типизация вместо динамической».
Ок, опциональная статическая типизация — так лучше?
Dart официально декларирует (см. habrahabr.ru/post/130065/) своими преимуществами: классовость, опциональная типизация, стандартные библиотеки, инструментарий.
Первое и второе вопрос вкуса, с третьим у JS всё ок (API интенсивно развивается), инструментарий у JS куда лучше.
> Что касается нормального ООП, то это чистая правда. ООП действительно в Dart нормальное, но что главнее всего оно уже есть в языке, а не эмулируется каждым программистом в меру потребностей этого программиста и в зависимости от его предпочтений.
ООП не подразумевает обязательной имплементации классовой парадигмы. Прототипное ООП — такое же ООП, как и классовое. Другое дело, что исторически вместо дисциплины «ООП» преподают конкретно классово-ориентированное ООП.
en.wikipedia.org/wiki/Class-based_programming
Вы не могли бы освежить мою память и напомнить, например, предыдущие три раза, когда вы пытались от меня добиться ответа на этот вопрос.
> Если оно работает нормально в Firefox и скажем лежит на Heroku, а стандартизацией языка занимается комитет в ECMA (TC-52), то где здесь привязка к чему либо?
Оно НЕ работает ни в Firefox, ни на Heroku (только через трансляцию в JS). Ни один вендор не сообщал о намерении поддерживать Dart LLVM (см. en.wikipedia.org/wiki/Dart_%28programming_language%29#Browser_adoption).
Комитет TC-52 был организован аж месяц назад (13 декабря 2013 года, news.dartlang.org/2013/12/ecma-forms-tc52-for-dart-standardization.html) и сделал пока примерно ничего.
Смысл ваших аргументов мне неясен. Существование open-source Chromium и Android никак не мешает гуглу извлекать профит из привязки пользователя к платформе.
Ну и лучше Брендана Эйка мне не сказать
I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM.
So 'Works best in Chrome' and even 'Works only in Chrome' are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste.
> Я вам также уже говорил, что Dart не статически типизированный, поэтому не может подаваться под соусом «статическая типизация вместо динамической».
Ок, опциональная статическая типизация — так лучше?
Dart официально декларирует (см. habrahabr.ru/post/130065/) своими преимуществами: классовость, опциональная типизация, стандартные библиотеки, инструментарий.
Первое и второе вопрос вкуса, с третьим у JS всё ок (API интенсивно развивается), инструментарий у JS куда лучше.
> Что касается нормального ООП, то это чистая правда. ООП действительно в Dart нормальное, но что главнее всего оно уже есть в языке, а не эмулируется каждым программистом в меру потребностей этого программиста и в зависимости от его предпочтений.
ООП не подразумевает обязательной имплементации классовой парадигмы. Прототипное ООП — такое же ООП, как и классовое. Другое дело, что исторически вместо дисциплины «ООП» преподают конкретно классово-ориентированное ООП.
en.wikipedia.org/wiki/Class-based_programming
> Оно НЕ работает ни в Firefox, ни на Heroku (только через трансляцию в JS). Ни один вендор не сообщал о намерении поддерживать Dart LLVM
Именно для этого создан dart2js, создающий на выходе кроссбраузерный (да еще и весьма быстрый) код. Просто нативный Dart VM быстрее, вот и все дела.
Насчет типизации и библиотек — просто Dart… более классический, что ли, чем JS. Он очень близок к Java (или даже C#) по синтаксису и идеологии + там есть более-менее нормальная библиотека коллекций, а Future и Isolates очень удобны в использовании.
Именно для этого создан dart2js, создающий на выходе кроссбраузерный (да еще и весьма быстрый) код. Просто нативный Dart VM быстрее, вот и все дела.
Насчет типизации и библиотек — просто Dart… более классический, что ли, чем JS. Он очень близок к Java (или даже C#) по синтаксису и идеологии + там есть более-менее нормальная библиотека коллекций, а Future и Isolates очень удобны в использовании.
Ок. Дарт вполне себе неплохой язык со своей нишей, подобно Coffee Script и Type Script.
Проблема-то только в том, что, в отличие от создателей других обёрток/альтернативных языков, Гугл всерьёз планирует ЗАМЕНИТЬ JavaScript. Везде — и в вебе, и на сервере.
gist.github.com/paulmillr/1208618
Т.е. заменить текущую систему на моноэкосистему из одного Дарта.
Проблема-то только в том, что, в отличие от создателей других обёрток/альтернативных языков, Гугл всерьёз планирует ЗАМЕНИТЬ JavaScript. Везде — и в вебе, и на сервере.
The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform.
gist.github.com/paulmillr/1208618
Т.е. заменить текущую систему на моноэкосистему из одного Дарта.
Как вы себе представляете реализацию такого плана: сегодня JavaScript работает, а завтра перестал? Мне становится смешно, это же очевидно не работоспособная идея. Такое может случится, только если JavaScript будет использоваться на 0.0000000000000000001% сайтов, а я сомневаюсь что такая ситуация когда либо возникнет. В каком-то смысле web это универсальная демократия.
Примите Dart за то, что он есть: еще один инструмент, который хочет быть полезным и который люди находят полезным.
Примите Dart за то, что он есть: еще один инструмент, который хочет быть полезным и который люди находят полезным.
> Как вы себе представляете реализацию такого плана
Понятия не имею, это у гуглоидов надо спрашивать, как они себе это представляют.
> Примите Dart за то, что он есть: еще один инструмент, который хочет быть полезным и который люди находят полезным.
Не могу, извините. У меня занятие такое — думать за архитектуру веба.
Понятия не имею, это у гуглоидов надо спрашивать, как они себе это представляют.
> Примите Dart за то, что он есть: еще один инструмент, который хочет быть полезным и который люди находят полезным.
Не могу, извините. У меня занятие такое — думать за архитектуру веба.
> Гугл всерьёз планирует ЗАМЕНИТЬ JavaScript. Везде — и в вебе, и на сервере.
Давайте говорить откровенно: воткнуть dart в каждый сервер хочет не гугл, а лишь одно его подразделение, работающее над самим dart. Потому что другая часть корпорации, работающая над, например, go грезит тем же самым. Крупные корпорации очень немонолитны, а в продвижении технологий даже внутри них самих дофига политики.
И еще через год ведущий разработчик dart-а может захотеть уйти из гугла, создав свой стартап, и язык перестанет ориентироваться на серверы, потому что этому разработчику «больше всех было нужно», а теперь двигать вперед направление некому.
В общем, я бы поостерегался заявлять, что гугл всерьез собирается заменить язык на серверах, тем более, что пока что «серебряные пули» редко летели дольше, чем длился шум вокруг них.
Давайте говорить откровенно: воткнуть dart в каждый сервер хочет не гугл, а лишь одно его подразделение, работающее над самим dart. Потому что другая часть корпорации, работающая над, например, go грезит тем же самым. Крупные корпорации очень немонолитны, а в продвижении технологий даже внутри них самих дофига политики.
И еще через год ведущий разработчик dart-а может захотеть уйти из гугла, создав свой стартап, и язык перестанет ориентироваться на серверы, потому что этому разработчику «больше всех было нужно», а теперь двигать вперед направление некому.
В общем, я бы поостерегался заявлять, что гугл всерьез собирается заменить язык на серверах, тем более, что пока что «серебряные пули» редко летели дольше, чем длился шум вокруг них.
Вы не могли бы освежить мою память и напомнить, например, предыдущие три раза, когда вы пытались от меня добиться ответа на этот вопрос.
Вы выше ссылку давали на свой топик, в котором вы объясняли почему лично вам Dart не нужен. Мы там с вами дискутировали навязывает ли вам кто-то что-то и привязывает ли вас кто-то к чему-то, но как-то так и не пришли к пониманию.
Оно НЕ работает ни в Firefox, ни на Heroku (только через трансляцию в JS).
Как-то я вас не понимаю, вы в одном предложении одновременно говорите «оно не работает, но оно работает». Трансляция Dart в JS это его встроенная фича, так сказать. Он проектировался, чтобы более менее нормально транслироваться в JS и исполнятся даже в браузерах, которые его нативно не поддерживают.
А на Heroku Dart кстати из коробки работает blog.sethladd.com/2012/08/running-dart-in-cloud-with-heroku.html
Dart LLVM
LL лишнее. Dart VM это Dart Virtual Machine, а LLVM это из другой оперы вообще.
Ок, опциональная статическая типизация — так лучше?
Да.
Прототипное ООП — такое же ООП, как и классовое.
Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия. Кто как хочет, так и рисует свои иерархии. Кто-то на конструкторах+прототипах (что часто называют «прототипным ООП», но что имеет весьма косвенное отношение к настоящему прототипному ООП из, скажем, Self), кто-то Object.create, кто-то клонирует (т.е. все-таки пытается прототипное ООП изобразить) и так далее. Точно такой же зоопарк в реализации делегации и в наследовании и в способах делать mixinы.
Большие команды обычно ставят жестокие рамки на то, как код должен писаться и тем спасаются.
А в Dart спасаться не нужно. Есть одно нормальное ООП и всё :-)
Ну да я вам этот аргумент, уже приводил (см. опять же свой топик), но вы его отметаете и говорите, что преимущества «неназываемы». Ну да и ладно, если вам Dart не нужен, я убеждать вас не буду, для меня главнее, чтобы разработчики, которые видят преимущества Dart для себя, могли его комфортно использовать и чтобы сомневающиеся видели достоинства и недостатки, а не просто негатив от людей, которые видят в языке (по совершенно непонятным мне причинам) какой-то злой умысел, а не желание облегчтить web разработку.
> Вы выше ссылку давали на свой топик, в котором вы объясняли почему лично вам Dart не нужен. Мы там с вами дискутировали навязывает ли вам кто-то что-то и привязывает ли вас кто-то к чему-то, но как-то так и не пришли к пониманию.
Вы не находите, что «один раз подискутировали, но не пришли к пониманию» — это как-то совсем не то же самое, что «я много раз пытался добиться от вас ответа, но как-то не получается»?
> Как-то я вас не понимаю, вы в одном предложении одновременно говорите «оно не работает, но оно работает». Трансляция Dart в JS это его встроенная фича, так сказать.
Что не понятно? Dart в Firefox не работает — это JavaScript работает в FF. Dart же только препроцессор.
> А на Heroku Dart кстати из коробки работает
«Из коробки» в Heroku работают Ruby, Java, Python, Clojure, Scala и Node
devcenter.heroku.com/categories/language-support
Читайте свою ссылку внимательно: you can now run your server-side Dart app on Heroku's cloud. Read on to learn how. (Disclaimer: Even though Heroku can host arbitrary runtimes, they don't officially support the Dart runtime.)
Напишите ещё «Amazon EC2 поддерживает Dart», ага.
> LL лишнее. Dart VM это Dart Virtual Machine, а LLVM это из другой оперы вообще.
Ок. По существу есть замечания?
> Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия.
Т.е. вы против разнообразия? Оооок.
> просто негатив от людей, которые видят в языке (по совершенно непонятным мне причинам) какой-то злой умысел, а не желание облегчтить web разработку.
А можно уточнить, где в текущем треде вы увидели «негатив» с моей стороны. Спасибо.
Вы не находите, что «один раз подискутировали, но не пришли к пониманию» — это как-то совсем не то же самое, что «я много раз пытался добиться от вас ответа, но как-то не получается»?
> Как-то я вас не понимаю, вы в одном предложении одновременно говорите «оно не работает, но оно работает». Трансляция Dart в JS это его встроенная фича, так сказать.
Что не понятно? Dart в Firefox не работает — это JavaScript работает в FF. Dart же только препроцессор.
> А на Heroku Dart кстати из коробки работает
«Из коробки» в Heroku работают Ruby, Java, Python, Clojure, Scala и Node
devcenter.heroku.com/categories/language-support
Читайте свою ссылку внимательно: you can now run your server-side Dart app on Heroku's cloud. Read on to learn how. (Disclaimer: Even though Heroku can host arbitrary runtimes, they don't officially support the Dart runtime.)
Напишите ещё «Amazon EC2 поддерживает Dart», ага.
> LL лишнее. Dart VM это Dart Virtual Machine, а LLVM это из другой оперы вообще.
Ок. По существу есть замечания?
> Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия.
Т.е. вы против разнообразия? Оооок.
> просто негатив от людей, которые видят в языке (по совершенно непонятным мне причинам) какой-то злой умысел, а не желание облегчтить web разработку.
А можно уточнить, где в текущем треде вы увидели «негатив» с моей стороны. Спасибо.
это как-то совсем не то же самое
У меня осталось воспоминание, что в том топике мы с вами ходили по кругу, и мы опять ходим по кругу здесь с одинаковыми аргументами и контраргументами.
Dart в Firefox не работает — это JavaScript работает в FF
Странная логика, JS-то вы не руками написали, он прямым образом получился из Dart программы и выполняет не что-то там случайное, а что в Dart программе было написано… Пользуясь вашей логикой можно ведь сказать, что Dart вообще нигде не работает, потому что CPU его не понимает, и это x86 (ARM, MIPS, etc) assembly, который работает на CPU.
Browser+JS это просто такая платформа, как CLR или там CPU+OS.
Напишите ещё «Amazon EC2 поддерживает Dart», ага.
Хорошо, коробка на официальная Herokuвская, но это не отменяет того факта, что вы можете там хостить свой server-side Dart без какой-либо привязки, которой вы так опасаетесь.
Есть даже стартап, который хочет предложить Dart PaaS: www.dartvoid.com/
Т.е. вы против разнообразия? Оооок.
Я за выразительные возможности и я против зоопарка :-) Опять же нужно понять: чем оно это разнообразие эмуляции ООП так полезно? Где здесь прибыль в виде ускорения разработки? Если 90% команд фиксируют одну и ту же модель эмуляции ООП на уровне конвенций о стиле разработки, то нет никакой пользы от разнообразия, а иногда оно просто вредит переиспользованию стороннего кода, который совсем не обязательно нормально вписывается в конвенции, установленные в вашей команде.
где в текущем треде вы увидели «негатив»
Для меня негатив состоит в том, что вы очевидно видите некий злой умысел за Dart, предполагаете, что кто-то хочет вам Dart «навязывать» и «привязывать». Кто-то хочет взять отключить JavaScript одной темной ночью и т.д. Это явно не нейтральные и точно не позитивные эмоции по отношению к Dart.
> Опять же нужно понять: чем оно это разнообразие эмуляции ООП так полезно?
(а) это не «эмуляция», а мультипарадигменность — разработчик волен использовать любую парадигму ООП или не использовать никакой.
(б) это разнообразие полезно абсолютно тем же, что и любое другое разнообразие.
> Если 90% команд фиксируют одну и ту же модель эмуляции ООП на уровне конвенций о стиле разработки,
Осталось показать, что 90% команд фиксируют одну и ту же модель.
На практике наиболее популярные фреймворки над JS (jQuery, Node.js и, скажем, Ext) используют совершенно разные подходы.
> нет никакой пользы от разнообразия, а иногда оно просто вредит переиспользованию стороннего кода, который совсем не обязательно нормально вписывается в конвенции, установленные в вашей команде.
В нашей команде установлена вот такая конвенция.
Именно поэтому я люблю JS.
> Для меня негатив состоит в том, что вы очевидно видите некий злой умысел за Dart, предполагаете, что кто-то хочет вам Dart «навязывать» и «привязывать». Кто-то хочет взять отключить JavaScript одной темной ночью и т.д.
Это, фактически, прямые цитаты из переписки сотрудников Гугла. Вы видите негатив с моей стороны в том, что я цитирую идеологов Dart?
(а) это не «эмуляция», а мультипарадигменность — разработчик волен использовать любую парадигму ООП или не использовать никакой.
(б) это разнообразие полезно абсолютно тем же, что и любое другое разнообразие.
> Если 90% команд фиксируют одну и ту же модель эмуляции ООП на уровне конвенций о стиле разработки,
Осталось показать, что 90% команд фиксируют одну и ту же модель.
На практике наиболее популярные фреймворки над JS (jQuery, Node.js и, скажем, Ext) используют совершенно разные подходы.
> нет никакой пользы от разнообразия, а иногда оно просто вредит переиспользованию стороннего кода, который совсем не обязательно нормально вписывается в конвенции, установленные в вашей команде.
В нашей команде установлена вот такая конвенция.
Ни одно правило не является догмой, и не надо применять никакие правила бездумно. В частности, наличие сильных пользовательских use-case-ов является основанием для нарушения любого из правил.
Именно поэтому я люблю JS.
> Для меня негатив состоит в том, что вы очевидно видите некий злой умысел за Dart, предполагаете, что кто-то хочет вам Dart «навязывать» и «привязывать». Кто-то хочет взять отключить JavaScript одной темной ночью и т.д.
Это, фактически, прямые цитаты из переписки сотрудников Гугла. Вы видите негатив с моей стороны в том, что я цитирую идеологов Dart?
(а) это не «эмуляция», а мультипарадигменность
Я бы это назвал эмуляцией мультипарадигменности. Разницу с настоящей мультипарадигменностью почувствовать легко: там все парадигмы являются частью языка, а не состоят из спичек и изоленты. Можно допустим себя спросить: «А вот если я хочу ключевое слово
super для делегации к методам предка, то через какое место мне нужно этого добиваться?», и все становится ясно. Осталось показать, что 90% команд фиксируют одну и ту же модель.
Да было бы интересно включить такой вопрос в JavaScript Developers Survey. У меня есть ощущение, что большинство все-таки использует constructor+prototype.
используют совершенно разные подходы.
И вы считаете, что это хорошо? Мне почему-то ситуация, когда у нас есть фреймворки с несовместимыми объектными моделями кажется странной и неудобной, и не привносящей никакой пользы.
Ни одно правило не является догмой, и не надо применять никакие правила бездумно.
Правильно. А теперь у меня вопрос, даже два.
1. Фиксированная ли у вас в комманде объектная модель? Или каждый объекты делает как хочет? Мне почему-то кажется, что она фиксированная, и более того у вас есть библиотечка со всякими утилитными функциями, которая позволяет вам эмулировать выбранную парадигму ОО.
2. Почему вы эту конвенцию не стремитесь применить к JavaScript в целом. Например, кто сказал, что JS должен быть единственным языком, к которому программисты должны иметь доступ?
> Я бы это назвал эмуляцией мультипарадигменности. Разницу с настоящей мультипарадигменностью почувствовать легко: там все парадигмы являются частью языка, а не состоят из спичек и изоленты. Можно допустим себя спросить: «А вот если я хочу ключевое слово super для делегации к методам предка, то через какое место мне нужно этого добиваться?», и все становится ясно.
Т.е., по-вашему, «настоящая» мультипарадигменность — это когда парадигмы уже нативно вшиты в язык?
А мне вот казалось, что настоящая мультипарадигменность — это когда ты можешь сам изобрести и пользоваться любой парадигмой, как это сделали в jQuery, например.
> Да было бы интересно включить такой вопрос в JavaScript Developers Survey. У меня есть ощущение, что большинство все-таки использует constructor+prototype.
Ваши ощущения в карман не положишь, извините.
> И вы считаете, что это хорошо? Мне почему-то ситуация, когда у нас есть фреймворки с несовместимыми объектными моделями кажется странной и неудобной, и не привносящей никакой пользы.
> 1. Фиксированная ли у вас в комманде объектная модель? Или каждый объекты делает как хочет? Мне почему-то кажется, что она фиксированная, и более того у вас есть библиотечка со всякими утилитными функциями, которая позволяет вам эмулировать выбранную парадигму ОО.
> 2. Почему вы эту конвенцию не стремитесь применить к JavaScript в целом. Например, кто сказал, что JS должен быть единственным языком, к которому программисты должны иметь доступ?
Люди, отрицающие очевидное, меня всегда вводят в некоторые ступор. Вот, казалось бы, JS как никто демонстрирует свою пригодность для мышления в любых терминах. На нём написаны инструменты от супернизкоуровневых (NodeJS) до супервысокоуровневых (DOM), реализованы фреймворки в любой парадигме — классовое OO, MVC, MVP, etc; он сам породил несколько новых методологий (jQuery, JSON) — но нет, приходят люди и говорят, что этот инструмент неудобный и во всём этом многообразии нет никакой пользы. И одновременно при этом требуют предоставить взамен инструмент с меньшими возможностями.
Я не против Дарт как языка. Я против Дарт как инициативы по замене JS.
Т.е., по-вашему, «настоящая» мультипарадигменность — это когда парадигмы уже нативно вшиты в язык?
А мне вот казалось, что настоящая мультипарадигменность — это когда ты можешь сам изобрести и пользоваться любой парадигмой, как это сделали в jQuery, например.
> Да было бы интересно включить такой вопрос в JavaScript Developers Survey. У меня есть ощущение, что большинство все-таки использует constructor+prototype.
Ваши ощущения в карман не положишь, извините.
> И вы считаете, что это хорошо? Мне почему-то ситуация, когда у нас есть фреймворки с несовместимыми объектными моделями кажется странной и неудобной, и не привносящей никакой пользы.
> 1. Фиксированная ли у вас в комманде объектная модель? Или каждый объекты делает как хочет? Мне почему-то кажется, что она фиксированная, и более того у вас есть библиотечка со всякими утилитными функциями, которая позволяет вам эмулировать выбранную парадигму ОО.
> 2. Почему вы эту конвенцию не стремитесь применить к JavaScript в целом. Например, кто сказал, что JS должен быть единственным языком, к которому программисты должны иметь доступ?
Люди, отрицающие очевидное, меня всегда вводят в некоторые ступор. Вот, казалось бы, JS как никто демонстрирует свою пригодность для мышления в любых терминах. На нём написаны инструменты от супернизкоуровневых (NodeJS) до супервысокоуровневых (DOM), реализованы фреймворки в любой парадигме — классовое OO, MVC, MVP, etc; он сам породил несколько новых методологий (jQuery, JSON) — но нет, приходят люди и говорят, что этот инструмент неудобный и во всём этом многообразии нет никакой пользы. И одновременно при этом требуют предоставить взамен инструмент с меньшими возможностями.
Я не против Дарт как языка. Я против Дарт как инициативы по замене JS.
это когда парадигмы уже нативно вшиты
Ну вшиты не вшиты, но должны ощущаться как граждане первого класса, не должна абстракция протекать… А в JS только копни любую ОО реализацию, сразу прототипы видны.
Я против Дарт как инициативы по замене JS.
А я вам и не предлагаю в своей коробке инструментов заменять JS на Dart. Я все пытаюсь вам объяснить, что Dart — это предложение для тех, кто видит в нем пользу. Но вы мне не верите, я уж не знаю, что мне такое написать, чтобы вы мне поверили, что никто не может прийти и отобрать у вас JS. Это невозможно.
Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия. Кто как хочет, так и рисует свои иерархии...
Классы из ecmascript 6 вы смотрели?
class Animal {
constructor(name) {
this.name = name;
}
say() {
return this.name + " say:";
}
}
class Cat extends Animal {
say() {
return super.say() + " meow";
}
}
let tomas = new Cat('Tomas');
console.log(tomas.say());
Ничего не мешает уже сейчас использовать es6 и транслировать его в js. Хотя я конечно понимаю, что у вас есть и другие причины предпочитать Dart, но именно в плане стандартизации ООП в es6 есть какие-никакие подвижки.
Да я в курсе классов в ES6 и считаю, что очень хорошо, что их ввели, boilerplate у людей из кода станет постепенно исчезать. Проблема в том, что все остальные способы эмуляции классов остались, поэтому я бы ожидал, что особые любители так и продолжат делать свое собственное.
Более того возникает интересная ситуация когда люди могут вроде писать код на JS, потому что class выглядит похоже на то, что они где-то видели, но при этом не понимаю что происходит на самом деле, потому что внутри этот class реализован на основе прототипов. Люди будут себе ноги и руки отстреливать время от времени.
Более того возникает интересная ситуация когда люди могут вроде писать код на JS, потому что class выглядит похоже на то, что они где-то видели, но при этом не понимаю что происходит на самом деле, потому что внутри этот class реализован на основе прототипов. Люди будут себе ноги и руки отстреливать время от времени.
> Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия. Кто как хочет, так и рисует… А в Dart спасаться не нужно. Есть одно нормальное ООП и всё :-)
Угу. Вот только кроме Dart есть еще TypeScript, CoffeeScript, и далее везде. В итоге к существующему зоопарку добавилось еще несколько реализаций.
При этом TS, по крайней мере, пытается следовать драфту ES6 в тех фичах, которые последний покрывает…
Угу. Вот только кроме Dart есть еще TypeScript, CoffeeScript, и далее везде. В итоге к существующему зоопарку добавилось еще несколько реализаций.
При этом TS, по крайней мере, пытается следовать драфту ES6 в тех фичах, которые последний покрывает…
Ну в мире вообще говоря много языков программирования. Если экосистема языка достаточна богата, то задумываться о взаимодействии с другими языками нет необходимости, лишь бы сама эта экосистема была внутри согласованна. В случае когда у нас все программируют ОО в силу своих представлений о красоте согласованность как бы отсутствует.
С другой стороны мне интересно развитие идей Web Component, когда вы можете свое приложение собрать из инкапсулированных кусочков (Custom Elements) и вам нет необходимости задумываться о том, как они реализованы, и на каком языке, потому что они черные ящики. Но даже здесь возникают проблемы, потому что не всегда понятно что означает extend в таком случае, семантика опять оказывается привязана к языку.
С другой стороны мне интересно развитие идей Web Component, когда вы можете свое приложение собрать из инкапсулированных кусочков (Custom Elements) и вам нет необходимости задумываться о том, как они реализованы, и на каком языке, потому что они черные ящики. Но даже здесь возникают проблемы, потому что не всегда понятно что означает extend в таком случае, семантика опять оказывается привязана к языку.
Пишу каждый день на JS — и это ужасный язык.
Он не очевидный.
Прототипы ужасны (не сами по себе, а та реализация, что в языке).
Каждую вещь можно сделать 10 способами но только 3 будет приемлемым (но в вашем конкретном случае может быть только один).
И самое главное — Dart быстрее JS был и будет. Бывший разработчик V8 который теперь разрабатывает Dart говорил, что V8 дальше уже почти нереально улучшать, а из-за порототипного ООП его ускорять вообще очень сложно (там идёт прямая зависимость скорость-RAM).
Классический ООП гораздо удобнее для компиляторов и интерпретаторов, а в свете сяких WebGL, Canvas производительность часто стоит ребром.
Он не очевидный.
Прототипы ужасны (не сами по себе, а та реализация, что в языке).
Каждую вещь можно сделать 10 способами но только 3 будет приемлемым (но в вашем конкретном случае может быть только один).
И самое главное — Dart быстрее JS был и будет. Бывший разработчик V8 который теперь разрабатывает Dart говорил, что V8 дальше уже почти нереально улучшать, а из-за порототипного ООП его ускорять вообще очень сложно (там идёт прямая зависимость скорость-RAM).
Классический ООП гораздо удобнее для компиляторов и интерпретаторов, а в свете сяких WebGL, Canvas производительность часто стоит ребром.
stalkerg скорее всего Lars Bak имеет ввиду, я не настолько известный разработчик V8 ушедший в Dart, чтобы меня цитировать, к тому же я не согласен со словами «нереально», я считаю что в V8 есть много чего, что весьма реально улучшить и что будет улучшено.
Именно вас: www.youtube.com/watch?v=tCG0aPNvkTs (очень познавательная вещь, почти всем рекомендую кто изучает или использует JS).
Я сказал «почти нереально». Это значит, что сложно. А там где очень сложно может быть не очень экономически выгодно. Если не верно вас понял то sorry.
К тому же я помню выводы из проекта Ласточка для Python по сему дальнейшие увеличения производительности будут ложится на оперативку. Это к слову хорошо видно когда я запускаю Python+Tornado и NodeJS то разница в потреблении памяти в разы (это ясно так как в классическом интерпретаторе Python нету JIT).
к тому же я не согласен со словами «нереально»,
Я сказал «почти нереально». Это значит, что сложно. А там где очень сложно может быть не очень экономически выгодно. Если не верно вас понял то sorry.
К тому же я помню выводы из проекта Ласточка для Python по сему дальнейшие увеличения производительности будут ложится на оперативку. Это к слову хорошо видно когда я запускаю Python+Tornado и NodeJS то разница в потреблении памяти в разы (это ясно так как в классическом интерпретаторе Python нету JIT).
> Пишу каждый день на JS — и это ужасный язык.
Пишу каждый день на JS — и это прекрасный язык.
> Он не очевидный.
А Dart прям очевидный.
> Прототипы ужасны (не сами по себе, а та реализация, что в языке).
Каждую вещь можно сделать 10 способами но только 3 будет приемлемым (но в вашем конкретном случае может быть только один).
Некоторые считают, что это достоинство.
К тому же мы говорим не о просто «вещах», поскольку никакой избыточностью в JS и не пахнет, а о вариантах реализации той или иной парадигмы.
> И самое главное — Dart быстрее JS был и будет.
Ввиду asm.js это сомнительное утверждение.
> из-за порототипного ООП его ускорять вообще очень сложно
Не затруднит ли вас дать ссылку, где было бы написано, что JS сложно ускорять из-за прототипного ООП? Спасибо.
> Классический ООП гораздо удобнее для компиляторов и интерпретаторов
Не затруднит ли вас дать ссылку, где бы разъяснялся этот момент? Спасибо.
>, а в свете сяких WebGL
Простите, а вы хоть раз видели, как код для WebGL пишется?
> Canvas производительность часто стоит ребром.
Не затруднит ли вас указать примеры, где производительность Canvas упирается именно в производительность самого языка. Спасибо.
Пишу каждый день на JS — и это прекрасный язык.
> Он не очевидный.
А Dart прям очевидный.
> Прототипы ужасны (не сами по себе, а та реализация, что в языке).
Каждую вещь можно сделать 10 способами но только 3 будет приемлемым (но в вашем конкретном случае может быть только один).
Некоторые считают, что это достоинство.
К тому же мы говорим не о просто «вещах», поскольку никакой избыточностью в JS и не пахнет, а о вариантах реализации той или иной парадигмы.
> И самое главное — Dart быстрее JS был и будет.
Ввиду asm.js это сомнительное утверждение.
> из-за порототипного ООП его ускорять вообще очень сложно
Не затруднит ли вас дать ссылку, где было бы написано, что JS сложно ускорять из-за прототипного ООП? Спасибо.
> Классический ООП гораздо удобнее для компиляторов и интерпретаторов
Не затруднит ли вас дать ссылку, где бы разъяснялся этот момент? Спасибо.
>, а в свете сяких WebGL
Простите, а вы хоть раз видели, как код для WebGL пишется?
> Canvas производительность часто стоит ребром.
Не затруднит ли вас указать примеры, где производительность Canvas упирается именно в производительность самого языка. Спасибо.
А Dart прям очевидный.
Мой любимый язык это Python по этому, я бы сказал, что Dart гораздо более очевидный.
Некоторые считают, что это достоинство.
К тому же мы говорим не о просто «вещах», поскольку никакой избыточностью в JS и не пахнет, а о вариантах реализации той или иной парадигмы.
Мне нравится философия Python вырезка:
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Особые случаи не настолько особые, чтобы нарушать правила.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
До этого JS далеко. Особенно пугает подход к приведению типов.
Ввиду asm.js это сомнительное утверждение.
Вы пробовали на нём писать? Мягко говоря это ужасно, OpenCL и то удобнее будет (есть что то общее, в плане ощущений).
Не затруднит ли вас дать ссылку, где было бы написано, что JS сложно ускорять из-за прототипного ООП? Спасибо.
Выше дал ссылку на youtube. Да и это логично… в классовой системе вы класс можете собрать класс (как породитель) один раз создать и дальше не держать этот класс вместе с каждым объектом, а доступ к методам и аргументам можно осуществлять тупо смещением адреса (если статическая типизация).
Простите, а вы хоть раз видели, как код для WebGL пишется?
И сам писал. Но может быть как то не так… расскажете, что там не то?
Не затруднит ли вас указать примеры, где производительность Canvas упирается именно в производительность самого языка. Спасибо.
К примеру я писал систему частиц… :-)
> Мой любимый язык это Python по этому, я бы сказал, что Dart гораздо более очевидный.
Это очевидно?
> До этого JS далеко. Особенно пугает подход к приведению типов.
Напомните, чему равно значение вот такого выражения в Python:
> Вы пробовали на нём писать? Мягко говоря это ужасно, OpenCL и то удобнее будет (есть что то общее, в плане ощущений).
Разговор вроде про производительность шёл, нет?
asm.js ещё очень молодой, допишут к нему удобные инструменты, я не сомневаюсь.
> Выше дал ссылку на youtube.
Вы мне предлагаете посмотреть часовое видео, в котором, быть может, говорят об указанном вопросе — а, быть может, и нет.
Не затруднит ли вас привести ссылки на какие-то _тексты_, в которых говорится о том, что:
— JS сложно ускорять из-за прототипного подхода
— классовое ОО удобнее для написания компиляторов
Ещё раз спасибо.
> И сам писал. Но может быть как то не так… расскажете, что там не то?
Ну как бы там значительная часть кода не на JavaScript пишется. Интересно было бы узнать, откуда вы делаете вывод, что производительность WebGL упирается в JavaScript.
> К примеру я писал систему частиц… :-)
И?.. Я не совсем понял, как из этого следует, что вы упёрлись в производительность языка.
class Greeter implements Comparable {
String prefix = 'Hello,';
Greeter() {}
Greeter.withPrefix(this.prefix);
greet(String name) => print('$prefix $name');
int compareTo(Greeter other) => prefix.compareTo(other.prefix);
}
Это очевидно?
> До этого JS далеко. Особенно пугает подход к приведению типов.
Напомните, чему равно значение вот такого выражения в Python:
foo = 1,0 + 2> Вы пробовали на нём писать? Мягко говоря это ужасно, OpenCL и то удобнее будет (есть что то общее, в плане ощущений).
Разговор вроде про производительность шёл, нет?
asm.js ещё очень молодой, допишут к нему удобные инструменты, я не сомневаюсь.
> Выше дал ссылку на youtube.
Вы мне предлагаете посмотреть часовое видео, в котором, быть может, говорят об указанном вопросе — а, быть может, и нет.
Не затруднит ли вас привести ссылки на какие-то _тексты_, в которых говорится о том, что:
— JS сложно ускорять из-за прототипного подхода
— классовое ОО удобнее для написания компиляторов
Ещё раз спасибо.
> И сам писал. Но может быть как то не так… расскажете, что там не то?
Ну как бы там значительная часть кода не на JavaScript пишется. Интересно было бы узнать, откуда вы делаете вывод, что производительность WebGL упирается в JavaScript.
> К примеру я писал систему частиц… :-)
И?.. Я не совсем понял, как из этого следует, что вы упёрлись в производительность языка.
Какой жирный. Лучше пойду подальше от этого моста…
Затрудняюсь понять, что из этого «жирное».
Просьба предоставить пруфлинки?
Указание на то, что в Питоне типы так же динамически кастуются?
Пример кода на Дарт?
Указание на то, что из факта написания вами кода на канвас никак логически не подтверждает вашу фразу о том, что ключевой проблемой оптимизации кода для канваса является сам JavaScript?
Просьба предоставить пруфлинки?
Указание на то, что в Питоне типы так же динамически кастуются?
Пример кода на Дарт?
Указание на то, что из факта написания вами кода на канвас никак логически не подтверждает вашу фразу о том, что ключевой проблемой оптимизации кода для канваса является сам JavaScript?
class Greeter implements Comparable {
String prefix = 'Hello,';
Greeter() {}
Greeter.withPrefix(this.prefix);
greet(String name) => print('$prefix $name');
int compareTo(Greeter other) => prefix.compareTo(other.prefix);
}
По-моему все понятно. Более-менее Java-подобный синтаксис с местным «сахаром».
> foo = 1, 0 + 2
Вы утрируете. Любой начинающий питонист вам скажет что это tuple, и ничего неочевидного тут нет.
Пробовал dart2js, вопросов к компилированному коду, который я написал, нет — там все понятно и красиво. Загвоздка в другом — помимо мною написанного скомпилированного кода нужно еще подгружить js вариант некого окружения dart-а. А это приличный размер. Насколько я понимаю, dart -> js не актуально использовать на веб-сайтах, он больше подойдет для интранет. Вот будет круто когда, хотя-бы, хром будет нативно его крутить, так что ждем и надеемся. Язык сам красив и удобен. Может быть, это новое рождение языка для web.
Я так понимаю, что подключаемый компилятор нужен только на этапе разработки. Так же как и при работе с less. Для продакшена он компилируется и юзается уже скомпилированный вариант.
«Окружение», а точнее использованные библиотеки, включено в тот самый единственный js файл, который вы получили на выходе из dart2js. Причем dart2js старается выкинуть все, что не используется и оставить только те фрагменты библиотеки, которые реально использовались.
Основной дополнительный размер обычно приходит из
Основной дополнительный размер обычно приходит из
dart:html, потому что он уж слишком причесанный по сравнению с нормальным DOM (как пример вместо NodeList везде нормальные коллекции).
Я вот вообще не понимаю, почему производители браузеров не делают подключаемые модули для скриптовых языков. Пишешь в теге script type=«text/php» или type=«text/python» и все дела. А дальше уж пусть разработчики языка соревнуются, кто эффективнее.
В случается Java, например, это ничем хорошим не кончилось
ES6 module loader proposal
Делайте свой транслятор и подключайте любой язык. Поверьте, сделать транслятор, например Python->JS легче, чем добавить в браузер полноценную/обновляемую/безопасную поддержку языка
1.6.3.19 Loader.prototype.translate ( load )
Optionally translate the given source from some other language into ECMAScript.
Делайте свой транслятор и подключайте любой язык. Поверьте, сделать транслятор, например Python->JS легче, чем добавить в браузер полноценную/обновляемую/безопасную поддержку языка
Sign up to leave a comment.
Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов