я думаю потому что у меня процессор не последнего поколения

и память DDR3 1600

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

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

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

Представь ситуацию... в мире работет и производится (на замену ежегодно) порядка семи миллиардов штук электро-двигателей различной мощности и исполнений. Уменьшение потребления на 20-30% (с увеличением мощности), дает экономию гигаваты электричества (миллиаров рублей или долларов)

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

Но интерфейс у неё будет чисто сишный. А его ещё и сделать надо, он автоматически не делается. Либо делать крестовый интерфейс, но тогда применение этих dll сильно ограничивается. То есть даже с другой версии крестового компилятора могут возникнуть проблемы.

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

вы, я надеюсь, не забываете GOMAXPROCS=1 ставить?

нужен гайд, как делать тру бенчи

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

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

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

Биндинга?

Кстати на счёт иммутабельности, вместо того чтобы вводить ключевое слово, почему бы не ввести ее в виде иммутабельных типов? Например 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 кода...

Биндинга?

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

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

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

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 кода...

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

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

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

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

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

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

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

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

Ну вообще-то нет.

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

может)) весь пропосал про иммутабельные типы если внимательно почитать)

Достаточно взглянуть на тот же питон.

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

что такое "биндинг"?)

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

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

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

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

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

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

Нет.

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

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

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

Object.freeze

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

указатель это тип. *T иммутабельный указатель это тоже тип. const *T указатель на иммутабельный объект это тоже тип. * const T и иммутабельный указатель на иммутабельный тип - тоже тип. const * const T 2.9.1. Pointer Examples https://github.com/romshark/Go-2-Proposal---Immutability#291-pointer-examples

привет c++

только там const *T - это указатель на иммутабельный тип

вроде

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

нет в JS иммутабельности, там только shallow immutability, я её называю fake & useless immutability. можно изменить поле const объекта и рантайм даже не пикнет ? а freeze это не решение, ибо, опять-же, shallow... deepfreeze сильно бьёт по производительности

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

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

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

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

Опять вы оптимизируете производительность до замеров

в общем я предвижу reject пропозола с формулировкой «это не нужно», в общем, как и всегда

смотрите у нас есть rust и go. оба языка новые. на go у нас есть несколько больших сложных проектов. на rust у нас есть какой-то фейспалм. мне кажется, уже можно сказать, что rust не выстрелил.

Можно кстати сравнить. Есть parity , а есть go-eth. Два проекта реализуют одинаковую логику и спекуу.

Оба достаточно большие

Можно

нет в JS иммутабельности, там только shallow immutability, я её называю fake & useless immutability. можно изменить поле const объекта и рантайм даже не пикнет ? а freeze это не решение, ибо, опять-же, shallow... deepfreeze сильно бьёт по производительности

В JS у const обычная семантика const *T

в общем я предвижу reject пропозола с формулировкой «это не нужно», в общем, как и всегда

Скорее всего

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

да, давайте плюнем на производительность, нагородим кодогенерации, и сделаем всё всё всё ЛИШЬ БЫ не облегчать себе работу иммутабельными типами))

в общем я предвижу reject пропозола с формулировкой «это не нужно», в общем, как и всегда

Иммутабельность нужна и поэтому на эту тему появляется много пропозалов, но const не примут, да

Иммутабельность нужна и поэтому на эту тему появляется много пропозалов, но const не примут, да

go way - это реализация иммутабельности с помощью генерации геттеров и сеттеров на каждый чих

go way - это реализация иммутабельности с помощью генерации геттеров и сеттеров на каждый чих

У вас странное представление о говэй

Опять вы оптимизируете производительность до замеров

я не оптимизирую, то что интрерфейсы не бесплатные, как и впрочем копии, каждому должно быть понятно... у меня лишь возникает вопрос: зачем? если этого можно добиться без лишней кодогенерации, копий и интерфейсов и НЕ терять производительность вовсе

У вас странное представление о говэй

ну да, ведь иметь нормальный пакетный менеджер из коробки это то же go way, хотя подождите ка….

ну да, ведь иметь нормальный пакетный менеджер из коробки это то же go way, хотя подождите ка….

Говэй это простота и читабельность, в го не стремятся добавит побольше новых фич, но при этом стремятся не ломать ничего старого

Говэй это простота и читабельность, в го не стремятся добавит побольше новых фич, но при этом стремятся не ломать ничего старого

ну вот, иммутабельность через новое ключевое слово - это новая ненужная фича, как я и писал до этого

ну вот, иммутабельность через новое ключевое слово - это новая ненужная фича, как я и писал до этого

Нет, скорее чужеродная реализация нужной фичи

Про иммутабельность в том или ином виде разговоры идут давно, никто не говорит что это не нужно

Говэй это простота и читабельность, в го не стремятся добавит побольше новых фич, но при этом стремятся не ломать ничего старого

Простота лишь в плане изучения, а вот читабельность - это вряд-ли. Го-код очень плохо передает намерения программиста, а ещё его много.

Его много но он очень легко читается, когда тыс каждый день ревьювишь тонны кода это становится очень ценным

Простота лишь в плане изучения, а вот читабельность - это вряд-ли. Го-код очень плохо передает намерения программиста, а ещё его много.

Возможно есть более читаемые, но я не сталкивался

Его много но он очень легко читается, когда тыс каждый день ревьювишь тонны кода это становится очень ценным

Легко читается только когда точно знаешь, что код должен делать. Иначе приходится гадать на кофейной гуще.

Возможно есть более читаемые, но я не сталкивался

