Как избежать ошибок, используя современный C++

Например курить меньше спайса придумать менее не очевидную экранирующую обёртку нежели чем R"xyz()xyz"
Для сравнения Scala / F#

"""")"""

C#

@""")"

js

'")'

Как избежать ошибок, используя современный C++

А вот например строка из двух символов, закрывающей скобки и двойной кавычки):

const char* zhopa = R"xyz()")xyz";

что они курят?

Как избежать ошибок, используя современный C++

Хочу полноценную поддержку UTF-8 на уровне языка аналогично Go или UTF-16 в .net. По моему это желание такое же очевидное, как и сжечь все остальные кодировки.

Как избежать ошибок, используя современный C++

неизменяемый char* внутри которого UTF-8 — давным давно придуманное, полноценное работающее решение для представления строки. Проблемы с производительностью — это извините полная ерунда. Много ли программистов .net / java / Go используют изменяемые null-terminated строки для повышения производительности?

Прелесть UTF-8 в том, что первый байт представления символа всегда отличается от остальных его байтов. Следствие этого — простая и эффективная синхронизация: посреди потока легко можно выяснить, где начинается представление следующей кодовой точки (следующий байт, начинающийся не с 10) и простой просмотр текста в обратном направлении (например, эффективный поиск последнего вхождения одной строки в другую).

реализовать свой u32string, который бы позволял индексацию по кодпоинтам, а во внутреннем представении бы хранил строку как UTF-8.

— сменить яп зачастую проще и дешевле нежели вот так вот велосипедить

Как избежать ошибок, используя современный C++

Я эту каку разве что палочкой тыкаю по сильной необходимости. 5 видов строковых литералов например

u32string s5{ U"AAAA!"s };
string s{ "bububu"s };
string s2{ u8"bebebe" };
wstring s3{ L"aaaa"s };
u16string s4{ u"oooo"s };

UTF-8? не, не слышали. Есть мнение, что люди, до которых никак не дойдет, что текст не впихивается в кодировку фиксированной битности, и которые из-за этого тупо вводят новые типы под разные размеры — должны сдохнуть и сгореть в аду.

JavaScript: где мы сейчас и куда двигаться

зато теперь есть пока еще не такая крупная и сложная задача — компоновка этих компонентов, сборка и доставка (webpack.config.js, gulp и т.д.)

В нормальных платформах/языках это делает компилятор/линковщик. В js это, как и всё остальное, реализовано через одно место — с помощью гимнастики на волшебных костылях.

Что, если нам вообще не нужна надежность и гарантия в браузере?

Простите, но это похоже на бессвязный поток понятий

JavaScript: где мы сейчас и куда двигаться

упрощенный Haskell ориентированный на фронтенд

Не упрощённый Haskell общего назначения избыточен и слишком сложен для решения проблем, типичных для клиентской вебморды.

запутанный ffi (вызов js из elm)

Иначе Elm не даст гарантий безопасности рантайма, очевидно же.

JavaScript: где мы сейчас и куда двигаться

Вряд ли Haskell такой уж идеальный ЯП что вот так прям взлетит в будущем, учитывая его сложность. Упомянутый Elm скорее взлетит, ибо он проще. Я собственно про то, что его можно же уже сейчас брать. То есть те причины, по которым его люди избегают ("у меня в проекте DataTimePicker из jQuery UI, как мне его вставить в Elm ?!") мне не кажутся убедительными, если только нет действительно большого количества legacy кода.

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

JavaScript: где мы сейчас и куда двигаться

Будем честны. Все поднятые Вами проблемы решаются сменой языка программирования на тот, в котором statless и promises реализованы на уровне языка. Elm, Clj, F# и ни разу не на TypeScript или "статический" js + Flow. Например

эти чуваки пытаются достичь того же, чего и я — избавиться от классов, перейдя на чистые функции.

Но изначально React создавался, как урезанный Elm с классами. Ну и тэ пэ

Близкая к идеалу адаптация ВКонтакте API для платформы .NET

Скорее ВК изменит свой API)) в этом случае так же придётся вносить изменения в программу. Я бы предложил продумать логику автообновления дабы закрыть этот вопрос

Близкая к идеалу адаптация ВКонтакте API для платформы .NET

Да, именно так. В случае успеха авторизации ответ содержит строку-токен клиентской сессии. Я использовал такой подход с некоторыми известными веб сервисами, например, betfair.com, и не не припомню что-бы что-то там менялось. Вряд ли vc.com исключение

Близкая к идеалу адаптация ВКонтакте API для платформы .NET

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

Близкая к идеалу адаптация ВКонтакте API для платформы .NET

Логика формирования запроса для авторизации готова, теперь можно заняться ей самой. Насколько нам уже известно, для этого требуется диалог на WPF со встроенным браузером из библиотеки Windows Forms:

Ну и чего ради этот треш со встроенным ослобраузером, если далее у вас

using (var webClient = new WebClient())
{

? Вы вообще понимаете, что авторизацию можно сделать через WebClient без дополнительной гимнастики, или это у вас такой подход «максимально всё запутать»?