DEV Community: Yaroslav Podorvanov

The Goroutine Temptation. Examples of goroutine usage where they are actually unnecessary

Yaroslav Podorvanov — Thu, 02 Apr 2026 17:21:57 +0000

This is a compact collection of examples where goroutines are actually unnecessary.

Background — just add "go"

Go makes it easy to parallelize tasks like saving statistics, tracking online status, or similar background work — just add the go keyword.
This simplicity helps you focus on business logic, but sometimes leads to mindlessly adding go before tasks that can be parallelized but don't need to be.

Example 1: launching a goroutine at the end of a goroutine

package main

import (
    "fmt"
    "log"
    "net/http"
    "time"
)

func endLongtimeAction(now int64) {
    time.Sleep(time.Microsecond)

    // some logic
    log.Printf("endLongtimeAction %d", now)
}

func longtimeAction(now int64) {
    time.Sleep(time.Microsecond)

    // some logic
    log.Printf("longtimeAction    %d", now)

    // useless start goroutine
    go endLongtimeAction(now)
}

func hello(w http.ResponseWriter, r *http.Request) {
    // useful start goroutine
    go longtimeAction(time.Now().UnixNano())

    fmt.Fprintf(w, "hello\n")
}

func main() {
    http.HandleFunc("/hello", hello)

    log.Printf("start server on port 8090")

    http.ListenAndServe(":8090", nil)
}

The goroutine before calling endLongtimeAction is unnecessary — it's the last thing longtimeAction does anyway.

Example 2: using a goroutine for a simple action

Here's a similar hello handler where AddView is launched in a goroutine:

func hello(w http.ResponseWriter, r *http.Request) {
    go AddView(fontThemeID(), country(r))

    fmt.Fprintf(w, "hello\n")
}

AddView is just a simple buffer write:

import "sync"

type FontThemeKey struct {
    FontThemeID uint8
    Country     string
}

type FontThemeValue struct {
    ViewCount     uint32
    RegisterCount uint32
}

var (
    fontThemeBuffer = make(map[FontThemeKey]FontThemeValue)
    fontThemeMutex  sync.Mutex
)

func AddView(fontThemeID uint8, country string) {
    var key = FontThemeKey{
        FontThemeID: fontThemeID,
        Country:     country,
    }

    fontThemeMutex.Lock()
    defer fontThemeMutex.Unlock()

    var value = fontThemeBuffer[key]
    value.ViewCount += 1
    fontThemeBuffer[key] = value
}

func Flush() error {
    return store(swap())
}

func swap() map[FontThemeKey]FontThemeValue {
    fontThemeMutex.Lock()
    defer fontThemeMutex.Unlock()

    var result = fontThemeBuffer
    fontThemeBuffer = make(map[FontThemeKey]FontThemeValue, len(result))
    return result
}

func store(map[FontThemeKey]FontThemeValue) error {
    // store to stats

    return nil
}

Let's write a simple benchmark to check whether go actually speeds things up here:

import (
    "sync/atomic"
    "testing"
)

const (
    fontThemeCount = 15
)

var (
    fixtureCountries     = []string{"C1", "C2", "C3", "C4", "C5", "C6", "C7", "C8"}
    fixtureCountryLength = uint32(len(fixtureCountries))
)

func reset() {
    fontThemeBuffer = make(map[FontThemeKey]FontThemeValue)
}

func BenchmarkAddView(b *testing.B) {
    reset()

    var index uint32

    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            var i = atomic.AddUint32(&index, 1)

            AddView(uint8(i%fontThemeCount), fixtureCountries[i%fixtureCountryLength])
        }
    })
}

func BenchmarkAddViewExtraGoroutine(b *testing.B) {
    reset()

    var index uint32

    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            var i = atomic.AddUint32(&index, 1)

            // useless goroutine
            go AddView(uint8(i%fontThemeCount), fixtureCountries[i%fixtureCountryLength])
        }
    })
}

Benchmark results:

Test name	Iterations	Avg time per iteration	Memory allocated
AddView	6413756	185 ns/op	0 B/op
AddViewExtraGoroutine	2628880	403 ns/op	58 B/op

The extra goroutine only slowed things down.

Example 3: goroutine by template

On a product page you need to render two blocks: "recommendations / similar items" and "bought together". Fetching them in parallel makes sense:

func ExtraGoodCodes(goodCode uint32) ([]uint32, []uint32) {
    var wg = new(sync.WaitGroup)

    var (
        recommendations []uint32
        supplies        []uint32
    )

    wg.Add(1)
    go func() {
        recommendations = getRecommendationGoods(goodCode)

        wg.Done()
    }()

    wg.Add(1)
    go func() {
        supplies = getSupplyGoods(goodCode)

        wg.Done()
    }()

    wg.Wait()

    return recommendations, supplies
}

The logic is correct, but one goroutine can be removed — the main goroutine can do one of the two calls directly:

func ExtraGoodCodes(goodCode uint32) ([]uint32, []uint32) {
    var wg = new(sync.WaitGroup)

    var (
        recommendations []uint32
        supplies        []uint32
    )

    wg.Add(1)
    go func() {
        recommendations = getRecommendationGoods(goodCode)

        wg.Done()
    }()

    supplies = getSupplyGoods(goodCode)

    wg.Wait()

    return recommendations, supplies
}

Epilogue

All of these examples came from real code I encountered during development. This article was originally written in Ukrainian five years ago — published on DOU — but the patterns are still just as common today.

If you're working with Go in production and want to see which product companies use it, check out ReadyToTouch — Go companies.

I'd be curious in the comments: which of these have you seen in the wild?

How to Switch to Go, Rust, Elixir, or Any Modern Backend Stack

Yaroslav Podorvanov — Wed, 04 Mar 2026 11:01:38 +0000

Back in early 2018, I switched from PHP to Go. At the time I had 6 years of total experience — 4.5 of them with PHP. Three years later, I wrote about switching in Ukrainian. Three years after that, I wrote another post about switching — again in Ukrainian. Now I'm building my own job search project and keep getting the same question on LinkedIn: "How do I switch to [Go / Rust / Elixir / pick your stack]?"

A couple of days ago I ran a poll about this on LinkedIn. I didn't wait for it to finish — 85% interest out of 118 votes made it obvious enough. Act when it's clear.

This post was originally written in Ukrainian and translated into English with Claude.

So here's my answer — for everyone who has asked, and for everyone who will ask.

It's Two Steps, Not One

A successful stack switch breaks down into two big steps:

Learn the technology
Find a job with that technology

Most people focus only on the first step and treat the second one as something that will figure itself out. It won't. Both steps need deliberate effort — and ideally, they overlap.

Step 1: Learn the Technology (Without Overthinking It)

Your first move will probably be a little lazy — and that's fine. You'll watch a few free courses to get a feel for whether you actually enjoy the language, read a popular book or two, maybe solve some exercises. That's a perfectly valid start.

Just don't fall into the trap of searching for the perfect learning path. It doesn't exist. The path is personal. Whether you learn through TDD, side projects, competitive programming, or just reading docs — it's all valid as long as you're actually building things.

The goal at this stage isn't mastery. It's enough familiarity to start a real project.

Step 2: Build a Project That Actually Helps You Get Hired

Before you start applying, you need hands-on experience with the new stack. The fastest way to get it is building your own project. But not just any project — one that's strategically aligned with the companies you want to work for.

Start with a Company List

Let's say you want to switch to Rust and you live in Brazil. (Swap in your own country and technology as you read.)

Your first task is to research and build a list of companies that hire — or have hired — Rust developers. Don't look only at companies with open positions right now. Job listings come and go. By the time you finish your project, those roles might be gone. Companies that hired Rust engineers in the past are very likely to hire again.

Build a spreadsheet with columns like:

