Не прыгайте выше головы — останетесь тупицей в плену больших денег

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

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

Какая асинхронность должна была бы быть в Python

что только не сделают люди, чтобы не переходить на elixir, go или haskell.

Критика протокола и оргподходов Telegram. Часть 1, техническая: опыт написания клиента с нуля — TL, MT

о, а вот это интересно
https://github.com/vk-com/kphp-kdb/tree/master/TL
не для телеги его придумывали, выходит

Не очередной язык программирования. Часть 1: Логика предметной области

господи, что вы к языку-то прикопались.
ну если вы можете написать такое описание — напишите кодогенератор из него в lsf, и будет вам счастье.

RBKmoney Payments под капотом — микросервисы, протоколы и конфигурация платформы

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

Про найм людей я полностью согласен с chainick — ничуть не легче нормальных людей на JVM найти, а возможно даже сложнее — людей сильно больше просеивать придется.
И дополню — к тому же, приличные разработчики на Erlang несколько дешевле, потому что их рынок не перегрет крупными лавочками, выметающими всех, кто вообще видел код на Java.

RBKmoney Payments под капотом — микросервисы, протоколы и конфигурация платформы

Вы абсолютно не понимаете, зачем нужны Erlang/Elixir.

Высокий RPS — это не про них, сырого перфоманса BEAM не дает.
А вот сравнимого удобства разработки асинхронных штук, смешивания синхронного и асинхронного кода, каскадирования и обработки ошибок нет больше нигде.

RBKmoney Payments под капотом — микросервисы, протоколы и конфигурация платформы

В итоге остановились на разработке своего DSL

а почему не lisp-in-json, типа

["if", 
  ["or", 
    ["=", "maestro", ["ctx-get", "payment_tool/definition/payment_system"]], 
    ["=", "mastercard", ["ctx-get", "payment_tool/definition/payment_system"]]]
  [ ...then... ]
  [ ...else... ]
]

(ну или вообще честный лисп, joxa или clojure-erlang, но это я не очень серьезен).

Я просто сталкивался с вашим подходом к конфигурации, и после определенного момента очень хочется вырвать себе глаза.

Несколько историй про подпольных программистов

скажем так, было бы неплохо, если бы они об этих автоматизациях кому-то сообщали все же.

Фростпанк: разбираем механику

Слушайте, вы игрой ошиблись. Frostpunk делали авторы This war of mine, и было вполне ожидаемо получить слезовыжималку без всякой логики под видом "сложного морального выбора".

Проще, чем кажется. Перелом

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

Мороженое с Kubernetes, или контейнерные решения для начинающих

Разработчики говорят, что это не важно, и эта система просто нужна для управления контейнерами. Тогда мы интересуемся, когда уже мы дойдем до продажи мороженого.

При таком подходе — никогда.

Используем Apple Pay и карту Тройка в качестве пропуска на работу

Отдельное шифрованое хранилище, в скоупе PCI DSS, половинки ключа шифрования вводятся разными людьми на старте сервиса, CVV не хранятся, банк-эквайрер одобряет для отдельных платежных сервисов оплату без CVV.

Spark — Потрясающий веб-микрофреймворк для Java

Я так и не нашел какого-то единого устоявшегося термина, но да, это возможность сгенерировать ссылку, исходя из обработчика или идентификатора роута и параметров.

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

Spark — Потрясающий веб-микрофреймворк для Java

Мне всегда было интересно, как создатели таких проектов предполагают жить без reverse URL resolution.

О-о-очень долгожданный релиз Sublime Text 3.0

Автор говорил, что сначала релиз 3.0, а потом уже лигатуры.

Готовим сборку Go-приложения в продакшн

Кстати, а сейчас есть какие-то тулзы, позволяющие избавиться от полных путей к репозиториям в импортах?

Создатель Node.js: «Для серверов я не могу представить другой язык кроме Go»

Ну, в нем есть не столько косяки, сколько некоторая неконсистентность. Например, вот взять дурацкий синтаксис вызова анонимных функций fun_variable.(:a, :b, :c).

