Александр Павлюк

Интерфейсы нужны для полиморфизма.
Конкретно в твоём случае да - разницы нет.
Но чисто в теории ты бы мог сделать вот так:

type Numbers struct {
  Num1 int
  Num2 int
}

type ThreeNumbers struct {
  Num1 int
  Num2 int
  Num3 int
}

func (n Numbers) Sum() int {
  return n.Num1 + n.Num2
}

func (n ThreeNumbers) Sum() int {
  return n.Num1 + n.Num2 + n.Num3
}

func SumAll(numbers NumberInterface) int {
  return numbers.Sum()
}

Функция SumAll будет работать с любыми типами, которые реализуют интерфейс NumberInterface, причём даже если они сами об этом не в курсе, благодаря утиной типизации.

https://go.dev/blog/defer-panic-and-recover

A deferred function’s arguments are evaluated when the defer statement is evaluated.

Т.е. функция fmt.Println выполнится в конце, но её аргументы "defer 2 result" и f(2) вычисляются сразу.

В документации os/exec даже есть пример под ваш случай: https://pkg.go.dev/os/exec#example-CommandContext

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

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

Это не ошибка. Открой ЛЮБОЙ туториал по го, будь добр

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

Чтобы в этом убедиться добавим два fmt.Printf, чтобы получилось вот так

package main

import (
    "fmt"
    "runtime"
    "sync"
)

var wg sync.WaitGroup

func main() {
    runtime.GOMAXPROCS(8)
    arr := []int{1343434, 1343434300, 234343400, 334343434000, 400434340, 203434340, 4232, 23545, 15535, 353535, 33434434, 5334345, 3533434345, 3535}
    for idx, el := range arr {
        wg.Add(1)
        go test(el, idx)
    }
    wg.Wait()
}

func test(el int, idx int) {
    fmt.Printf("%d started: %d\n", idx, el)
    for i := 0; i < el; i++ {
        el = el - 1
    }
    fmt.Printf("%d completed: %d\n", idx, el)
    defer wg.Done()
}

Вывод будет примерно таким

4 started: 400434340
8 started: 15535
8 completed: 7767
13 started: 3535
13 completed: 1767
6 started: 4232
6 completed: 2116
10 started: 33434434
3 started: 334343434000
7 started: 23545
7 completed: 11772
5 started: 203434340
12 started: 3533434345
11 started: 5334345
2 started: 234343400
1 started: 1343434300
11 completed: 2667172
9 started: 353535
9 completed: 176767
0 started: 1343434
0 completed: 671717
10 completed: 16717217
5 completed: 101717170
4 completed: 200217170
2 completed: 117171700
1 completed: 671717150
12 completed: 1766717172

При внимательном просмотре станет видно, что нет записи 3 completed.

меняю элементы с индексами 4 и 5 на такие же числа 334343434000, 334343434000, т.е. делаем чтобы все горутины отработали, но чтобы 3 осталось, т.е. вот так

arr := []int{1343434, 1343434300, 234343400, 334343434000, 334343434000, 334343434000, 4232, 23545, 15535, 353535, 33434434, 5334345, 3533434345, 3535}

Запускаем заново и видим, что теперь 3 ядра отлично загружены

%Cpu0  :  0.3 us,  1.0 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  1.7 us,  0.7 sy,  0.0 ni, 97.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  1.6 us,  2.9 sy,  0.0 ni, 95.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  5.6 us,  1.0 sy,  0.0 ni, 93.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

Ну не фигня ли?? )

Нет, ведь у тебя две разных переменные с одним именем — db



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

Потому что переменная input объявлена, но не используется.
Внутри for вы используете оператор := который объявляет локальные переменные input и error. А та, которую вы объявили выше тут не используется.

https://golangdocs.com/short-variable-declaration-...

Более четырёх лет пишу на Go, лично для меня поддерживать проекты на других языках сложнее ))
До Go много лет писал на Perl/PHP/Python/Java/C/Ruby on rails/JavaScript и "крутил" еще не мало чего.
Сейчас пишу только на Go и Python.

Основная сложность в Go - это то, что если вы начинаете писать "криво" - то писать так очень трудно :))
Подход к реализации в Go достаточно непривычный для тех, кто приходит из скриптовых языков.
Например запрет циклических импортов - это самое первое, что "взрывает" мозг :)
Нужно время чтобы адаптироваться после скриптовых языков.

Про обработку ошибок - это да, это, пожалуй, единственное что мне не нравится в Go.
Для себя я решил эту проблему за 1-2 часа :) и больше меня это не беспокоит.

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

А если объективно - то я бы не стал говорить о сложности поддержки проекта применимо к какому то конкретному языку.

Как правило сложность поддержки возникает там, где нормальная архитектура не заложена в проект.
Т.е. проект как могла так и писала куча людей плюс, как обычно, сделать нужно было побыстрее )), от этого никто вообще не думал об архитектуре и получилось то, что получилось :))
Про покрытие тестами и документацию мы вообще не говорим )))

А когда в таком проекте нужно что-то доработать или исправить ошибку, то почти всегда очень не просто найти то место, где нужно править, и после правок в одном месте, как правило, что-то ломается в другом :)

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

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

Хочется добавить, что как бы не писали про Go, что он простой и т.д. - он явно сложнее Python/PHP и т.д.
Это еще один повод сказать, что поддерживать код на Go сложно ))

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