Company name
Their products and domains
Tech stack, databases, cloud providers they use
Do they have an office in Brazil?
If international — do they have current or former employees from Brazil?

Use LinkedIn Smarter

To find companies with Brazilian employees, use LinkedIn's People Search with a company filter and set "Universities" to well-known local technical universities. This helps you identify which international companies already have a pipeline into your local market.

Choose Your Domain Based on What You Find

Once you've analyzed your list, look for patterns. Maybe three companies use GCP, ScyllaDB, and build chat-related products. That's your signal.

Start building a demo chat app in Rust using Axum and ScyllaDB, deployed to GCP via GitHub Actions. Build the frontend yourself or with help from Claude / Gemini / ChatGPT. Make the chat functional by using a GenAI API to generate responses — it makes the demo interactive and impressive. Aim to keep everything on the free tier.

While you're building, google common problems in chat systems — scaling, message ordering, presence indicators. Understanding these issues will make you a much stronger candidate in interviews.

Connect With People in Parallel

While coding, start adding people on LinkedIn who work at your target companies — engineers, tech leads, engineering managers. Always include a short personal note: something like "I'm exploring opportunities at [Company] and would love to connect. If you have a referral program, I'd appreciate a heads up when the right role opens."

Don't push. Don't follow up aggressively. Just plant the seed.

When your project is ready, reach out to these contacts again and ask if they'd be willing to refer you — assuming there's an open position that fits.

Step 3: The Job Search Reality Check

Be Ready for a Title Downshift

If you're currently a Senior engineer in your old stack, switching to a new one often means entering the market as a Middle-level developer — or at most, a weak Senior. This is normal and expected. Your overall engineering experience still counts, but your hands-on depth in the new stack is limited.

Accepting this reality upfront saves a lot of frustration and helps you set realistic salary expectations. Think of it as a temporary investment — most people recover their seniority level within 1–2 years.

Update Your Resume Before You Start Applying

Don't wait until you have a job offer to update your resume. Do it early and make the project the centerpiece.

Lead with the project. Put your new-stack project near the top of the resume, under a clear "Projects" section. Include a link to the live demo and the GitHub repo.
Describe it with impact. Don't just list technologies. Explain what the project does, what problems it solves, and what you learned — especially anything related to domain challenges (e.g., real-time message delivery, connection handling).
Reframe your existing experience. Highlight transferable skills — system design, architecture decisions, working with databases, API design — even if they were done in a different language.
Keep your old stack on the resume. It shows depth and maturity. Just make clear that your focus going forward is the new stack.

Bonus: Share What You Learn

While building the project, keep a running note of what you discovered — tricky parts of the language, surprising behavior, useful libraries, things that weren't covered in any tutorial.

By the time you're done, you might have enough material for a post in the Rust (or Go, or Elixir) community on Reddit or here on dev.to. That kind of post builds credibility, gets you visibility in the exact community you're trying to join, and sometimes leads directly to job opportunities.

Summary

Learn enough to start building.
Research which companies hire in your stack and location.
Build a project aligned with those companies' tech and domains.
Connect with people at those companies while you build.
Accept that a title downshift might happen — it's temporary.
Update your resume with the project front and center.
Share what you learned — it compounds over time.

The switch isn't magic, but it's also not as mysterious as it seems. The main thing is to stop optimizing the learning phase and start building something real.

My Own Switch, in Numbers

I built an API for a music player as my side project during the switch. It helped me qualify for Go roles — but not for the first one. There I made a mistake: I went from Senior PHP directly to Junior Go.

Six months later I joined another company as Middle Go — and that time I got hired without a technical interview. Their Senior engineer reviewed my music player project and that was enough. Six months after that I had the Senior Go title back. So in total, recovering the seniority level took about a year. But honestly, I didn't feel like a Senior Go engineer until about three years in.

The title downshift is real. The recovery is also real. And the project matters more than you think — it's what got me in the door.

Cross-Linking Your Project Properly

Once your project is live, don't leave it as an isolated repo. Connect everything:

GitHub profile: pin the repository, and in your profile README add a link to the live project with a short description of what it does and what stack it uses.
LinkedIn profile: add a link to your GitHub profile and to the live project — either in the Featured section or directly in your About.
Live project header: add a GitHub repository link with a star button — so anyone using the demo can easily find and star the repo.
Live project footer: add a GitHub repository link with a star button, and a link to your LinkedIn profile.

This creates a loop. Recruiters reviewing your resume can visit the live project, then follow through to LinkedIn — confirming for themselves that the project is genuinely yours. Engineers who discover your site can star the repo and find you on LinkedIn, or the other way around. This cross-linking tells employers: this person is who they say they are.

A few more things worth doing:

Add the live project URL to the GitHub repo description — it shows up right under the repo name and is the first thing people see.
Write a solid README for the repo — explain what the project does, how to run it locally, and what stack it uses. This is often the first thing a technical interviewer will read.
Pin a post about the project on LinkedIn — a short post with a screenshot, a link, and two sentences about what you built. Pinned posts stay visible on your profile indefinitely.
Add the project to your LinkedIn Experience or Projects section — not just in About. Some recruiters scan sections, not prose.

Research Your Own Path

Part of what I've described here I stumbled into by accident. Later I figured out why it worked, turned it into a personal instruction, and published it — to preserve it better and get some criticism.

Treat this article the same way. Don't follow it blindly. Use it as a starting point, then pay attention to what actually moves the needle for you — your market, your stack, your situation. A path you've researched and adapted yourself will always outperform one you borrowed from someone else.

A couple more tips. If you can't build a frontend but have a little budget — hire a junior designer and a junior developer part-time, someone without experience. When you review resumes yourself, you'll realize that most of the time you only care about one thing: whether the candidate can do the job. Everything else fades. It was like that for me too — and it changed how I looked at my own resume.

And if you're too honest for your own good — you'll still need to polish your resume enough to get invited to an interview. At FAANG-style behavior interviews, for example, you're expected to have conflict resolution stories ready. Prepare them in advance. If you haven't had dramatic conflicts, find the closest thing and shape it into a story.

I'm currently building ReadyToTouch — a job search tool for developers. If you have questions about switching stacks or job searching in tech, feel free to ask in the comments.

Face recognition with Golang

Yaroslav Podorvanov — Sat, 14 Nov 2020 10:28:52 +0000

Привіт, мене звати Ярослав. Ця стаття буде про практичне використання face recognition в Golang.

Стандартна задача — розпізнати людей на фотографії

У нас є фотографія та функція Recognize, яка знаходить обличчя на фотографії і для кожного знайденого обличчя формує вектор — 128-розмірний масив чисел [128]float, що в коді називається descriptor.

type Descriptor [128]float32

функція Recognize отримує картинку і повертає знайдені обличчя

import "image"

// Descriptor holds 128-dimensional feature vector.
type Descriptor [128]float32

type Face struct {
    Rectangle  image.Rectangle
    Descriptor Descriptor
    Shapes     []image.Point
}

func Recognize(imgData []byte) (faces []Face, err error) {
    // logic

    return
}

між двома векторами можна порахувати відстань (Евклідову відстань вивчають у школі)
а ось так розрахунок відстані виглядає на Golang:

import (
    "math"
)

type Descriptor [128]float32

func SquaredEuclideanDistance(d1 Descriptor, d2 Descriptor) (sum float64) {
    for i := range d1 {
        sum = sum + math.Pow(float64(d2[i]-d1[i]), 2)
    }

    return sum
}

Чим більше схожі обличчя, тим менша відстань між їх векторами.

Для розробки системи розпiзнавання обличь відомих людей, необхiдно завантажити вiдповiднi фотогорафії та перетворити їх у вектори.

