to post messages and comments.
"Rust: implementation of `hg`

This commit provides a mostly-working implementation of the
`hg` script in Rust along with scaffolding to support Rust in
the repository.

If you are familiar with Rust, the contents of the added rust/
directory should be pretty straightforward. We create an "hgcli"
package that implements a binary application to run Mercurial.
The output of this package is an "hg" binary.

Our Rust `hg` (henceforth "rhg") essentially is a port of the existing
`hg` Python script. The main difference is the creation of the embedded
CPython interpreter is handled by the binary itself instead of relying
on the shebang. In that sense, rhg is more similar to the "exe wrapper"
we currently use on Windows. However, unlike the exe wrapper, rhg does
not call the `hg` Python script. Instead, it uses the CPython APIs to
import mercurial modules and call appropriate functions. The amount of
code here is surprisingly small.

It is my intent to replace the existing C-based exe wrapper with rhg.
Preferably in the next Mercurial release. This should be achievable —
at least for some Mercurial distributions. The future/timeline for
rhg on other platforms is less clear. We already ship a hg.exe on
Windows. So if we get the quirks with Rust worked out, shipping a
Rust-based hg.exe should hopefully not be too contentious."

Баян-статья про промисы в жабоскрипте, нашел попутно.

Так вот, там чуваки РУГАЮТ async/await потому что по сравнению с промисами код хуже читается (!!). Вроде не шутят. Беда (!!), говорят, что асинхронный код становится похож на синхронный. И это не один человек, там вроде есть группа с консенсусом на эту тему. Да, и постоянно ссылаются что становится сложно выполнить 2 функции одновременно: Promise.all(f1(), f2()).

Вопрос публике: в вашем проекте какой процент кода вот это вот, запускает одновременно 2 future? Это оптимизация latency на коленке каждый раз? Нафиг так жить?

Какой смысл в node.js если есть dart?

Варианты ответов: 1) под ноду есть офигенне ВЕБ-фреймворк, без которого не жизнь, и оно без ноды на сервере не живет 2) реюзать код с бровзером

В моем случае: чисто енларг-подобный процессинг: схватил — сцепил — залил/отдал, никаких веб фреймворков. Шарить с вебом тоже нечего. Зато строгая типизация с тайпчекером, системные штучки искаропки, раздельные кучи, и самое главное — это то, что оно задизайнено все изначально как надо, не костыльно, весь тулчейн включая package mgr.

Говорю как человек, который к ноде подходит только издалека палочкой потыкать, чтобы не развонялось, а вот с дартом у меня такого нет.

Неявный вопрос звучит так: может я пропустил что-то, что в этом направлении идет еще дальше дарта?

Похоже на то что зарабатывание денег на заказах с фрилансерских сайтов по написанию прикладного ПО (.NET, WPF в даном случае) это экзотика и малореально (да ещё от исполнителя могут потребоваться познания в спецефических вещах). Так что в целом путь фрилансера это путь сайтостроителя.

Пишу на дарте, дык реально утомительно и забывчиво писать там везде "await s.readBytes()", вот это await. В котлине здорово придумали вообще на уровне языка чтобы само все делалось.


В C# можно создать объект анонимного типа используя записав свйства в фигурных скобках (как в языке–который–нельзя–называть)

var o = new {name = "Ndndn", place = 12};
Но как потом обратиться к этим свойствам? Судя по подсказке IDE у объекта свойств таких нет. Оказывается всё просто (проще чем в языке–который–нельзя–называть):

item.GetType().GetProperty("label").GetValue(item, null)

Michael, your ideas are a bit dated: web development isn't about scripting today. E.g., we're writing web apps that run on Google App Engine (JPA/POJO/Servlet) and accessed by Flex and Android (Java). We avoid JavaScript like the plague. :) Tools like Google Web Toolkit (GWT) let you program in Java and automatically generate optimized JavaScript that readily runs on multiple browsers — you never mess with JavaScript.

Посмотрел на современные статически-типизированные языки. Как-то получается, что они разделились на три категории

1. Низкоуровневые с нативным компилятором (go, rust, d)
2. Высокоуровневые под jvm/.net (boo, kotlin, scala)
3. Заумно-задротские с нативным компилятором (haskell, *ML)

