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

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

Всем нам предстоит поддерживать уже существующий код, а также проводить ревью кода коллег.

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

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

Представляю вашему вниманию перевод статьи The Magical Methods in C# автора CEZARY PIĄTEK.

Есть определенный набор сигнатур методов в C#, имеющих поддержку на уровне языка. Методы с такими сигнатурами позволяют использовать специальный синтаксис со всеми его преимуществами. Например, с их помощью можно упростить наш код или создать DSL для того, чтобы выразить решение проблемы более красивым образом. Я встречаюсь с такими методами повсеместно, так что я решил написать пост и обобщить все мои находки по этой теме, а именно:

• Синтаксис инициализации коллекций
• Синтаксис инициализации словарей
• Деконструкторы
• Пользовательские awaitable типы
• Паттерн query expression

Привет, Хабр! Представляю вашему вниманию статью "Four Better Rules for Software Design" автора David Bryant Copeland. David Bryant Copeland — архитектор ПО и технический директор Stitch Fix. Он ведет свой блог и является автором нескольких книг.

Мартин Фаулер недавно создал твит с ссылкой на его пост в блоге о четырех правилах простого дизайна от Кента Бека, которые, как я думаю, могут быть еще улучшены (и которые иногда могут отправить программиста по ложному пути):

Правила Кента из книги Extreme Programming Explained:

• Кент говорит: "Запускайте все тесты".
• Не дублируйте логику. Старайтесь избегать скрытых дубликатов, таких как параллельные иерархии классов.
• Все намерения, важные для программиста, должны быть явно видны.
• Код должен иметь наименьшее возможное количество классов и методов.

Согласно моему опыту, эти правила не совсем соответствуют нуждам проектирования ПО.

Привет, Хабр! Представляю вам перевод статьи "What Does a Game Designer do?" автора Kai Wüest. Kai Wüest — продюсер из Исландии, работавший раньше тестировщиком, а затем — геймдизайнером.

День в роли геймдизайнера

Легендарный геймдизайнер. Человек, миф, легенда, стоящая за игрой. Источник вдохновения для юных мечтателей, желающих однажды работать в игровой индустрии. Но чем занимается геймдизайнер на самом деле? И как вам стать одним из них?

Привет, Хабр! Представляю вашему вниманию перевод статьи "Pointers Are Complicated, or: What's in a Byte?" авторства Ralf Jung.

Этим летом я снова работаю над Rust фуллтайм, и я снова буду работать (помимо прочих вещей) над "моделью памяти" для Rust/MIR. Однако, прежде чем я заговорю о своих идеях, я наконец должен развеять миф, что "указатели просты: они являются просто числами". Обе части этого утверждения ошибочны, по крайней мере в языках с небезопасными фичами, таких как Rust или C: указатели нельзя назвать ни простыми, ни (обычными) числами.

Я бы также хотел обсудить часть модели памяти, которую необходимо затронуть, прежде чем мы можем говорить о более сложных частях: в какой форме данные хранятся в памяти? Память состоит из байтов, минимальных адресуемых единиц и наименьших элементов, к которым можно получить доступ (по крайней мере на большинстве платформ), но каковы возможные значения байта? Опять же, оказывается, что "это просто 8-битное число" не подходит в качестве ответа.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Perils of Constructors" автора Aleksey Kladov.

Один из моих любимых постов из блогов о Rust — Things Rust Shipped Without авторства Graydon Hoare. Для меня отсутствие в языке любой фичи, способной выстрелить в ногу, обычно важнее выразительности. В этом слегка философском эссе я хочу поговорить о моей особенно любимой фиче, отсутствующей в Rust — о конструкторах.

Что такое конструктор?

Конструкторы обычно используются в ОО языках. Задача конструктора — полностью инициализировать объект, прежде чем остальной мир увидит его. На первый взгляд, это кажется действительно хорошей идеей:

1. Вы устанавливаете инварианты в конструкторе.
2. Каждый метод заботится о сохранении инвариантов.
3. Вместе эти два свойства значат, что можно думать об объектах как об инвариантах, а не как о конкретных внутренних состояниях.

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

К сожалению, в этих рассуждениях есть дыра: сам конструктор наблюдает объект в незаконченном состоянии, что и создает множество проблем.

Привет, Хабр! Представляю вашему вниманию перевод статьи "What Is Rust's unsafe?" автора Nora Codes.

Мне доводилось видеть много недопониманий относительно того, что значит ключевое слово unsafe для полезности и правильности языка Rust и его продвижения как "безопасного языка системного программирования". Правда намного сложнее, чем можно описать в коротком твите, к сожалению. Вот как я ее вижу.

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