Тепер, коли ви захочете дізнатися, хто на фотографії — завантажте фотографію, система сформує вектор, порівняє вектор з кожним збереженим вектором, знайде найближчий-найближчі та поверне вам імена (i фотографії) тих, кому належать найближчі вектори.

Вищевказаного буде достатньо для розуміння як працює розпізнавання.

Далі у статті буде йтися про підключення Golang бібліотеки github.com/Kagami/go-face з прикладами та поясненнями, як почати використовувати.

Вибір бібліотеки та її підключення

Пошук Google golang face recognition повернув дві бібліотеки:

github.com/esimov/pigo (2900+ stars)
github.com/Kagami/go-face (500+ stars)

Я переглянув обидві і вибрав github.com/Kagami/go-face найбiльш зрозумiлу для себе документацію, а також ознайомився зi статтею Face recognition with Go.

Бібліотека github.com/Kagami/go-face є обгорткою над C++ бібліотекою dlib.

Щоб Golang міг використовувати dlib — його треба встановити.
Для Ubuntu:

sudo apt-get install libdlib-dev libblas-dev liblapack-dev libjpeg-turbo8-dev

Як встановити dlib для macOS та Winodws зазначено в документації README.md.

Також dlib потребує файлів з натренованими моделями, ці моделі доступні на офіційному репозиторії github.com/davisking/dlib-models або github.com/Kagami/go-face-testdata.
Тепер завантажимо моделі:

mkdir -p ./testdata/models
wget https://github.com/Kagami/go-face-testdata/raw/master/models/shape_predictor_5_face_landmarks.dat -P ./testdata/models
wget https://github.com/Kagami/go-face-testdata/raw/master/models/dlib_face_recognition_resnet_model_v1.dat -P ./testdata/models
wget https://github.com/Kagami/go-face-testdata/raw/master/models/mmod_human_face_detector.dat -P ./testdata/models

tree ./testdata/models/

./testdata/models/
├── dlib_face_recognition_resnet_model_v1.dat
├── mmod_human_face_detector.dat
└── shape_predictor_5_face_landmarks.dat

Я завантажив з інтернету jennifer.jpg і написав приклад, який виводить дескриптори.

package main

import (
    "github.com/Kagami/go-face"
    "io/ioutil"
    "log"
    "time"
)

func main() {
    var recognizerInitStartTime = time.Now()

    // Init the recognizer.
    rec, err := face.NewRecognizer("./testdata/models")
    if err != nil {
        log.Fatalf("Can't init face recognizer: %v", err)
    }
    // Free the resources when you're finished.
    defer rec.Close()

    log.Printf("recognizer init by %s", time.Since(recognizerInitStartTime))

    var jenniferImageBytes, readFileErr = ioutil.ReadFile("./jennifer.jpg")
    if readFileErr != nil {
        // log.Fatalf call os.Exit(1)
        // so use log.Printf to defer rec.Close()
        log.Printf("Can't read file: %v", readFileErr)

        return
    }

    var recognizeStartTime = time.Now()
    var faces, recognizeErr = rec.Recognize(jenniferImageBytes)
    log.Printf("recognize faces by %s", time.Since(recognizeStartTime))

    if recognizeErr != nil {
        log.Printf("Can't recognize: %v", recognizeErr)

        return
    }

    log.Printf("found %d faces", len(faces))

    for i, face := range faces {
        log.Printf("face %d with descriptor %+v", i, face.Descriptor)
    }
}

go run main.go

17:22:00 recognizer init by 371.305232ms
17:22:00 recognize faces by 316.697968ms
17:22:00 found 1 faces
17:22:00 face 0 with descriptor [-0.07678388 0.15807864 0.14382923 -0.07904527 -0.11428883 -0.029490437 0.058661476 -0.0933703 0.23498747 -0.054770716 0.24722381 -0.05858693 -0.28161827 -0.00729264 0.053299718 0.15644383 -0.15317412 -0.09491905 -0.11324714 0.015937451 0.017232804 0.02061552 0.09107592 0.08736397 -0.17142092 -0.3387704 -0.040354054 -0.0375154 0.068538606 -0.13365544 0.03331705 0.09273607 -0.17582977 -0.06855342 0.028308533 0.027136123 -0.10719579 -0.11425108 0.23959376 -0.025176954 -0.25584993 -0.08564242 0.07274324 0.28109437 0.1977994 0.0743362 0.04528319 -0.15180072 0.11090667 -0.3346209 0.03862732 0.14867145 -0.052644238 0.0695322 0.056489225 -0.16142687 0.031142544 0.091048405 -0.24351647 0.071151696 0.13612525 -0.1243305 -0.00016226899 -0.090171695 0.28420573 0.05841827 -0.12638493 -0.11757094 0.14316459 -0.1568535 -0.057871066 0.09184233 -0.09624884 -0.18405873 -0.2898923 -0.03938524 0.351529 0.14347278 -0.14661624 0.037677716 -0.1709492 -0.030889995 0.019944552 0.12754735 0.011989551 -0.060295634 -0.10107601 0.022347813 0.2718173 -0.11187582 0.040455934 0.29762152 0.057943583 -0.06804431 -0.051001664 0.012894538 -0.20557034 0.024265196 -0.18289387 -0.057812028 0.023129724 0.035144385 0.05509291 0.1335184 -0.27161613 0.2431183 0.043914706 -0.059160654 0.07033479 -0.074724026 -0.106148675 -0.10262138 0.15065585 -0.2624043 0.22501433 0.15340629 0.11548248 0.12753347 0.05119327 0.093256816 0.044141423 0.019079404 -0.08248548 -0.03165059 0.09458799 -0.055271063 0.061118975 0.023323089]

Тепер я завантажив ще й фотографії jennifer-aniston.jpg та jennifer-love-hewitt.jpg.
Напишемо код, який порівняє попередньо завантежену jennifer.jpg з jennifer-aniston.jpg та jennifer-love-hewitt.jpg.

package main

import (
    "fmt"
    "github.com/Kagami/go-face"
    "io/ioutil"
    "log"
    "time"
)

func main() {
    rec, err := face.NewRecognizer("./testdata/models")
    if err != nil {
        log.Fatalf("Can't init face recognizer: %v", err)
    }
    defer rec.Close()

    var (
        jenniferFace           = mustRecognizeSingleFile(rec, "./jennifer.jpg")
        jenniferAnistonFace    = mustRecognizeSingleFile(rec, "./jennifer-aniston.jpg")
        jenniferLoveHewittFace = mustRecognizeSingleFile(rec, "./jennifer-love-hewitt.jpg")
    )

    var (
        jenniferAnistonDistance    = face.SquaredEuclideanDistance(jenniferAnistonFace.Descriptor, jenniferFace.Descriptor)
        jenniferLoveHewittDistance = face.SquaredEuclideanDistance(jenniferLoveHewittFace.Descriptor, jenniferFace.Descriptor)
    )

    log.Printf("Jennifer with Jennifer Aniston     = %.8f", jenniferAnistonDistance)
    log.Printf("Jennifer with Jennifer Love Hewitt = %.8f", jenniferLoveHewittDistance)
}

func mustRecognizeSingleFile(rec *face.Recognizer, filename string) face.Face {
    var imageBytes, readFileErr = ioutil.ReadFile(filename)
    if readFileErr != nil {
        panic(fmt.Sprintf("Can't read file %s: %v", filename, readFileErr))
    }

    var recognizeStartTime = time.Now()
    var faces, recognizeErr = rec.Recognize(imageBytes)
    log.Printf("recognize faces on %s by %s", filename, time.Since(recognizeStartTime))

    if recognizeErr != nil {
        panic(fmt.Sprintf("Can't recognize %s: %v", filename, recognizeErr))
    }

    var length = len(faces)
    if length != 1 {
        panic(fmt.Sprintf("Expected 1 face on photo %s, got %d faces", filename, length))
    }

    return faces[0]
}

