Golang в крупных проектах возможен (back)?

https://go.dev/doc/tutorial/database-access#multiple_rows

rows.Scan(&alb.ID, &alb.Title, &alb.Artist, &alb.Price)

По поводу run-time panic в Rust, шоб не быть голословным.

Не ахти какой идеоматический код, но есть у меня маленькая демка, которую я вместо «hello world» делаю, что бы освоиться немного с языком за пределами бесполезных туториалов → https://github.com/dim13/doomfire

Так вот, меняем в src/fire.rs в строке 46 «1» на «0» и добро пожаловать runtime паника, которая не ловится в compile-time.

PS: критика, кстати приветсвуется.

Вы там осторожнее, они поди не в курсе что здесь за место классов структуры ;) Которая по сути и есть db ;)

Это не маппинг, это клоунада какая-то закат солнца вручную.

Там в стандартной есть какая то sql … а зачем? либов тысячи начиная с gorm и т.д.

Раст не обещал отсутствие паник. Safety это когда память не портится и всё такое. Как без паник-то? В любом языке можно выйти за пределы массива. Только в C это будет расстрел памяти с непредсказуемыми последствиями. А тут просто паника.

Зато просто и понятно. И, кстати, производительно.

Ну можно наворотить всякую магию с помощью https://gorm.io или https://entgo.io или ещё чего-нибудь. Да, не stdlib, но это же не проблема?

А затем полезли глубокие философствования на тему object–relational impedance mismatch и фреймворки, пытающиеся решить эту проблему, наряду с шаблонизацией и прочем.

Эти исследования могут продолжаться десятилетиями, а код сам себя не напишет =)

type FooBar struct {
     Whatever string `db:"whatever"`
}

Но стоить заметить, что это пожалуй единственное не-ORM стороннее расширение стандартного database/sql пакета, которое заслуживает внимания → https://jmoiron.github.io/sqlx/

Для рутинных задач stdlib есть и большая.

Раст не обещал отсутствие паник. [..] В любом языке можно выйти за пределы массива.

Но нам все говорят, что это в Rust не возможно! Там же все выходы за пределы проверятся в compile-time.

TL;DR: шуму много, толку мало. Вместо malloc/free borrow-checker и Vec<>, Box<>, что суть одно и тоже. И с тем же результатом. Ну и вместо того, чтобы работу работать, программист на rust вручную исполняет работу компиятора, что компилятор вполне ведь мог делать самостоятельно, ведь знает же, свовочь, что где не так.

Возможно, я сильно заблуждаюсь, но создаётся такое впечатление, что людям больше нравятся исследовательские (research) проекты, а не практические. Не смог удивить публику изысканным элегантным открытием — go fish. Смог — поздравляю, мы готовы отказаться от самых удобных инструментов ради доказательства своей преданности идее.

Ничего не имею против ресёрча, скорее наоборот, просто «со своим уставом в чужой монастырь» пользы не несёт.

Практично – это когда ты за 10 минут сделал то, что на C потребует 10 часов, а на rust 10 дней. Да, оно будет не такое быстрое. Но достаточно быстрым, чтобы об этом особенно не беспокоится. (Я стал старым прагматиком, да.)

There are only three optimizations: Do less. Do it less often. Do it faster. The largest gains come from 1, but we spend all our time on 3.

Я не спорю, я как раз имел ввиду Go как «практичный» и Rust как «исследовательский». Он может быть не таким удобным (хотя я лично не пробовал), но людям зашла его идея и они ради неё готовы идти на жертвы. И выглядит странно, когда они ожидают от других того же.

Та же история с ORM. Некоторые люди полжизни отдали на решение связанных философских проблем, а мы тут в database/sql ручками всё делаем. Неуважение традиций!

Там же все выходы за пределы проверятся в compile-time.

Никто такого не мог говорить. Максимум, что Rust даёт, это range для индексов, т.е. в стандартной библиотеке хватает средств, чтобы большинство кода можно было писать в стиле, когда выход за границы невозможен. Но проверка выхода за пределы границ в compile-time звучит как фантастика, может в каких-то экзотических языках такое есть, но здесь и сейчас в практически применяемых языках этого можно сказать нигде нет.

TL;DR: шуму много, толку мало. Вместо malloc/free borrow-checker и Vec<>, Box<>, что суть одно и тоже.

Толку много. Borrow checker это прорыв. И совсем не то же самое. Borrow checker гарантирует отсутствие ряда ошибок. malloc/free не гарантируют.

Огромного кредита доверия что характерно тоже.

Я не знаю точно как с этим в РФ, но скорее всего хорошо. В общем, в банках вообще наплевать на чем оно написано. Они все следуют одним и тем же процедурам, что-то вроде большого фреймворка или гайдлайна, где язык реализации мало на что влияет. Виртуально, это что-то вроде огромной электронной книги бух учета. Если банк получил лицензию, значит у него провели аудит, в т.ч. на безопасность. Самое последнее, что хочет сделать банк — так это просрать или не отдать тебе деньги — это все грозит отзывом лицензии.

