Из 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, его изучить можно за пару дней (естественно имея базу из Си подобных языков).

Golang глазами PHP-программиста

По моему мнению громоздкий синтаксис у C#, Java, Kotlin, C++

Пример синтаксиса на C# (на Java похоже)

[Anotation1]
[Anotation2(Enum.Param)]
public static void TryAddSingleton<TService, [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)] TImplementation>(this IServiceCollection collection)
            where TService : class
            where TImplementation : class, TService
        {...}

У Kotlin плюс ко всему его DSL, когда вызов функции пишется как объявление функции (и получаются многоярусные вложения на несколько экранов)

val appModule = module {
    single<UserRepository> { UserRepositoryImpl().apply{  
                                this.param = MyClass.GetParam()
                                  }
                            }
}

А на Golang исходный код проще всего читать, он понятнее, синтаксические конструкции прощее. Минимализм конструкций языка позволяет после пары часов изучения уже писать достаточно качественное ПО.

В Kotlin же например только 5 scope function: let, run, with, apply, и also. И программист глубоко не знакомый с языком, читая код не поймет, что там происходит? не прочитав документацию.

Почему ты не можешь просто начать меньше есть? (Не)очевидные факторы аппетита

Я наоборот не могу набрать вес. Ем целый день, но по подсчету калорий выходит всего максимум 1600-1700. Физически съесть больше не могу, так как и так почти передаю, и поменять на жирные продукты не могу, т.к. проблема с ЖКТ тогда будет. Пример меню (один прием пищи - 250-400 грам):

Завтрак: Овсяная каша, куриная грудка отварная с сыром, банан

Перекус: яблоко, банан

Обед: картофельное пюре, котлета куриная

Перекус: банан

Ужин: рис, котлета из свинины, салат из овощей

Практически не ем: мучное (булки,хлеб), сладости: сгущенку, торты, печенья и прочее.

Голода никогда нет, так как ем много. И очень хочу набрать вес, но получается медленно.

Практика Go — Обработка ошибок (2 часть)

В тех же Java, Kotlin, C# нужно так же чуть ли ни каждую строчку оборачивать в try-catch

Вот пример для Kotlin:

import java.io.IOException
import java.nio.file.Files
import java.nio.file.Paths
 
fun main() {
    val fileName = "/home/data/file.txt"
    try {
        val lines = Files.readAllLines(Paths.get(fileName))
        println(lines)
    } catch (e: IOException) {
        e.printStackTrace()
    }
}

А то, что не обернуто в try-catch, нужно проверить на null. Пример:

companydb = getCustomer(name, inn);
if (companydb == null) {}

Получается в Go много "if err != nil", а в Java/C# много if ( p != null ).

В той же 1с очень редко используется перехват исключений, вся обработка ошибок построена на том, что функция возвращает "неопределенно" (null) в случае ошибки, а вызывающая сторона проверяет, что вернулось.

И проверки на null после каждого вызова функций никого не смущает.

Мне тоже не нравится, что в Go код "замусоривается" проверками ошибок, но прочитав статью, понял, что и механизм исключений не лучше. Получается лучший вариант, это вариант описанный в разделе "Устранение обработки ошибок за счёт устранения ошибок"

Практика Go — Concurrency

В коде примера метод Hello объявлен на ресивере указателя Ben или Jerry. Если вместо этого объявить метод на значении Ben или Jerry, решит ли это проблему гонки данных?

Не решит, т.к. во первых проблема не в данных интерфейса, а в том, что тип и данные записываются разными операциями записи, между которыми может вклинится другая операция. И в самом интерфейсе всегда хранится ссылка на данные (uintptr). Не важно, что мы определили приемником значение, а не ссылку.

Или я не прав?

Практика Go — Основы

Итак, если пустая структура не содержит полей и не содержит данных, то зачем она нужна? 

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

И все? Зачем?

Ad-hoc-полиморфизм и паттерн type class в C#

Конечно, есть вариант решить задачу «в лоб» — писать перегрузку на каждый тип данных, однако хотелось бы заставить компилятор помогать нам, не создавая 100500 методов.

Т.е. вместо 100500 методов вы предлагаете создать 100500 реализаций абстрактного класса? В чем профит?