Из Go в Rust или ад generics

Что значит "вместо" если это ООП и есть?

Концепциями ООП являются инкапсуляция, полиморфизм и наследование. Как в Rust реализовано наследование?

Очень долгая компиляция. Даже в не очень большом проекте у тебя будет порядка 500 сквозных зависимостей и их все нужно собирать, а сборка долгая. В CI/CD сборку приходится ждать иногда по 10 минут

Собранные единожды зависимости разве не кэшируются?

Из Go в Rust или ад generics

Но тренд же сейчас наоборот в переходе с C/C++ на Rust, как раз за счет концепции управления памятью. А GC в Go наоборот записывают ему в минусы (в том виде, в котором он сейчас, из-за приостановки выполнения программы). Если нужен GC и "свобода" написания кода, то лучше выбрать Python или js. Я выбрал Go за то, что он компилируется в нативный код, статически типизированный, имеет свою концепцию интерфейсов вместо ООП и не требует ручного управления памятью (как С/С++), при этом синтаксически простой. После написания проекта на Go, и ряда последних статей на Хабре про Rust (где говорилось, что Go хуже), я решил еще раз на него обратить внимание (первый раз, давно, на нем писал драйвер и не рассматривал его как язык для прикладного ПО). И вот сейчас, после Go, я увидел что концепция та же, только не нужен GC, меньше кода писать, больше гибкости. Т.е. если сравнивать "в лоб", то код простого сервиса на Rust выглядит так же как на Go. Только для Go это "потолок", а для Rust "база". В итоге я пытаюсь услышать объективные доводы за/против перехода с Go на Rust. Пока кажется, что большинство разработчиков просто консервативны и противятся новому. (так же как в случае с Java и Kotlin)

Из Go в Rust или ад generics

Мне пока видится, что Go это подмножество Rust. У того же С++ другая концепция (ООП, классы, ручной контроль за памятью). Что есть в Go, чего нет в Rust? Могу предположить, что только концепция каналов. (GC в расчет не берем, т.к. в Rust он не нужен и в этом одно из его преимуществ). Никто из комментаторов ни приводит ни одного довода за или против Go/Rust, все суждения не объективны. Я пересмотрел кучу статей "сравнений" этих двух языков и везде только общие слова, как будто написанные GPT, никакой конкретики, примеров.

Из Go в Rust или ад generics

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

Из Go в Rust или ад generics

Вы считаете, что в примере из статьи дженерики улучшили код? Этот код легко прочитать и понять?

Из Go в Rust или ад generics

У GORM есть raw SQL запросы https://gorm.io/docs/sql_builder.html

Из Go в Rust или ад generics

На 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 был вроде один из самых быстрых.

Из Go в Rust или ад generics

На нем можно писать под web (backend+frontend, wasm), Android, iOS, UI приложения для Windows, Linux, MacOS ?

Из Go в Rust или ад generics

Согласен с вашими высказываниями. Насчет языков мне кажется у Go и у Rust одинаковые концепции, они близки по подходам к разработке (через интерфейсы/трейты, модули). Rust решил проблему утечек памяти и рантайм ошибок, Go обеспечил быстрое обучение + быстрая разработка мелких программ. Оба языка обеспечивает небольшое использование памяти программами и отличное быстродействие. Но лично мне не нравится в Go после вызова каждой функции (которая возвращает ошибку) писать обработку ошибки.

Из Go в Rust или ад generics

От CRM мне нужна поддержка подключения к разным СУБД через одно API и мапинг данных из строки БД на структуру. Сами запросы я предпочитаю писать на SQL.

Из Go в Rust или ад generics

Какую ORM вы посоветуете для Go ?

Из Go в Rust или ад generics

Шаблонами это называется в С++. С тех пор и в других языках называю это шаблонами.

IntelliJ IDEA 2023.2. Долгожданный LSP, встроенный AI-чат, апгрейд до Windows 10 и -Xmx2G

Только что вышла IntelliJ IDEA 2023.2

Она же вышла еще в июле.

Разрушители легенд: Как на самом деле магазины проверяют приложения на уязвимости

Еще нужно также проверить Apple AppStore

Зачем нужен архитектор 1С

Мне кажется описаны рассуждения аналитика, а не архитектора. Архитектор продумывает реализацию под конкретное ТЗ. Если в аналитик в ТЗ указал, что нужен контроль отрицательных остатков, то он должен быть.

Разрешать минусовые остатки можно только на кассах, где покупатель стоит с товаром. В других случаях (опт) нельзя. Например в резерве по Контрагент1 стоит предоплаченный товар. Пришел Контрагент2 и менеджер продал ему этот товар. Реализация провелась в минус, но менеджеру на это все равно, ему главное продать и получить свой процент. Далее пришел Контрагент1 за своим оплаченным товаром, а его нет. (и следующая поставка через полгода....)

Multipath TCP в Go

Получается, что например, если у меня две сетевых карты, каждая подключена к интернету через своего провайдера и я запущу такой сервер на Go, то все запросы на любой сетевой интерфейс будут идти в этот Go-сервис и ответ этот сервис будет слать через любой из двух сетевых интерфейсов выбрав по определенному алгоритму? Или в чем смысл такого сервера?

С клиентом более менее понятно, например можно грузить большой файл одновременно и через WiFi и через сотовую сеть.

Как я стал iOS разработчиком

Напишите, как зарегистрировать аккаунт разработчика на юр. лицо из РФ и оплатить его.

Два frontend фреймворка. Два подхода

SSR и SSG при таком подходе будут поддерживаться?

И мне больше нравится вариант отрисовки компонентов через функции, как в Compose Multiplatform (в котором есть компиляция в js) или SwiftUI

Ликбез по корутинам Kotlin

fun main() = runBlocking{
    println("program runs...: ${Thread.currentThread().name}")

    val taskDeferred = async {
        generateUniqueID()
    }

    val taskResult = taskDeferred.await()

    println("program run ends...:  
        ${taskResult}  ${Thread.currentThread().name}")
}

Чем это отличается от вызова обычной, не suspend, функции?

4 сценария, когда нужно сделать ставку на Kotlin Multiplatform, а не Flutter

Есть у меня нативное приложение под android (compose). Получает данные с сервера, отображает, хранит данные в sqlite и делает бэкап в хранилище. Решил сделать его кросплатформенным: android+iOS+desktop+wasm. Выбирал между kmp и flutter. На Хабре топят за kmp, выбрал его (точнее compose multiplatform). И... Ничего быстро не получилось. В процессе выяснилось, что используемые мной сторонние compose библиотеки собраны только под android, а под compose multiplatform даже аналогов нет, нужно писать с нуля. Работа с файлами, получение разрешений, открытие диалогов открытия/сохранения файлов находится в composable функциях (т. к. это интерфейс) и это нельзя шарить между платформами, нужно под каждую писать свою реализацию, свои экраны. На это уйдёт много времени и по сути это как дублирование кода. Еще неизвестно с какими проблемами придется столкнуться под web.

Таким образом выбор kmp в разы увеличил время разработки, требует навыков разработки под ios. (Приложение пишу я один). Поэтому мне пока не понятны восхищённые отзывы об kmp. И теперь опять перед выбором: писать все с нуля и долго на kmp (всетаки как язык Kotlin нравится) или перейти на flutter и быстро получить результат под все платформы...

А довод про поиск разработчиков считаю невереным. Для разработки на flutter нужен один разработчик, для kmp два. Это же дороже в два раза. При этом сам язык Dart проще Kotlin, его изучить можно за пару дней (естественно имея базу из Си подобных языков).