Само собой — оно только внешне похоже. И все же сокращение только за счет фигурных скобок мне не нравится — раньше свойства и методы визуально легко разделялись. Теперь же это усложнилось, вдобавок будут короткие методы. которые в одну строку, и есть длинные со скобками. В style guide'ах добавятся пункты, чтобы в ревью не возникали священные войны. В общем, пространства для вкусовщины теперь больше.
Представляю себе количество разностильного кода — кто вручную, кто с сахаром, кто перемешивает. В целом сахар неплохой, но вот делать для ctor/dtor лямбды никакого смысла не вижу — экономия копеечная.
Это слишком дорого — как раз на днях искал дочке моноблок. Долго искал, везде рылся, но нашел и купил практически аналог — Lenovo Ideacentre 300-22ISU, Так вот, обошлось в 54000. Более того, именно этого ASUS Zen AiO ZN220IC просто нигде нет. Выше LisinA дал ссылку, и цена там сравнима, но это i3 (хотя и GeForce).
Шутка не очень. Знаете, есть такая табличка «Занял мое место — забери и мои болезни» на автоместах для инвалидов. Все эти синдромы не совсем болезни, но определенные и весьма заметные трудности в жизни создают.
А откуда в ASF «на одной машине 2-3 сило»? Насколько я понимаю, там на каждом узле крутятся инстансы stateless и реплики stateful (поскольку акторы в AFS это специальная разновидность stateful), причем ASF старается primary реплики раскидывать по разным узлам. Они, конечно, могут и сойтись на одном узле, но это все-таки не «монолитное» silo Orleans, внутренняя организация скорее всего другая.
Вот мы в Cloud Service и хостим — нам еще нужен WebApi, так вот в ASF это было бы все вместе, а в Cloud Service приходится поднимать Web Role. Зато масштабируем как хотим. Как обычно «сразу из коробки» vs «делай сам как хочешь».
TcpListener нужен для ADC, тут без вариантов.
Ключевое слово тут «для примеров». Это не реальная разработка, а изучение ASF. Orleans есть у нас в реальном проекте, и да, по акторам Orleans выглядит симпатичнее. Но у ASF и Orleans разные цели — ASF это все «из коробки», включая какую-нито панель управления, Orleans именно что фреймворк. Завести Orleans в Stateless сервис наверное, можно, но с ходу выглядит как уж с ежом — на мой взгляд если уж Orleans, то и вся обвязка должна быть своя. А про какие низкоуровневые кейсы Вы говорите?
«Эмбоссированные» — довольно старый термин, хотя действительно заимствованная калька. Там, где встречалось, применяется только в контексте пластиковых кард вместе с «прокатать», «слип» и пр.
На ГТ статьи не нашел, но порылся в интернете (например, тут и тут) — да, опускаются/поднимаются, но пишут, что автоматически, отслеживая наличие провода над машиной. Более того, токосьёмники стабилизированы, так что боковая болтанка машины по дороге на них не влияет (понятно, что в некоторых пределах). Были у меня сомнения насчет времени автозапуска дизеля — все-таки процесс не мгновенный, а масса фуры много тонн — но, видимо, для современных двигателей и это сейчас не проблема.
Это понятно — я про переход между источниками энергии. Скажем для многосистемных электровозов есть процедуры перехода между системами вплоть до полного останова. Тут такое не годится, значит, для съезда с магистрали нужно быстро (а то и заранее) перейти на дизель (@Notzeal пишет, что гибрид последовательный). И токосъемники не забыть опустить — кто напомнит об этом водителю? Наверное, навигатор — значит, надо навигаторы дообучить таким дорогам и такому транспорту. В общем, всяких деталей полно.
Ну, «я не ракетчик», поэтому соглашусь со всеми высказываниями — понятно, что в Европе и места под ЖД меньше, да и сами расстояния не те, что у нас, и структура экономических отношений не такая. Но с технической точки зрения все-таки неясно — тут требования к безопасности другие (причем как трассы, так и машин), и появляется ограничение по высоте правой полосы, и что делать с развязками трассы и пр. В общем, это не просто агрегатный, а какой-то специфический вид транспорта получается — посмотрим, что покажет тестирование.
Неужели такая конструкция дешевле, чем ЖД+развозные машины? Вот напряжение (у нас) в троллейбусе 600 вольт, на ЖД — 3кВ постоянки/25кВ переменки. Это я к тому, что требования по безопасности разные. И опоры под сеть нужны другие. Да и как выше уже написали — за чей счет электрический банкет? Для конкретного случая типа БЕЛАЗа в карьере все понятно, а тут геморроя много, а профит какой-то неясный.
Отвечаю по порядку.
Опыт использования в реальных условиях MS Orleans есть — продукт новый, динамично развивается, проблемы иногда вылезают, но в целом сейчас релиз стабильный, и использовать его можно. Реального опыта по ASF пока нет, и мне самому интересно послушать тех, у кого уже появился.
Теперь об остальном. Сразу замечу, что Orleans — это framework (иначе говоря, библиотека), а ASF — серверное решение, поэтому для Orleans разворачивание, диагностику, мониторинг и пр. надо писать самому, а ASF сам строит кластер и сам себя диагностирует (годится ли такое “из коробки” для Вашего проекта надо смотреть по месту). Взаимодействие между акторами/сервисами есть в обоих решениях.
Далее — Orleans в основе предлагает actor model, ASF в основе предлагает микросервисы (как я упомянул в статье, сами ASF Actors построены на микросервисах). Несмотря на некоторое сходство, микросервис и актор — разные сущности. Система акторов — это система именованных объектов, доступ к которым осуществляется по имени через интерфейс. Система микросервисов — система неких объектов, запущенных на исполнение. Внешнего доступа к таким объектам может и не быть (если это сервис фоновой задачи), а если и есть, то тяготеет скорее к TCP/HTTP, чем к RPC. Актор является точкой синхронизации — в один момент времени исполняется не более одного вызова. И жизненный цикл актора/сервиса разный — при запросе актора можно активировать, а при отсутствии активности деактивировать (см. virtual actors и grains), экзмепляр сервиса же, будучи запущен, работает до полного останова. Сервис можно эмулировать бессмертным актором — такой фокус возможен, более того, в Orleans мы так и делали для фоновых задач, но концептуальную красоту это нарушает :)
Ну и наконец durable шина сообщений — в Orleans это Streams, а вот в ASF готовой шины нет (коллеги подсказывают, что были в ASF те же Streams, но вышли такими кривыми, что пока их выпилили от греха подальше и когда впилят обратно — неизвестно).
Афера века или секта свидетелей Илона Маска
Макаронный монстр Илона Маска
Hyperloop и Гиперлох от Илона Маска
Ссылок не даю, найти их несложно. Звучат эти мнения несколько более реалистично, чем испытания рельсовой тележки «в вакууме». В теории все красиво, но пока пересаживание проекта на российскую почву видится как желание попилить государственного бабла в стране, где за этим баблом не очень следят. А судя по поддержке высоких лиц — желание обоюдное. Хотя действительно России с ее размерами скоростной транспорт нужен как воздух и масштаб проекта вполне достоин бывшей 1/6 части суши. Но это совсем не московский уровень — таким транспортом у нас надо связывать крупные города, регионы и даже Европу с Азией.
«Денег нет, но вы там держитесь» — уже набило оскомину, но подходит идеально.
TcpListener нужен для ADC, тут без вариантов.
Опыт использования в реальных условиях MS Orleans есть — продукт новый, динамично развивается, проблемы иногда вылезают, но в целом сейчас релиз стабильный, и использовать его можно. Реального опыта по ASF пока нет, и мне самому интересно послушать тех, у кого уже появился.
Теперь об остальном. Сразу замечу, что Orleans — это framework (иначе говоря, библиотека), а ASF — серверное решение, поэтому для Orleans разворачивание, диагностику, мониторинг и пр. надо писать самому, а ASF сам строит кластер и сам себя диагностирует (годится ли такое “из коробки” для Вашего проекта надо смотреть по месту). Взаимодействие между акторами/сервисами есть в обоих решениях.
Далее — Orleans в основе предлагает actor model, ASF в основе предлагает микросервисы (как я упомянул в статье, сами ASF Actors построены на микросервисах). Несмотря на некоторое сходство, микросервис и актор — разные сущности. Система акторов — это система именованных объектов, доступ к которым осуществляется по имени через интерфейс. Система микросервисов — система неких объектов, запущенных на исполнение. Внешнего доступа к таким объектам может и не быть (если это сервис фоновой задачи), а если и есть, то тяготеет скорее к TCP/HTTP, чем к RPC. Актор является точкой синхронизации — в один момент времени исполняется не более одного вызова. И жизненный цикл актора/сервиса разный — при запросе актора можно активировать, а при отсутствии активности деактивировать (см. virtual actors и grains), экзмепляр сервиса же, будучи запущен, работает до полного останова. Сервис можно эмулировать бессмертным актором — такой фокус возможен, более того, в Orleans мы так и делали для фоновых задач, но концептуальную красоту это нарушает :)
Ну и наконец durable шина сообщений — в Orleans это Streams, а вот в ASF готовой шины нет (коллеги подсказывают, что были в ASF те же Streams, но вышли такими кривыми, что пока их выпилили от греха подальше и когда впилят обратно — неизвестно).
Афера века или секта свидетелей Илона Маска
Макаронный монстр Илона Маска
Hyperloop и Гиперлох от Илона Маска
Ссылок не даю, найти их несложно. Звучат эти мнения несколько более реалистично, чем испытания рельсовой тележки «в вакууме». В теории все красиво, но пока пересаживание проекта на российскую почву видится как желание попилить государственного бабла в стране, где за этим баблом не очень следят. А судя по поддержке высоких лиц — желание обоюдное. Хотя действительно России с ее размерами скоростной транспорт нужен как воздух и масштаб проекта вполне достоин бывшей 1/6 части суши. Но это совсем не московский уровень — таким транспортом у нас надо связывать крупные города, регионы и даже Европу с Азией.