Или вот эти приколы с proplist syntax:

Interactive Elixir (1.4.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> [1, 2, 3, a: 4, b: 5]
[1, 2, 3, {:a, 4}, {:b, 5}]
iex(2)> [1, 2, 3, a: 4, b: 5, 6]
** (SyntaxError) iex:2: syntax error before: 6

iex(2)> a = [1, 2, 3, a: 4, b: 5]
[1, 2, 3, {:a, 4}, {:b, 5}]
iex(3)> [c: 6 | a]
** (CompileError) iex:3: undefined function |/2
    (stdlib) lists.erl:1353: :lists.mapfoldl/3
    (stdlib) lists.erl:1354: :lists.mapfoldl/3
iex(3)>

или вот такие истории с мапами

iex(4)> b = %{:a => 5}
%{a: 5}
iex(5)> %{b | :a => 5}  
%{a: 5}
iex(6)> %{b | :a => 6}
%{a: 6}
iex(7)> %{b | :a => 6, b => 7}
** (KeyError) key %{a: 5} not found in: %{a: 6}
    (stdlib) :maps.update(%{a: 5}, 7, %{a: 6})
    (stdlib) erl_eval.erl:255: anonymous fn/2 in :erl_eval.expr/5
    (stdlib) lists.erl:1262: :lists.foldl/3
iex(7)> %{:a => 6, b => 7 | b}
** (CompileError) iex:7: undefined function |/2
    (stdlib) lists.erl:1353: :lists.mapfoldl/3
    (stdlib) lists.erl:1354: :lists.mapfoldl/3
    (stdlib) lists.erl:1353: :lists.mapfoldl/3

или proplist syntax который работает только для ключей-атомов

iex(7)> ["c": 6]                 
[c: 6]
iex(8)> ["c": 6][:c]
6

Если идти от языка к стандартной библиотеке, есть вот такое

iex(9)> ["c": 6]["a"]
** (ArgumentError) the Access calls for keywords expect the key to be an atom, got: "a"
    (elixir) lib/access.ex:255: Access.fetch/2
    (elixir) lib/access.ex:269: Access.get/3

Причем, это поведение изменить никак нельзя. because fuck you, that's why
Были еще какие-то шероховатости, уже не помню.

А вот если идти дальше, вот мы видим Plug и Phoenix, и вот они — редкостное говно во целому ряду причин.

Создатель Node.js: «Для серверов я не могу представить другой язык кроме Go»

Ну погуглите Erlang killer features. Изоляция данных и ошибок, например. Вообще механика каскадирования ошибок. Per-actor GC. Крутой preemptive планировщик c work stealing. Очень крутые возможности интроспекции, когда ты можешь своими руками потрогать изнутри работающую систему.
Еще есть hot code replacement, которым, впрочем, мало кто пользуется, потому что это мало кому реально нужно.
Порты как метод FFI весьма приятны.
Distribution с его сетевой прозрачностью, к которому я отношусь довольно двояко, но который все же есть и работает из коробки до поры до времени. Рано или поздно приходится начинать думать, но это везде так.

Создатель Node.js: «Для серверов я не могу представить другой язык кроме Go»

Все то же самое, только по-другому. Местами получше, местами похуже. Язык богаче, косяки есть, но не ужасают. Тулсет неплох.
Рантайм — BEAM — сложно сравнить, просто принципиально другой и обладает рядом killer features, которых нет вообще ни у кого.

Создатель Node.js: «Для серверов я не могу представить другой язык кроме Go»

Этот фрагмент меня поражает поразительной незамутненностью интервьюируемого.

Насколько же нужно не смотреть вообще по сторонам и не интересоваться ничем кроме своей песочницы, чтобы открыть для себя "блокирующий стиль поверх грин-тредов" с SMP-планировщиком в Go в 2012? Я не удивлюсь, если Дал лет через пять откроет для себя, скажем, Elixir.