Тимофей

Помимо основной частоты 2кГц, меандр содержит кучу гармоник. Всё, что превышает половину частоты дискретизации, у вас теряется.

"Пузо" светодиода - паять обязательно.
К обратной стороне "звезды" - радиатор.
P.S. Обычно, в документации на светодиод всё написано. Или в отдельном разделе на сайте фирмы-производителя.

А зачем когда ты сам можешь все контролировать
Тут два основных паттерна
1 когда запросов мало и они простые и ты понимаешь как они работают и никаких косяков со странными данными из вне прийти не должно или ты это уже сам экранироовал , реально намного быстрее напрямую сделать чем вникать в орм
2 когда тебе в каких то частях нужен перформанс или когда орм генерит еретические запросы там где у тебя сложная логика и приходится их переписывать напрямую
Ну и забыл третье вкусовщина

Как гофер с 1.13 версии могу предложить следующие рассуждения:

1) Нормальная общепризнанная и безболезненная ORM отсутствует. Самая популярная - GORM, где-то на втором месте - ent. Обе в целом как-то соответствуют ожиданиям, но имеют свои особенности. Кто в GORMе делал джоин - в цирке не смеется.
2) Из за того что в большинстве нормальных проектов ORMы не используются очень быстро привыкаешь писать именно SQL. Ты ещё на стадии аналитики рисуешь все эти create table и select from в голове, потом просто вставляешь в код.
3) Производительность GORM сделала в мире го репутацию всем ORMкам как очень плохому решению.

Лично я делю всех гоферов на 4 типа: бывшие джависты, бывшие пхпшники, бывшие питонисты и непосредственно гоферы - те у кого го первый или основной язык. В большинстве наблюдаемых случаев ORM в го пытаются затащить бывшие джависты по старой привычке: вот у нас в спринге был ORM значит и здесь возьмём. Клинический случай - когда такой бывший джавист становится тим или тех-лидом и делает ORM обязательным. Сколько видел таких случаев - каждый раз в результате команда ходит плюётся.

Ну и да, есть ORMки основанные на генерации кода, но самая популярная - GORM основана на рефлексии и иногда магии, это очень сильно бьет по производительности и иногда может стать "бутылочным горлышком" приложения.

Почему некоторые решают рабоатать с бд на чистом sql

В целом есть несколько причин:
1) В целом ORM в го не очень удобные, тот же gorm особо не даёт выигрыша в простоте относительно sql
2) В целом запросы могут быть относительно простыми и ORM не нужна
3) Нет стандартной ORM по типу Hibernate, SQLAlchemy
4) В го у ORM есть ограничения,
5) Если ORM на основана на рефлексии то она будет медленно работать (привет gorm) даже для средненагруженных проектов, не говоря про highload

В целом многие используют штуки по типу sqiurell, и sqlc, т.к. они легче чем ORM и для ряда вещей упрощают код. Для миграций в большинстве проектов хватит go-migrate

Не гошник, но расскажу в целом.
1. На 1 уровень абстракции меньше. При работе с ORM нужно думать одновременно и об особенностях твоей ORM-ки и об особенностях базы.
2. На сыром SQL некоторые вещи сделать проще, чем с ORM-ками.
3. Лучше сырой SQL, чем тупая ORM-ка.
4. Некоторые ORM-ки могут негативно влиять на производительность.

Если тебе приходится при работе с ORM писать куски SQL-я (например для WHERE), передавать названия колонок в параметрах, и при этом ты не можешь использовать специфику твоей базы не опускаясь до уровня сырого SQL, то это плохая ORM.

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

Нормальные ормки я пока видел только:
1. В C# из-за Linq
2. В Rust из-за макросов.

Вам скорее всего помогут transport_maps.

Довекот тут не при чём, его задачи совершенно другие.