17 млрд событий, 60 млн пользовательских сессий и огромное количество виртуальных свиданий происходят в Badoo ежедневно. Каждое событие аккуратно сохраняется в реляционные базы данных для последующего анализа на SQL и не только.

Современные распределённые транзакционные базы данных с десятками терабайт данных — настоящее чудо инженерной мысли. Но SQL как воплощение реляционной алгебры в большинстве стандартных реализаций пока не позволяет формулировать запросы в терминах упорядоченных кортежей.

В последней статье из серии, посвящённой виртуальным машинам, я расскажу про альтернативный подход к поиску интересных сессий — движок регулярных выражений («Поросячий Матчер»), определённых для последовательностей событий.

Виртуальная машина, байт-код и компилятор прилагаются бесплатно!

Всем привет!

Несмотря на диковинность и некоторую отвлеченность рассматриваемой сегодня темы — надеемся, что она сможет разнообразить вам выходные. В конце поста помещаем три ссылки от автора, позволяющие познакомиться с зависимой типизацией в Idris, F* и JavaScript

Замедляем Windows, часть 3: завершение процессов



Автор занимается оптимизацией производительности Chrome в компании Google — прим. пер.

Летом 2017 года я боролся с проблемой производительности Windows. Завершение процессов происходило медленно, сериализованно и блокировало системную очередь ввода, что приводило к многократным подвисаниям курсора мыши при сборке Chrome. Основная причина заключалась в том, что при завершении процессов Windows тратила много времени на поиск объектов GDI, удерживая при этом критическую секцию system-global user32. Я рассказывал об этом в статье «24-ядерный процессор, а я не могу сдвинуть курсор».

Microsoft исправила баг, и я вернулся к своим делам, но потом оказалось, что баг вернулся. Появились жалобы на медленную работу тестов LLVM, с частыми подвисаниями ввода.

Но на самом деле баг не вернулся. Причина оказалась в изменении нашего кода.

Да-да, именно «байт» и именно по индейски (не по индийски). Начну по порядку. В последнее время тут, на Хабре, стали появляться статьи о байт-коде. А когда-то давным-давно я развлекался тем, что писал форт-системы. Конечно, на ассемблере. Они были 16-ти разрядными. На x86-64 никогда не программировал. Даже с 32 поиграться не удалось. Вот и пришла такая мысль — а почему бы нет? Почему бы не замутить 64х разрядный форт, да ещё с байт-кодом? Да еще и на Linux, где я тоже ничего системного не писал.

У меня есть домашний сервер с Linux. В общем, я немного погуглил и узнал, что ассемблер на Linux называется GAS, а команда as. Подключаюсь по SSH к серверу, набираю as — есть! Он у меня уже установлен. Ещё нужен компоновщик, набираю ld — есть! Вот так, и попробуем написать что-нибудь интересное на ассемблере. Без цивилизации, только лес, как у настоящих индейцев :) Без среды разработки, только командная строка и Midnight Commander. Редактор будет Nano, который висит у меня на F4 в mc. Как там поет группа «Ноль»? Настоящему индейцу нужно только одного… Что еще нужно настоящему индейцу? Конечно, отладчик. Набираем gdb — есть! Ну что же, нажмем Shift+F4, и вперед!

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

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

Довелось намедни на одном белорусском ресурсе прочесть статью «10 языков программирования, которые больше никому не нужны». Среди «заживо погребенных» оказались Fortran, Basic, J#, Turbo Pascal, Ada и другие. Так вот, наибольшую полемику, как ни странно, вызвало обсуждение Aдa (надеюсь в этом месте я не оскорбляю чьи-либо чувства). Что, собственно говоря и сподвигло покопаться в этой увлекательной теме.

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

Все это уже хорошо известно всем, кто хоть немного следит за развитием современных технологий программирования. Но что если вы не системный программист, да и многопоточного кода в ваших проектах не много, но вас все же привлекает производительность Rust'а. Получите ли вы какие-то дополнительные преимущества от его использования в прикладных задачах? Или все, что он вам даст дополнительно — это суровую борьбу с компилятором, который будет заставлять вас писать программу так, чтобы она неотступно следовала правилам языка по заимствованию и владению?

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

Не так давно на Хабре появилась отличная и вдохновляющая статья про компиляторы и стековые машины. В ней показывается путь от простой реализации исполнителя байт-кода ко всё более и более эффективным версиям. Мне захотелось показать на примере разработки стековой машины, как это можно сделать Haskell-way.

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

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

Раньше я очень любил C#

