Программирование *

Возможно я был недостаточно внимателен, но мне попалось на Хабре буквально одно, очень краткое упоминание крайне интересного исследования от команды из Университета Цинхуа и партнерских институтов нескольких стран: Absolute Zero Reasoner (AZR) — новую систему машинного обучения, которая развивает принципы self-play и способна обучаться без каких-либо внешних данных. В отличие от традиционных подходов, требующих тысячи размеченных примеров, AZR использует принцип самообучения через создание и решение собственных задач программирования. Система играет две роли одновременно: составителя задач (Proposer) и решателя (Solver), используя исполнитель кода как объективного судью для получения обратной связи. AZR продемонстрировал state-of-the-art результаты в программировании и математических рассуждениях, превзошедший модели, обученные на десятках тысяч человеческих примеров, при этом показав впечатляющий кросс-доменный перенос знаний между различными областями знаний.

Привет, Хабр! Меня зовут Владимир Марунин, я ведущий разработчик в команде Clatch. Сегодня расскажу о новых мапах в Go 1.24: разберем изменения, посмотрим, что было и что стало. О мапах часто спрашивают на собеседованиях, а еще без них нельзя просто так взять и написать программу на Go — так что, надеюсь, тема будет полезной и интересной.

Этот текст — расширенная версия моего доклада с митапа МТС True Tech Go. Если больше нравится слушать, а не читать, можно сразу переходить по ссылке. Поехали!

В прошлом месяце я зарелизил ZLinq v1 — революционную LINQ-библиотеку, которая достигает zero allocation на структурах и дженериках. Она может похвастаться такими расширениями, как LINQ to Span, LINQ to SIMD, LINQ to Tree (FileSystem, JSON, GameObject и т.д.), drop-in replacement Source Generator для произвольных типов, поддержкой нескольких платформ, включая .NET Standard 2.0, Unity и Godot и на данный момент ZLinq имеет более 2000 звезд на GitHub.

Помните, как долго выполняется сложение на бумаге?

¹¹ ¹
6876
+ 3406
------
10282

Начиная с единиц, мы складываем 6 + 6 = 12, записываем 2 и переносим 1. Затем пошагово двигаемся влево, пока складываемые разряды не закончатся.

При реализации сложения больших чисел (например, от 2⁶⁴ и выше) обычно пишут код, похожий на этот алгоритм. Любопытно здесь то, что существует простой трюк, позволяющий существенно ускорить этот процесс на современных CPU.

Но сначала я задам вопрос: почему сложение столбиком мы начинаем с самого младшего разряда? Почему бы не начать слева?

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

Как инфоцыгане захватили IT-курсы, обещали зарплаты по 300к за 3 месяца и сломали рынок. IT-образование начиналось с желания помочь, но закончилось спамом, разочарованием и враньём в резюме.

Вы знаете, что такое прогрессивный JPEG? Можете почитать хорошее объяснение. Идея заключается в том, что вместо загрузки изображения сверху вниз оно сначала грузится размытым, а потом постепенно становится чётче.

Что, если мы применим тот же принцип к передаче JSON?

Программисты на Go уже давно и долго жалуются на слишком многословную обработку ошибок. Все мы близко (а иногда и болезненно) знакомы со следующим шаблоном кода:

x, err := call()
if err != nil {
// обработка err}

Проверка if err != nil встречается настолько часто, что может становиться объёмнее остального кода. Обычно это происходит в программах, выполняющих много вызовов API, в которых обработка ошибок рудиментарна и они просто возвращаются. Некоторые программы в итоге выглядят примерно так:

func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return err
}
y, err := strconv.Atoi(b)
if err != nil {
return err
}
fmt.Println("result:", x + y)
return nil }

Из десятка строк кода тела этой функции реальную работу выполняют только четыре (вызовы и последние две строки). Остальные шесть строк — это шум. Код слишком многословен, поэтому неудивительно, что жалобы на обработку ошибок уже годами находятся на вершине списков в опросах разработчиков. (Какое-то время жалобы на обработку ошибок обгоняла только досада из-за отсутствия дженериков, но теперь, когда Go поддерживает дженерики, обработка ошибок снова вернулась на первое место.)

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