Есть ли примеры, которые не попадают в эти три категории?
"Using Rust in Mercurial
This page describes the plan and status for leveraging the Rust programming language in Mercurial.
Why use Rust?
Today, Mercurial is a Python application. It uses Python C extensions in various places to achieve better performance.
There are many advantages to being a Python application. But, there are significant disadvantages.
Performance is a significant pain point with Python. There are multiple facets to the performance problem:
Startup overhead
General performance overhead compared to native code
GIL interfering with parallel execution
It takes several dozen milliseconds to start a Python interpreter and load the Mercurial Python modules. If you have many extensions loaded, it could take well over 100ms just to effectively get to a Mercurial command's main function. Reports of over 250ms are known. While the command itself may complete in mere milliseconds, Python overhead has already made hg seem non-instantaneous to end-users.
A few years ago, we measured that CPython interpreter startup overhead amounted to 10-18% of the run time of Mercurial's test harness. 100ms may not sound like a lot. But it is enough to give the perception that Mercurial is slower than tools like Git (which can run commands in under 10ms).
There are also situations like querying hg for shell prompts that require near-instantaneous execution.
Mercurial is also heavily scripted by tools like IDEs. We want these tools to provide results near instantaneously. If people are waiting over 100ms for results from hg, it makes these other tools feel sluggish.
There are workarounds for startup overhead problems: the CommandServer (start a persistent process and issue multiple commands to it) and CHg (a C binary that speaks with a Mercurial command server and enables chg commands to execute without Python startup overhead). chg's very existence is because we need hg to be a native binary in order to avoid Python startup overhead. If hg weren't a Python script, we wouldn't need chg to be a separate program.
Python is also substantially slower than native code. PyPy can deliver substantially better performance than CPython. And some workloads with PyPy might even be faster than native code due to JIT. But overall, Python is slower than native code.
But even with PyPy's magical performance, we still have the GIL. Python doesn't allow you to execute CPU-bound Python code on multiple threads. If you are CPU bound, you need to offload that work to an extension (which releases the GIL when it executes hot code) or you spawn multiple processes. Since Mercurial needs to run on Windows (where new process overhead is ~10x worse than POSIX and is a platform optimized for spawning threads — not processes), many of the potential speedups we can realize via concurrency are offset on Windows by new process overhead and Python startup overhead. We need thread-level concurrency on Windows to help with shorter-lived CPU-bound workloads. This includes things like revlog reading (which happens on nearly every Mercurial operation).
In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial's development velocity.
Today, when performance is an issue, Mercurial developers currently turn to C. But we treat C as a measure of last resort because it is just too brittle. It is too easy to introduce security vulnerabilities, memory leaks, etc. On top of vanilla C, the Python C API is somewhat complicated. It takes significantly longer to develop C components because the barrier to writing bug-free C is much higher..."

Почитал тут про диалектический предел

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

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

це тому що в js числа можуть бути цілими і поламаними, int — integer, а var — various, типу "різні" числа, а потім ця ідея сподобалась автору js і він почав використовувати var для всіх інших типів даних. В той день в нього ще кішка народжувала, і народила котенятка з членом на мордочці. Саме це наштовхнуло автора js на використання var для всіх інших типів даних.

Поплавал в документации OLE Automation. Глаза текут от GetIDsOfNames, DISPATCH_METHOD, rgdispidNamedArgs, DISPPARAMS.

И ладно бы это только OLE такое. У сторонних разрабов духу не хватает пойти против птичьих стандартов именования, сказать «да в гробу мы видели ВАШИНЕЧИТАЕМЫЕКРИЧАЩИЕИМЕНАКАПСОМСКАЖИСПАСИБОЕСЛИВНУТРЕННИЕСЛОВАНЕСОКРАТИЛИ, ВАШИ_ЧУТЬ_ЛУЧШЕ_ЧИТАЕМЫЕ_КРИЧАЩИЕ_ИМЕНА_КАПСОМ, местВаши прилВенгерские сущИмена, ВашЕдваЧитаемыйВерблюжийРегистр, вашДебильныйВерблюжийРегистрСМаленькойБуквы и вс эт вш атмсфр», забубенить Везде_Одинаковые_Идентификаторы и сильной рукой навести порядок. Как сделали в языке Ада. По сравнению с Делфями нравится, что выправили Char на Character, чтоб с самого начала не показывать дурной пример.