Это был мой основной язык программирования, и каждый раз, когда я сравнивал его с другими, я радовался тому, что в свое время случайно выбрал именно его. Python и Javascript сразу проигрывают динамической типизацией (если к джаваскрипту понятие типизации вообще имеет смысл применять), Java уступает дженериками, отстутствием ивентов, value-типов, вытекающей из этого карусели с разделением примитивов и объектов на два лагеря и зеркальными классами-обертками вроде Integer, отсутствием пропертей и так далее. Одним словом — C# клевый.

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

А потом я из любопытства попробовал F#.

Перевод статьи канадского журналиста и писателя Джо Кларка

Я как-то писал инструкцию для портативного модуля диагностики двигателей автомобилей Daewoo. Так что я знаю, что значит «неудобно использовать». И айфонами пользоваться неудобно.

Два раза в автобусе на одном и том же маршруте я прямо смотреть не мог на то, как пожилые люди (в одном случае – с очками, сдвинутыми на лоб) пытались что-то читать с айфонов. Я брал у них телефоны (с их разрешения) и выводил очень хорошо спрятанный экран с выбором размера шрифта. Затем они выбирали шрифт побольше — такой, который им был нужен. В итоге они так меня благодарили, что мне было даже неловко.

То же произошло ещё раз, позже, правда, не в автобусе,- с одним 85-летним мужчиной, также страдавшим от мелкого текста.

Ещё один пожилой человек знал, что можно отправить текстовое сообщение на определённый телефонный номер, содержащее ID автобусной остановки, но не знал, что это наихудший из возможных способов узнать предполагаемое время прибытия автобуса, или что эти предсказания можно узнать где угодно, или что делать, если вы находитесь в незнакомом месте и не можете найти ID остановки. (Как он научился пользоваться айфоном? Он спрашивал у своей жены. А ещё он думал, что для чтения емейла можно пользоваться только приложением Gmail).

На днях вышел Kotlin 1.3 с комплектом сопутствующих библиотек, инструментов сборки и учебных материалов.

Мы делаем Kotlin как инструмент для разработки приложений любого масштаба на любых платформах. В Kotlin 1.3, благодаря корутинам, читать и писать неблокирующий асинхронный код стало легко и удобно. Масштабируемость стала гораздо доступнее. В новом релизе мы также выпустили бета-версию Kotlin/Native, позволяющую компилировать код Kotlin непосредственно в машинный код. Мультиплатформенные возможности Kotlin теперь работают на всех поддерживаемых платформах, что позволяет, например, использовать одну и ту же бизнес-логику в приложениях для Android и iOS. Общую логику можно также использовать для серверов и мобильных и веб-клиентов. Кроме того, появилась возможность писать легко переносимые мультиплатформенные библиотеки, которые возьмут на себя большинство повседневных задач.



В ближайшее время мы проведем серию вебинаров по основным возможностям версии 1.3, записывайтесь здесь.

Когда программисты обсуждают преимущества тех или других языков программирования, они часто рассуждают о них в прозаических терминах, как об инструментах в наборе различных приспособлений – один больше подходит для системного программирования, другой – для склеивания других программ в целях решения текущей задачи. Так и должно быть. У языков разные сильные стороны, и заявлять, что один язык лучше других языков, не указывая конкретных примеров, — значит, лишь вызывать непродуктивные и резкие споры.

Однако есть один язык, который странным образом вызывает всеобщее уважение: Lisp. Крестоносцы клавиатур, готовые атаковать любого, кто посмеет заявить, что какой-либо язык лучше других, сходятся в том, что Лисп находится на другом уровне. Он выходит за пределы утилитарных критериев, по которым судят другие языки, поскольку средний программист никогда не использовал Лисп для создания чего-либо практического, и, вероятно, никогда не будет этого делать, однако же, уважение к Лиспу настолько глубокое, что ему часто приписывают мифические свойства. Всеми любимые комиксы xkcd изображали таким образом Лисп как минимум дважды: в одном комиксе персонаж достигает Лисп-просветления, которое помогает ему познать фундаментальную структуру Вселенной. В другом старый программист в халате передаёт стопку круглых скобок своему падавану, объясняя, что это – «элегантное оружие для более цивилизованных времён», намекая на присущие Лиспу оккультные возможности Силы.

Бывают культовые фильмы, игры, книги или музыка — их страшно любит сплоченное сообщество, профессионалы и критики. Но коммерческого успеха и широкой популярности нет. Мне в таких ситуациях обычно до боли обидно.

В разработке хорошие технологии тоже не всегда становятся массовыми. Например, F#. Все что я о нем знаю — это дико крутой, но совершенно непопулярный язык, после которого разработчики уже не могут просто так возвращаться к своим привычным языкам.

Я попытался узнать, в чем причина. И вообще — кто те люди, которые на нем пишут, и зачем они это делают, если язык не нужен бизнесу? Для этого я постучался поговорить в русскоязычное сообщество F# в «Телеграме». Здесь — наш круглый стол.

Дефицита технических материалов о Kotlin нет, узнать о корутинах или nullability можно много где. Но остаётся куда менее освещённой другая сторона: а как вообще выглядит процесс разработки языка? Как принимаются решения? Каковы задачи у «самого главного человека»? Остаётся ли у него в жизни время на что-либо ещё?

И сейчас, когда вот-вот выйдет Kotlin 1.3, мы расспросили «самого главного» Андрея Бреслава не про корутины, а про совсем другое: от того, чем он занимался до Kotlin, до того, чем полезна психотерапия.

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

В настоящее время, когда во всю продвигаются шлемы виртуальной реальности и теслы летают в космос, можно использовать всю мощность браузерных движков для создания по настоящему интерактивных, кроссплатформенных и стильных презентаций, а не делать набор страниц PPTX или, чего хуже, PDF в стиле «иллюстративный материал к расчетно-пояснительной записке».

С 2015 года я пытаюсь найти для себя оптимальный формат презентаций (не считая дипломных проектов). И сейчас, в 2018-м, думаю, что это почти удалось. Начиналось все с Power Point, а закончилось веб-фреймворками на базе JavaScript.

Существует несколько JavaScript- движков, с помощью которых можно создавать классные презентации — Marp, Reveal, landslide, hacker-slides, slidify и другие. В каких-то можно использовать Markdown, какие-то встраиваются в IDE, а какие-то — можно создавать в собственных редакторах. Мне пока что удалось попробовать первые два.

В качестве демонстрации материала, доступны примеры слайдов и видео.

Мысль перевести фронт на какой-либо js фреймворк появилась одновременно с возможностью писать React на Kotlin. И я решил попробовать. Основная проблема: мало материалов и примеров (постараюсь эту ситуацию поправить). Зато у меня полноценная типизация, безбоязненный рефакторинг, все возможности Kotlin, а главное, общий код для бека на JVM и фронта на Javascript.

В этой статье будем писать страницу на Javasript + React параллельно с её аналогом на Kotlin + React. Чтобы сравнение было честным, я добавил в Javasript типизацию.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Understanding How Graal Works — a Java JIT Compiler Written in Java".

Введение

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

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

Привет! Сегодня я надеюсь показать вам немного магии. Моим хобби является придумывание всяких казалось бы невозможных штук на С++, что помогает мне в изучении всевозможных тонкостей языка ну или просто развлечься. Оператор in есть в нескольких языках, например Python, JS. Но в С++ его не завезли, но иногда хочется чтобы он был, так почему бы его не реализовать.

	std::unordered_map<std::string, std::string> some_map = 
	{
		{ "black", "white" },
		{ "cat", "dog" },
		{ "day", "night" }
	};

	if (auto res = "cat" in some_map)
	{
		res->second = "fish";
	}

Сейчас с уверенностью можно утверждать, что времена самописных C++-парсеров постепенно отходят в прошлое. На сцену медленно, но неумолимо выходит clang — полноценный C++-фронренд и компилятор, предоставляющий своим пользователям богатое API. С помощью этого API можно распарсить исходный текст на C/C++/Objective C, и вытащить из него всю необходимую информацию — от простого лексического значения токенов, до таблицы символов, AST-деревьев и результатов статического анализа кода на предмет всяких разных проблем. В связке с llvm и при сильном на то желании C++ можно использовать в качестве скриптового языка, парся и исполняя C++-программы «на лету». В общем, возможности перед программистами открываются богатые, надо только понять — как ими правильно воспользоваться. А тут, как это не редко случается, и начинается самое интересное.

Java Generics — это одно из самых значительных изменений за всю историю языка Java. «Дженерики», доступные с Java 5, сделали использование Java Collection Framework проще, удобнее и безопаснее. Ошибки, связанные с некорректным использованием типов, теперь обнаруживаются на этапе компиляции. Да и сам язык Java стал еще безопаснее. Несмотря на кажущуюся простоту обобщенных типов, многие разработчики сталкиваются с трудностями при их использовании. В этом посте я расскажу об особенностях работы с Java Generics, чтобы этих трудностей у вас было поменьше. Пригодится, если вы не гуру в дженериках, и поможет избежать много трудностей при погружении в тему.