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

https://openai.com/index/introducing-openai-o1-preview/

Дженерик алиасы типов в Go в 1.24 : что это и зачем они нужны

Представьте, что вы работаете над крупным проектом на Go, который развивается уже несколько лет. В какой-то момент вы понимаете, что структура пакетов, которую вы изначально выбрали, больше не отвечает потребностям проекта. Вам нужно перенести некоторые типы из одного пакета в другой. Звучит просто, верно? Но не тут-то было!

Проблема рефакторинга в больших проектах

Представим, что у вас есть популярный пакет oldpkg с типом User:

package oldpkg

type User struct {
    ID   int
    Name string
}

Теперь вы хотите перенести этот тип в новый пакет newpkg. Но ваш тип User используется в сотнях мест по всему проекту и в зависимых проектах. Как провести такой рефакторинг без боли?

Go 1.9 представил концепцию алиасов типов. Это позволяет нам создать новое имя для существующего типа без создания нового типа. Вот как это выглядит:

package newpkg

import "path/to/oldpkg"

type User = oldpkg.User

Теперь newpkg.User и oldpkg.User - это один и тот же тип. Мы можем постепенно обновлять использование oldpkg.User на newpkg.User по всему проекту, и компилятор будет счастлив.

Но что насчет дженериков?

С появлением дженериков в Go 1.18 возникла новая проблема. Как быть, если наш тип User использует параметры типа? До сих пор алиасы типов не поддерживали параметры типа. Но это изменится в Go 1.24

Дженерик алиасы типов

Представим, что наш тип User теперь дженерик:

package oldpkg

type User[T any] struct {
    ID   T
    Name string
}

В Go 1.24 мы сможем создать алиас для этого типа следующим образом:

package newpkg

import "path/to/oldpkg"

type User[T any] = oldpkg.User[T]

Это позволяет нам сохранить полную совместимость типов при переносе дженерик-типов между пакетами.

Когда это будет доступно?

В Go 1.23 вы можете включить поддержку дженерик алиасов типов с помощью флага GOEXPERIMENT=aliastypeparams.
В Go 1.24 (ожидается в начале 2025 года) эта функция будет включена по умолчанию.

Подробности здесь

Я принес. Гуманизм против «эффективного менеджмента». Почему заботиться о людях выгодно

Вы знаете, что я тот еще гуманист 🙂 Поэтому не мог пройти мимо этого лонгрида https://habr.com/ru/articles/816545/
Текст большой, так что наливайте чай-кофе, заводите один таймер pomodoro и погружайтесь.

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

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

Вышел PostgreSQL 17

Производительность:

Существенно улучшена работа с памятью. Вакуум теперь потребляет до 20 раз меньше памяти, что ускоряет его работу и снижает нагрузку на систему.
Запись при высокой конкурентной нагрузке стала быстрее в 2 раза благодаря оптимизации обработки WAL.
Улучшена производительность запросов с использованием условий IN для B-tree индексов.
Добавлена поддержка SIMD-инструкций (в том числе AVX-512) для ускорения вычислений.
Оптимизирована производительность COPY для экспорта больших объемов данных.

Для разработчиков:

Расширена поддержка JSON: добавлен JSON_TABLE для конвертации json в обычные таблицы PostgreSQL.
Появились новые конструкторы и функции для работы с json: JSON, JSON_SCALAR, JSON_SERIALIZE, JSON_EXISTS, JSON_QUERY, JSON_VALUE.
Улучшена команда MERGE: добавлена поддержка RETURNING и возможность обновления представлений.
EXPLAIN теперь показывает время, затраченное на локальное чтение и запись блоков, а также использование памяти.

Репликация и обновление:

Упрощен процесс обновления между мажорными версиями при использовании логической репликации. Теперь не нужно удалять слоты репликации при обновлении.
Добавлен контроль отказоустойчивости для логической репликации.
Представлен инструмент pg_createsubscriber для конвертации физической реплики в логическую.

Безопасность и управление:

Новые опции TLS для более гибкой настройки безопасности соединений.
Добавлена предопределенная роль pg_maintain для выполнения задач обслуживания.
Улучшены возможности резервного копирования: поддержка инкрементальных бэкапов в pg_basebackup.

Мониторинг и анализ:

Добавлено отображение прогресса при вакууме индексов.
Новое системное представление pg_wait_events для более детального анализа ожидающих сессий.

Я наверно слоупок, только сейчас узнал о программе dust, замене du

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

Запустил в папке с проектами, сразу нашел гигабайтные node_modules в старых проектах, прикольно.

подробнее тут (там куча полезных параметров)

Ставится просто brew install dust

Давайте пофантазируем.

Что, если сделать свой отдельный Go, который бы транспилировался в обычный? как TS -> JS

