Скорее всего не в этом дело. Я запускал сервис и последовательно выполнял по 3 замера с 10,50 и 100 соединениями не перезапуская сервис (9 замеров). Таким образом пул бы "прогрелся" уже после первого замера
Концепциями ООП являются инкапсуляция, полиморфизм и наследование. Как в Rust реализовано наследование?
Очень долгая компиляция. Даже в не очень большом проекте у тебя будет порядка 500 сквозных зависимостей и их все нужно собирать, а сборка долгая. В CI/CD сборку приходится ждать иногда по 10 минут
Собранные единожды зависимости разве не кэшируются?
Но тренд же сейчас наоборот в переходе с C/C++ на Rust, как раз за счет концепции управления памятью. А GC в Go наоборот записывают ему в минусы (в том виде, в котором он сейчас, из-за приостановки выполнения программы). Если нужен GC и "свобода" написания кода, то лучше выбрать Python или js. Я выбрал Go за то, что он компилируется в нативный код, статически типизированный, имеет свою концепцию интерфейсов вместо ООП и не требует ручного управления памятью (как С/С++), при этом синтаксически простой. После написания проекта на Go, и ряда последних статей на Хабре про Rust (где говорилось, что Go хуже), я решил еще раз на него обратить внимание (первый раз, давно, на нем писал драйвер и не рассматривал его как язык для прикладного ПО). И вот сейчас, после Go, я увидел что концепция та же, только не нужен GC, меньше кода писать, больше гибкости. Т.е. если сравнивать "в лоб", то код простого сервиса на Rust выглядит так же как на Go. Только для Go это "потолок", а для Rust "база". В итоге я пытаюсь услышать объективные доводы за/против перехода с Go на Rust. Пока кажется, что большинство разработчиков просто консервативны и противятся новому. (так же как в случае с Java и Kotlin)
Мне пока видится, что Go это подмножество Rust. У того же С++ другая концепция (ООП, классы, ручной контроль за памятью). Что есть в Go, чего нет в Rust? Могу предположить, что только концепция каналов. (GC в расчет не берем, т.к. в Rust он не нужен и в этом одно из его преимуществ). Никто из комментаторов ни приводит ни одного довода за или против Go/Rust, все суждения не объективны. Я пересмотрел кучу статей "сравнений" этих двух языков и везде только общие слова, как будто написанные GPT, никакой конкретики, примеров.
Согласен с вашими высказываниями. Насчет языков мне кажется у Go и у Rust одинаковые концепции, они близки по подходам к разработке (через интерфейсы/трейты, модули). Rust решил проблему утечек памяти и рантайм ошибок, Go обеспечил быстрое обучение + быстрая разработка мелких программ. Оба языка обеспечивает небольшое использование памяти программами и отличное быстродействие. Но лично мне не нравится в Go после вызова каждой функции (которая возвращает ошибку) писать обработку ошибки.
От CRM мне нужна поддержка подключения к разным СУБД через одно API и мапинг данных из строки БД на структуру. Сами запросы я предпочитаю писать на SQL.
Мне кажется описаны рассуждения аналитика, а не архитектора. Архитектор продумывает реализацию под конкретное ТЗ. Если в аналитик в ТЗ указал, что нужен контроль отрицательных остатков, то он должен быть.
Разрешать минусовые остатки можно только на кассах, где покупатель стоит с товаром. В других случаях (опт) нельзя. Например в резерве по Контрагент1 стоит предоплаченный товар. Пришел Контрагент2 и менеджер продал ему этот товар. Реализация провелась в минус, но менеджеру на это все равно, ему главное продать и получить свой процент. Далее пришел Контрагент1 за своим оплаченным товаром, а его нет. (и следующая поставка через полгода....)
Получается, что например, если у меня две сетевых карты, каждая подключена к интернету через своего провайдера и я запущу такой сервер на Go, то все запросы на любой сетевой интерфейс будут идти в этот Go-сервис и ответ этот сервис будет слать через любой из двух сетевых интерфейсов выбрав по определенному алгоритму? Или в чем смысл такого сервера?
С клиентом более менее понятно, например можно грузить большой файл одновременно и через WiFi и через сотовую сеть.
Скорее всего не в этом дело. Я запускал сервис и последовательно выполнял по 3 замера с 10,50 и 100 соединениями не перезапуская сервис (9 замеров). Таким образом пул бы "прогрелся" уже после первого замера
Если этот так, то можно как то в Rust подготовить заранее подключения не выполняя запросов?
Значит медленнее чем ряд других ОRМ, например медленнее чем Diesel
Концепциями ООП являются инкапсуляция, полиморфизм и наследование. Как в Rust реализовано наследование?
Собранные единожды зависимости разве не кэшируются?
Но тренд же сейчас наоборот в переходе с C/C++ на Rust, как раз за счет концепции управления памятью. А GC в Go наоборот записывают ему в минусы (в том виде, в котором он сейчас, из-за приостановки выполнения программы). Если нужен GC и "свобода" написания кода, то лучше выбрать Python или js. Я выбрал Go за то, что он компилируется в нативный код, статически типизированный, имеет свою концепцию интерфейсов вместо ООП и не требует ручного управления памятью (как С/С++), при этом синтаксически простой. После написания проекта на Go, и ряда последних статей на Хабре про Rust (где говорилось, что Go хуже), я решил еще раз на него обратить внимание (первый раз, давно, на нем писал драйвер и не рассматривал его как язык для прикладного ПО). И вот сейчас, после Go, я увидел что концепция та же, только не нужен GC, меньше кода писать, больше гибкости. Т.е. если сравнивать "в лоб", то код простого сервиса на Rust выглядит так же как на Go. Только для Go это "потолок", а для Rust "база". В итоге я пытаюсь услышать объективные доводы за/против перехода с Go на Rust. Пока кажется, что большинство разработчиков просто консервативны и противятся новому. (так же как в случае с Java и Kotlin)
Мне пока видится, что Go это подмножество Rust. У того же С++ другая концепция (ООП, классы, ручной контроль за памятью). Что есть в Go, чего нет в Rust? Могу предположить, что только концепция каналов. (GC в расчет не берем, т.к. в Rust он не нужен и в этом одно из его преимуществ). Никто из комментаторов ни приводит ни одного довода за или против Go/Rust, все суждения не объективны. Я пересмотрел кучу статей "сравнений" этих двух языков и везде только общие слова, как будто написанные GPT, никакой конкретики, примеров.
Логика статьи не в том, что дженирики плохо, а в том, что если в Go превращается в Rust, то почему бы сразу не писать на Rust?
Вы считаете, что в примере из статьи дженерики улучшили код? Этот код легко прочитать и понять?
У GORM есть raw SQL запросы https://gorm.io/docs/sql_builder.html
На Rust это не быстрая ORM, для Go навскидку нашел пару сравнений производительности https://blog.jetbrains.com/go/2023/04/27/comparing-db-packages/ и https://github.com/efectn/go-orm-benchmarks/blob/master/results.md, но результаты почему то в них разные. Когда в свое время выбирал ORM, Gorm был вроде один из самых быстрых.
На нем можно писать под web (backend+frontend, wasm), Android, iOS, UI приложения для Windows, Linux, MacOS ?
Согласен с вашими высказываниями. Насчет языков мне кажется у Go и у Rust одинаковые концепции, они близки по подходам к разработке (через интерфейсы/трейты, модули). Rust решил проблему утечек памяти и рантайм ошибок, Go обеспечил быстрое обучение + быстрая разработка мелких программ. Оба языка обеспечивает небольшое использование памяти программами и отличное быстродействие. Но лично мне не нравится в Go после вызова каждой функции (которая возвращает ошибку) писать обработку ошибки.
От CRM мне нужна поддержка подключения к разным СУБД через одно API и мапинг данных из строки БД на структуру. Сами запросы я предпочитаю писать на SQL.
Какую ORM вы посоветуете для Go ?
Шаблонами это называется в С++. С тех пор и в других языках называю это шаблонами.
Она же вышла еще в июле.
Еще нужно также проверить Apple AppStore
Мне кажется описаны рассуждения аналитика, а не архитектора. Архитектор продумывает реализацию под конкретное ТЗ. Если в аналитик в ТЗ указал, что нужен контроль отрицательных остатков, то он должен быть.
Разрешать минусовые остатки можно только на кассах, где покупатель стоит с товаром. В других случаях (опт) нельзя. Например в резерве по Контрагент1 стоит предоплаченный товар. Пришел Контрагент2 и менеджер продал ему этот товар. Реализация провелась в минус, но менеджеру на это все равно, ему главное продать и получить свой процент. Далее пришел Контрагент1 за своим оплаченным товаром, а его нет. (и следующая поставка через полгода....)
Получается, что например, если у меня две сетевых карты, каждая подключена к интернету через своего провайдера и я запущу такой сервер на Go, то все запросы на любой сетевой интерфейс будут идти в этот Go-сервис и ответ этот сервис будет слать через любой из двух сетевых интерфейсов выбрав по определенному алгоритму? Или в чем смысл такого сервера?
С клиентом более менее понятно, например можно грузить большой файл одновременно и через WiFi и через сотовую сеть.
Напишите, как зарегистрировать аккаунт разработчика на юр. лицо из РФ и оплатить его.