а как ты хотел

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

а я вообще не хотел в го - ситуация заставила )

В Go после Раста стрёмно тем, что ты хочешь мувнуть значение в замыкание, а оно само неявно копируется. И вроде бы всё ок, но как-то не по себе.

Семантика вьедается в мозги ппц

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

А ещё не всегда`nil` == nil

а мутировать без мутекса позволяет?

или атомарных операций

да

Причем мьютексы там стандартные-плохие: компилятор не проверяет, что мьютекс был взят перед использованием данных. Ну и для RWLock корректность Lock/RLock тоже возлагается на программиста.

мммм)

Ахахах думаешь, борроу-чекер - универсальная фича? )

В какой язык пальцем ни ткни - ограничений на мутацию нет

хаскель?

Ну в C++ можно хоть какое-то подобие безопасности сделать.

речь не идёт о языках без мутации вестимо

То есть отслеживать лайфтайм мьютекса не выйдет.
Но хотя бы можно не дать использовать данные без залоканного мьютекса.

Модель памяти гоу достаточно стандартная - happens-before и тп (Те ничего совсем нового там в принципе нет). Понятно что после rust уже привыкаешь что к тому что компилятор по рукам бьет если что не так. Чем меньше многопоточного кода у в программе (и он сосредоточен именно там где он нужен) тем программы проще поддерживаются. Приятно конечно скинуть часть работы на компилятор - но реальность такова что еще N-лет корректность большей части многопоточного ПО будет анализироваться в основном разработчиками, а не тулами

Кроме rust (и может есть каких-нибудь изотерических языков) out of the box чтобы компилятор делал проверки аналогичные rustc? Наверное нет,  мутексы как мутексы. Они не могут быть “плохими” - программист проверит вместо компилятора