А с какими языками вы вообще работали?

ERROR: S client not available

А с какими языками вы вообще работали?

C,C++, java, js, Python, ruby, php

Чето ещё наверняка но меньше

Ну есть конечно SQL. Тот тоже хорошо читается

Раст например гораздо более сложен и замысел автора гораздо менее очевиден

Но там может нехватка знания языка

Хорошо читаются декларативные языки, например тот же SQL. Го же не даёт никаких возможностей даже для того, чтобы написать декларативный DSL, для обработки, например, итерируемых объектов.

Но там может нехватка знания языка

Какой смысл говорить о читабельности языка, который ты даже не знаешь?

Ну я пытался освоить, написал пару простеньких хелловордов на базе libp2p но упёрся как раз в то что очень тяжело читать чужой код и забросил

Иммутабельность нужна и поэтому на эту тему появляется много пропозалов, но const не примут, да

если const не примут тогда не видать нам в Go 1.x иммутабельности совсем

go way - это реализация иммутабельности с помощью генерации геттеров и сеттеров на каждый чих

читайте пропосал, поймёте что getter'ы / setter'ы тут совершенно не при чём и не решают перечисленные проблемы и вообще кодогенерация это никак не Go way, иначе бы она была встроена в язык (generics anybody?) а не просто в toolchain

Хорошо читаются декларативные языки, например тот же SQL. Го же не даёт никаких возможностей даже для того, чтобы написать декларативный DSL, для обработки, например, итерируемых объектов.

Предполагаю, что вы путаете читабельность и выразительность, го невыразительный, но читабельный Есть много выразительных языков, но читаются они хуже

ну вот, иммутабельность через новое ключевое слово - это новая ненужная фича, как я и писал до этого

это вам она не нужна, что не значит что она всем не нужна. Если вам она не нужна - спокойно игнорируйте, ибо вас никто не заставит её использовать даже если пропосал примут и реализуют, можете по старинке писать всё в мутабельном стиле а через новый keyword я не предлагал

Предполагаю, что вы путаете читабельность и выразительность, го невыразительный, но читабельный Есть много выразительных языков, но читаются они хуже

Нет, я ничего не путаю. Читабельные языки - те, которые позволяют понять не только, что код делает, но и зачем он это делает.

да за живое вас задело

прямо бомбит

это вам она не нужна, что не значит что она всем не нужна. Если вам она не нужна - спокойно игнорируйте, ибо вас никто не заставит её использовать даже если пропосал примут и реализуют, можете по старинке писать всё в мутабельном стиле а через новый keyword я не предлагал

Изменится чтение чужого кода

это вам она не нужна, что не значит что она всем не нужна. Если вам она не нужна - спокойно игнорируйте, ибо вас никто не заставит её использовать даже если пропосал примут и реализуют, можете по старинке писать всё в мутабельном стиле а через новый keyword я не предлагал

вы зачем то объясняете мне то, что я сам прекрасно знаю, выше я озвучил не свою позицию, а позицию разработчиков языка и с 99% вероятностью предсказал результат работы над этим пропозолом

Нет, я ничего не путаю. Читабельные языки - те, которые позволяют понять не только, что код делает, но и зачем он это делает.

Переменные функции нормально именовать надо

Нет, я ничего не путаю. Читабельные языки - те, которые позволяют понять не только, что код делает, но и зачем он это делает.

Ну вот в го с этим нет проблем

Его много но он очень легко читается, когда тыс каждый день ревьювишь тонны кода это становится очень ценным

когда из определения функции не понятно: 1. мутирует ли она переданные ей объекты 2. можно ли мутировать то что она возвращает 3. имеет ли она side-effect'ы на объект если это метод это вы называете читабельным? Обычно это называют неоднозначным кодом и он нечитабелен и опасен (ambiguous code)

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

когда из определения функции не понятно: 1. мутирует ли она переданные ей объекты 2. можно ли мутировать то что она возвращает 3. имеет ли она side-effect'ы на объект если это метод это вы называете читабельным? Обычно это называют неоднозначным кодом и он нечитабелен и опасен (ambiguous code)

Да, я называю го читабельным, по крайней мере в сравнении с другими яп

когда из определения функции не понятно: 1. мутирует ли она переданные ей объекты 2. можно ли мутировать то что она возвращает 3. имеет ли она side-effect'ы на объект если это метод это вы называете читабельным? Обычно это называют неоднозначным кодом и он нечитабелен и опасен (ambiguous code)

если что-то возращает указатель, можно мутировать ?

Переменные функции нормально именовать надо

Ага, а ещё доку писать и обновлять вовремя. Говорю же, детсад, а не инженерная область.

В инженерии все давно поняли, что людям доверять нельзя.

Ага, а ещё доку писать и обновлять вовремя. Говорю же, детсад, а не инженерная область.

Да даже SQL можно писать абсолютно нечитаемо.

Да даже SQL можно писать абсолютно нечитаемо.

Можно. Но его хотя-бы можно писать читаемо, с го же такого не прокатит.

Именуй все таблицы и переменные как a, b, c, d

Можно. Но его хотя-бы можно писать читаемо, с го же такого не прокатит.

Почему? С го можно писать читаемо

Изменится чтение чужого кода

да, изменится, в лучшую сторну, станет яснее что автор имел ввиду

да, изменится, в лучшую сторну, станет яснее что автор имел ввиду

Изменится в плане учебник от go 1.10 не даст понимания что это за херь и надо переучивать программиста