В отличие от Glass, полноэкранное отображение информации. Т.е. не окошко в углу, а полноценная дополненная реальность с накладыванием маршрута прямо на дорогу, подсветкой объектов etc.
У сановского JVM реально лучше оптимизирующий JIT. Раньше был и более быстрый GC, но сейчас я за это уже не поручусь. Мне доводилось слышать такое объяснение этому: в JVM JIT-компилируется не все подряд, и есть байткодный интерпретатор, поэтому JIT можно сделать дорогим и долгим, но выдающим очень качественный результат, а потом включать его выборочно только для горячего кода. В CLR же архитектурно вообще нет интерпретатора байткода, там все JIT-компилируется — и компилятор, соответственно, должен быть достаточно быстрым, что ограничивает возможность использовать более дорогие оптимизации.
Поэтому при прочих равных, JVM мог выдавать более быстрый код, с более агрессивным инлайнингом, вытаскиванием объектов на стек etc.
Но на практике C# предоставляет куда больше возможностей для ручной оптимизации, благодаря наличию структур, unions (StructLayoutKind.Explicit), сырых указателей, stackalloc, fixed-полей и т.п. вещей. Поэтому «прочих равных» не получается.
Кстати, на самом деле, если внимательно посмотреть на C#, то единственное, что ему не хватает для системного программирования — это сырые указатели на функции. В остальном, он полностью покрывает весь спектр возможностей, которые есть в C. Ну, еще нужно как-то отвязать GC — для стандартных типов это вполне можно сделать подсчетом ссылок.
Фишка Vala в том, что в нем GObject является нативной объектной моделью. Поэтому непонятно, какое отношение к нему будет иметь Go, и уже тем более, QML.
Еще два года назад игрался с Ubuntu в chroot на TF101. Но вот чего сильно не хватает — это полноценного Xserver для андроида. Был вариант с VNC, то это очень тормозно. Вроде бы кто-то начинал писать свой сервер, но, судя по статье, воз и ныне там?
> acme и Plan9 в целом вдохновляющее свидетельство состоятельности простых и ясных подходов на тот случай, когда одолевает «ну когда Go приделают generic и почему он не обгоняет JVM».
Ну или, наоборот, вдохновляющее свидетельство их несостоятельности, только усиливающие подобные недобрые думы — все-таки это штука очень специфичная и очень на любителя (как и Go) — что видно по комментариям выше…
В общем, да, вы правы. Но, насколько мне известно, те СУБД, в которых MVCC был заложен в дизайн изначально (как в InterBase/Firebird), все используют optimistic locking.
Да, про Postgres я не знаю деталей, но судя по вот этой доке — их уровень изоляции SERIALIZABLE, это тоже полноценный snapshot, с таким же способом разрешения конфликтов — там явно приводится пример классического retry loop для разрешения конфликтов записи при коммите.
В смысле — «теоретически»? Это самый что ни на есть классический snapshot isolation на основе MVCC, со всеми вытекающими из него бонусами в виде отсутствия блокировок, и, соответственно, быстрыми, и при этом полноценно изолироваными одновременными транзакциями в случаях, когда конфликты на запись редки (что очень типично для обычных ворклоадов). Именно так на практике работают SQL Server (в режиме изоляции snapshot) и Firebird. В Oracle, да, есть блокировки на запись, но это какбэ уже не чистый MVCC.
>> Вы ошибаетесь, версионники тоже используют блокировки, так как невозможно в двух параллельных транзакциях обновить одну и ту же запись: одна из транзакций должна ожидать завершения другой
Почему же невозможно? Просто одна транзакция при коммите обломится. В этом, собственно, весь смысл snapshot isolation, разве нет?
>> Эх, как еще в дотнете 1.1 не хватало жавовских BigInteger и BigDecimal…
Все-таки большинство целей, для которых в Java использовался BigDecimal (работа с деньгами и прочие моменты, где нужна десятичная арифметика без неявной потери точности), в .NET успешно покрывались обычным decimal — который при этом намного быстрее.
«Наследования стоит избегать» — это правило из разряда «goto всегда плохо». В наследовании как таковом проблем нет, проблемы есть в языках, которые ограничивают возможности его применения. Но если в данном конкретном случае эти ограничения вас не касаются, то писать больше кода только ради того, чтобы не использовать наследование — глупо.
Вот если вы дизайните public API (какую-нибудь библиотеку, например), то там, да, придется задуматься о наследовании, потому что проблемы потом будут уже у клиентов вашей библиотеки.
И он совершенно прав. Потому что цепочка байт может быть и не utf-8, и вообще не строкой.
Если это строка — то скажите об этом интерпретатору (decode). И вы получите юникодную строку, с которой можно работать. А потом, когда её нужно отдать обратно, сделайте encode. Таким образом, код, который работает со строками, не парится с кодировками — они фигурируют только на interop boundary, и при этом везде в явном виде. И в чем проблема?
На практике та модель, к которой пришел Питон в третьей версии, практикуется в Java, .NET, Obj-C и многих других современных языках уже много лет. И все проблемы с ней решаются очень просто — если вы работаете со строками, представленными в виде байт, то преобразуйте их к строке и работайте с ней, а потом обратно. А если это на самом деле и не строка вовсе, тогда с какой стати на ней должны работать стандартные строковые операции?
Здесь, однако, речь о некоем Vortex86EX. Судя по тому, что удалось нарыть в сети, в EX таки есть FPU — более того, утверждается, что туда из коробки можно поставить Ubuntu, что, я так понимаю, подразумевает и наличие CMOV.
Если так, я бы взял себе эту коробочку на предмет установки в нее DOS и Win9x, для ностальгического гейминга (DOSBox не предлагать!).
I-751 надо через два года (точнее, за 90 дней до) подавать, после чего привязка ГК к браку снимается.
tvision.sourceforge.net/
По идее, там все несколько более высокоуровнево, т.е. всякие там менюшки и поля есть из коробки с минимум приседаний.
А еще есть FreePascal и FreeVision…
Поэтому при прочих равных, JVM мог выдавать более быстрый код, с более агрессивным инлайнингом, вытаскиванием объектов на стек etc.
Но на практике C# предоставляет куда больше возможностей для ручной оптимизации, благодаря наличию структур, unions (StructLayoutKind.Explicit), сырых указателей, stackalloc, fixed-полей и т.п. вещей. Поэтому «прочих равных» не получается.
Кстати, на самом деле, если внимательно посмотреть на C#, то единственное, что ему не хватает для системного программирования — это сырые указатели на функции. В остальном, он полностью покрывает весь спектр возможностей, которые есть в C. Ну, еще нужно как-то отвязать GC — для стандартных типов это вполне можно сделать подсчетом ссылок.
Ну или, наоборот, вдохновляющее свидетельство их несостоятельности, только усиливающие подобные недобрые думы — все-таки это штука очень специфичная и очень на любителя (как и Go) — что видно по комментариям выше…
Почему же невозможно? Просто одна транзакция при коммите обломится. В этом, собственно, весь смысл snapshot isolation, разве нет?
Ну и Zen of Python — «explicit is better than implicit».
Все-таки большинство целей, для которых в Java использовался BigDecimal (работа с деньгами и прочие моменты, где нужна десятичная арифметика без неявной потери точности), в .NET успешно покрывались обычным decimal — который при этом намного быстрее.
Вот если вы дизайните public API (какую-нибудь библиотеку, например), то там, да, придется задуматься о наследовании, потому что проблемы потом будут уже у клиентов вашей библиотеки.
Если это строка — то скажите об этом интерпретатору (decode). И вы получите юникодную строку, с которой можно работать. А потом, когда её нужно отдать обратно, сделайте encode. Таким образом, код, который работает со строками, не парится с кодировками — они фигурируют только на interop boundary, и при этом везде в явном виде. И в чем проблема?
Если так, я бы взял себе эту коробочку на предмет установки в нее DOS и Win9x, для ностальгического гейминга (DOSBox не предлагать!).