Я бы добавил туда как минимум две вещи, которые точно никогда не появятся в Go, и половине людей там и не нужны:

1. Сахар для обработки ошибок (как-нибудь как в Расте, чтобы обработка была всё еще явной, но синтаксически попроще). Плюс синтаксис для ловли паник тоже попроще.

2. Добавил бы немного structured concurrency: запретил бы голый вызов команды go. Синтаксически заставить дожидаться завершения горутины в той же функции, где она была запущена.

Может, еще с каналами что-то намутить, чтобы заставить их закрывать примерно там же, где в них шла запись (в том же пакете?)

Тогда это получится язык в 10 раз более читаемый и в 10 раз менее запутанный в вопросах concurrency

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

Как делить на модули, когда нужно или не нужно использовать микросервисы, гексагональную архитектуру и т.д. Что важнее: гибкость/универсальность кода или простота.

TLDR: используйте сложные трюки только там, где они действительно нужны.

https://github.com/zakirullin/cognitive-load

В догонку к предыдущему посту про гибкость vs простота. В языке Go очень интересно сделаны интерфейсы.

Например, есть какой-то класс (точнее структура с методами) с методом getWeather(city), который является обёрткой над внешним сервисом погоды.

type WeatherService struct {
    apiKey string
}

func (w *WeatherService) GetWeather(city string) (string, error) {
    // http вызов внешнего API
    return "Sunny", nil
}

Мы можем такой класс использовать в каком-то коде, где на основании погоды происходят различные вычисления.

type WeatherAnalyzer struct {
    weatherService *WeatherService // конкретный класс
}

func (wa *WeatherAnalyzer) AnalyzeWeather(city string) string {
    weather, err := wa.weatherService.GetWeather(city)
    if err != nil {
        return "Unable to analyze weather"
    }
    if weather == "Sunny" {
        return "Great day for a picnic!"
    }
    return "Maybe stay indoors"
}

// Использование
func main() {
    ws := &WeatherService{apiKey: "some-api-key"}
    wa := &WeatherAnalyzer{weatherService: ws}
    result := wa.AnalyzeWeather("New York")
    fmt.Println(result)
}

И тут мы ВНЕЗАПНО поняли, что покрывать тестами это неудобно (ибо внешние вызовы), и лучше бы написать интерфейс, чтобы потом его замокать. Или у нас вдруг появился еще один сервис погоды, и нужен интерфейс. Так вот, в Go достаточно просто ПО МЕСТУ добавить интерфейс с описанием нужных в этом месте методов, а сам класс погоды останется неизменным.

Вот как это будет выглядеть:

// WeatherService остается без изменений

type WeatherProvider interface {
    GetWeather(city string) (string, error)
}

type WeatherAnalyzer struct {
    weatherProvider WeatherProvider
}

func (wa *WeatherAnalyzer) AnalyzeWeather(city string) string {
    weather, err := wa.weatherProvider.GetWeather(city)
    if err != nil {
        return "Unable to analyze weather"
    }
    if weather == "Sunny" {
        return "Great day for a picnic!"
    }
    return "Maybe stay indoors"
}

Потому что в отличие от Java/PHP/etc не нужно писать что класс имплементирует что-то там. Если у класса есть методы такие же как в интерфейсе, то он подходит под сигнатуру

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

Теперь мы можем легко создать мок для тестирования (упрощенный пример)

type MockWeatherProvider struct {
    MockWeather string
}

func (m *MockWeatherProvider) GetWeather(city string) (string, error) {
    return m.MockWeather, nil
}

func TestWeatherAnalyzer(t *testing.T) {
    mockProvider := &MockWeatherProvider{MockWeather: "Sunny"}
    analyzer := &WeatherAnalyzer{weatherProvider: mockProvider}
    
    result := analyzer.AnalyzeWeather("Test City")
    expected := "Great day for a picnic!"
    
    if result != expected {
        t.Errorf("Expected %s, but got %s", expected, result)
    }
}

У этого конечно есть и недостатки.

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

FizzBuzz Enterprise Edition

Думаю, все знают задачку Fizz Buzz (выведи Fizz, если число делится на 3, Buzz, если на 5, FizzBuzz если на 3 и на 5). Посмотрите, как делают эту задачу серьёзные люди. Для серьёзного бизнеса. Какие стратегии, фабрики, интерфейсы и всё такое.

Это настоящее пособие по паттернам, а паттерны - это язык, облегчающий общение разработчиков

Гоферы, пройдите опрос 2024

Прошлогодний опрос показал, что гошники в основном бывшие пыхари, и от языка хотят они одного: улучшения обработки ошибок :)

иногда комментарии в коде очень важны