Конечно, банк может вести себя недобросовестно, но это а) жесткая уголовка б) не зависит от того, на чем написана бухкнижка.

На самом деле borrow-checker фигня. Не понимаю, как другие имеют с ним проблемы. (Особенно если трогал Erlang раньше.)

Меня больше бесит весь это раздутый синтаксис, кода всё-всё-всё в ручную.

if err != nil {}

по сравнению с этим – детский лепет и фигня.

Проблема ошибок при работе с памятью, например использование освобождённой памяти (use after free), в том, что достаточно часто такие ошибки приводят к уязвимостям. А уязвимости это плохо. Также такие ошибки сложно выявлять, т.е. память портится непойми где и программа может упасть вообще в другом месте или просто записать мусор вместо полезных данных.

Если говорить про конкретные классы ошибок, то можно их попробовать расписать.

1. Использование неинициализированных переменных. Это тривиально реализуется на уровне компилятора и любой C компилятор подсветит предупреждением такой код.

2. Выход за границы массива. Это тоже тривиально реализуется, хотя в C и не сделано. Надо вместе с указателем передавать длину и везде вставлять проверки индекса. Главная проблема - это просаживает производительность. В Rust это обходится с помощью unsafe блоков. В принципе ничего не мешает это сделать и в C. А в C++ это вообще тривиально сделать самому, написав небольшой класс для массивов.

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

3. Использование освобождённой памяти. Это самая главная «фишка» Rust-а. Альтернатива borrow checker-у только сборщик мусора, с очевидными минусами.

4. Автоматическое освобождение памяти. Хотя утечки памяти в safe rust возможны, но вообще это надо постараться случайно такое допустить.

5. Гонки в многопоточном коде. И с этим Rust помогает справиться с помощью того же borrow checker-а, что для меня было совсем неожиданным, т.к. вроде его делали совсем для другого.

Безусловно цена всему этому - сложный в использовании язык. Конечно если требования к программе допускают использование сборщика мусора, Rust вероятно будет не лучшим выбором. Rust конкурирует с C и C++. Go, Java и тд играют в другой лиге.

1. Потому что это легко сделать (в отличии от C, например)
2. Такова потребность времени. Все работают с SQL
3. Удобно, когда не надо искать что-то на стороне
4. Маленький интерфейс позволяет присоединить больше разнообразных технологий. https://go.dev/wiki/SQLDrivers — все они реализуют database/sql

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

Его смысл в том, чтобы ты знал один API и с его помощью мог работать с любой БД, а не учил разные API для Postgres, SQLite и MySQL.

А также чтобы поверх этого интерфейса можно было написать библиотеки, которые давали бы возможность маппить структуры и эти библиотеки опять же работали бы с любой БД, а не пришлось бы писать отдельную библиотеку для каждой из БД. В том числе и ORM. Которые для Go вполне себе существуют.

Так уж получилось, что у всех SQL СУБД очень схожий API, поэтому использование стандартизированного интерфейса тут напрашивается и реализовано много где: JDBC, ODBC из популярных, например.

Меня больше бесит весь это раздутый синтаксис, кода всё-всё-всё в ручную.

+1 Синтаксис раста — будто говном из вентилятора насыпало. Мне он кажется в среднем даже многословнее и тяжелее С++ (на который растоманы и направляют этот вентилятор). В плюсах можно упороться в шаблонный вырвиглаз, но не обязательно. В расте все эти закорючки практически обязательны всю дорогу.

А Го, он хоть и слегка раздут из-за проброса ошибок, но семантически очень лаконичен.

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

Нахрена кому-то в здравом уме «реализовывать весь спринг» на Go? Спринг - это конкурент J2EE, которого он давно похоронил и обе эти технологии изначально создавались под монолит. Для микросервисной архитектуры этот ваш Спринг нафиг не упал, слишком тяжёл и неповоротлив. К тому же он оброс сплошной декларативщиной, от которой уже просто тошнит. Особенно если она нестандартная, в стиле Жени и Баруха с jugru.

Согласен. У Раста эти несколько слоёв <A<B<C<D>>> повсюду. Не знаю, можно ли к этому привыкнуть.

Зачем вообще заморачиваться выбором, если архитектура микросервисная. Пишите всё на чём угодно. Конкретные сервисы, которые не справляется, переписываете.

Python -> Go -> Rust. Такова последовательность оптимизации.

Конечно зависит от нагрузки. Если она известна заранее, то можно прикинуть расход ресурсов. Набросать самые тяжёлые операции. Прогнать нагрузку. Посмотреть профиль потребления ресурсов. Если на Го, и упор в сборку мусора. И пулы объектов уже используются. И прочие оптимизации. Тогда смысл переписать на Расте.

Питон может и в проц упереться. Тогда на Го переписывается.

Слишком много внимания выбору. А он определяется профилем нагрузки.

Есть функция. Трудозатраты и сроки. Оборудование (стоимость). Удовлетворение нагрузочных требований. Если данных не хватает: планируется и ставится опыт. Конкретная проблема и её конкретное решение.

