JVM какой версии держать будем? Обновлять как будем? Сэндбоксом для JVM кто будет управлять? RPC как построить так, чтобы можно было получить ограничение по доменам? На стороне клиента нужен какой-то стандарт для хранения данных? Окей, будем считать с десктопом вопрос зарешаем. Тут ходовых платформ всё же всего полторы — x86 + unix/windows.
Теперь дело за малым, перенести эту референсную реализацию на ARM да под android, windows phone, ios… tizen, remix, sailfish, symbian, webOS и заставить на телевизорах работать.
Это я всё к чему? Если сделать замену вот такую: JVM -> V8, WebGL -> WebGL, API мышки/клавиатуры -> MouseEvents, RPC -> Ajax/XHR то получится, внезапно, то что сейчас есть, только оно более-менее работает почти на всех платформах старше IE9.
И ответ на это тоже один — аналогичный функционал для одной платформы на нативных компонентах требует больше времени разработки. Нативные приложения — это здорово. Но между нативное послезавтра и webkit сегодня, ответ, за редким исключением, очевиден.
MacBook 12" бывает с 1.4 GHz Core i7 и 16 Gb
В штатах стоит $2k.
Проблема с Ethernet решается переходником, а лучше док-станцией. Тогда его и заряжать одновременно можно.
Привет. Я правильно понимаю, что это всё же параллелизм на уровне процессов, и по-прежнему в кластере из четырех акторов можно добиться не более 4-х реально одновременно выполняющихся CPU-bound задач?
П.С. а почему таки не подпилили под интерфейс web workers?
Если не углубляться совсем в дебри, то на основе статистики поведения метода в runtime, виртуальная машина может его не только скомпилировать в машинный код, но и например, выкинуть какие-нибудь проверки аргументов, ветки условий, итд.
Более того, эти оптимизации занимают некоторое время, и требуют определенного способа использования приложения. Поэтому иногда для того, чтобы свежезапущенное приложение было молодцом с самого начала, в него профиль оптимизации можно загрузить. Вот так никогда не делал, но на хабре где-то не так давно была статья по этому поводу.
Не кидайте помидорами, но мне кажется, что сегодняшний JavaScript ближе к Java чем когда бы то ни было. Смотрите сами:
Кроссплатформенность. Java на кофеварке сегодня запустить не так уж и прямо (профили, вот это всё), но браузер там скорее всего есть. И с помощью нескучного тюнинга бабеля, думаю можно под этот браузер писать со всеми радостями ES7+.
Write Once Run Everywhere. Опять же за счёт бабеля (по желанию можно взять что-то другое) веб-приложение может быть собрано в какой-нибудь ES3 и запуститься на старых платформах.
Язык/Платформа. Сам по себе язык довольно простой с несколькими неочевидными нюансами, которые спустя пару недель проклятий становятся уже не настолько неочевидными. Платформа, конечно, так себе — реализации отличаются, стандартная библиотека очень маленькая, но тем не менее.
М? Чем не каноничная Java? Осталось портировать Spring, чтобы было для чего конфиги иксэмэльные писать, и готово :)
А в чем проблема? Eсли речь идет не о 8гб таблиц, то до определенного предела фронтенд вполне себе в состоянии из json получить xml.
Разумеется, если киллер-фича приложения это генерирование xlsx на любой кофеварке с браузером, то нужно крепко подумать, желательно дважды. Но если речь идёт о данных, которые уже есть в вебе и их не десятки мегабайт, то в чем проблема? Современные движки JS достаточно быстрые для этого.
Постойте, я и не говорю, что нода хороша для CPU-bound операций. Больших фишек у ноды ровно две:
асинхронный io с приятным интерфейсом для простых смертных (нет, последователи Карри, для этого не нужна специальная монада, и да, парни из мира Стандартных Изданий, для этого не нужно упражняться с тредпуллами), который внезапно показывает весьма приятную производительности без лишнего тюнинга.
javascript. Который, внезапно, не смотря на все фу-фу-фу, доступен практически любому разработчику на Java, C, C++, C#, Pascal, PHP итд. А если немного подтянуть матчать и разобраться в том как работает this и прототипное наследование (которое, вообще говоря надмножество Java-like OOP), то внезапно оказывается, что это вполне пристойный инструмент. А если копнуть еще чуть глубже, то внезапно оказывается, что JS можно декорировать типами (flow), проверять линтерами, собирать под платформы разной степени древности (babel) и использовать фичи из черновиков грядущих стандартов прямо вот сейчас (опять, привет babel). Чем, не смотря на некоторую костыльность и соберисамность, может похвастаться далеко не каждый ЯП.
Теперь про CPU-bound и тот-самый excel. Я конечно в офисных xml делах не очень рублю, но что-то мне подсказывает, что если мы собираемся массово генерировать excel- файлики, то я бы предпочёл это действо передавать системе и вызывать отдельным процессом. Потому что наверняка есть хорошая сторонняя/системная тулза, которую не стоит пытаться запихнуть ни в ноду, ни в похапэ, ни в питон.
Это не значит, что надо писать на ноде всё и вся. Но для типовых веб-серверных задач нода — прекрасный, доступный и достаточно мощный инструмент.
Мы в каких-то видимо сильно разных мирах живём, но как мне видится пласт задач вида "сходи в базу, принеси A, потом прими решение на его основе и принеси Б" — довольно широкий и охватывает если не весь веб, то довольно серьезную его часть.
Разумеется, есть еще уйма CPU-bound задач, которые на ноду ложатся мягко говоря не очень. Но это ведь не делает ноду плохим инструментом, для решения io-bound задач.
Ну и многопоточность тоже момент очень хитрый. Безусловно многопоточность в природе нужна. Но в ряде случаев от этого можно отказаться, и поиметь определенный профит от этого — выше уже был пример с nginx.
У латеха есть еще одна проблема, сформулировать её можно так: если у вас есть проблема и вы решили использовать латех, у вас уже две проблемы.
Латех сам по себе весьма неплох, и позволяет сделать с документом практически всё, что угодно, но сам по себе достаточно сложен, и с автоматизацией тоже не всё так гладко, хотя и решаемо.
У меня немного другой опыт (но на скале я уже два года активно не пишу, до этого писал активно о). Если использовать скалу, как Better Java, то ничего хорошего из этого не получается. А если активно писать в около-функциональном стиле, то выясняется две интересных подробности:
для этого надо знать слишком много о том, как работает JVM и во что превращается scala-код
стоит только сделать небольшой шаг дальше композиции функций, как тут же возникает огромное количество вопросов, на которые в "продвинутом" скала-сообществе принято отвечать примерами на хаскеле.
Это далеко не всегда так.
Отдать страничку с данными и правда не сильно сложно, гораздо сложнее отдать часть приложения с данными. Потому что вдруг выясняется, что у фронтенда есть:
внутреннее состояние (любимый цвет кнопок, текст не до конца набранного комментария, настройки какого-нибудь фильтра и еще уйма интересных штук, которые разумеется более чем реализуемы в парадигме "отдать страничку, а при переходе по ссылке отдать следующую страничку", но по какой-то причине очень часто приводят к "я тут накидал на jquery, пожалуйста не трогай это никогда")
архитектура. Потому что на чистом HTML, CSS и JS можно реализовать всё что угодно, но на Angular (фанатам фейсбука читать как "React") оно почему-то выходит более поддерживаемым и работоспособным.
как ни странно, команда, которая обычно этим самым фронтендом занимаются фуллтайм, и обычно, при SPA подходе decoupling (как это по-русски правильно?) получается значительно выше.
JVM какой версии держать будем? Обновлять как будем? Сэндбоксом для JVM кто будет управлять? RPC как построить так, чтобы можно было получить ограничение по доменам? На стороне клиента нужен какой-то стандарт для хранения данных? Окей, будем считать с десктопом вопрос зарешаем. Тут ходовых платформ всё же всего полторы — x86 + unix/windows.
Теперь дело за малым, перенести эту референсную реализацию на ARM да под android, windows phone, ios… tizen, remix, sailfish, symbian, webOS и заставить на телевизорах работать.
Это я всё к чему? Если сделать замену вот такую: JVM -> V8, WebGL -> WebGL, API мышки/клавиатуры -> MouseEvents, RPC -> Ajax/XHR то получится, внезапно, то что сейчас есть, только оно более-менее работает почти на всех платформах старше IE9.
И ответ на это тоже один — аналогичный функционал для одной платформы на нативных компонентах требует больше времени разработки. Нативные приложения — это здорово. Но между нативное послезавтра и webkit сегодня, ответ, за редким исключением, очевиден.
В штатах стоит $2k.
Проблема с Ethernet решается переходником, а лучше док-станцией. Тогда его и заряжать одновременно можно.
А чем не устраивает, допустим, Google Music? В него можно загрузить 10 000 своих треков.
Привет. Я правильно понимаю, что это всё же параллелизм на уровне процессов, и по-прежнему в кластере из четырех акторов можно добиться не более 4-х реально одновременно выполняющихся CPU-bound задач?
П.С. а почему таки не подпилили под интерфейс web workers?
Так message-based IPC в event-driven языке с managed memory и async/await искоробки, это так же просто и прямо как котят гладить.
В рантайме можно спекулятивные оптимизации на основе статистики использования, которые нельзя в compile time.
Вот тут есть довольно общий список: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
А вот тут пара слов про Profile: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
Если не углубляться совсем в дебри, то на основе статистики поведения метода в runtime, виртуальная машина может его не только скомпилировать в машинный код, но и например, выкинуть какие-нибудь проверки аргументов, ветки условий, итд.
Более того, эти оптимизации занимают некоторое время, и требуют определенного способа использования приложения. Поэтому иногда для того, чтобы свежезапущенное приложение было молодцом с самого начала, в него профиль оптимизации можно загрузить. Вот так никогда не делал, но на хабре где-то не так давно была статья по этому поводу.
Про джавовый HotSpot и другие интересные вещи, которые возможны только в рантайме, уже можно рассказывать?
Не кидайте помидорами, но мне кажется, что сегодняшний JavaScript ближе к Java чем когда бы то ни было. Смотрите сами:
М? Чем не каноничная Java? Осталось портировать Spring, чтобы было для чего конфиги иксэмэльные писать, и готово :)
А в чем проблема? Eсли речь идет не о 8гб таблиц, то до определенного предела фронтенд вполне себе в состоянии из json получить xml.
Разумеется, если киллер-фича приложения это генерирование xlsx на любой кофеварке с браузером, то нужно крепко подумать, желательно дважды. Но если речь идёт о данных, которые уже есть в вебе и их не десятки мегабайт, то в чем проблема? Современные движки JS достаточно быстрые для этого.
В файл её и отдать через sendFile
Постойте, я и не говорю, что нода хороша для CPU-bound операций. Больших фишек у ноды ровно две:
Теперь про CPU-bound и тот-самый excel. Я конечно в офисных xml делах не очень рублю, но что-то мне подсказывает, что если мы собираемся массово генерировать excel- файлики, то я бы предпочёл это действо передавать системе и вызывать отдельным процессом. Потому что наверняка есть хорошая сторонняя/системная тулза, которую не стоит пытаться запихнуть ни в ноду, ни в похапэ, ни в питон.
Это не значит, что надо писать на ноде всё и вся. Но для типовых веб-серверных задач нода — прекрасный, доступный и достаточно мощный инструмент.
Мы в каких-то видимо сильно разных мирах живём, но как мне видится пласт задач вида "сходи в базу, принеси A, потом прими решение на его основе и принеси Б" — довольно широкий и охватывает если не весь веб, то довольно серьезную его часть.
Разумеется, есть еще уйма CPU-bound задач, которые на ноду ложатся мягко говоря не очень. Но это ведь не делает ноду плохим инструментом, для решения io-bound задач.
Ну и многопоточность тоже момент очень хитрый. Безусловно многопоточность в природе нужна. Но в ряде случаев от этого можно отказаться, и поиметь определенный профит от этого — выше уже был пример с nginx.
У латеха есть еще одна проблема, сформулировать её можно так: если у вас есть проблема и вы решили использовать латех, у вас уже две проблемы.
Латех сам по себе весьма неплох, и позволяет сделать с документом практически всё, что угодно, но сам по себе достаточно сложен, и с автоматизацией тоже не всё так гладко, хотя и решаемо.
А на чём всё это написано, и не седеют ли программисты от такого количества асинхронной условной логики?
У меня немного другой опыт (но на скале я уже два года активно не пишу, до этого писал активно о). Если использовать скалу, как Better Java, то ничего хорошего из этого не получается. А если активно писать в около-функциональном стиле, то выясняется две интересных подробности:
Часть 0. Изучить Haskell, чтобы понимать функциональную магию Shapeless, Scalaz, Iteratee итд.
Это далеко не всегда так.
Отдать страничку с данными и правда не сильно сложно, гораздо сложнее отдать часть приложения с данными. Потому что вдруг выясняется, что у фронтенда есть: