14 мая в столице пройдет очередной golang-meetup - "Весенний Go в Badoo".

Спешим сообщить вам прекрасную новость – 14 мая в московском офисе компании Badoo пройдет весенний Go-митап. Начинаем в 12:00. Приходите послушать интересные доклады и просто пообщаться! Выступления будут сниматься на видео.

Программа:

Марко Кевац, Badoo «Оптимизация программ на Go»

Из доклада вы узнаете:

• про большинство утилит из арсенала Go, предназначенных для оптимизации производительности;
• как и когда их (утилиты) использовать, а также мы посмотрим как они устроены внутри;
• про применимость linux утилиты perf для оптимизации программ на Go.

Кроме того, устроим небольшой crash course, в рамках которого поэтапно соптимизируем несколько небольших программ на Go с использованием вышеперечисленных утилит.

Сергей Камардин, Mail.ru Group «Семь тысяч rps, один Go»

Из доклада вы узнаете:

• как мы пришли к Go, оставив идею использования Node.js, Scala или Rust;
• про первый сервис, который мы написали на Go и запустили в продакшен;
• про ошибки, с которыми сталкивались под нагрузкой;
• про оптимизации, которые мы сделали и еще планируем сделать;
• про тестирование и предотвращение тестирования на продакшене (в частности, websocket'ов).

Алексей Палажченко, mc² software «Reform: путь к лучшему ORM»

Из доклада вы узнаете:

• как работает database/sql;
• интерфейс и реализации database/sql/driver;
• обзор популярных ORM и что с ними не так;
• как мы делали свой лучший ORM;
• и почему столько раз его переделывали.

Записывайтесь и приходите.

Ждем!

17 мая в столице состоится первая конференция разработчиков на языке Rust.

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

Год назад произошёл выпуск первой стабильной версии языка — Rust 1.0. С тех пор язык активно развивался. Ещё вчера про Rust никто не знал, а сегодня Dropbox переписал на нём ядро своей дисковой инфраструктуры.

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

Не пропустите! CoLaboratory: Rust — это шанс узнать о многообещающем языке программирования, который может вскоре заменить привычные инструменты, чьи позиции сейчас кажутся незыблемыми.

Программа мероприятия: 18:00 — 18:30 Регистрация участников.

18:30 — 18:40 Начало встречи. Приветственные слова.

18:40 — 19:40 Rust — лучше, чем C++. Степан Кольцов.

Rust — современный практический удобный быстрый и безопасный язык программирования с хорошей системой типов.

Rust должен стать заменой C++, т. к. решает проблемы C++ в работе с памятью (use after free, double free, buffer overrun и т. п.) и с многопоточностью при этом предоставляя такие же возможности для написания быстрого кода.

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

В своём рассказе я подробно (настолько, насколько это возможно за один час) опишу ту часть системы типов, которая гарантирует безопасную работу с памятью — lifetimes, borrowed pointers, Sync/Send и прочее. На мой взгляд, это самое важное, самое сложное и самое интересное, что есть в Rust.

19:40 — 20:30 Многопоточность и параллелизм в Rust. Никита Баксаляр.

Зачем нужны многопоточность и параллелизм, и почему это важно. Какие подходы применялись в Rust, и к чему в итоге пришли.

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

Альтернативные подходы к многопоточности: MPSC и обмен сообщениями, легковесные процессы, акторы и корутины.

20:30 — 20:50 Кофе-брейк 20:50 — 21:40 Практика разработки веб-серверов на Rust. Михаил Панков.

Rust позволяет писать быстрые и надёжные программы. Особенно когда они многопоточные. Это делает его хорошим выбором для написания серверной части разнообразных веб-приложений.

Но что для этого нужно? Зачем терпеть все эти длиннющие ошибки от borrow checker'а? Что с продуктивностью разработки? Где взять библиотеки? А что если библиотеки нет? Какой веб-фреймворк выбрать? Как отлаживать и профилировать код? В своём докладе я отвечу на эти и другие вопросы. Ещё я расскажу, что нужно делать, чтобы решить обойти проблемные места, которые у Rust, конечно, тоже есть.

Всё это — на примере кода инфраструктурного сервера, обеспечивающего «всегда зелёный master» (commit gatekeeper, аналог homu и zuul).

21:40 — 22:10 Rust FFI на примере расширения структуры данных из Haskell. Александр Вершилов.

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

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

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

Мероприятие состоится в штаб-квартире "Лаборатории Касперского".

Внимание, **Требуется регистрация!**

Из других новостей про этот язык - участник Fedora, инженер Red Hat и разработчик GCC, GDB и binutils, Tom Tromey, представил патчсет с поддержкой Rust в GDB. Патчи сразу заинтересовали других разработчиков GDB, и Tom представил уже вторую версию патчсета, исправленную и дополненную. Скоро можно будет отлаживать программы на Rust в GDB!

Вот, правда, для их отладки нужно их сначала собрать, а с этим у нас не все гладко. Включение Rust в Fedora что-то застряло на ровном месте. Уже три года, как на месте топчемся.

Это архивная статья

Вы уже знаете, что Red Hat активно участвует в работе комитета ISO по стандартизации C++, и регулярно отчитывается. Недавно компания отчиталась про проделанной работе по март 2016 года.

Основная работа велась по стандартизации современных многопоточных примитивов, таких, как "coroutines", хорошо известных разработчикам на Golang, Rust и иных современных языках, таких, как Simula-67, Modula-2, BCPL. Войдет ли все в C++17, пока неясно, но рабочие реализации будут в следующих версиях компиляторов.

Одновременно, Red Hat продолжает публиковать общеобразовательные статьи. В этот раз было решено рассказать про то, почему <cstdlib> настолько сложен?

Разработчики OpenSource мессенджера с фокусом на безопасности, Cryptocat, в своем твиттере признались в любви к нашему дистрибутиву.

Это, разумеется, очень правильно, т.к. именно наш дистрибутив предлагает разработчикам удобную платформу с современным ПО и отзывчивым коммьюнити. Выбирайте и вы!

Pieter Hintjens сообщил в своем Твиттере, что его дни сочтены. Мы все глубоко сожалеем.

Pieter, это очень непростой человек, и, как некоторые утверждают, якобы и в личном общении тоже. Он - автор AMQP, перессорившийся со всеми другими участниками, затем создавший 4 версии ZeroMQ, несовместимых настолько, что впору говорить о совершенно разных системах Message-oriented Middleware, и к которым было много претензий, но на базе которых можно выстроить распределенную систему. И хоть до сих пор хипстер-молодежь, начитавшись рекламных текстов о ZeroMQ, ходит по известным граблям, система вполне заслуженно заняла некоторую нишу. Надо просто очень внимательно читать инструкцию и тщательным образом следить за нетривиальным ходом мысли Питера.

Некоторые наши знакомые порой отвечают на просьбу ознакомиться со статьей, что "я не буду это читать, ведь это написал Pieter Hintjens". Однако, если уж говорить честно, то вклад Питера в дело становления и развития современной AйТи-индустрии, и его интеллектуальный потенциал нельзя переоценить. Что бы дальше ни произошло, мы желаем ему только хорошего (насколько это возможно в его ситуации).

Кот и Pieter Hintjens

Это архивная статья

ScyllaDB, совместимая реализация Apache Cassandra, о которой вы уже слышали, доросла до версии 1.0. Ну, правда, разработчики тут же выкатили bugfix-версию 1.0.1 в которой исправили десять (!) критических (!!!) багов в версии 1.0. Ничего страшного, бывает и не так, дело-то житейское.

Переписывать Cassandra было бы не очень интересно, но наши товарищи переписали ее используя только наисовременнейшие технологии - разработка ведется с использованием возможностей стандарта C++14, фреймворка Seastar и последних технологий создания многопоточного ПО на многоядерных системах. Особо ценно, что они публикуют огромное количество практически полезных исследований стыка между ядром и userspace и соответствующих подсистем ядра.

Например, они провели исследование файловых систем, в результате которого выявили единственный подходящий вариант для многопоточного современного приложения - XFS. Мы заранее просим прощения за то, что разочаровываем любителей несовершеннолетних файловых систем, типа ZFS и btrfs, но даже рассматривать эти системы пока несерьезно. Особенно для критически важных приложений, типа хранения коллекции любимых видеофайлов где-нибудь в ~/. Если же кто-то нас не слушает, и использует не XFS (ну или хотя-бы ext4), то `его накажет само провидение <https://www.linux.org.ru/forum/talks/12518526>`__. В дальнейшем, они создали CharybdeFS, специальную тестовую файловую систему для эмуляции ошибок файловых систем, [STRIKEOUT:таких как btrfs]. Коллеги-аналитики уже обсудили тестовую файловую систему на Linux.org.ru и OpenNET.ru.

Система позволяет эмулировать типичные ошибки ФС, такие как ошибки ввода/вывода, превышение дисковой квоты, нехватка памяти, ситуации когда файл занят другим процессом. Работа с файлами, кстати, это не самое простое занятие, и появление тестовой ФС может серьезно облегчить процесс разработки и тестирования ПО. Наши друзья уже активно используют CharybdeFS при разработке ScyllaDB.

Лицензия, скажем сразу, странноватая - копирайта нет, но есть рекомендация не использовать во зло. Что то это нам напоминает.

На днях Glauber Costa (Lord Glauber of Sealand) начал публикацию серии статей о том, как они разработали userspace IO scheduler.

Складывается впечатление, что народ из ScyllaDB снова делает крутой разработку системных вещей. Не всё вам на голанге и на Node.js писать! Разработка на уровне ядра в сравнении с разработкой на Node.js и golang.

Это архивная статья

Участник Samba и инженер Red Hat, Александр Боковой, опубликовал "лонгрид" о том, как была исправлена ошибка Badlock, и чего это стоило. Особо рекомендуем обратить внимание на статистику по патчам. За это-то и платят клиенты Red Hat.

Также обратите внимание на то, как было организовано взаимодействие с самыми разными компаниями и заинтересованными лицами на всех этапах - обнаружение уязвимости, исправление, бэкпортирование, тестирование результата, и распространение. Как вы думаете, суверенная, изолированная от проклятого Запада, айти-компания в какой-либо стране, смогла бы самостоятельно провести такой объем работы?

Это архивная статья

Участник коммьюнити Debian, Jorgen Schäfer, начал публиковать в блоке стартапа Loggly свои заметки про подходы к журналированию, ориентированные на начинающих системных администраторов. Начал он с разъяснений того, почему надо использовать Journald (вкратце, потому что Journald хранит логи в бинарном хорошо структурированном виде).

Продолжил по актуальной теме надежности и верифицируемости журнала и о том, как добавлять журналирование в приложения используя средства systemd.

На самом деле, структурированное журналирование теперь есть и в традиционных syslog-серверах (в rsyslog и в syslog-ng). Другое дело, что подавляющее большинство ПО не использует пока возможность systemd, полагаясь либо на syslog-протокол, либо и вовсе ведя журнал самостоятельно, в файлы. Это, конечно, проблема.

Интересно, что Journald уже довольно давно по меркам systemd не меняется. И пока серверное ПО только начинает переписываться используя функционал systemd, и, в частности, Journald, традиционные syslog-серверы не стоят на месте. Все идет к тому, что любой из двух наиболее популярных (syslog-ng и rsyslog) вскоре может быть использован, как drop-in replacement для Journald, который, в общем-то, ничего особенного не умеет. А вот, например, syslog-ng быстро разрабатывается, и его основной разработчик, Péter Czanik, регулярно пишет об изменениях и принимает участия в мероприятиях, например, участвует в DevConf.cz.

Недавно он опубликовал заметки о новой функциональности группировки сообщений, дедупликации и поиска простейших корреляций в журнале событий. А до этого он рассказывал, как использовать для структурированного хранилища бинарных логов Kafka (т.е. сообщения перенаправляются в Kafka, а там уж кто-то их должен читать и записывать), ElasticSearch и Hadoop.

Конечно, читать логи из HDFS глазами не получится.