Почему я не верю в Dart

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

    Сегодняшний пост про грядущее господство Дарта подтолкнул меня к тому, чтобы ясно сформулировать, наконец, почему я считаю Дарт всё равно просто гиковской игрушкой и в чем неправа корпорация Google. Начну, пожалуй, с цитаты:

    «Нужна полная замена JS — язык широкого профиля: от простых скриптов, для сложных приложений»

    Что в ней не так? Да то, что JavaScript и есть язык широкого профиля, от сложных скриптов до сложных приложений. JavaScript — высокоуровневый и чрезвычайно мощный объектно-ориентированный язык, и именно поэтому все попытки его «улучшить» проваливаются с треском (ну, пока, по крайней мере).



    В JavaScript есть некоторые очевидные досадные недоработки, типа объявления глобальной переменной без var, дурацкая таблица сравнений или отсутствие for… each. Положа руку на сердце, это вовсе не смертельные недостатки для языка программирования. Главная проблема JavaScript — это малая распространенность прототипного объектно-ориентированного программирования в противовес «классовому» объектно-ориентированному программированию. Стремление сделать из JavaScript «нормальный» язык приводит к каким-то монструозным конструкциям и полностью отбивает желание с ним работать. Стоит отказаться от классовой парадигмы — и работа с JavaScript становится лёгкой и приятной.

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

    Я с недоумением отношусь к подобного рода утверждениям:

    Но при написании приложений по прежнему остаются определённые проблемы: необходимость без классов/типизации писать приложения можно, но сложно — многие средства, которые позволяют той же Java иметь производительные VM и умные IDE не применимы к JS.


    Писать приложения на прототипах ничуть не сложнее, чем на классах, а уж умных IDE для JS уже вагон написан — WebStorm, NetBeans, Eclipse, Comodo, Aptana. WebStorm вполне справляется с такими нетривиальными для JS задачами, как перейти к декларации метода или провести рефакторинг интерфейса класса.

    Попробуем внимательно разобрать аргументацию собственно Гугла в пользу замены JavaScript:

    Dash is designed with three perspectives in mind:

    — Performance — Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have.

    — Developer Usability — Dash is designed to keep the dynamic, easy-to-get-started, no-compile nature of Javascript that has made the web platform the clear winner for hobbyist developers.

    — Ability to be Tooled — Dash is designed to be more easily tooled (e.g. with optional types) for large-scale projects that require code-comprehension features such as refactoring and finding callsites.

    Dash, however, does not require tooling to be effective--small-scale developers may still be satisfied with a text editor.


    1. Производительность. Здесь, признаться, аргументация гугла выглядит просто нелепой. Серверный V8 уж точно никак не медленнее Python, который используется в GAE; мне как-то не приходят в голову динамические интерпретируемые языки, которые были бы производительнее V8 JavaScript. Те, кто пытался использовать JS на серверах, скажут вам, что главная проблема V8 — стабильность работы, а вовсе не производительность. Думается, что Гугл мог бы легко допилить V8 до нормального стабильного серверного скриптового языка, но не делает этого. Почему?

    Главное же, что меня удивляет в пассаже про производительность JavaScript — это то, что Гугл отлично понимает, что главное — инфраструктура, а не производительность языка. Вспомните, как представители гугла смеялись над Майкрософтом. Секрет производительности гугла — в файловой системе и datastore, а вовсе не в производительности используемых языков программирования. Node.js со своей асинхронной природой, казалось бы, идеально подходит к гугловой архитектуре.

    2. Юзабилити. Этот аргумент вообще выше моего понимания — Гугл собирается создать Dart таким же удобным, как JavaScript — так чем в этом месте не устраивает JavaScript?

    Что, Dart прост и очевиден для начинающих? Ха-ха три раза. Я смотрю на вот этот туториал:
    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);
    }
    

    И он не производит впечатления простоты и понятности. Да, прикольные плюшки, но явно непривычные и нечитаемые для начинающих программистов.

    3. Фреймворки. Как я уже писал, тот же WebStorm прекрасно справляется с рефакторингом JS-кода; в любом случае, разработать собственный фреймворк, удобно поддающийся рефакторингу, и добиться его поддержки в IDE — гораздо проще, чем продвинуть язык на замену JavaScript.

    Итак, получается, что Dart может быть «лучше» JavaScript только в одном компоненте — он классический классовый объектно-ориентированный язык программирования, а не прототипный. Возможно, с точки зрения далеко идущих планов гугла и лучше, чтобы все языки были похожи друг на друга; с моей — нет, не надо без нужды увеличивать энтропию.

    Мне кажется, что задача гугла при внедрении Dart состоит ровно в одном — привязать всю веб-разработку к своему языку, своей платформе и своему фреймворку. Напомню: гугл отлично знает, что главное — инфраструктура, а не язык; поставляя язык «из коробки» вместе со своими инструментами и фреймворками, гугл пересаживает разработчиков на свою инфраструктуру. Никаких объективных причин искать замену JavaScript у гугла просто нет.

    Впрочем, исходя из бритвы Хэнлона, можно и предположить, что некая инициативная группа в составе гугла просто не понимает прототипную парадигму и стремится навязать взамен классовую. Тоже не исключено.
    Share post

    Comments 435

      +8
      Насколько я понял, хотят от JS отказаться не из-за самого языка (особенности и традиции етсть в любом, чем JS хуже/лучше), а из-за накладных расходов, которые ограничивают его быстродействие.
        +8
        Только почему-то нигде не пишут, что это за накладные расходы и почему их нет у той же Java, Python, Go, etc.
          +2
          «Гоу» лишний в этом ряду, он компилируемый.
            +2
            Java тоже
              0
              Она в байт-код компилируется, как и Пайтон. А «Гоу» — компилируемый.
                +4
                Байт-код Java давно уже не интерпретируется.
                  0
                  А что с ним происходит дальше? Компилируется в нативный код? Разница есть, конечно, тем не менее, затраты на эту компиляцию всё равно есть.
                    +6
                    Они есть только при запуске. Во время долгой работы приложения уже никаких накладных расходов не остаётся.
                      +1
                      Простите начинающего программиста — это JIT (just in time) compilation имеется в виду? А в Python есть такое?
                        0
                        Скорее, не «в», а «для». Со смешным названием ПиПи :)
                          –1
                          Наверное правильнее ПайПай. Python ведь произносится как Пайтон. Спасибо.
                            +4
                            Так что оно так, но кто ж на практике будет называть ПайПай что-то, что можно называть ПиПи :)
                          +1
                          JIT в принципе возможен и для Python и для Javascript (и для последнего есть). Вот только беда в том, что из-за динамической природы языка даже JIT породит не самый эффективный код (я писал об этом выше). Кстати, у дефолтной реализации питона есть ещё одна проблема — подсчёт ссылок. Так что, полагаю, всякие IronPython и JPython должны быть пошустрее, ибо они идут поверх среды, где уже есть и быстрый GC и JIT. А с недавних пор ещё и встроенная поддержка динамических языков.
                        0
                          0
                          Что вы все мне про JIT рассказываете? Разве непонятно чем компилируемый язык отличается от языка, у которого байткод и JIT? Это совершенно разные затраты на старт, это другие оптимизации. JIT ограничен в этом — ему надо компилироваться очень быстро, тут не до оптимизаций кода.
                            0
                            Ну оптимизации то происходят при компиляции в байткод. Думаю, в Java и в .NET JIT-компиляторы тоже оптимизированы в определенной мере (чтобы поддерживать баланс «оптимизации-скорость»). Конечно, все это уступает по скорости нативному коду. Но уж точно быстрее интерпретируемого.
                              0
                              Мы тут обсуждаем разницу между компилируемыми и компилируемыми «на лету» из байт-кода.
                  +3
                  Я вроде не задавался целью перечислять некомпилируемые языки. Я спрашивал, какие такие накладные расходы у JS по сравнению с (список из популярных интернет-языков).
                    0
                    «Гоу» тут всё-таки резко выбивается из ряда.

                    1) Он не является популярным.
                    2) Он строго типизированный и статический
                    3) Он компилируется (например, нет накладных расходов на интерпретацию чего бы то ни было)
                      0
                      4) он не интернет-язык (если вы имеете ввиду язык для создания сайтов)
                        0
                        Node.js уже вполне себе инструмент для создания сайтов, на котором крутятся очень даже некислые проекты. См. github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
                          +1
                          Парсер лох.
                            0
                            «Гоу» тут причём? Я про «Гоу» говорю, вы текст-то прочитайте.

                            На JS сайты делались задолго до появления Node.js, ASP посмотрите, хотя бы
                              0
                              А, сорри.
                            0
                            С чего бы? Go подходит для «создания сайтов» даже лучше, чем Python или Java. И уж точно лучше, чем всеми «любимый» PHP. Производительность феноменальная — ближе к C, чем к Java. Потребление памяти значительно меньшее чем у Java. Go, как и Python с Java включён в проект Google App Engine, что тоже свидетельствует в пользу его веб-применимости.

                            Для Go уже давно созданы и фреймворки, облегчающие создание сайтов (Web.go, Twister.go) и все необходимые библиотеки (для работы с DB, FS).
                              +5
                              Ну, я-то Гоу хорошо знаю, написал на нём не одну тысячу строк. Так вот, подходит он явно хуже. Он очень производительный, правда, но статический, уровень абстракции, следовательно, ниже. Многие вещи на нём просто дольше описывать.

                              Я знаю, что «Гоу» подключен к ГАЕ, но это пока эксперимент. Это эксперимент хотя бы потому, что язык обещают стабилизировать не раньше следующего года.
                                +5
                                Я тоже пишу на Go c момента его создания. И пишу на нём именно HiLoad проекты, позволяющие использовать один сервер там, где Java уже потребует два или три. Я понимаю, что это разница в подходах. Олдскульные программисты, к коим я отношу себя, не ленятся описать чуть побольше «на входе», чтобы получить «на выходе» значительно большую производительность.

                                BTW, у меня не поворачивается язык назвать экспериментом проект, под который уже выпущен GCC-компилятор :) GCCGO вполне можно использовать именно как стабильную ветвь, тем более, что GCC компилирует значительно эффективнее.
                                  +6
                                  Олдскульные программисты, к коим я отношу себя, не ленятся описать чуть побольше «на входе», чтобы получить «на выходе» значительно большую производительность.
                                  Вам важна скорость работы, другим — скорость разработки. В вебе часто важнее последнее. Зарплата программиста выше стоимости сервера, так что проще купить железку, чем нанять программиста.
                                  BTW, у меня не поворачивается язык назвать экспериментом проект, под который уже выпущен GCC-компилятор :) GCCGO вполне можно использовать именно как стабильную ветвь, тем более, что GCC компилирует значительно эффективнее.
                                  А у меня не повернётся язык назвать «Гоу» стабильным.

                                  Во-первых, с выходом новой версии частенько приходится что-то менять. В последний раз заменял Split на SplitN.
                                  Во-вторых, есть ещё масса странных мест. Например, зачем-то в CGO структуры выравниваются, чего мне совсем не нужно.
                                  В-третьих, есть ещё раздражающие глюки. К примеру (это место могли и исправить, кстати), если в конце функции return стоит под if/else, то компилятор жалуется, что нет return и не хочет компилировать.
                                    +1
                                    Зарплата программиста выше стоимости сервера, так что проще купить железку, чем нанять программиста.

                                    Ага, и к этому серверу обслуживающий персонал. Которому тоже нужно платить з/п.
                                      +2
                                      Стоимость аренды стойки не сравнима с зп программиста. Там где изменения может внести один быдло-кодер на каком-то скриптовом языке, вам понадобится пара высококвалифицированных программистов на «Гоу».
                                        +2
                                        Ну не знаю насчёт аренды. У нас на серваке в дисковом массиве один диск стоит моих пары з/п. А так даже не знаю по поводу быдлокодеров. Возможно, если проекты серьёзные, то имеет смысл и высококвалифицированных спецов держать. А то быдлокодер так набыдлокодит, что потом больше потеряешь денег, чем на з/п для спецов.

                                        Или вон фейсбук. Построили же себе датацентр. Тут уже не стоимость аренды. Тут и железо дорогое, и программисты крутые нужны. Которые на C++ пишут.
                                          +3
                                          Ладно, мы уезжаем в такие спорные дебри, что лучше не продолжать. :)
                                      +1
                                      Вам важна скорость работы, другим — скорость разработки. В вебе часто важнее последнее.


                                      99% задач веб-программирования уже давно имеют готовые решения. Я проверял — скорость копипаста одинакова для Python и Go :) Таким образом, задача сводится к наличию программиста, обладающего хорошей памятью и умением использовать open-source решения. Давайте говорить откровенно — почти все задачи веб-программирования сводятся к примитивным CRUD-операциям и работе с темплетами. Т.е. решаются одинаково несложно на любом языке, хоть на C++, хоть на Free Pascal.

                                      Я понимаю, что фрилансерам, клепающим под заказ примитивные проекты на готовых CMS проще и выгоднее подход «быстрой разработки», с передачей постоянных издержек непосредственному заказчику. Но когда разработка делается для собственных нужд, выгоднее платить квалифицированному программисту, чем наращивать серверные фермы и строить колхозников для обслуживания.

                                      Во-первых, с выходом новой версии частенько приходится что-то менять.

                                      А что заставляет вас постоянно обновлять версию?

                                      А у меня не повернётся язык назвать «Гоу» стабильным.

                                      Значит в Google работают инженеры и программисты менее квалифицированные, чем вы :) У них язык поворачивается.
                                        +3
                                        99% задач веб-программирования уже давно имеют готовые решения. Я проверял — скорость копипаста одинакова для Python и Go :)
                                        Мой опыт не столь однозначен, правда я использовал другие пары — Гоу и ПХП, в основном.

                                        Если касаться небольших кодовых вставок, скорость разработки порою неразличима, в больших проектах на процедурном подходе близкая (но у ПХП всё равно выше, это ведь не статический язык), на объектном у ПХП сильно выше.
                                        Давайте говорить откровенно — почти все задачи веб-программирования сводятся к примитивным CRUD-операциям и работе с темплетами.
                                        Вы как-то сильно всё упрощаете. Вы ещё скажите, что всё равно везде используется два числа — ноль и единица, посмотрите как всё просто.

                                        Я, кстати, сайты на Гоу не делал, у меня другие цели совершенно.
                                        А что заставляет вас постоянно обновлять версию?
                                        Постоянно ничего не заставляет, я три версии пропустил. Обновляться же иногда требуется. В языке появляются новые модули, в старых — новые возможности, сторонние модули так же обновляются. Не обновляться нельзя — исправляются баги, упрощаются некоторые вещи.

                                        Значит в Google работают инженеры и программисты менее квалифицированные, чем вы :) У них язык поворачивается.
                                        Есть такая поговорка «всяк кулик своё болото хвалит».
                                          +1
                                          За двадцать лет программирования я плотно поработал почти со всеми распространёнными языками. И именно Go оказался для меня наиболее близким к недостижимому идеалу. А вот как люди до сих пор пишут на PHP — диву даюсь. Более мутного языка даже представить себе не могу (а ведь писал даже на эрланге) — с ужасом вспоминаю те несколько лет, когда обстоятельства вынуждали с ним работать.

                                          Вы как-то сильно всё упрощаете. Вы ещё скажите, что всё равно везде используется два числа — ноль и единица, посмотрите как всё просто.

                                          Наоборот, я усматриваю у большинства программистов привычку излишне раздувать сложность. Представляете, как не повезло тем кодерам, которые работают у меня? Мне-то мозги не запудрить тем, «как это сложно» :) Впрочем, возможно сложными простые задачи делает именно привязанность мышления к шаблонам абстракций?
                                            +1
                                            За 22 года за компьютером я тоже много на чём программировал и защищать ПХП не стану. Язык плохой. Но у нас разговор вроде как не об этом вовсе.
                                              +1
                                              > мутного языка даже представить себе не могу (а ведь писал даже на эрланге

                                              Что мутного можно было найти в Эрланге, ума не приложу

                                        0
                                        А вот написал бы кто-нибудь про практическое применение гоу в реальных проектах (это и к bolk-у образение)? Так хорошо бы было…
                                          0
                                          «Обращение», конечно:)
                                            0
                                            Я писал небольшую заметку: bolknote.ru/2011/06/06/~3258

                                            С той заметки прошло несколько месяцев ещё более интенсивного использования языка, но мнение не изменилось.
                                          0
                                          К слову, а кроме GAE как у него с поддержкой на хостингах?
                                            +1
                                            Когда создаётся проект, требующий столь жёсткой оптимизации, о виртуальном хостинге как-то никто и не думает.
                                          0
                                          > но статический, уровень абстракции, следовательно, ниже

                                          В этом месте какие-нибудь хаскелисты вымерли от гомерического гогота.
                                            –1
                                            Я ничего смешного не сказал. Для меня знание человеком языка Хаскель не является признаком того, что он разбирается в языках и том как они устроены.
                                              0
                                              Это называется «я ему про Фому, он мне про Ерему».

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


                                              В выделенном слово «следовательно» поставлено неверно, потому что второе из первого не следует
                                    –2
                                    Накладные расходы есть как у компилируемых, так и некомпилируемых. Накладных расходов нет только если писать под конкретную CPU-архитектуру на ASM.
                                      +1
                                      Капитан заметил бы, что это смотря как писать. Существующие компиляторы на сегодняшних объёмах кода делают машинные коды более качественно, чем программист.
                                        –3
                                        Удивительно. Что только ни скажет человек в поддержку своих прошлых слов.
                                    +21
                                    Накладные расходы — из-за того, что язык динамически типизированный. Совокупность методов, которые доступны у объекта, известна только в рантайме. Следовательно, эта совокупность и хранится у самого объекта. У той же Java заранее для каждого типа известен точный набор методов. Это значит, что у объекта хранится только его тип. Теперь что происходит при вызове метода у объекта. В случае JavaScript происходит поиск метода по таблице методов. Это ещё учитывая, что надо перебрать все прототипы. В случае Java заранее известна позиция адреса метода в vtable, так что всё разруливается косвенной адресацией со смещением, которая в том же x86 поддерживается нативно.

                                    Задача анализа кода для динамически-типизированных языков в общем случае алгоритмически неразрешима. Поэтому любые оптимизации работают постольку поскольку и рано или поздно во что-нибудь операции. То же верно относительно IDE. Те, кто говорит «IDE для JavaScript» просто никогда не писали в Eclipse или IDEA на Java. Ну или на C# в VS + Resharper
                                      +1
                                      Т.е. вся проблема в статической типизации? Из-за неё гугл развёл весь сыр-бор что ли?
                                      Но постойте: полно же серверных языков с динамической типизацией — python (поддерживаемый Гуглом в GAE, между прочим), php, ruby, perl, erlang — и почему-то никто не призывает их хоронить и не заявляет, что они непригодны для больших проектов.
                                        +4
                                        Ну не знаю. Я просто ответил на вопрос. Лично я не считаю, что основное преимущество статической типизации — это быстродействие. Тут важнее скорость разработки. Не скорость выкатывания рабочего прототипа, как на Python, а полноценный жизненный цикл ПО.

                                        Кстати, про серверные. Если нагрузка большая, то никто не мешает купить сервер помощнее, сделать кластер и т.п. А вот у пользователя есть его слабенький нетбук или планшет. Который, заметьте, ещё и батарейку кушает. Так что, быть может, что-то тут есть…
                                          –1
                                          > Не скорость выкатывания рабочего прототипа, как на Python, а полноценный жизненный цикл ПО.

                                          Это, мягко говоря, спорное замечание. Я лично очень слабо себе представляю, как динамическая типизация может существенно уменьшить скорость разработки.

                                          > А вот у пользователя есть его слабенький нетбук или планшет. Который, заметьте, ещё и батарейку кушает. Так что, быть может, что-то тут есть…

                                          Упереться в производительность JS в Хроме — практически невозможно. Узким местом всегда будет отрисовка в браузере.
                                            0
                                            Это, мягко говоря, спорное замечание. Я лично очень слабо себе представляю, как динамическая типизация может существенно уменьшить скорость разработки.


                                            Если нужно вносить изменения в старый код, то статическая типизация порой спасает. Не ото всего, но от многих бед, свойственных тому же Python.
                                              0
                                              Если код криво написан, то тут уже ничего не поможет.
                                              0
                                              легко — попробуйте распарсить очень большой JSON (больше 10 — 12 Мб) или использовать что-то типа espeak.js
                                                +1
                                                Зачем использовать espeak.js, если есть нативный JSON.parse?
                                                  0
                                                  еще раз ) нативный JSON.parse плохо работает с очень большими (и сложными — меньше сложность, например, массив строк больших, легче) JSON объектами. Включая и серверный, V8 плохо переносит парсинг такого объема JSON-а.

                                                  espeak — это пример большого очень скрипта, который тормозит именно обработкой данных, не DOM. Это text-to-speach engine, скомпилированый через LLVM в javascript
                                                    +3
                                                    Отлично.
                                                    И что, какой язык хорошо работает с большими (больше 10-12 мб) JSON-объектами?
                                                      +1
                                                      на мой взгляд, если вы оперируете объектами ~ 10 мбайт, то предпочтительней использовать google protocol buffers, а не json
                                            0
                                            На сервере у вас есть альтернатива. Тот кусок, где вам важна статическая типизация или производительность вы можете переписать на Java или .Net. Если что-нибудь из этого вам понадобилось в браузере вы можете только смирится и писать на JS.
                                              0
                                              См. мой коммент выше. Мне неизвестны примеры браузерного приложения, упирающегося в скорость чистого JS, а не отрисовки. Вам, быть может, такие примеры известны?
                                                +7
                                                Вспоминаю только демки на canvas с Box2D. Тормоз там как раз физический движок Box2D, а не canvas. Но в целом да, более серьезных примеров, упирающихся в скорость JS я не знаю. Но плюсы статической типизации — это не только скорость, это еще и контроль. На сегодняшний день, кроме костылей типа GWT воспользоватся статической типизацией нельзя.

                                                P.S. Ни в коем случае не защищаю дарт — я сам в него не особо верю. Считаю, что при текущем разнообразии задач, решаемых в браузере, разумнее всего было бы принять стандарт не на еще один высокоуровневый язык, а на байткод. Плюсы:

                                                1. Если вам нужен новый язык, вы пишите транслятор в байткод, а не ждете, пока поддержку вашего языка добавят во все браузеры.
                                                2. Кроме этого мы можем использовать любой уже существующий язык при наличии транслятора
                                                3. Весь код на этих языках совместим с друг другом. Например, код на JS без костылей сможет использовать библотеку, написанную на Python так, как будто она изначально писалась на JS.
                                                4. Поскольку передаем байткод, а не текст, немного экономится трафик
                                                5. По той же причине отсутствует синтаксический и лексический анализ на клиенте
                                                  –2
                                                  Так напишите транслятор в байт-код для JS, в чем тут проблема. Для прототипного Lua, например, такой транслятор существует => при желании его можно сделать и для JS.
                                                    0
                                                    ru.wikipedia.org/wiki/Llvm

                                                    LLVM позволяет компилировать программы написанные на языках Си, C++, Objective-C, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end
                                                      0
                                                      Тем более. Почему гугл не захотел сделать виртуальную машину для JavaScript, а решил написать полностью новый язык и продвигать его в браузеры?
                                                        0
                                                        Не знаю, тоже не понимаю.
                                                      0
                                                      Не проблема. Код браузеров не читал, но думаю что все JS-движки делают это. Только они делают это каждый по своему и уже после того как скачали себе скрипт. Если этот байткод стандартизовать и разрешить подключать напрямую к тегу <script>, то будет все то, что я описал в прошлом посте.
                                                      Что-то подобное предлагал сделать Мигель Де Иказа — всторить Mono в Firefox
                                                        0
                                                        Ну так почему гугл пошел не по простому пути — написать свою виртуальную машину — а по сложному — сделать новый язык и продвинуть в браузер? Выходит же, что и неплох JS, можно и с ним работать.
                                                          0
                                                          Я не знаю, я не работаю в Гугле. Уже говорил в другом топике, допустим, Дарт победит, он будет встроен во все бразуеры и будет жить там наравне c JS. Где гарантия что еще через 10 лет не нужен будет третий выскоуровневый язык, чтобы исправить ошибки Дарта? И того, несовместимых между собой высокоуровневых языков в браузере растет. [тут должен быть комикс xkcd про стандарты]
                                                  0
                                                  Или сделать это на Флеше :) Или на Яве (про апплеты забыли уже?). Или, если вспоминать решения Гугла скопилировать, используя Native Client в «Хроме».
                                                    0
                                                    Флеш и Ява работют не в браузере, а в своих ВМ. На сервере это терпимо, а на клиенте мобильники и планшеты идут лесом. Native Client — он будет работать где-либо кроме Хрома? Как плагин или нативно?
                                                      0
                                                      Про ВМ не понял в чём проблема.
                                                        0
                                                        Нужны плагины. Если для десктопа это в общем-то, не проблема, то для мобильных и планшетов у нас особо выбора нет. Апплетов и Native Client нет нигде, Флеш есть только на Android и Blackberry.
                                                          –1
                                                          Я, кстати, не в курсе как с апплетами на мобильных устройствах. Ничего нигде нет? Если да, то это очень странно.
                                                            0
                                                            Ну, их нет по крайней мере на iOS, Android, WP7 и Blackberry. Насчет Symbian, WebOS и Bada не знаю, но кажется мне, что тоже нет. При правильной архитектуре есть шансы относительно безболезненно сделать из апплета нативное Android или Blackberry приложение, но что делать с остальными платформами?
                                                          0
                                                          В процессоре и оперативке. Запустите на телефоне страницу с флешем и посчитайте сколько проживет батарея. Да и оперативки на эти vm нужно _дополнительно_ к движку браузера и js.
                                                  • UFO just landed and posted this here
                                                      +2
                                                      И почему же на них пишут-то тогда?
                                                      Потому что инфраструктура важнее производительности языка. Фронты множить очень легко.
                                                      • UFO just landed and posted this here
                                                          0
                                                          Python/GAE может похвастать.
                                                          • UFO just landed and posted this here
                                                              +1
                                                              Разные языки программирования существуют потому, что кому-то кажутся удобнее. Мне вот, например, динамически типизированные языки нравятся больше, чем статически типизированные.

                                                              В лагере javascript всё плохо просто потому, что прототипная концепция распространена много меньше классовой.
                                                              • UFO just landed and posted this here
                                                                  0
                                                                  > «Удобнее» и «нравится» не те аргументы, которые может привести инженер в споре. Вот если бы вы сказали — «динамическая типизация позволяет делать (какая либо уникальная особенность динамической типизации)» или что-нибудь подобное…

                                                                  Конечно. Зачем тут вообще приводить какие-то аргументы, если про этот холивар сотни страниц написаны. Нас интересует _только_ джаваскриптовая специфика, которая, по мнению гугла, не дает развивать джаваскрипт.

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

                                                                  Ну а вот разработчикам Dart/coffeescript/cappuccino/etc почему-то так не кажется.
                                                                    0
                                                                    По-моему, в Dart нет вывода типов, увы. Либо я что-то проглядел.
                                                                    Переменная без указания типа считается Dynamic, тип определяется в рантайме.
                                                                    • UFO just landed and posted this here
                                                                      • UFO just landed and posted this here
                                                                          0
                                                                          Возможно, это уже детали реализации. Не буду спорить, я еще спецификацию не прочитал полностью. =)
                                                              +2
                                                              Ну вашу фразу можно инвертировать: почему пишут на статически-типизируемых языках?

                                                              Что лично для меня — то я не очень люблю динамически-типизируемые языки. Когда я пишу код в IDE я хочу точно знать какие методы у какой переменной. Я хочу быть уверен что многие вещи задокументированы типами в самом коде. Я хочу смотреть на типы и понимать что делает данный метод. И мне не сложно дописать для этого типы.

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

                                                              Ну и про скорость еще одно соображение: когда разница на порядки (случай не самый частый, но бывает =( ) это становится грустно. И фразой «фронты множить очень легко» не отделаешься.
                                                              Да и не весь софт просто «фронты множатся».
                                                                0
                                                                > Ну вашу фразу можно инвертировать: почему пишут на статически-типизируемых языках?

                                                                Потому что каждый разработчик/тим-лид выбирает тот язык, который ему удобнее и который лучше (по его мнению) подходит к конкретному проекту.

                                                                В конечном итоге скорость языка не так важна, важна инфраструктура. Поэтому я и в недоумении, чем не угодил JavaScript.
                                                          +1
                                                          Никакой проблемы с RTTI прототипов нет.
                                                          Можете почитать как эту проблему обходит тот же V8( при появлении нового уникального «класса» он его жестко фиксирует под определённым именем, статически собирая предков, на выходе — vtable )
                                                          Насчет типизирования — мышки кололись, но продолжали писать JsDoc
                                                            +2
                                                            не совсем так, «предки» никуда статически не собираются, прямой аналог виртуальный таблицы не строится.

                                                            в любом случае возникает много интересных вопросов.

                                                            например, как отличить, «настоящий» объект, который используется ООП-стиле, от объекта, который используется как словарь (в JS-то нет полноценных словарей, только объекты с именнованными свойствами). представление оптимальное для словаря не оптимально для «настоящего» объекта и наоборот… приходится действовать эвристически (и всякие фичи типа delete только под ногами мешаются).
                                                              0
                                                              Никакой проблемы с RTTI прототипов нет.

                                                              Run time type information? А я как бы про compile time говорил.

                                                              Насчет типизирования — мышки кололись, но продолжали писать JsDoc


                                                              А как там с параметрическим полиморфизмом aka generics? Например, я хочу вызвать метод, который возвращает список. Как узнать тип элементов списка?
                                                                0
                                                                /**
                                                                 * @param {String[]} aliases
                                                                 */
                                                              –1
                                                              > В случае Java заранее известна позиция адреса метода в vtable, так что всё разруливается косвенной адресацией со смещением, которая в том же x86 поддерживается нативно.

                                                              Что за наглая неправда. Расскажите мне, какой процессор умеет выполнять байт-код явы? Никакой. Потому в реальности перед вызовом самого метода тратится куча инструкций на чтение и разбор байткода, проверку типа объекта, поиск адреса метода. и т.д. Более того, если мне не изменяет память, кривокодеры из сан в модуле хранят названия методов и классов из других модулей *текстом* а не каким-то идентификатором, так что там еще дополнительные расходы идут на их преобразование в id метода.

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

                                                              Вообще, Ява на редкость тормозной и неэффективный язык. Чтобы в этом убедиться, достаточно скачать тот же Eclipse и посмотреть, сколько времени он запускается (у меня почти минуту например).
                                                                0
                                                                Последний аргумент уже много лет доказывает мне что JIT в Java на самом деле приближают его по скорости к С\С++, а технология HotSpot позволяет даже обогнать матерого соперника
                                                                  +5
                                                                  Что за наглая неправда. Расскажите мне, какой процессор умеет выполнять байт-код явы? Никакой. Потому в реальности перед вызовом самого метода тратится куча инструкций на чтение и разбор байткода, проверку типа объекта, поиск адреса метода.


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

                                                                  Более того, если мне не изменяет память, кривокодеры из сан в модуле хранят названия методов и классов из других модулей *текстом* а не каким-то идентификатором, так что там еще дополнительные расходы идут на их преобразование в id метода.


                                                                  Ну и что, что преобразовывать? Один раз ведь! И то, в самом байт-коде хранятся не строковые идентификаторы, а смещения в constant pool. Их вполне можно использовать в качестве идентификаторов. А то, что метаданные вообще хранятся — это правильно, иначе RTTI идёт лесом.
                                                                    0
                                                                    Только что перезапустил эклипс — он уложился в 15 секунд.
                                                                    А MSVS сильно быстрее?
                                                                      +3
                                                                      Перезапуск — не считается, так как там прогрет кеш ОС и она половину данных читает из RAM а не с диска. Такие вещи лучше проверять сразу после загрузки системы. Но в любом случае, 15 секунд на современном многоядерном процессоре, выполняющем миллиарды операций в секунду, чтобы отобразить простое окошечко с текстом и меню — это приемлемо?

                                                                      Простая программа на Си может запускаться мгновенно, а на Яве — нет. Например, в Яве крайне неэффективный метод загрузки классов — они загружаются по одному (вдумайтесь!) по мере использования, причем из zip-архивов. Причем для работы даже простой программы нужна куча клакссов из rt.jar. На практике это означает огромное число random access обращений к диску. Вопрос, о чем думали инженеры сана. Очевидно, они думали только о том, как бы побыстрее выпустить продукт и захватить рынок, а не отнюдь о совершенстве, качестве и производительности.

                                                                      Если бы они ставили перед собой цели сделать качественный продукт, Java код компилировался бы в машинный код и работал с нормальной скоростью. жальЮ я плохо знаком с этой самой явой, уверен, у нее недостатков множество.

                                                                      Да, все мои комментарии относятся к использованию Java на десктопных рабочих станциях. На выделенном сервере все перечисленное, естественно, не критично.
                                                                        +1
                                                                        Но в любом случае, 15 секунд на современном многоядерном процессоре, выполняющем миллиарды операций в секунду, чтобы отобразить простое окошечко с текстом и меню — это приемлемо?
                                                                        Ну, эклипс это ж не только окошечко с текстом.
                                                                        И при загрузке подгружаются плагины с диска, а дисковым операциям ввода-вывода наплевать на производительность ЦП.
                                                                        Простая программа на Си может запускаться мгновенно, а на Яве — нет.
                                                                        Простая программа на Си никому не нужна. Нужна программа, которая умеет что-то делать. Можно подумать, Embarcadero RAD Studio или MS Visual Studio запускаются мгновено.
                                                                        Очевидно, они думали только о том, как бы побыстрее выпустить продукт и захватить рынок, а не отнюдь о совершенстве, качестве и производительности.
                                                                        Возможно, Гослинг сотоварищи действительно намного глупее вас.
                                                                        Если бы они ставили перед собой цели сделать качественный продукт, Java код компилировался бы в машинный код и работал с нормальной скоростью.
                                                                        А в машинный код какого процессора? Под X86, ARM, MIPS, SPARC или PowerPC? Потому-что сейчас один и тот же jar без перекомпиляции работает и на старой сантехнике, и на айбиэмовских мейнфреймах, и на писюках, и на старых маках.
                                                                          +4
                                                                          парсер — лох.
                                                                          … блин, зачем писать «можно использовать html-теги», если они не работают?..
                                                                          +1
                                                                          Например, в Яве крайне неэффективный метод загрузки классов — они загружаются по одному (вдумайтесь!) по мере использования, причем из zip-архивов. Причем для работы даже простой программы нужна куча клакссов из rt.jar. На практике это означает огромное число random access обращений к диску.

                                                                          Во-первых, курим класслоадеры и вообще подробно изучаем архитектуру загрузки классов в JVM и понимаем, почему так сделаны и откуда вообще могут браться классы. Во-вторых, на практике это ничего не означает. Подобные вещи могут свободно кэшироваться. Если что — можно написать свой мегакласслоадер, который работал бы оптимальнее. Вот только я думаю, что инженеры из Sun Oracle не такие уж дураки и о подобных вещах уже подумали.
                                                                            –1
                                                                            откройте для себя excelsior jet
                                                                            +2
                                                                            У меня MSVS открывается за 2 секунды, проект подхватывается еще за 2. Эклипс до такого же состояния открывается почти минуту. И то и то стоят на SSD.
                                                                            Хуже всего, что Eclipse работать просто невозможно, он тормозит. Пишешь себе код — он бац, о чем-то своём задумался секунды на две. Потом повылазили какие-то левые окошки с подсказками, которые уже неактуальны, перехватили нажатия клавиш, которые им не предназначались. Проект средний, 100к строк кода. Ну что за фигня-то в самом деле?
                                                                              0
                                                                              Проект 1М строк кода. Небольшие тормоза есть, но работать вполне можно.
                                                                            0
                                                                            Ну некоторые ARM'ы вообще-то умеют выполнять байт-код явы.
                                                                              0
                                                                              picoJava — это про процессоры.
                                                                            +2
                                                                            у JS есть один фатальный недостаток — отсутствие типизации (хотябы опциональной). Это все, это тяжелый крест на нем. Об этом жаловались разрабы V8 (нельзя нормально оптимизировать байткод), это самый гемор в разработке (все ошибки вылазят только в рантайме :)) ).

                                                                            но при этом нафига дартс — непонятно. для JS есть несколько нестандартизированных расширений (именно за их счет работает недавно проплывавший тут симулятор линуска под JS, на чистом JS ничего бы не вышло — сам автор у себя на сайте пишет)
                                                                              +1
                                                                              Пока ваш коментарий выглядит как будто единственным по комментарием делу. Dart остается динамическим языком, так что споры динамический язык vs статический или Java vs C++ вроде как не к месту. Мне все таки непонятно, неужели все улучшения производительности ожидаются только за счет типов? Гугл и ребята из v8 пока ничего не прояснили.
                                                                                0
                                                                                Причем типизация должна бы включать в себя возможность описания сложных структур с опциональными (но фиксированного типа) полями — примерно как описания Protocol Buffers. Плюс к этому — какой-то способ описания «декларативного duck typing» — чтобы можно было компактно сказать: «принимаю объекты, имеющие float x, float y и метод move(NUM x, NUM y)».

                                                                                Вторая претензия — способы управиться с асинхронным спагети в коде — к примеру, на базе continuations.
                                                                                0
                                                                                www.youtube.com/watch?v=tCG0aPNvkTs&list=FLwsU3PafdpFFy6SFC4RLklQ&index=26 — вот тут об этом рассказывает разработчик V8.
                                                                                +10
                                                                                «Накладные расходы» — это долбаное быстродействие DOM дерева, которое как было тормозным с момента его создания, так и остаётся до сих пор. В великом большинстве случаев затык происходит именно при работе с DOM, а не при мультипроцессорных вычислениях на голой веб-странице. Ну будет Dart, будет он слеплять строки быстрее, а чего толку, когда все это блокируется инициализацией кубиков на страничке.
                                                                                  0
                                                                                  Угу. XMLDocument в каком-нибудь PHP или Python — тоже пипец какая тормозная штука, но никто же по этому поводу не призывает убить PHP и Python.
                                                                                    0
                                                                                    Сервер-сайдовый питон использует биндинги к сишным библиотекам (наподобие той же libxml) для парсинга, поэтому со скоростью в этом случае все в порядке. А мы в данном случае говорим о клиентской стороне — здесь уже другие проблемы…
                                                                                      +3
                                                                                      Проход DOM тоже не на JS написан. Тот же самый «биндинг».
                                                                                        0
                                                                                        Первый проход, при построении — несомненно. А вот любые модификации объектов уже сформированного документа делаются яваскриптом, логично же.
                                                                                          0
                                                                                          Ровно то же происходит и в любом другом языке.
                                                                                            0
                                                                                            Не совсем. DOM на то и DOM, чтобы представлять объектный интерфейс яваскрипту для манипуляции телом документа, только вот все действия, которые составляют нечто большее, чем простое обращение к объекту, уже ограничиваются производительностью яваскрипта.
                                                                                              0
                                                                                              Так где по-другому-то?
                                                                                                +1
                                                                                                По-моему, мы об одном и том же говорим :) я уже даже потерял нить спора.
                                                                                            0
                                                                                            Не логично. Весь dom сидит в браузере и в его нативных структурах описания.
                                                                                            Внутренности браузера и js — это, к сожалению, два отдельных мира.
                                                                                              0
                                                                                              И чего? ну происходят они. Вы считаете, что вызов какого-либо метода DOM или обращение к свойству — это то, в чём недостаёт скорости JS? Он тут совсем ни при чем.
                                                                                                0
                                                                                                Я и не говорю, что он тут причем-то, я говорю, что любые манипуляции с объектами помимо вызовов методов DOM уже ограничиваются производительностью яваскрипта. Ну да, кэп-mode :)
                                                                                                  0
                                                                                                  Я ни разу не замечал, чтобы манипуляции с объектами ограничивались производительностью JS. Пример в студию.
                                                                                                    0
                                                                                                    Да не утверждаю я, что манипуляции DOM быстрее или медленнее движка яваскрипта. Я лишь говорю, что вся эта комбинация работает со скоростью самой медленной операции. Как и было уже замечено сверху.
                                                                                                      0
                                                                                                      Ну так Дарт здесь ничего не изменит. Зачем тогда уничтожать JS?
                                                                                                        0
                                                                                                        Я и не считаю, что надо уничтожать js. То, что делает гугл — это просто переливание пустого в порожнее в данном случае. Ну да, может, чуть более удобный синтаксис и чуть другое внутреннее устройство. Но в остальном это — навязывание стандарта. Я думаю, что они мыслят примерно так: «Выпуск новой версии JS с классами и Java-подобным синтаксисом — дело слишком хлопотное и не сиюминутное, поэтому почему бы не взять и не сделать свой, с преферансом и пианистками? Пусть даже это потребует плагинов к браузеру».
                                                                                                          +1
                                                                                                          Так я про то и написал статью: гугл хочет навязать всем свою инфраструктуру под соусом «JavaScript плохой».
                                                                                                            0
                                                                                                            Вот, уважаемый коллега, мы и пришли с вами к консенсусу :)
                                                                                                        0
                                                                                                        манипуляции с объектами помимо вызовов методов DOM уже ограничиваются производительностью яваскрипта

                                                                                                        Какими объектами? В каких случаях? Насколько ограничиваются?
                                                                                                          0
                                                                                                          Объектами DOM. Вы же не будете утверждать, что DOM служит для чего-то большего, чем базовая перестановка блоков и простейшее обращение к атрибутам? Ну и вот, а в случае любых, например, математических действий с этими объектами, играет роль уже производительность яваскрипта, а не DOM. К лучшему это или к худшему.
                                                                                                            0
                                                                                                            Вы что-то всё в одну кучу смешали. То говорите, что не имеете ввиду DOM, то опять какие-то манипуляции «математические» над DOM. Конкретный пример все-таки можно?
                                                                                                              0
                                                                                                              Да пожалуйста, например, вычисление и присвоение высоты блока на основе высот окружающих его блоков, с помощью математической функции. Здесь за обращение (get и set) к параметрам блоков будут отвечать DOM-методы, а вот за скорость математического вычисления высоты — яваскрипт. Что непонятно?
                                                                                                                0
                                                                                                                Ну так это обычные вычисления, они к DOM отношения не имеют никакого. Можно складывать циферки просто из массива с тем же успехем. И что, вы считаете, что скорость подобноё операции на данный момент никак не является производительной, зависание браузера или что-то ещё, когда вычисляете пару математических формул на JS?
                                                                                                                Это всё абстрактные примеры, у меня таких проблем не возникает при подсчёте сумм/разниц чисел и ему подобного.
                                                                                                                  0
                                                                                                                  Ещё раз, я не говорю, что DOM упирается в производительность яваскрипта или наоборот :) Я лишь говорю, что они решают разные задачи, но конечная производительность приложения зависит именно от скорости их совместной работы, а точнее, самой медленной операции. С чем вы не согласны?
                                                                                                                    0
                                                                                                                    Мой первый комментарий как раз в точности об этом. Если вы с этим согласны, то как какой-либо другой язык повысит эту скорость, когда самая медленная часть остаётся без изменений?
                                                                                                                      0
                                                                                                                      Никак :) и снова мы говорим об одном и том же. Насколько я знаю, никакой замены DOM еще не придумали, иначе это был бы Дом 2.
                                                                                                      0
                                                                                                      Пример приведёте, какие такие манипуляции с какими объектами затрагивают производительность вычислений на том же V8? Только конкретно, пожалуйста.
                                                                                            0
                                                                                            И тем не менее, видал я энтерпрайз, написанный на GWT, который тормозил не на DOM. И даже не на взаимодействии с сервером. Просто мог подвисать секунд на 5 и кушать 100% процессора.
                                                                                          +3
                                                                                          Лично меня сразу насторожило, когда Гугл начал разговаривать лозунгами. Как не молодой человек, уже повидал последствия такого общения с аудиторией.
                                                                                            +17
                                                                                            Re: JavaScript и есть язык широкого профиля, от сложных скриптов до сложных приложений. JavaScript — высокоуровневый и чрезвычайно мощный объектно-ориентированный язык

                                                                                            Ну-ну. Даже между Java 1.4 и java 1.5 лежит пропасть, а уж где JavaScript находится…
                                                                                            Q: А как на JS обстоят дела с синхронизацией потоков?
                                                                                            A: Нет потоков — нет проблем.

                                                                                            Q: Отсутствие строгой типизации не будет проблемой при создании больших приложений?
                                                                                            A: Нет (узким местом будет браузер, который начнет подвисать гораздо раньше)

                                                                                            Q: JS динамический язык, он наверно чем-то похож на Python?
                                                                                            A: Да. Только очень, очень, очень отдаленно.

                                                                                            Q: Что делать разработчику, если он не знает ни одного языка кроме JS?
                                                                                            A: Доказывать всем и вся, что «JS -высокоуровневый и чрезвычайно мощный объектно-ориентированный язык» (ц)
                                                                                              +34
                                                                                              Читаю этот комментарий и вспоминаю рассказ «Срезал».

                                                                                              > Ну-ну. Даже между Java 1.4 и java 1.5 лежит пропасть, а уж где JavaScript находится…

                                                                                              Какое отношение JavaScript имеет к Java?

                                                                                              > Q: А как на JS обстоят дела с синхронизацией потоков?
                                                                                              > A: Нет потоков — нет проблем.

                                                                                              А как там в Дарте дела обстоят с синхронизацией потоков, не напомните?
                                                                                              Реализация потоков на JavaScript давно написана Мозиллой, см. Rhino и Ringo. Подробный разбор здесь.

                                                                                              > Q: Отсутствие строгой типизации не будет проблемой при создании больших приложений?
                                                                                              > A: Нет (узким местом будет браузер, который начнет подвисать гораздо раньше)

                                                                                              Вы про клиент-сайд или про сервер-сайд? На серверной стороне нет никаких браузеров. А на клиентской стороне браузер будет всегда, независимо от того, выполняет он Dart или JavaScript.

                                                                                              > Q: JS динамический язык, он наверно чем-то похож на Python?
                                                                                              > A: Да. Только очень, очень, очень отдаленно.

                                                                                              Отличный аргумент! Если язык не похож на питон, то он не годится для high-load приложений, я правильно понял?

                                                                                              > Q: Что делать разработчику, если он не знает ни одного языка кроме JS?
                                                                                              > A: Доказывать всем и вся, что «JS -высокоуровневый и чрезвычайно мощный объектно-ориентированный язык» (ц)

                                                                                              Ну вот я знаю Питон, и как это мне должно помешать считать JS высокоуровневым и чрезвычайно мощным объектно-ориентированным языком?
                                                                                                0
                                                                                                Срезал так срезал.
                                                                                                +10
                                                                                                Знаете, они хотят сделать свой классический ОО язык, чтобы можно было юзать стандартные шаблоны проектирования, а также юзать MVC. Для многих это — признак крутости.
                                                                                                А тут бац — прототипный язык, да еще и с асинхронным вызовом. Епт, как же я MVC то реализую? О, идея — а сделаю я классический ОО язык…

                                                                                                В прототипном, асинхронном ООП, есть свои шаблоны проектирования (некоторые вы в исх. коде jQuery можете увидеть). Только гуглить придется откровенно долго.
                                                                                                Про разделение логики и представления. На msdn находил хорошее описание реализации для асинхронным языков программирования. Да и книжка старая у меня где-то была. Там про подходы решения задач с инструментами асинхронной обработки.
                                                                                                Я прошу прощения, что не привожу ссылки — нет времени по хистори лазить.

                                                                                                Кстати, прошу взглянуть на QT и Java. И если говорят, что JavaScript убожество, то пусть взглянут на JavaScript и его собрата QScript(в QT). И вот Dart я не могу представить в Java или в QT.
                                                                                                  +1
                                                                                                  Собственно именно так
                                                                                                  JS быстрый, удобный, но держать на нём крупный проект просто невозможно. Классическая схема работы, построенная на ООП, наследовании, инкапсуляции тут просто не работает.

                                                                                                  Это основная причина появляния Dart-а.
                                                                                                    0
                                                                                                    > JS быстрый, удобный, но держать на нём крупный проект просто невозможно.

                                                                                                    А ребята из plurk.com и не знали.

                                                                                                    > Классическая схема работы, построенная на ООП, наследовании, инкапсуляции тут просто не работает.

                                                                                                    А нельзя как-то с примерами, где какая схема не работает?
                                                                                                      0
                                                                                                      > А ребята из plurk.com и не знали.

                                                                                                      Простите, а что именно и в каких объемах у них написано на JavaScript?
                                                                                                        0
                                                                                                        Чатег. amix.dk/blog/post/19490
                                                                                                        Что, скажете, это не пример high-load веб-приложения?
                                                                                                          0
                                                                                                          не хочу вас сильно огорчать (я сам сильно огорчился, когда узнал :-)), но они обратно на Java перебежали:

                                                                                                          amix.dk/blog/post/19577

                                                                                                          [в любом случае надо разделять скажем приложения с большой нагрузкой и приложения с большой (архитектурной) сложностью, это две совершенно ортогональные характеристики. например, приложение под большой нагрузкой может быть очень компактным и простым]
                                                                                                            0
                                                                                                            Remember that node.js served us well for the past 8 months serving millions of comet notifications each day.


                                                                                                            А дальше речь про то, что в V8 нет нормальной реализации тредов, хотя Мозилла давно запилила её в своем Рино. Так что, очевидно, мы сталкиваемся именно с нежеланием самого Гугла допилить V8 до уровня нормального сервер-сайд движка.
                                                                                                              0
                                                                                                              У V8 есть изоляты. Хочется использовать потоки? Пожалуйста. То, что node.js не использует изоляты, это их архитектурное решение.

                                                                                                              [ну и ECMA-262 не стандартизирует модель многопоточного исполнения с общим состоянием для JavaScript. у SpiderMonkey, например, был режим когда несколько потоков могли существовать в пределах одной VM (с устным условием(!), что они не трогают одни и те же области памяти, иначе бабах!), но он теперь «deprecated», ибо одна головная боль].
                                                                                                                0
                                                                                                                Отлично. Теперь ключевой вопрос: почему Гугл вместо того, чтобы использовать уже готовый V8 бросился делать новый язык, внедрять его в браузеры и переучивать миллионы разработчиков?
                                                                                                      +1
                                                                                                      Кто не работает?
                                                                                                      У меня все отлично работает!
                                                                                                      Быть может дело не в языке, и не его архитектуре.
                                                                                                      А в архитектуре конечного приложения?
                                                                                                    0
                                                                                                      +5
                                                                                                      Код, упомянутый в статье очень хорошо понятен Java и PHP программистам, коих в мире web больше всех, кажется. Для больших проектов реально важно иметь статическую типизацию. Неприятие автором этого утверждения, на мой взгляд, говорит лишь об отсутствии положительного опыта в таких проектах. В больших проектах приходится ограничивать свободу разработчику, чтобы проект не развалился. Уверяю, автоматически обнаружить ошибку на этапе compile time, это лучше, чем писать тест с проверкой типа.

                                                                                                      Полагаю, что цель Гугла, создать язык не только для клиентских скриптов, но и для сервера. Единый язык для клиента и сервера позволит создавать веб-фреймворки нового уровня качества, по сравнению с Ruby on Rails и даже GWT.
                                                                                                        +3
                                                                                                        >>Код, упомянутый в статье очень хорошо понятен Java и PHP программистам
                                                                                                        А так же AS3 и C# программистам. ИМХО, он понятен любому ООП программистe.

                                                                                                        Не знаю, как остальные, а я вот в первую очередь хотел бы увидеть от Дарта две вещи — один движок для всех браузеров, пускай на некоторых это даже будет плагин, как сейчас Flash, и родной, привязанный к языку фреймворк для разработки, без геморроя с HTML DOM.
                                                                                                          +1
                                                                                                          > Для больших проектов реально важно иметь статическую типизацию.

                                                                                                          Т.е. на питоне, руби, php не пишут большие проекты? И зачем тогда гугл использует Python в GAE?
                                                                                                          Вы, видимо, проглядели мысль: инфраструктура важнее языка, и в гугле это отлично понимают.
                                                                                                            +1
                                                                                                            Пишут. Только обслуживать и развивать такие проекты — это ад. Технический долг в таких проектах моментально пересекает критическую черту.

                                                                                                            Я не проглядел мысль, что инфраструктура важнее языка, и полностью согласен с этим утверждением. Я не согласен с оценочным суждением языка в статье. Гугл может преследовать любые выгодные ему цели. От хорошего языка и хорошей инфраструктуры выиграют все, не только Гугл.
                                                                                                              +2
                                                                                                              Я вот все читаю и думаю… а ведь был VisualBasic, единый на сервере и на клиенте…
                                                                                                                0
                                                                                                                > Только обслуживать и развивать такие проекты — это ад. Технический долг в таких проектах моментально пересекает критическую черту.

                                                                                                                Примеры можно?

                                                                                                                > От хорошего языка и хорошей инфраструктуры выиграют все, не только Гугл.

                                                                                                                Речь идёт не просто о хорошем языке, а о полной замене JavaScript, который гугл справедливо называет lingua franca веб-разработки (и который, замечу, никому не принадлежит) на свой Дарт, т.е. об установлении монополии. А это очень, очень плохо.
                                                                                                                  –1
                                                                                                                  Можно, на личном опыте. Я люблю досконально изучать основные фреймворки, с которыми работаю. Так вот на Java в Eclipse, спокойно могу сидеть и исследовать код. Всё удобно, всё под рукой и на горячих клавишах. Уходи на любую глубину — не потеряешься.

                                                                                                                  Затем я столкнулся с Django… Долго я матюгался, пытаясь исследовать код этого фреймворка. Банально — сидишь и гадаешь, а что в этот метод можно передать, а что нет. И вообще, что туда можно передать. Такие вещи просто выводили из себя, а еще и документации к этому методу толку нет.
                                                                                                                    0
                                                                                                                    Какая нафиг монополия? Вот JavaScript это точно монополия.
                                                                                                                      +2
                                                                                                                      На данный момент существует 4 активно развивающихся JS-движка.
                                                                                                                      Движок дарта будет один.
                                                                                                                        +1
                                                                                                                        Почему вы в этом так уверены? Может тоже их будет 4? Вроде же open-source, не?
                                                                                                                          0
                                                                                                                          Потому что если их будет четыре, гугл зря затевал эту революцию. Я не верю здесь, что за добрыми намерениями гугла не стоит желание править миром.

                                                                                                                          Хром вот тоже якобы open-source и всем прекрасен. А ещё он оружие против Яндекса. И с Дартом будет то же.
                                                                                                                          –1
                                                                                                                          Под монополией имелось ввиду, что кроме JavaScript выбора то больше и нету…
                                                                                                                            +1
                                                                                                                            Java и Flash в браузере никто не отменял.
                                                                                                                              +1
                                                                                                                              Safari в iOS и IE10 Metro отменял.
                                                                                                                  0
                                                                                                                  JavaScript уже претендует на серверную часть в виде Node.js. Единый язык для клиента и сервера. К чему тут Дарт?
                                                                                                                    +1
                                                                                                                    JS давно уже на серверной части. ASP можно вспомнить, хотя бы.
                                                                                                                  +1
                                                                                                                  Я был на TechTalk по DART в офисе гугла. Так вот объяснили все весьма наглядно. Так, например, на том же дарте можно написать фронтенд на сервере и клиентский код на дарте, так что получится полноценное веб приложение, написанное на одном языке и взаимодействующее с БД и т.п. с серверной стороны. Предлагаете использовать NodeJS? Я бы не стал.
                                                                                                                    0
                                                                                                                    Почему не стали бы?
                                                                                                                      +3
                                                                                                                      лапша из callbackов например
                                                                                                                        0
                                                                                                                        Уже придуманы десятки вариантов обхода этой проблемы.
                                                                                                                        Начиная от promise и закачивания синхронными вариантами вызовов( и никаких проблем ваааще, все по старинке )
                                                                                                                          0
                                                                                                                          Уже придуманы десятки вариантов обхода этой проблемы.>> Если их десять и вы о них упомянули значит серебрянной пули тут не существует и все подходы имеют недостатки. Синхронный вызов таким уж точно не является. Дальше большой проект подразумевает множество библиотек. Где такие для нода? node.js это собрать тестовый сервачок для js dev. Исключения больше напоминают фанатизм.
                                                                                                                            +2
                                                                                                                            > Дальше большой проект подразумевает множество библиотек. Где такие для нода?

                                                                                                                            Это сарказм, что ли? Ну вот, множество библиотек: github.com/joyent/node/wiki/modules
                                                                                                                              0
                                                                                                                              это вы называете множеством, выкидываем половину библиотек которые реализуют всякие костыли для более менее нормально ооп, mvc и т.п. и остаётся кот наплакал. Я как-то игрался с этим node.js захотелось мне из оракла выборку сделать. Да так что бы по человечски с мапингом, лейзи лоадингом и т.п. Погуглил. нет такой возможности. И таких пробелов там миллионы. Вы действительно счтитаете что на node.js сейчас можно написать высокпроизводительный бекенд, с использованием кучи разных библиотек для агрегации данных откуда угодно. И самое главное БЫСТРО и качественно?
                                                                                                                                0
                                                                                                                                и да забыл добавить версия оракла 9.
                                                                                                                                  +1
                                                                                                                                  А тут, пока что, все по честному.
                                                                                                                                  Нужно нормальный конектор к БД — пинай оракл, если не получиться — пиши сам.
                                                                                                                                  Нода, и язык на котором она написанна тот тут причом?
                                                                                                                                    0
                                                                                                                                    вот так себе и представил начинается проект, кастомер говорит у меня база данных, а ты ему говоришь так нужно в естимацию заложить попинать оракл или если нет давайте напишем ка сами свой костыль потом пол года будем в нём вылавливать баги, пару раз испортим данные и т.п. Вы в каком мире живете?
                                                                                                                                      +4
                                                                                                                                      А что, для Дарта есть оракловый модуль? Нет.
                                                                                                                                      Что, гуглу написать оракловый модуль к дарту проще, чем к Node.js? Ни разу.

                                                                                                                                      Где здесь проблема _языка_?
                                                                                                                                        +2
                                                                                                                                        я в реальном живу, с реальными проектами и технологиями. В итоге меньший перфоманс меньше возможностей для масштабирования и распаралеливания и слабая или никакая поддержка даже мейнстримовых задач. Перемножайте это на черти какое ООП. Гугл это и пытается решить. Переписать с джавы или шарпа тот же драйвер будет не сложнее чем забекпортить с джавы 7 на какую-то 1.4, чего не скажешь о node.js
                                                                                                                                          –3
                                                                                                                                          Вы просто не умеете его готовить.
                                                                                                                                            +1
                                                                                                                                            я вам привёл кокретные примеры. Если json из какого-то key-value хранилища отдать. То пишется это на коленке, и я в том числе его пользовал на некоторых POC для себя. Чем дальше тем граблей больше. Всему свое место.
                                                                                                                                              –1
                                                                                                                                              Нельзя ли конкретизировать конкретный пример?
                                                                                                                                              0
                                                                                                                                              что более конкретного конекторы к разным версиям баз данных в т.ч. не сильно мейнстримовые версии какое нибудь легаси и т.п. Отсутсвие нормального дебага и т.п. blocking IO only etc… etc…
                                                                                                                                                –1
                                                                                                                                                Простите, это какой-то поток сознания.
                                                                                                                                            –2
                                                                                                                                            Какой еще оракловый модуль к дарту, если дарт работает в браузере, а оракл на сервере?
                                                                                                                                              +3
                                                                                                                                              Я думаю, Вам стоило минимально разобраться в обсуждаемой теме, прежде чем оставлять такие комментарии.
                                                                                                                                                –2
                                                                                                                                                Я так понимаю, я имею дело с экспертом по языку дарт, который реализовал уже не один десяток проектов на нем, да?
                                                                                                                                                  +1
                                                                                                                                                  Сарказм?
                                                                                                                                                    +2
                                                                                                                                                    Думается что вы имеете дело с человеком который знает что Dart можно запустить на серверной стороне по специальной VM.
                                                                                                                                                      –1
                                                                                                                                                      Ну и как успехи в запуске?
                                                                                                                                                        0
                                                                                                                                                        Первое сообщенеи ветки вы так и не смогли прочитать?
                                                                                                                                                          +1
                                                                                                                                                          На текущий момент дарт парсером питона перегоняется в джаваскрипт. Для клиента. Для сервера ничего в открытом виде вообще не представлено.
                                                                                                                                                          Поэтому рассуждать вообще ни о чем. Если будет джава-машина, там поддержка любой БД есть, если парсер на питоне, аналогично.
                                                                                                                                                          Выпускать язык совсем в чистом виде… ну Go уже выпустили. Быстро, красиво, с нулевой поддержкой.

                                                                                                                                                          Полагаю, до начала холиваров надо хотя бы рабочий вид всего что будет представлять.
                                                                                                                                        0
                                                                                                                                        да можно. мы, например, написали и используем в продакшине уже год в мишин критиках приложении
                                                                                                                                          +4
                                                                                                                                          Не-не-не. Вы ушли в частности. Проблемы node.js просты:
                                                                                                                                          1. Stop the world GC. Я с трудом себе представляю чтобы зависание всего приложения для работы сборщика мусора в HighLoad'e было нормой.
                                                                                                                                          2. Слишком легко выстрелить самому себе в ногу. Легко наделать лапши из callback'ов. Очень легко сожрать кучу памяти и при этом не понимать где именно происходят утечки.
                                                                                                                                          3. Молодость платформы. Нестабильность. Слабость библиотек.
                                                                                                                                          3.1. Отсутствие адекватной работы с кодировками. Также и с бинарными данными.

                                                                                                                                          И, все же, да, отсутствие статической типизации плюсом тоже являться не может.
                                                                                                                                            +2
                                                                                                                                            спасибо, вы структурировали все что я пытался сказать, ну кроме GC )
                                                                                                                                              0
                                                                                                                                              > 1. Stop the world GC. Я с трудом себе представляю чтобы зависание всего приложения для работы сборщика мусора в HighLoad'e было нормой.

                                                                                                                                              Это проблема в первую очередь V8, и починить её по факту не хочет именно Гугл. Странно, не находите?

                                                                                                                                              > 2. Слишком легко выстрелить самому себе в ногу. Легко наделать лапши из callback'ов. Очень легко сожрать кучу памяти и при этом не понимать где именно происходят утечки.

                                                                                                                                              Легче, чем в Python/Ruby/...? Пример в студию. Особенно про «сожрать кучу памяти».

                                                                                                                                              > 3. Молодость платформы. Нестабильность. Слабость библиотек.

                                                                                                                                              Ну, у Дарта здесь никакого преимущества нет.

                                                                                                                                              > 3.1. Отсутствие адекватной работы с кодировками.

                                                                                                                                              Проблемы с кодировками? В моём джаваскрипте??? Пруфпик или не было.
                                                                                                                                                0
                                                                                                                                                Про сборщик мусора. Не важно чья это проблема. Важно что она есть.

                                                                                                                                                Про лапшу callback'ов, надеюсь, спорить не будете?

                                                                                                                                                Я расскажу небольшую историю.

                                                                                                                                                Писал я на node.js небольшой картографический сервис и граббер сторонних сайтов был одной из частей. Сам сервис работал неплохо и тут претензий нет. Правда вот явная надобность где-нибудь искать process watcher перед выкатыванием в production напрягала, но, к счастью, до этого не дошло.

                                                                                                                                                Веселье началось при написании граббера. Знаете, я много грабберов написал. Причем на разных языках. Но чтобы так(!!!) выжирать оперативу и при этом не чистить ее сборщиком мусора — это жесть! У меня на vps память заканчивалась просто! Ладно, эту проблему я решил сохранением очереди url'ов и запуск граббера в несколько этапов.

                                                                                                                                                Но тут появилась другая проблема. Из сокета данные читаются блоками. Логично. Стандартно. Так вот, собрать одну строку в том случае, если один байт UTF-8 символа попал в один блок прочтенных данных, а второй байт — в другой, я не смог. Я долго возился, поверьте. Все. После полудня возни я переписал за пару дней вообще весь проект на Java и ни разу не жалею.

                                                                                                                                                Так вот. Про работу с кодировками. Я языке программирования должны четко разделятся текстовые данные и бинарные. А стандартная библиотека везде предполагать, что кодировка текста на входе может быть любой. В том же PHP ничего этого нет. Итогом стало расширение mbstring, с которым проблем хватает (надо примеры приводить или на слово поверите?). В node.js была сделана попытка. Но она оказалась провальной. Я уж молчу про то, что «кодировка» binary — deprecated.

                                                                                                                                                Зрелая и серьезная платформа должна сильно ограничивать программиста, чтобы его код был относительно легко поддерживаемым. В этом плане node.js для серьезной разработки, особенно в команде, не подходит.

                                                                                                                                                Адское же потребление памяти у JS, фактически, — by design. Ибо надо постоянно кучу областей видимости в памяти держать.

                                                                                                                                                 

                                                                                                                                                Мне давно нравилась идея запихнуть JS на сервер. Но, к сожалению, вынужден признать, что для серьезных проектов это вряд ли сработает. Слишком рискованно. Рискованно как в плане времени на поддержку кода, так и в плане отладки.
                                                                                                                                                  –1
                                                                                                                                                  > Ладно, эту проблему я решил сохранением очереди url'ов и запуск граббера в несколько этапов.

                                                                                                                                                  Не понял. Вы запускали выкачивание мильона урлов одновременно и удивляетесь, что выжиралась память? Сюрприз!
                                                                                                                                                  И что, на каком-то другом языке не было этой проблемы?

                                                                                                                                                  > Стандартно. Так вот, собрать одну строку в том случае, если один байт UTF-8 символа попал в один блок прочтенных данных, а второй байт — в другой, я не смог.

                                                                                                                                                  У меня вот такой код собирает utf-ные строки:
                                                                                                                                                  function(res){
                                                                                                                                                      res.setEncoding('utf-8');
                                                                                                                                                  
                                                                                                                                                      var data = '';
                                                                                                                                                      res.on('data', function (chunk) {
                                                                                                                                                          data += chunk;
                                                                                                                                                      });
                                                                                                                                                  
                                                                                                                                                      res.on('end', function() { /* Обработка ответа /* }
                                                                                                                                                  }


                                                                                                                                                  Ни единой проблемы ни разу не было.
                                                                                                                                                  А уж работа с кодировками в тех же PHP, Python, Ruby — это вообще какой-то цирк с конями, JS в этом плане монолитен и стабилен.
                                                                                                                                                  Для бинарных данных в Node.js существует Buffer — чем он Вас не устроил?

                                                                                                                                                  > Адское же потребление памяти у JS, фактически, — by design. Ибо надо постоянно кучу областей видимости в памяти держать.

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

                                                                                                                                                    Урлов там 200-400. Граббер на Java за 30 МБ не вылезает. Причем там и встроенный JS, и XML+XPath. В node.js же на каждую пропарсенную страницу потребление памяти увеличивалось. Я не знаю почему. Важно другое — node.js позволил мне или автору одной из используемых библиотек выстрелить в ногу. А вот Java не позволила.

                                                                                                                                                    А вот у меня такой подход для сбора строки не сработал. Почему? Я не знаю. И разбираться не хочу. Точнее, полдня на разборки я уже потратил и больше не намерен. К счастью, я знаю далеко не один язык.

                                                                                                                                                    Вы вообще читаете что я пишу? Или это такой тонкий троллинг? Покажите мне многие скриптовые языки, где надо сохранять области видимости. И ничего что в документации черным по белому написано про «кодировку» binary в Buffer'ах: «This encoding method is deprecated and should be avoided in favor of Buffer objects where possible. This encoding will be removed in future versions of Node.»? А если открыть исходники node, то можно увидеть что там много где эти буферы используется…

                                                                                                                                                     

                                                                                                                                                    Платформа для серьезной разработки ценна не своими плюсами. Она ценна меньшим кол-вом минусов и неожиданностей. В JS их немерено. Опять же, к сожалению, т.к. сам JS мне нравится.

                                                                                                                                                     

                                                                                                                                                    У меня ощущение, что я не просто пытаюсь что-то объяснить фанатику, но этот фанатик даже в своей-то платформе разбирается плохо. Хотелось бы ошибаться, но…
                                                                                                                                                      +2
                                                                                                                                                      > Не надо меня держать за идиота, ок?

                                                                                                                                                      Да я Вас ни за что не держу. Вы излагаете какой-то hate speech в адрес Node.js — ок, не используйте его. Мне вот java не нравится, и, я уверен, при желании вполне могу найти миллион способов выстрелить себе в ногу и в ней. Но я же не предлагаю её выкинуть.
                                                                                                                                                0
                                                                                                                                                > Stop the world GC.

                                                                                                                                                было бы интересно посмотреть на приложения на node.js, которые страдают от GC. я пытаюсь долгое время добится внятных примеров, из которых бы можно выделить бенчмарки.

                                                                                                                                                тут важно помнить, что a) подавляющее большинство реализаций различных языков имеют в своем составе stop the world коллекторы. b) throughput у stop the world коллектора больше, а overhead для мутатора меньше.

                                                                                                                                                исключения слабораспостранены, тут и azulовский pauseless gc, который только недавно перенесли на обычный хардвер (до этого он крутился на специализированной архитектуре Vega), и G1 (aka Garbage First), который до сих пор считается экспериментальным, тут и старый CMS (aka mostly concurrent garbage collector), который все равно требует остановки всех потоков для завершения цикла сборки мусора (показательная вещь: confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues там открытым текстом говорят «пожалуйста не используйте CMS, если не хотите проблем с производительностью. требуется очень тщательная настройка.»).
                                                                                                                                                  0
                                                                                                                                                  Azul ни разу не pauseless. Я не понимаю, с какого перепоя они считают свои паузы на 30мкс pauseless, это, вообще говоря, дофига (хотя, возможно, по сравнению с обычной JVM это и мало), кроме тупого маркетинга.
                                                                                                                                                +2
                                                                                                                                                Что вы называете нормальным ООП и как вы это понимаете. А также какие вариации есть ООП.
                                                                                                                                                Дальше mvc. Я уже писал про это. Вы и с DART не сможете нормально реализовать MVC (скорее HMVC получится костыльный). Если в языке подразумевается асинхронность — MVC не реализуем.
                                                                                                                                                Вы бы еще erlang назвали бы недоязыком.
                                                                                                                                                В третьих — node.js еще не в конечной стадии. И если вы его юзаете в продакшене — то это на ваш страх и риск. Это еще очень молодой проект, а уже наезжают на него.

                                                                                                                                                В четвертых. Если у вас используется две БД (Mongo и допустим MySQL), то как вы будете реализовывать хранение кеша приложения(!) с данными БД(надеюсь правильно поймете). Будете очередность запросов делать? Но это две БД, и второй незачем ждать ответа от первой.

                                                                                                                                                В пятых — допустим на сайте, есть форма обратной связи. Вы данные проверяете на сервере и на клиенте. Это нормально. Да вот только вы пишете наверное две проверки на разных языках. В данном случае — я это напишу на одном языке. (при должной структуре и построении приложения — я пишу один интерфейс на сервере, и тот же код, если он серверо-независим, проверит и на клиенте).

                                                                                                                                                Я считаю что на данном этапе развития, на node.js нежелательно писать высокопроизводительное и стабильное приложение. Это и разработчики пока не рекомендуют, т.к. версии 1.0 еще нет! Они работают еще и довольно таки оперативно — не надо их поливать грязью.

                                                                                                                                                Мне нравится возможность исполнять код в созданной песочнице(что позволяет юзать безопасные макрокоманды, которые пишутся на том же JS). Нравится возможность компиляции JS кода возможностями V8. Нравится то — как легко писать модули для него на С (причем там реально очень просто). Если мне по нуждам нужно именно классическое ООП и оптимально для моих задач подходит, я беру PHP|Python|C++ и юзаю их. Если мне node.js подходит — я юзаю node.js.

                                                                                                                                                Поймите правильно — классическое ООП, не подходит при асинхронном подходе к решению задач. Слишком много нарушений постулатов будет.

                                                                                                                                                Кстати, в том же Вконтакте. Они юзают PHP как серверное приложение, НО, для чата юзают ноду. Почему? Просто этот инструмент отлично подошел для решения конкретной задачи.
                                                                                                                                                Ну и еще. Вы с сокетами работали? тогда знаете, как высодно когда код блокирует дальнейшее исполнение, пока не получит необходимые данные с сокетов. Асинхронный стиль отлично подходит для этого.

                                                                                                                                                Респект за то — что хотя бы попробовали и привели пример =)
                                                                                                                                                  0
                                                                                                                                                  Что такое нормальное ООП, мнений очень много, холиварных. Но js наверно лидирует по количеству попыток причесать этот язык куда бы то ни было. С этим думаю никто спорить не будет.
                                                                                                                                                  И по поводу node.js а почему вы считаете что авторы к примеру не захотят перейти на DART? написан он на с как я понимаю. js роль там… извините. Свичнуться будет не сложно.
                                                                                                                                                    0
                                                                                                                                                    Ну просто механизмы разные. node.js придерживается негласного стандарта commonJS, поэтому они и дальше будут развивать свой труд.
                                                                                                                                                    Dart это Dart — это еще один ЯП. Я не вижу в нем замены JS. Слишком разные в этих языках подходы к решению задач.
                                                                                                                                                    Лично мне просто не нравится то, что его позиционируют как замену. Чувствуется какой-то именно маркетинговый ход если честно….
                                                                                                                                                    Как я уже выше писал — в Java можно юзать JavaScript(Rhino), в QT — QScript. И я просто физически не могу представить Dart в этих местах, что уже показывает — что JS, со своей парадигмой, незаменим. Да и зная основной уровень разработчиков, использующих Java или QT — могу сказать, что они знают — где и что им удобнее использовать.

                                                                                                                                                    Я когда делаю ремонт — я использую не один инструмент, а набор. И для решения нужной задачи, я беру подходящий инструмент. Я не забиваю отверткой гвозди — это можно но не удобно. я забиваю молотком. Но шурупы я завинчиваю отверткой — молотком — это изврат. И только умелое комбинирование этих инструментов позволяет мне приемлемого результата.

                                                                                                                                                    Я прошу прощения — если не понятно написал. Довольно таки сумбурно — но надеюсь поймете правильно мой ход мыслей =)
                                                                                                                                                      +1
                                                                                                                                                      если он будет во всех браузерах, будет заменой так или иначе. Исторически так получилось, что ecma script очутился на клиенте. Я за конкуренцию. Никуда js не денется ещё лет пять так точно. Но если в бразуер протолкнут нечно другое, я за. Что в этом плохого?
                                                                                                                                                        +3
                                                                                                                                                        я просто про visual basic вспоминаю. Тоже два языка. Впихнули его куда только можно. Сейчас тенденция же выпиливания его пошла.
                                                                                                                                                        Пусть лучше развивают то, что есть. И так с трудом, немного утихомирились (тыкаю пальцем в microsoft).

                                                                                                                                                        Силверлайты(DotNet), JavaFXы(Java), Flash(AS), HTML5(JS), SVG vs VML, JS vs Dart vs VBScript, h.263 vs Theora, mp3 vs vorbis. Причем мало того что конкурируют, так еще все это до сих пор в ущербном состоянии, причем у каждого браузера, по своему ущербно.
                                                                                                                                                        Надоели они уже с этой чертовой войной. Лучше бы допилили до серьезного состояния, что-то одно, а то практически за двадцать лет, банальный HTML4, и тот работает не везде как надо. Банальные локальные хранилища — и те разные! Зоопарк.

                                                                                                                                                        Лет через 5 опять будем писать сайты наверное так:
                                                                                                                                                        Chrome: Dart + canvas;
                                                                                                                                                        IE: VB + силверлайт;
                                                                                                                                                        FF: JS + XUL + JavaFX;
                                                                                                                                                        MobilePlatforms: JS + HTML5;
                                                                                                                                                        Ну и Флеш выскакивать еще где-нить будет

                                                                                                                                                        Костыле развитие сопровождаться будет. Сейчас хоть немного, но тенденция идет к развитию линейки JS + HTML5 + CSS3(2d|3d|transform|animate|transition т.д.);
                                                                                                                                                        Итак все шатко держится. Пусть хоть в одном стандартизируются. Нам же — разработчикам, потом этот зоопарк развивать(немного аналогия с «Собор и Базар»).
                                                                                                                                                      0
                                                                                                                                                      На JS там написано много чего: github.com/joyent/node/graphs/languages
                                                                                                                                                      Вы не поверите, но даже в V8 часть стандартной библиотеки JS реализовано на JS, а не на C++.
                                                                                                                                                      0
                                                                                                                                                      ИМХО, для чата ВКонтакте лучше всего подошел бы Erlang с уже готовым и более чем известным ejabberd. Ну или без ejabberd, какая разница. Почему они предпочли ноду — лично для меня загадка. Единственный мой вариант — ниасилили/побоялись. Хотя чего тут бояться — непонятно. Что тут ниасилить — тем более.

                                                                                                                                                      Для задач такого уровня из существующих языков хорошо подходит только Erlang. На всех остальных разработка раньше или позже превратится в бег по граблям.
                                                                                                                                                  +3
                                                                                                                                                  Мы потому тут и общаемся что у разных людей разные вкусы.
                                                                                                                                                  Поэтому и есть 10+ различных решений «проблемы node.js» — каждый предлагает свое решение.
                                                                                                                                                  Можно подумать что в других языках нет таких случаев( сколько на свете существует шаблонизаторов, баз данных и 3д движков. Зачем? Неужели нет серебряной пули? )
                                                                                                                                                  И совсем не понятно что вы подразумеваете под множеством библиотек.
                                                                                                                                                  Для ноды их уже много, и ничего не мешает их количество увеличивать.
                                                                                                                                                +1
                                                                                                                                                используйте евенты.
                                                                                                                                                +2
                                                                                                                                                вы погуглите про управление потоками в node.js про сравнение performance. node.js увы это детский сад.
                                                                                                                                                  +1
                                                                                                                                                  Нельзя ли конкретную ссылочку?
                                                                                                                                                    0
                                                                                                                                                    гугл наберите node.js vs java или vs python или vs с#. Почти везде раза в два меньше. Кроме того проблемы с памятью кроме того только none blocking only. Это ли все не показатели проекта на коленке или для стартапов, когда важно побыстрее POC а потом уже и переписать на чем. Порог вхождения низкий. Но чем дальше в лес тем больше дров.
                                                                                                                                                      +1
                                                                                                                                                      Нельзя ли конкретную ссылочку?
                                                                                                                                                          0
                                                                                                                                                          и таких ссылок миллионы буквально первые из списка. То что я видел как в пользу нода это сравнение с апачем, который ну мягко говоря слабый конкурент в связи с явными архитектурными изьянами.
                                                                                                                                                            –1
                                                                                                                                                            Миллионы? Вы, мягко говоря, выдаёте желаемое за действительное.

                                                                                                                                                            Если посмотреть хотя бы первую страницу выдачи, то можно увидеть, что цифры сильно меняются в зависимости _от конкретной задачи_ и от прямоты рук разработчика. См., например, blog.mixu.net/2011/01/17/performance-benchmarking-the-node-js-backend-of-our-48h-product-wehearvoices-net/
                                                                                                                                                            groups.google.com/group/faye-users/browse_thread/thread/41735035d9880a22?pli=1

                                                                                                                                                            Любой инструмент хорош на своём месте.
                                                                                                                                                              –2
                                                                                                                                                              ну сравнил django!=python. Или вы не видите разницы??? уж извините вторая ссылка на раби… ну приехали. Любой школьник знает что на раби хорошо писать но плохо с перфомансом. Для этих целей всякие страждущие пишут всякие jruby.
                                                                                                                                                                0
                                                                                                                                                                Мне кажется, если Вы начнёте излагать свои мысли яснее, дискуссия сильно выиграет.