go run main.go

18:12:00 recognize faces on ./jennifer.jpg by 313.49215ms
18:12:00 recognize faces on ./jennifer-aniston.jpg by 342.010394ms
18:12:00 recognize faces on ./jennifer-love-hewitt.jpg by 294.416138ms
18:12:00 Jennifer with Jennifer Aniston     = 0.35406203
18:12:00 Jennifer with Jennifer Love Hewitt = 0.64027529

Збереження 128-розмірного вектору в БД або файл

Оскiльки розпізнання кожної фотографії це 200-300 мс — то буде правильно завчасно підготувати базу дескрипторів.

Майже усі SQL бази даних можуть зберегти масив байтів, а дескриптор [128]float32 можна перетворити в [512]byte за допомогою функції math.Float32bits.
Ось приклади функцій, які перетворюють дискриптор в масив байтів і назад:

func DescriptorToBytes(descriptor [128]float32) [512]byte {
    var result [512]byte

    var buffer = result[:0]

    for i := 0; i < 128; i++ {
        var bits uint32 = math.Float32bits(descriptor[i])

        buffer = append(
            buffer,
            byte(bits),
            byte(bits>>8),
            byte(bits>>16),
            byte(bits>>24),
        )
    }

    return result
}

func BytesToDescriptor(bytes [512]byte) [128]float32 {
    var result [128]float32

    var i = 0

    for j := 0; j < 512; j += 4 {
        result[i] = math.Float32frombits(
            uint32(bytes[j]) +
                uint32(bytes[j+1])<<8 +
                uint32(bytes[j+2])<<16 +
                uint32(bytes[j+3])<<24,
        )

        i += 1
    }

    return result
}

Або можете інакше серіалізувати в масив байтів, наприклад, через protobuf.

Використання бази дескрипторів

В нас є функція, яка читає з бази дескриптори і повертає їх:

type UserDescriptor struct {
    ID         uint32
    UserID     uint32
    PhotoPath  string
    Descriptor [128]float32
}

func FetchUserDescriptors() ([]UserDescriptor, error) {
    var result []UserDescriptor

    // ...

    return result, nil
}

звісно, у користувача може бути багато фотографій

Якщо нам треба знайти тільки одного користувача по фотографії — то можемо скористатись вже готовою функцією Classify яка є в dlib.

func FindNearestUserID(rec *face.Recognizer, users []UserDescriptor, input [128]float32) uint32 {
    var (
        length     = len(users)
        categories = make([]int32, length)
        samples    = make([]face.Descriptor, length)
    )

    for i, f := range users {
        samples[i] = f.Descriptor
        categories[i] = int32(f.UserID)
    }

    rec.SetSamples(samples, categories)

    var userID = rec.Classify(input)

    return uint32(userID)
}

Також є можливість шукати і фільтрувати за максимальною відстанню через ClassifyThreshold:

// if find return userID, otherwise return -1
func FindThresholdUserID(rec *face.Recognizer, users []UserDescriptor, input [128]float32, tolerance float32) int {
    var (
        length     = len(users)
        categories = make([]int32, length)
        samples    = make([]face.Descriptor, length)
    )

    for i, f := range users {
        samples[i] = f.Descriptor
        categories[i] = int32(f.UserID)
    }

    rec.SetSamples(samples, categories)

    var userID = rec.ClassifyThreshold(input, tolerance)

    return userID
}

Глянемо реалізацію C++ функції Classify, яка повертає одного найближчого користувача, та перепишемо на Golang, щоб знаходити найближчих схожих користувачів.

#include <unordered_map>
#include <dlib/graph_utils.h>
#include "classify.h"

int classify(
    const std::vector<descriptor>& samples,
    const std::vector<int>& cats,
    const descriptor& test_sample,
    float tolerance
) {
    if (samples.size() == 0)
        return -1;

    std::vector<std::pair<int, float>> distances;
    distances.reserve(samples.size());
    auto dist_func = dlib::squared_euclidean_distance();
    int idx = 0;
    for (const auto& sample : samples) {
        float dist = dist_func(sample, test_sample);
        if (tolerance < 0 || dist <= tolerance) {
            distances.push_back({cats[idx], dist});
        }
        idx++;
    }

    if (distances.size() == 0)
        return -1;

    std::sort(
        distances.begin(), distances.end(),
        [](const auto a, const auto b) { return a.second < b.second; }
    );

    int len = std::min((int)distances.size(), 10);
    std::unordered_map<int, std::pair<int, float>> hits_by_cat;
    for (int i = 0; i < len; i++) {
        int cat_idx = distances[i].first;
        float dist = distances[i].second;
        auto hit = hits_by_cat.find(cat_idx);
        if (hit == hits_by_cat.end()) {
            hits_by_cat[cat_idx] = {1, dist};
        } else {
            hits_by_cat[cat_idx].first++;
        }
    }

    auto hit = std::max_element(
        hits_by_cat.begin(), hits_by_cat.end(),
        [](const auto a, const auto b) {
            auto hits1 = a.second.first;
            auto hits2 = b.second.first;
            auto dist1 = a.second.second;
            auto dist2 = b.second.second;
            if (hits1 == hits2) return dist1 > dist2;
            return hits1 < hits2;
        }
    );
    return hit->first;
}

Ось переписана на Golang функція, яка повертає найближчих користувачів по фотографії:

type UserDescriptorDistance struct {
    UserDescriptor
    Distance float64
}

type UserDescriptorDistanceList []UserDescriptorDistance

func (l UserDescriptorDistanceList) Len() int {
    return len(l)
}

func (l UserDescriptorDistanceList) Less(i, j int) bool {
    return l[i].Distance < l[j].Distance
}

func (l UserDescriptorDistanceList) Swap(i, j int) {
    l[i], l[j] = l[j], l[i]
}

func FindNearestUsers(rec *face.Recognizer, users []UserDescriptor, input [128]float32, tolerance float64) []UserDescriptorDistance {
    var result []UserDescriptorDistance

    if tolerance > 0 {
        for _, user := range users {
            var distance = face.SquaredEuclideanDistance(user.Descriptor, input)

            if distance < tolerance {
                result = append(result, UserDescriptorDistance{
                    UserDescriptor: user,
                    Distance:       distance,
                })
            }
        }
    } else {
        result = make([]UserDescriptorDistance, 0, len(users))

        for _, user := range users {
            var distance = face.SquaredEuclideanDistance(user.Descriptor, input)

            result = append(result, UserDescriptorDistance{
                UserDescriptor: user,
                Distance:       distance,
            })
        }
    }

    sort.Sort(UserDescriptorDistanceList(result))

    return result
}

Застереження

dlib supports a lot of image formats (JPEG, PNG, GIF, BMP, DNG) but go-face currently implements only JPEG, would be good to support more.

Щоб працювати з PNG фотографіями, вам треба буде використати стандартну Golang бібліотеку image та перетворити фото в JPEG. В мережі повно прикладів як це зробити.
Або ж додати підтримку PNG до github.com/Kagami/go-face.

Коли пробував розвернути на DigitalOcean, то при першому запуску з'їло усю оперативну пам'ять, тому для першого запуску підняв до 4 GB щоб зібрало і C++, а потім повернув до 1 GB.

Епілог

Рекомендую прочитати оригінальну статтю Face recognition with Go.
Все, що було описано в статті, я друзям розповів за пару хвилин, а ось написання тексту — майже робочий день.

Обережно кодогенерація

Yaroslav Podorvanov — Mon, 21 Sep 2020 17:15:51 +0000

Раніше вже писав про збільшення швидкодії та зменшення використання пам'яті після використання кодогенерації і ця історія має продовження, а саме розбір помилок.