Всем привет! Я Влад Лунин, занимаюсь анализом сложных угроз в экспертном центре безопасности Positive Technologies. В последнее время часто приходится сталкиваться с вредоносным ПО (ВПО), написанном на Rust, поэтому хочу поделиться своим опытом реверса исполняемых файлов, написанном на этом языке. ВПО бывает как очень простое, так и очень сложное в своей реализации, и чаще всего эта сложность обусловлена особенностями Rust. Расскажу, какие подходы применяю для успешного реверса, а также про сложности, с которыми сталкивался, и как их преодолевал.

Привет, Хабр!

В этой статье разберём мутный, но крайне важный инструмент ‒ std::launder. Мы поглядим, зачем его протащили в C++17 и что компилятор делает, когда видит launder.

В мире программирования существуют различные идеологии написания кода, которые отвечают за коммуникации (Unix-way), гибкость (Agile), чистоту и читаемость кода (DRY, KISS).

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

Потоки² — это просто состояния сохранения³ эмулятора⁴, связанные с условием, при котором продолжается их выполнение.

Привет. Меня зовут Андрей Соколов, я руководитель команды LLM в AI VK, которая обучает и дорабатывает модели, а потом помогает другим командам интегрировать их в свои продукты. И сегодня я расскажу про такое направление в LLM, как структурированная генерация. 

Константин Евтеев @beginner760собирает Java-код с помощью диктора NVDA, редактирует его в Блокноте и передает на Linux по SSH через самописные bash-скрипты. После потери зрения он не потерял интереса к жизни и желания быть полезным и выстроил собственную инженерную экосистему: оглавления по строкам .txt-файлами, навигация по main и маленьким методам, отладка на слух.

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

Глава 1: мой коллега, программист

Пустая оболочка человека. Он больше похож на попугая, чем на личность. Мой начальник, искренне верящий в священнодействие Парного Программирования, сковал цепью меня и этого коллегу-«программиста», как сиамских близнецов с разных планет. Общей была наша клавиатура, но не мышление. Боже, как же он был далёк от этого.

«Постой-ка. У меня появилась идея. Дай мне клавиатуру.»

Идея. Ага. Как у младенца появляется «идея» засунуть вилку в розетку. Я почти доделал нечто прекрасное; стройную, изящную логику, пронзающую сложность подобно ножу, режущему масло. И тут появился он — бьёт по клавиатуре, как будто она ему деньги должна, копипастит код-франкенштейн из комментария на StackOverflow, написанный последователем Дяди Боба в 2014 году.

Знает ли он, что делает наша система? Нет.

Прочитал ли он тикет? Разумеется, нет.

Ощущает ли он уверенность, когда безрассудно корёжит глобальное состояние? Разумеется, да.

В своей предыдущей статье [перевод на Хабре] я говорил о множестве недостатков C++, которые, по сути, устранил Rust. Благодаря этому код теперь легко использовать правильно и сложно использовать неверно. Я не говорил о безопасности по памяти, просто привёл пример того, что пользователь функции не может случайно поменять местами аргументы количества и цены.

На написание статьи меня вдохновил доклад Мэтта Годболта о том, как можно сделать интерфейсы C++ более надёжными: Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Вам стоит его посмотреть!

В той статье я сказал, что Rust гораздо лучше помогает разработчику, возможно, благодаря тому, что у него были десятки лет, чтобы учиться. В конце концов, первая версия C++ была выпущена в начале 80-х, а Rust — в начале 2010-х. Если дать C++ несколько десятков лет для обучения, то, разумеется, появятся новые структуры, которые будут обладать высоким качеством и которые сложно использовать неправильно.

Но так ли это?

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

После прочтения этой статьи вы хорошо поймете следующее:

• как работает цикл событий (event loop) в Node.js, включая все его фазы
• как Node.js выполняет JavaScript в одном потоке (single thread)
• как Node.js использует библиотеку libuv и внутренние API для обработки асинхронных операций
• почему знание работы цикла событий так важно для написания эффективного серверного кода

Понять, как JS работает "под капотом" в браузере (см. эту короткую 15-минутную статью), проще, чем понять устройство Node.js. В браузере нет сложных фаз и многослойных механизмов, как в Node.js.

Но почему в Node.js все устроено сложнее? Зачем столько фаз, которые так непросто понять?

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

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

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

Возглавляя бэкенд-команду витрины в KION, я, Леша Жиряков, постоянно балансирую между скоростью вывода фичей и стабильностью работы системы. Сегодня решил перевести абстрактные технические дискуссии в конкретные цифры. А еще — поделиться расчетами, которые помогут принять экономически обоснованное решение: что выбрать для следующего проекта — Python или Java?