KDB+ начали раздавать почти бесплатно. Если раньше лицензия на ядро стоила бешеных бабок (тысячи в год), и выдавалась вручную, то щас туда впилили динамическое измерение ядер во время выполнения, оно теперь постоянно стучится домой, и чуваки разворачивают его на cloud по 5 центов за ядро/час, а малые инсталляции (до 16 ядер) вообще вроде даром для личного пользования (до того была unlimited 32bit версия, но это просто смешно). вот тут чувак между делом меряет перфоманс и занимается вещами, которые лично мне не доводилось щупать. Там же сравнение с другими СУБД.

Кстати, прикол от Nanoc. Там есть возможность писать свои фильтры и вообще внедрять свой код в процесс компиляции сайта, достаточно закинуть модули в папку lib. Ну я и закинула. А у меня один главный файл, к которому через require_relative прицеплены другие. В standalone режиме всё прекрасно работало, а тут компиляция начала валиться с сообщением, что дескать unicode normalization не применима к US-ASCII. С этого момента началось перелопачивание исходников в поисках, где он нашёл US-ASCII. Думала, что из-за включения гема unicode, пихала всё в module, чтобы не светилось наружу – нифига. Потом от отчаяния догадалась убрать require_relative, раз уж оно грузит все модули, что есть в папке без дополнительных пинков, и ошибка пропала. Короче, мистика.

Собственно, чего это я? Сегодня вместо работы сидела портировала код, конвертирующий текст в HTML с сохранением внешнего вида (в том числе и табов), с VBScript на Руби. Тоесть код нужен был для обновления программы на VB6, но на работе VB6 нет поэтому сначала писала на VBScript, а потом в VBA приводила в чувства. Собственно, на Руби я это дело перевести тоже хотела, а всё для чего? Для того чтобы у меня был свой собственный фильтр для Nanoc, чтобы обычный текст выводился нормально без всех Markdown премудростей. И фильтр я таки сделала, теперь нужно допилить его для нормального состояния, чтобы параметры были и всё такое. А там уже можно будет придумать, как мелкие рассказики пачкой публиковать, конвертируя из CherryTree XML ^^'
"What’s in 1.22.0 and 1.22.1 stable

The headline feature for this release is one many have been anticipating for a long time: you can now use ? with Option<T>! About a year ago, in Rust 1.13, we introduced the ? operator for working with Result<T, E>. Ever since then, there’s been discussion about how far ? should go: should it stay only for results? Should it be user-extensible? Should it be usable with Option<T>?

In Rust 1.22, basic usage of ? with Option<T> is now stable. This code will now compile:

fn try_option_some() -> Option<u8> {
let val = Some(1)?;
assert_eq!(try_option_some(), Some(1));

fn try_option_none() -> Option<u8> {
let val = None?;
assert_eq!(try_option_none(), None);

However, this functionality is still a bit limited; you cannot yet write code that mixes results and options with ? in the same function, for example. This will be possible in the future, and already is in nightly Rust; expect to hear more about this in a future release.

Types that implement Drop are now allowed in const and static items. Like this:

struct Foo {
a: u32

impl Drop for Foo {
fn drop(&mut self) {}

const F : Foo = Foo { a : 0 };
static S : Foo = Foo { a : 0 };

This change doesn’t bring much on its own, but as we improve our ability to compute things at compile-time, more and more will be possible in const and static.

Additionally, some small quality-of-life improvements:

Two recent compiler changes should speed up compiles in debug mode. We don’t have any specific numbers to commit to with these changes, but as always, compile times are very important to us, and we’re continuing to work on improving them.

T op= &T now works for primitive types, which is a fancy way of saying:

let mut x = 2;
let y = &8;

// this didn't work, but now does
x += y;

Previously, you’d have needed to write x += *y in order to de-reference, so this solves a small papercut."