Rust паникует в runtime just fine. Хвалёный memory safety только для запудривания… index out of bounds

вот тут я совсем не понял. А что должна делать программа, если происходит обращение за пределы массива? Может голанг цветы дарит и в щечку целует, но раст совершенно справедливо паникует, и как раз это и называется safety, потому что не-safety код может сделать что угодно, это называется UB.

а нет, смотри-ка чо, голанг тоже таки немножечко паникует

https://go.dev/play/p/Aw1TqqceyL0

Питон может и в проц упереться. Тогда на Го переписывается.

Нет, тогда запускается второй (или двадцать второй) инстанс. Вот на двести двадцать втором можно и задуматься о переписывании.

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

К примеру можно вычислять все возможные значения индекса и отказываться компилировать код, в котором это значение может выходить за пределы массива. Тут нужно что-то вроде верификатора кода, встроенного в компилятор. Т.е. если по-простому, то ты обязан перед каждой индексацией вставить проверку вида if (index >= arr.length) { abort(); }.

Конечно писать на таком языке будет не очень удобно, как мне кажется…

Python -> Go -> Rust

У вас две ошибки в трех словах

PHP <-> Go <-> Clojure

и где-то под ними болтается js-ная нода.

Вообще, меня удивляет как вроде бы специалисты на серьёзных щщах могут рекомендовать языки без сборщика мусора а-ля rust для работы в режиме микросервисов 24/7/365.

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

А полезную работу делать когда? Вас случайно не С так травмировал?

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

А чтобы багов не было, нужно просто внимательно писать код.

как это мило! А чтобы не умирать, надо просто не болеть. А бездомным достаточно просто купить дом. А чтобы всем нравиться надо просто родиться красивым и с хорошим чувством юмора.

Пописав на С

Я тоже иногда писаю на С, на этом форуме в том числе.

Языков без багов не существуют тк архитектурные косяки в самом железе программой не победить (проблема точности вычисления чисел). Но языки которые действительно переводят программиста на новый уровень понимания существуют. Например, PHP Clojure, с его гомоиконностью, где все - это данные.

Большинство из вас не в состоянии осознать всю глубину этого подхода. Да вам и не нужно, ведь ваш потолок - ежедневная борьба с UB. (закинул невод и принялся терпеливо ждать)

Вообще, меня удивляет как вроде бы специалисты на серьёзных щщах могут рекомендовать языки без сборщика мусора а-ля rust для работы в режиме микросервисов 24/7/365

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

вон там яндекс свой микросервисный фреймворк userver(с++) продвигает.

Да нет там никакой ежедневной борьбы с UB. Даже не помню, когда в последний раз такой вопрос вставал. Это же не C++.

с его гомоиконностью

все, что начинается с «гомо», хорошим быть не может.

Сказал гомосапиенс.

проблема точности вычисления чисел

А что это за проблема?

включаешь все мыслимые варнинги и у тебя нет ub и в с++.

Если банк получил лицензию, значит у него провели аудит, в т.ч. на безопасность. Самое последнее, что хочет сделать банк — так это просрать или не отдать тебе деньги — это все грозит отзывом лицензии.

Ох и короткая же у вас память, как у золотых рыбок. (Или вы жили еще не долго :)) Банки-пылесосы тоже получали лицензию, и тоже «имитировали следование процедуре», служа прокладкой «вполне конкретным»(тм) выгодоприобретателям. Как раз с прицелом на вывести бабло и спрыгнуть. А уголовка пущай прокладкам светит и прочим наемным менеджерам. Это сейчас им нужен примерно другой глобус или мимикрия под политические преследования, чтоб «там» не обезжирили, высушили и выкинули.

Сказал гомосапиенс.

все эти гомосапиенсы поголовно - очень плохие люди.

вон там яндекс свой микросервисный фреймворк userver(с++) продвигает.

Наши разработчики знают только С++, а нам уже нужен Go. Давайте сделаем свой Go на C++17 и гокорутинах, мы что хуже гугла?

Давайте сделаем свой Go на C++17 и гокорутинах, мы что хуже гугла?

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

тем более что фреймворк для «микросервисов» не такая уж и сложная штука.

в голанге от микросервисов только корутины(сто лет в обед концепции) и каналы(примерно столько же), плюс наивный синтаксис.

А что это за проблема?

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

Только что проверил, на

int main(void) {
  while (true) {}
}

clang с -Wall не выдаёт варнинги. Не всё включил?

можно соорудить на всем понятном с++ ровно то же самое

@

яндекс

Да вы, батенька, оптимист.

Полностью корректный код, никакого UB. Бесконечный цикл. Программа для отопления квартиры системником, включаете на всех ядрах и греетесь.

Нет, в C++ это UB.

в чем заключается UB в данном случае? Пальцем ткните.

Спасибо за совет, но это совсем не прояснило что

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

и особенно, как это связано с ЯП

называеццо Infinite loop without side-effects