а вот это типо быстрее работает, чем обычный каст? func efaceToInt(eface interface{}) int { return (*(*int)((*[2]unsafe.Pointer)(unsafe.Pointer(&eface))[1])) }

у меня получилось 3846 ns/op vs 3626 ns/op

мои результаты

BenchmarkRemote0-4 200000 5566 ns/op BenchmarkNewList-4 300000 5851 ns/op BenchmarkRemote0Opt-4 200000 5704 ns/op BenchmarkNewListOpt-4 300000 5440 ns/op BenchmarkNewSlice-4 300000 4752 ns/op

.dll, .so они основа всех систем и приложений, ты сейчас ими пользушься пока пишешь)

твоя

так и есть

а вот и нет. 3 раза проверял. с точностью до наоборот все go version go1.11 darwin/amd64 mac os x BenchmarkRemote0 3807 ns/op BenchmarkRemote0Opt 3539 ns/op

а, логично тогда

BenchmarkRemote0-4 200000 5566 ns/op BenchmarkNewList-4 300000 5851 ns/op BenchmarkRemote0Opt-4 200000 5704 ns/op BenchmarkNewListOpt-4 300000 5440 ns/op BenchmarkNewSlice-4 300000 4752 ns/op

у меня была версия с (int)

Что серьезно за разрыв в 300-500 наносекунд спор идет?? :)

у меня .(int) медленнее работает :D

Что серьезно за разрыв в 300-500 наносекунд спор идет?? :)

представь сколько такая оптимизация для всех, в рамках планеты сэкономит электричества!

представь сколько такая оптимизация для всех, в рамках планеты сэкономит электричества!

представь сколько такая оптимизация для всех, в рамках планеты сэкономит электричества!

Это всё сишный интерфейс, то есть все функции - как старые добрые сишные с extern "C" с указателями и без всех крестовых возможностей. То есть никаких шаблонов к примеру. Хотя вроде Qt крестовые функции из dll экспортирует, но это не всегда возможно.

представь сколько такая оптимизация для всех, в рамках планеты сэкономит электричества!

написать .dll то можно и в C++ 🙂

BenchmarkRemote0-4 200000 5566 ns/op BenchmarkNewList-4 300000 5851 ns/op BenchmarkRemote0Opt-4 200000 5704 ns/op BenchmarkNewListOpt-4 300000 5440 ns/op BenchmarkNewSlice-4 300000 4752 ns/op

BenchmarkRemote0 300000 4284 ns/op BenchmarkNewList 500000 3951 ns/op BenchmarkRemote0Opt 500000 3948 ns/op BenchmarkNewListOpt 300000 4018 ns/op BenchmarkNewSlice 1000000 1589 ns/op

а вот это типо быстрее работает, чем обычный каст? func efaceToInt(eface interface{}) int { return (*(*int)((*[2]unsafe.Pointer)(unsafe.Pointer(&eface))[1])) }

Срань божья.

раст и го разные инструменты для решения разных задач. Rust это performance, Go это time-to-market.Я-ж не предлагаю убирать garbage collector)) но code safety нужен в любом языке, особенно в таком как го который сам по себе про конкуррентность. Concurrency и mutability это взрывоопасная смесь. Иммутабельные типы не будут особо нагружать компилятор, он от этого медленным не станет. Код Go 1.x от введения иммут типов не поломается. Возможность писать всё в мутабельном стиле никуда не исчезнет.

Кстати на счёт иммутабельности, вместо того чтобы вводить ключевое слово, почему бы не ввести ее в виде иммутабельных типов? Например i_int8/int8i

Кстати на счёт иммутабельности, вместо того чтобы вводить ключевое слово, почему бы не ввести ее в виде иммутабельных типов? Например i_int8/int8i

Кстати на счёт иммутабельности, вместо того чтобы вводить ключевое слово, почему бы не ввести ее в виде иммутабельных типов? Например i_int8/int8i

Кстати на счёт иммутабельности, вместо того чтобы вводить ключевое слово, почему бы не ввести ее в виде иммутабельных типов? Например i_int8/int8i

Биндинга?

Иммутабельность — свойство конкретного биндинга

1. в пропосале не описывается введение нового ключевого слова а перегрузка ключевого слова const: 4.4 Why overload the const keyword instead of introducing a new keyword like immutable etc.? https://github.com/romshark/Go-2-Proposal---Immutability#44-why-overload-the-const-keyword-instead-of-introducing-a-new-keyword-like-immutable-etc 2. потому-что тогда тебе придётся свои типы вручную писать в двух вариантах, мутабельный и немутабельный. Это можно делать уже сейчас, например оборачивать все типы интерфейсами и работать только через интерфейсы. Где-то использовать мутабельный интерфейс (с Write методами) а где-то немутабельный (только Read методы)). Но сколько же это boilerplate кода...

Связывания имени с данными.

Ну вообще не обязательно

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

Остальное контринтуитивно.

Иммутабельного типа быть не может.

Иммутабельность — свойство конкретного биндинга

const указатели это совсем другое.

а когда тонны boilerplate кода пугали евангелистов го? мне казалось, что у них фетиш на этом

Если я правильно понял, ты предлагаешь по имени проверять доступ к данным, тогда ты должен либо 1) запретить передачу по указателю 2) boxing мета-инфы типа вместе с ним (python way?)

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

Вот смотрите, в JS есть иммутабельные биндинги - const, а вот const указателей нет и по этому гарантии const в JS ничего не стоят, ибо почти все данные ссылочные.

const указатели это совсем другое.

Вот смотрите, в JS есть иммутабельные биндинги - const, а вот const указателей нет и по этому гарантии const в JS ничего не стоят, ибо почти все данные ссылочные.

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

ага, кодогенерации нам ещё не хватало)) всё она может решить, кроме пониженой runtime производительности ибо интерфейсы не бесплатные, как впрочем и копирование ну и конечно-же проблема explicit кодо-генерации кодогенерация, очевидно, не решает