Protobuf, перша помилка яка показала себе через пару тижнів після змін в коді

В проекті ми використовуємо офіційну бібліотеку Protobuf github.com/protocolbuffers/protobuf, яка підчас серіалізації використовує рефлексію і будує слайс байтів через append.
А потім я дізнався про "Protocol Buffers for Go with Gadgets" github.com/gogo/protobuf, бібліотеку-fork яка генерує додатковий код щоб прибрати рефексію підчас серіалізації і вже записує в слайс байтів по індексу бо так швидше.
Коли змінював одну бібліотеку на іншу то важливим вважав що стало працювати швидше і написані раніше тести пройшли успішно.
І все б було гаразд але в проекті існувала латка яка через пару тижнів після заміни перезапустила мікросервіс через паніку:

panic: runtime error: index out of range

Латка виглядала приблизно так:

import (
    google "gitlab.com/go-yp/go-warning-codegeneration/models/protos/google/advertisement"

    "github.com/golang/protobuf/proto"
)

func example() {
    var popup = &google.Popup{
        Id:      uuid(),
        Viewed:  true,
        Clicked: false,
    }

    // some deep nested function
    go func() {
        var content, err = proto.Marshal(popup)

        if err != nil {
            // log error

            return
        }

        // store to database
        store(content)
    }()

    // some delay with other actions

    // @temporary hack
    go func() {
        popup.Clicked = true

        var content, err = proto.Marshal(popup)

        if err != nil {
            // log error

            return
        }

        // store to database again
        store(content)
    }()
}

І зі стандартною бібліотекою латка працювала без паніки для мікросервісу який працює постійно:

import (
    "testing"

    google "gitlab.com/go-yp/go-warning-codegeneration/models/protos/google/advertisement"

    "github.com/golang/protobuf/proto"
)

const (
    n = 1000000
)

func TestGoogleProtoMarshal(t *testing.T) {
    for i := 0; i < n; i++ {
        var popup = &google.Popup{
            Id:      uint32(i),
            Viewed:  true,
            Clicked: false,
        }

        // some deep nested function
        go func() {
            _, _ = proto.Marshal(popup)
        }()

        // @temporary hack
        go func() {
            popup.Clicked = true

            _, _ = proto.Marshal(popup)
        }()
    }
}

А от з github.com/gogo/protobuf при аналогічному тесті вже видає паніку.
Якщо розглянути згенерований код:

func (m *Popup) Marshal() (dAtA []byte, err error) {
    size := m.Size()
    dAtA = make([]byte, size)
    n, err := m.MarshalToSizedBuffer(dAtA[:size])
    if err != nil {
        return nil, err
    }
    return dAtA[:n], nil
}

func (m *Popup) MarshalToSizedBuffer(dAtA []byte) (int, error) {
    i := len(dAtA)

    //...

    if m.Clicked {
        i--
        dAtA[i] = 1
        i--
        dAtA[i] = 0x18
    }

    //...

    return len(dAtA) - i, nil
}

то стає зрозуміло що розрахунок ємності слайсу відбувався за умов m.Clicked = false, а серіалізація за умов m.Clicked = true і таким чином отримав паніку "index out of range".
Звісно латку ми виправили і стало працювати навіть краще.

JSON, помилка у vendor бібліотеці

Бібліотека easyjson теж для серіалізації працює через додатковий код замість використання рефлексії.
Але після внесення в easyjson одної з оптимізацій, час від часу почали отримувати зламаний JSON, ось приклад тесту який покаже помилку.

package tests

import (
    "testing"

    "gitlab.com/go-yp/go-warning-codegeneration/models/jsons/easy"

    "github.com/stretchr/testify/require"

)

const (
    // language=JSON
    popupWithUnicodeContent = `{
        "title": "Some title with symbol \u201Dt",
        "description": "Any description"
    }`

    // language=JSON
    popupContent = `{
        "title": "Some title",
        "description": "Any description"
    }`
)

func TestEasyjsonUnmarshalJSON(t *testing.T) {
    content := make([]byte, 0, 1024)

    content = append(content[:0], popupWithUnicodeContent...)

    var popup easy.Popup

    unmarshalErr := popup.UnmarshalJSON(content)

    require.NoError(t, unmarshalErr)

    var expected = easy.Popup{
        Title:       "Some title with symbol \u201Dt",
        Description: "Any description",
    }

    require.Equal(t, expected, popup)

    content = append(content[:0], popupContent...)

    /**
    Failed:
    expected: easy.Popup{Title:"Some title with symbol ”t", Description:"Any description"}
    actual  : easy.Popup{Title:"Some title with symbol ”t", Description:" }y description"}
    */
    require.Equal(t, expected, popup)
}

В easyjson цю помилку вже виправили.

Висновки:

Звісно хочеться використовувати оптимізовані бібліотеки, але стандартні краще протестовані та мають менше помилок.
Приклади доступні в репозиторії.

Пошук в глибину на прикладі задачі Ханойської вежі

Yaroslav Podorvanov — Wed, 22 Jul 2020 16:25:43 +0000

Стаття орієнтована на спеціалістів які хочуть ознайомитись з Rust-ом або в майбутньому перекваліфікуватись на Rust-розробників, як і я.

Короткий переказ

Стаття буде про вирішення задачі "Ханойські вежі" через пошук в глибину, з використанням стандартних структур даних наявних в Rust з детальним описом що роблю і тому буде зрозуміла спеціалістам без досвіду з Rust-ом.
Будуть ілюстрації, налаштування Rust та створення першого проекту, а також написання тестів та пояснення деталей.
В кінці статті будуть посилання на навчальні матеріали а в коментарях відповім на питання стосовно статті.

За бажання можете відразу глянути репозиторій, а потім повернутись до читання статті.

Ханойські вежі

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

Щоб зрозуміти рішення задачі то почнемо з одного диску який перекладаємо з першого на третій стержень

тут мала б бути gif, але dev.to має обмеження

Для двох дисків:
перекладаємо верхній перший диск на другий стержень,
другий диск з першого на третій стержень,
перший диск з другого на третій стержень,
ось і все.

Для трьох дисків рішення рекурсивне: важаємо нижній диск за другий, а всі верхні диск за "один" і так само вирішуємо для них рекурсивно.

тут також мала б бути gif, але dev.to має обмеження

Число рухів для 1 диску = 1 раз перекладаємо диск
Число рухів для 2 дисків = 3, де 2 рази перекладаємо верхній диск і 1 раз нижній
Число рухів для N дисків має відносну формулу TN = 2 × TN-1 + 1
Число рухів для N дисків має абсолютну формулу TN = 2^N - 1

Звісно є й альтернативне рішення — просто перевернути картинку.

Пошук в глибину на прикладі задачі Ханойської вежі

Пошук у глибину (або Depth-first search або DFS) — алгоритм для обходу дерева, це класичне визначення з вікіпедії.
Пошук у глибину можна адаптувати для рішення задачі "Ханойської вежі", це одна з лабораторних робіт у студентів з напряму комп'ютерні науки.

Ми беремо початковий стан де N-дисків лежать на першому стержні та використовуючи правила гри будуємо всі можливі стани і так до досягнення стану коли всі диски будуть на третьому стержні.

Rust та створення першого проекту

Встановлення з офіційної сторінки Install Rust:

sudo apt update
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env

І перевіряємо що був встановлений сам installer rustup, компілятор rustc та менеджер пакетів cargo:

rustup --version
# rustup 1.21.1 (7832b2ebe 2019-12-20)
rustc --version
# rustc 1.44.1 (c7087fe00 2020-06-17)
cargo --version
# cargo 1.44.1 (88ba85757 2020-06-11)

Створення першого проекту через cargo init з назвою dfs-tower-of-hahoi:

cargo init --bin dfs-tower-of-hahoi
# Created binary (application) package

Проект створений і тепер глянемо що в ньому є:

tree dfs-tower-of-hahoi

dfs-tower-of-hahoi
├── Cargo.toml
└── src
    └── main.rs

бачимо два файли, перший main.rs з мініальним кодом для запуску, та другий Cargo.toml з налаштуванням залежностей:

cat dfs-tower-of-hahoi/src/main.rs dfs-tower-of-hahoi/Cargo.toml

fn main() {
    println!("Hello, world!");
}

[package]
name = "dfs-tower-of-hahoi"
version = "0.1.0"
authors = ["Yaroslav"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

розширення файлу .rs є скороченням від Rust, також є домен .rs який належить Сербії та із-за схожості часто використовуються для Rust проектів, один з таких проектів це Actix.rs
розширення файлу .toml викорстовується для збереження налаштувань у форматі TOML (Tom's Obvious, Minimal Language)
тепер перейдемо в папку проекту і запустимо проект:

cd ./dfs-tower-of-hahoi
cargo run

і отримаємо в терміналі:

Hello, world!

як бачимо програма Hello, world! на Rust займає всього 3 лінії коду:

fn main() {
    println!("Hello, world!");
}

для вас знайомим буде функція main яка є в частині з C-подібних мов програмування: C, C++, Objective-C, Java, C#, а також Go

а от конструкція println! є новою, println! це макрос, це помітно з того що завершуються символом оклику "!"

макроси будуть знайомі C та C++ розробникам, в Rust-і макроси теж є, писати їх складніше, зате безпечніше із-за гігієни макросів

Починаємо рішення з вибору структур

Вже писав раніше, та повторюсь, нам треба описати початковий стан де N-дисків лежать на першому стержні SBEGIN та кінцевий стан де всі диски на останньому стержні SEND.

Потім на основі початкового стану SBEGIN формуємо всі можливі стани SNEXT 1-N (де N число стержнів), потім на основі станів SNEXT 1-N формуємо наступні стани і так далі, до моменту досягнення SEND.

Для початку нам треба описати стержень з якого будемо брати або класти верхній диск, як бачимо це опис структури LIFO.
В Rust є Vector який має потрібні нам методи pop() та push(), отож маємо структуру для стержня Rod:

struct Rod {
    disks: Vec<u8>,
}

А також структуру для опису стану стержнів (для простоти виберемо також Vector):

struct State {
    rods: Vec<Rod>,
}

тепер можемо об'явити початковий і кінцевий стан і спробуємо вивести в терміналі:

fn main() {
    let begin = State {
        rods: vec![
            Rod {
                disks: vec![3, 2, 1],
            },
            Rod { disks: vec![] },
            Rod { disks: vec![] },
        ],
    };

    let end = State {
        rods: vec![
            Rod { disks: vec![] },
            Rod { disks: vec![] },
            Rod {
                disks: vec![3, 2, 1],
            },
        ],
    };

    println!("Tower of Hanoi begin state {:?}", begin);
    println!("Tower of Hanoi end state {:?}", end);
}

тут для нас дві нові конструкції, перша це макрос vec!, а друга це заповнювач (placeholder) {:?} для виведення детальної інформації про зміну

ключове слово let потрібно щоб об'явити змінну (так само як і в JavaScript)

тепер через cargo run запустимо і отримаємо помилку в терміналі:

error[E0277]: `State` doesn't implement `std::fmt::Debug`
  --> src/main.rs:30:49
   |
30 |     println!("Tower of Hanoi begin state {:?}", begin);
   |                                                 ^^^^^ `State` cannot be formatted using `{:?}`
   |
   = help: the trait `std::fmt::Debug` is not implemented for `State`
   = note: add `#[derive(Debug)]` or manually implement `std::fmt::Debug`

як бачимо компітялор rustc каже що для виведення налагоджувальної інформації нам потрібно реалізувати типаж (trait) std::fmt::Debug, а також запропонував два варіанти рішення:

note: add `#[derive(Debug)]` or manually implement `std::fmt::Debug`

типаж std::fmt::Debug, як і інші типажі, схожий на інтерфейс в інших мовах програмування

pub trait Debug {
    fn fmt(&self, f: &mut Formatter<'_>) ->; Result;
}

почнемо з ручної (manually) реалізації типажу std::fmt::Debug:

use std::fmt::{Debug, Formatter, Result};
struct State {
    rods: Vec<Rod>,
}

impl Debug for State {
    fn fmt(&self, f: &mut Formatter) -> Result {
        return write!(f, "`manually debug with rods {}`", self.rods.len());
    }
}

в цьому коді ми імпортували потрібні нам пакети за допомогою конструкції use та реалізували типаж Debug
так в цьому коді ще багато нових конструкцій, але в данному випадку цей код є лише прикладом реалізації типажу через impl Debug for State
запустивши програму отримаємо очікуваний результат:

Tower of Hanoi begin state `manually debug with rods 3`
Tower of Hanoi end state `manually debug with rods 3`

Але можна зробити простіше, як і рекомендував компілятор, додавши атрибут derive з налаштуванням Debug #[derive(Debug)] і це буде підказкою компілятору rustc згенерувати рутиний код за нас:

#[derive(Debug)]
struct Rod {
    disks: Vec<u8>,
}

#[derive(Debug)]
struct State {
    rods: Vec<Rod>,
}

fn main() {
    let begin = State {
        rods: vec![
            Rod {
                disks: vec![3, 2, 1],
            },
            Rod { disks: vec![] },
            Rod { disks: vec![] },
        ],
    };

    let end = State {
        rods: vec![
            Rod { disks: vec![] },
            Rod { disks: vec![] },
            Rod {
                disks: vec![3, 2, 1],
            },
        ],
    };

    println!("Tower of Hanoi begin state {:?}", begin);
    println!("Tower of Hanoi end state {:?}", end);
}

cargo run

Tower of Hanoi begin state State { rods: [Rod { disks: [3, 2, 1] }, Rod { disks: [] }, Rod { disks: [] }] }
Tower of Hanoi end state State { rods: [Rod { disks: [] }, Rod { disks: [] }, Rod { disks: [3, 2, 1] }] }

новий атрибут derive здатний реалізувати частину базових типажів за нас

Рефакторинг: виносимо число дисків в константу

Зараз в коді зашито число дисків у векторі disks: vec![3, 2, 1], і при збільшенні числа дисків треба буде змінювати налаштування в двох місцях в коді, тому винесемо в константу:

const TOWER_SIZE: u8 = 7;

fn main() {
    println!("Tower of Hanoi with size {}", TOWER_SIZE);

    // alternative
    // let disks: Vec<u8> = (1..=TOWER_SIZE).rev().collect();
    // let disks: Vec<u8> = (1..=TOWER_SIZE).rev().collect::<Vec<u8>>();
    let disks = (1..=TOWER_SIZE).rev().collect::<Vec<u8>>();

    let begin = State {
        rods: vec![
            Rod {
                disks: disks.clone(),
            },
            Rod { disks: vec![] },
            Rod { disks: vec![] },
        ],
    };

    let end = State {
        rods: vec![
            Rod { disks: vec![] },
            Rod { disks: vec![] },
            Rod { disks: disks },
        ],
    };

    println!("Tower of Hanoi begin state {:?}", begin);
    println!("Tower of Hanoi end state {:?}", end);
}

що ж давайте розбиратись, з const це зрозуміло
в коді 1..=TOWER_SIZE використовується конструкція ..= та створює послідовність від 1 до TOWER_SIZE включно, або start..=end це start ≤ x ≤ end, докладніше в документації range expressions
(1..=TOWER_SIZE).rev() (rev скорочення reverse) для перетворення послідовності від 1 до TOWER_SIZE включно на зворотню послідовність
і пояснення collect з документації для перетворення однієї колекції в іншу:

Transforms an iterator into a collection. collect() can take anything iterable, and turn it into a relevant collection. This is one of the more powerful methods in the standard library, used in a variety of contexts.

в нашому випадку collect перетворює послідовність типу RangeInclusiveExpr в Vec<u8>

І залишилось розібрати тільки disks.clone() який потрібний для повного копіювання бо інакше відбувається передача володіння над змінною disks і подальше використання disks буде помилкою про яку повідомить компілятор, володіння — це така особливість Rust яка підвищує безпеку.

Формуємо всі можливі стани з початкового

Ось дуже простий код з перебором:

fn get_next_states(state: &State) -> Vec<State> {
    let rods = state.rods.len();
    let result = vec![];

    for from_index in 0..rods {
        for to_index in 0..rods {
            // @TODO create next state and push to vector
        }
    }

    return result;
}

0..rods теж послідовність де start..end = start ≤ x < end
хоч ми й використовували макрос vec! раніше, але в цьому прикладі коду гарно видно що Rust вміє самостійно розраховувати типи змінних
тепер реалізуємо @todo як функцію create_state_by_move_disk яка повертає новий стан на основі поточного і перекладання диску між стержнями:

fn create_state_by_move_disk(
    state: &State,
    from_rod_index: usize,
    to_rod_index: usize,
) -> Option<State> {
    if from_rod_index == to_rod_index {
        return Option::None;
    }

    let from_rod = &state.rods[from_rod_index];

    let from_rod_length = from_rod.disks.len();
    if from_rod_length == 0 {
        // cannot move from empty rod
        return Option::None;
    }

    let to_rod = &state.rods[to_rod_index];
    let to_rod_length = to_rod.disks.len();
    if to_rod_length == 0 || from_rod.disks[from_rod_length - 1] < to_rod.disks[to_rod_length - 1] {
        let mut result = state.clone();

        let disk = result.rods[from_rod_index].disks.pop().unwrap();

        result.rods[to_rod_index].disks.push(disk);

        return Option::Some(result);
    }

    return Option::None;
}

в функції create_state_by_move_disk є нові для нас конструкції

ми передаємо в функцію вказівник &State бо передаючи просто State ми б передавали володіння
функція повертає Option, де Option це обгортка всередині якої може бути значення заданого типу, в данному випадку типу State

щоб краще зрозуміти Option ось адаптований приклад з документації:

fn checked_division(dividend: i32, divisor: i32) -> Option<i32> {
    if divisor == 0 {
        // Failure is represented as the `None` variant
        return Option::None;
    } else {
        // Result is wrapped in a `Some` variant
        return Option::Some(dividend / divisor);
    }
}

повернемось до логіки функції create_state_by_move_disk де ми перевіряємо чи можемо ми перемістити диск між стержнями за правилами гри
у випадку коли можемо перемістити то створюємо новий стан result і переміщаємо диск, а інакше повертаємо Option::None
а тепер давайте розглянемо детальніше блок коду зі створенням нового стану та переміщення:

let mut result = state.clone();

let disk = result.rods[from_rod_index].disks.pop().unwrap();

result.rods[to_rod_index].disks.push(disk);

return Option::Some(result);

в документації про об'явлення змінної через ключове слово let сказано:

Variables in Rust are immutable by default, and require the mut keyword to be made mutable.

тому ми об'являємо let mut result, щоб мати змогу змінювати змінну result
друге це метод pop() структури std::vec::Vec, pop() видаляє і повертає останній елемент вектору, якщо останній елемент є
звісно вектор може бути пустий і тому pop() повертає Option<T>, у випадку вектору дисків це Option<u8>
далі метод unwrap() обгортки Option, unwrap() повертає збережене всередині значення, а воно є бо ми це перевірили раніше
якби вектор був пустий і ми виконали .pop().unwrap() то отримали б паніку, майте це на увазі
якщо ви були уважні то помітили що у структури State відсутній метод clone який використовую
метод clone потрібний для копіювання стержнів а також дисків і це дуже просто зробити перебором:

#[derive(Debug)]
struct Rod {
    disks: Vec<u8>,
}

impl Rod {
    fn clone(&self) -> Self {
        return Rod {
            disks: self.disks.clone(),
        };
    }
}

#[derive(Debug)]
struct State {
    rods: Vec<Rod&gt,
}

impl State {
    fn clone(&self) -> Self {
        let mut rods = Vec::with_capacity(self.rods.len());

        for rod in &self.rods {
            rods.push(rod.clone());
        }

        return State { rods: rods };
    }
}

або ж правильно використати ще раз derive в який ми додамо типаж Clone і дати компілятору попрацювати за нас знову

#[derive(Debug, Clone)]
struct Rod {
    disks: Vec<u8>,
}

#[derive(Debug, Clone)]
struct State {
    rods: Vec<Rod&gt,
}

тепер час використати функцію create_state_by_move_disk для генерації можливих станів:

fn get_next_states(state: &State) -> Vec<State> {
    let rods = state.rods.len();
    let mut result = vec![];

    for from_index in 0..rods {
        for to_index in 0..rods {
            if from_index != to_index {
                match create_state_by_move_disk(state, from_index, to_index) {
                    Option::Some(next) => {
                        result.push(next);
                    }
                    Option::None => {
                        // NOP
                    }
                }
            }
        }
    }

    return result;
}

констуркція match схожа на switch в інших мовах програмування, але match потужніша
якщо ви дочитали до цього місця то якось натякніть в коментарях
я трохи скоротив код і ось вам повна картина:

#[derive(Debug, Clone)]
struct Rod {
    disks: Vec<u8>,
}

#[derive(Debug, Clone)]
struct State {
    rods: Vec<Rod>,
}

const TOWER_SIZE: u8 = 7;

fn main() {
    println!("Tower of Hanoi with size {}", TOWER_SIZE);

    let disks = (1..=TOWER_SIZE).rev().collect::<Vec<u8>>();

    let begin = &State {
        rods: vec![
            Rod {
                disks: disks.clone(),
            },
            Rod { disks: vec![] },
            Rod { disks: vec![] },
        ],
    };

    let end = &State {
        rods: vec![
            Rod { disks: vec![] },
            Rod { disks: vec![] },
            Rod { disks: disks },
        ],
    };

    println!("Tower of Hanoi begin state {:?}", begin);
    println!("Tower of Hanoi end state {:?}", end);

    let next_states = get_next_states(&begin);
    for next_state in next_states {
        println!("Tower of Hanoi next state {:?}", next_state);
    }
}

fn get_next_states(state: &State) -> Vec<State> {
    let rods = state.rods.len();
    let mut result = vec![];

    for from_index in 0..rods {
        for to_index in 0..rods {
            if from_index != to_index {
                match create_state_by_move_disk(state, from_index, to_index) {
                    Some(next) => {
                        result.push(next);
                    }
                    None => {
                        // NOP
                    }
                }
            }
        }
    }

    return result;
}

fn create_state_by_move_disk(
    state: &State,
    from_rod_index: usize,
    to_rod_index: usize,
) -> Option<State> {
    if from_rod_index == to_rod_index {
        return None;
    }

    let from_rod = &state.rods[from_rod_index];

    let from_rod_length = from_rod.disks.len();
    if from_rod_length == 0 {
        // cannot move from empty rod
        return None;
    }

    let to_rod = &state.rods[to_rod_index];
    let to_rod_length = to_rod.disks.len();
    if to_rod_length == 0 || from_rod.disks[from_rod_length - 1] < to_rod.disks[to_rod_length - 1] {
        let mut result = state.clone();

        let disk = result.rods[from_rod_index].disks.pop().unwrap();

        result.rods[to_rod_index].disks.push(disk);

        return Some(result);
    }

    return None;
}

Повертаємо тільки унікальні стани

Переклавши диск з першого стежня на другий, ми так само можемо повернути його назад, і щоб прибрати подібне зациклення ми будемо зберігати пройдені стани використовуючи стандартну структуру HashSet.

Отож так само генеруємо можливі стани та відфільтровуємо вже повернуті раніше, які були збережені в HashSet.

Елементи HashSet мають реалізувати типаж Hash (який в Rust-і вже реалізований для багатьох типів даних, строкових та числових).
І ми можемо реалівувати типаж Hash для структури State або серіалізувати структуру State в строку або число (які реалізують Hash).
Отже серіалізуємо State в 128-бітне число u128 і напишемо тест:

const DISK_BIT_SIZE: u8 = 4;

impl State {
    fn serialize(&self) -> u128 {
        let disk_bit_size: u128 = DISK_BIT_SIZE as u128;

        let mut result: u128 = 0;
        let mut shift: u128 = 0;

        for rod in &self.rods {
            for &disk in &rod.disks {
                result |= (disk as u128) << shift;

                shift += disk_bit_size;
            }

            // delimiter between rods
            shift += disk_bit_size;
        }

        return result;
    }
}

звісно використовуючи u128 ми накладаємо обмеження на число дисків та стержнів які зможемо серіалізувати правильно але нам цього обмеження достатньо
для написання тестів ми скористаємось прикладом з документації unit testing і зробимо так само:

#[cfg(test)]
mod state_test {
    use super::*;

    #[test]
    fn serialize() {
        {
            let state = State { rods: vec![] };

            assert_eq!(0, state.serialize());
        }

        {
            let state = State {
                rods: vec![Rod {
                    disks: vec![3, 2, 1],
                }],
            };

            // alternatives
            // assert_eq!(0b0001_0010_0011, state.serialize());
            assert_eq!(0x1_2_3, state.serialize());
        }

        {
            let state = State {
                rods: vec![
                    Rod { disks: vec![5, 4] },
                    Rod { disks: vec![] },
                    Rod {
                        disks: vec![3, 2, 1],
                    },
                ],
            };

            // alternatives
            // assert_eq!(0b0001_0010_0011_0000_0000_0100_0101, state.serialize());
            assert_eq!(0x1_2_3_0_0_4_5, state.serialize());
        }
    }
}

новими для нас є атрибути #[cfg(test)] та #[test], а також макрос assert_eq!, з назви зрозуміло навіщо вони потрібні, отож запустимо тести:

cargo test

running 1 test
test state_test::serialize ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

як бачимо тести пройшли успішно
тепер використаємо новий метод State.serialize та структуру HashSet для збереження повернутих раніше станів:

struct UniqueStateGenerator {
    past: HashSet<u128>,
}

impl UniqueStateGenerator {
    fn new() -> UniqueStateGenerator {
        return UniqueStateGenerator {
            past: HashSet::new(),
        };
    }

    fn get_next_states(&mut self, state: &State) -> Vec<State> {
        let rods = state.rods.len();
        let mut result = vec![];

        for from_index in 0..rods {
            for to_index in 0..rods {
                match create_state_by_move_disk(state, from_index, to_index) {
                    Some(next) => {
                        if self.unique(next.serialize()) {
                            result.push(next);
                        }
                    }
                    None => {
                        // NOP
                    }
                }
            }
        }

        return result;
    }

    fn unique(&mut self, value: u128) -> bool {
        return self.past.insert(value);
    }
}

fn main() {
    // ... unchanged code

    let mut generator = UniqueStateGenerator::new();

    {
        let next_states = generator.get_next_states(&begin);
        println!("Tower of Hanoi next states {}", next_states.len());
        for next_state in next_states {
            println!("Tower of Hanoi next state {:?}", next_state);
        }
    }

    {
        let next_states = generator.get_next_states(&begin);
        println!("Tower of Hanoi next states {}", next_states.len());
        for next_state in next_states {
            println!("Tower of Hanoi next state {:?}", next_state);
        }
    }
}

метод HashSet.insert повертає true якщо був вставлений новий елемент
після запуску через cargo run в терміналі отримаємо що дійсно фільтрує:

Tower of Hanoi next states 2
Tower of Hanoi next states 0

Реалізація пошуку в глибину

Всі попередні приклади в статті були потрібні для об'єднання в пошук в глибину, нарешті:

struct DeepFirstSearch {
    begin: State,
    end: State,
    unique_state_generator: UniqueStateGenerator,
}

impl DeepFirstSearch {
    fn new(begin: State, end: State, unique_state_generator: UniqueStateGenerator) -> Self {
        return DeepFirstSearch {
            begin,
            end,
            unique_state_generator,
        };
    }

    fn search(&mut self) -> bool {
        return self.search_by_state(self.begin.clone());
    }

    fn search_by_state(&mut self, state: State) -> bool {
        if state == self.end {
            return true;
        }

        for next_state in self.unique_state_generator.get_next_states(&state) {
            if self.search_by_state(next_state) {
                return true;
            }
        }

        return false;
    }
}

fn main() {
    // ... unchanged code

    let generator = UniqueStateGenerator::new();

    let mut searcher = DeepFirstSearch::new(begin, end, generator);

    println!(
        "Tower of Hanoi deep first search result {}",
        searcher.search()
    );
}

cargo run

Tower of Hanoi with size 7
Tower of Hanoi deep first search result true

щоб порівняти два стани в коді через просту операцію "==" state == self.end додали типаж PartialEq

#[derive(Debug, Clone, PartialEq)]
struct Rod {
    disks: Vec<u8>,
}

#[derive(Debug, Clone, PartialEq)]
struct State {
    rods: Vec<Rod>,
}

Перевірка правильності рішення

Для перевірки рішення треба зберігати в журнал дії переміщення диска між стержнями,а потім використавши журнал повторити дії починаючи від початкового стану і перевірити що кінцевий стан буде очікуваним.

Цю просту перевірку спробуйте написати самостійно, а весь код для повної картини можете глянути у відкритому репозиторії.

Пошук у ширину на прикладі задачі Ханойської вежі

Раз ми вже з одним пошуком познайомились, то легко побачимо відмінність пошуку у ширину
Якщо в пошуці в глибину ми рекурсивно заглиблювались, то в пошуці в ширину ми просто додаємо в чергу:

struct BreadthFirstSearch {
    begin: State,
    end: State,
    unique_state_generator: UniqueStateGenerator,
}

impl BreadthFirstSearch {
    fn new(begin: State, end: State, unique_state_generator: UniqueStateGenerator) -> Self {
        return BreadthFirstSearch {
            begin,
            end,
            unique_state_generator,
        };
    }

    fn search(&mut self) -> bool {
        let mut queue = vec![];

        self.unique_state_generator.unique(self.begin.serialize());

        queue.push(self.begin.clone());

        while queue.len() > 0 {
            let current_state = queue.pop().unwrap();

            if current_state == self.end {
                return true;
            }

            queue.extend(self.unique_state_generator.get_next_states(&amp;current_state));
        }

        return false;
    }
}

Епілог

Основна ціль статті це знайомство з Rust-ом на простому прикладі.
Написання статті і мені було корисно бо краще зміг структурувати свої знання.
Статтю хотів написати давно, але випередили.
Для написання статті використовував безкоштовну IntelliJ IDEA Community Edition для якої також є безкоштовний Rust плагін.

За перевірку статті на помилки дякую Олексію, який працює Cossack Labs і шукає до себе в команду спеціалістів з Rust.
За ілюстрації дякую Людмилі Тіторенко

Навчальні матеріали:

Також є класний YouTube канал Hello Rust!, але останнє відео там публікували рік тому.