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

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

а кто-нибудь на haskell пишет большие проекты, типа KDE?

Хаскель - не ООП (вообще). И на нём мало кто пишет.

Зачем вы копируете int?

а напиши свой вариант? а то я не понимаю, о чем ты

Хаскель - не ООП (вообще). И на нём мало кто пишет.

ну вроде в C++ с иммутабельностью не очень, но ведь на C++ большие проекты пишут?

в с++ в иммутабельностью все ок, благодяря ключевому слову const

в с++ в иммутабельностью все ок, благодяря ключевому слову const

в C++ нет проблем с shared mutable state?

ну вроде в C++ с иммутабельностью не очень, но ведь на C++ большие проекты пишут?

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

в C++ нет проблем с shared mutable state?

Везде есть, где проггер — человек-рукожоп

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

так вроде и сейчас особо нет из-за того, что на других языках либ написано меньше, чем на C++?

Ну сейчас раст вроде как потихонечку развивается.

раст как конкурент плюсам, ага...

раст как конкурент плюсам, ага...

А других вариантов особо и нет.

раст как конкурент плюсам, ага...

Сын батю обгонит, угу

Ну сейчас раст вроде как потихонечку развивается.

C++ существует больше 30 лет, за это время на C++ много либ написано, когда rust может заменить C++?

коллега @ruelephant, вы там бенчмарк мой посмотрели? я жду вашего заявления "я был не прав, на новом слайсе быстрее"

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

ты ещё скажи что нельзя было в Go типизацию завозить, слишком уж сложно код писать.. сделали бы как JavaScript, проверки типов аргументов мы писать в функциях не будем, будем писать для этого табличные тесты и бить по рукам за передачу неверных типов самостоятельно, да)) ибо зачем за это делать ответственным компилятор, Goэто же про быструю компиляцию!

C++ существует больше 30 лет, за это время на C++ много либ написано, когда rust может заменить C++?

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

Но только следует всегда учитывать, что кресты сложно изучать. А писать на них более-менее безбажный код ещё сложнее.

Но только следует всегда учитывать, что кресты сложно изучать. А писать на них более-менее безбажный код ещё сложнее.

сомнительно, что rust сможет заменить хотя бы C в ближайшие лет 10

коллега @ruelephant, вы там бенчмарк мой посмотрели? я жду вашего заявления "я был не прав, на новом слайсе быстрее"

ну я не спорю, на чистом слайсе

ты ещё скажи что нельзя было в Go типизацию завозить, слишком уж сложно код писать.. сделали бы как JavaScript, проверки типов аргументов мы писать в функциях не будем, будем писать для этого табличные тесты и бить по рукам за передачу неверных типов самостоятельно, да)) ибо зачем за это делать ответственным компилятор, Goэто же про быструю компиляцию!

Моё сообщение было насквозь ироничным, если что.

но мы то сравнивали СПИСКИ

сомнительно, что rust сможет заменить хотя бы C в ближайшие лет 10

Давайте сначала определимся, что вкладывать в слово "заменить".

Давайте сначала определимся, что вкладывать в слово "заменить".

использовать что-то вместо чего-то?

в с++ в иммутабельностью все ок, благодяря ключевому слову const

const_cast всегда даст возможность выстрелить в ногу)

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

ну вроде в C++ с иммутабельностью не очень, но ведь на C++ большие проекты пишут?

в C++ всё то что описано в пропосале - имеется и даже в том же виде (const qualifier)

в C++ нет проблем с shared mutable state?

проблемы есть, но есть и защита от них. А в го защиту пока что не завезли, хотя проблема имеется

использовать что-то вместо чего-то?

Использовать где именно? Если мы говорим про новые проекты, то думаю, что вполне можно брать раст (хотя это моё личное не подкреплённое ничем мнение) вместо сишки и даже крестов. Старые проекты конечно же уже не переписать, но в принципе можно линковать rust к сишному и плюсовому коду (хотя не без проблем скорее всего).

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

Не думаю, что их корректно сравнивать.

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

Раст все-таки единственный компилируемый язык со строгой статической типизацией без сборщика мусора

с++ как бы тоже не стоит на месте и развивается, никто не мешает пользоваться современными стандартами в новых проектах и не страдать от безопасности кода

Раст все-таки единственный компилируемый язык со строгой статической типизацией без сборщика мусора

++++

c++?

с++ как бы тоже не стоит на месте и развивается, никто не мешает пользоваться современными стандартами в новых проектах и не страдать от безопасности кода

UB никуда не делись ни в одном из новых стандартов.

c++?

У крестов же слабая типизация.

шта

https://play.golang.org/p/NcNtX-pVtAj BenchmarkRemote0-8 300000 4382 ns/op BenchmarkNewList-8 300000 4180 ns/op BenchmarkNewSlice-8 1000000 2162 ns/op

и ещё

кто-то из авторов начал размывать точность бенча

шта

У крестов слабая статическая типизация как и у сишки.

кто-то из авторов начал размывать точность бенча

операторы >/< и >=/<= имеют разную производительность

C++ существует больше 30 лет, за это время на C++ много либ написано, когда rust может заменить C++?

пока в новом языке можно использовать C/C++ библиотеки - всё окей (*нервно смотрю на Go*)

операторы >/< и >=/<= имеют разную производительность

Не уверен, что это важно

Не уверен, что это важно

мы бенчи пишем болтами меряться или всё-таки точный результат получить?

Моё сообщение было насквозь ироничным, если что.

сори, тут такой критики столько уже было что мне сложно иронию отличать))

Болтами, конечно!

ну вот и подумайте - как сборщик метрик из процесса отрепортит вам системную метрику?

зачем мне это думать, за меня уже подумали

Болтами, конечно!

так это

нихрена себе ты читер)))

смотри

Remote0 удаляет все инты меньше 50 или больше 60

а ты только с 50 до 60))

https://play.golang.org/p/nzc_38WPQjZ

пока в новом языке можно использовать C/C++ библиотеки - всё окей (*нервно смотрю на Go*)

Ну либы для крестов пожалуй нигде не заюзать кроме крестов. Вот сишные можно. C++ с обёртками в обычные функции с extern "C" тоже можно.

https://play.golang.org/p/nzc_38WPQjZ

играйтес, товарищи, я это имел ввиду

с операторами я уже не бегал

но я бы поставил все бенчи в одни условия

мы же удаляем 1000-10 значений, а не 10 значений

а что это за efaceToInt?

лицо попроще нельзя было сделать что ли

у меня такого не было

Ну либы для крестов пожалуй нигде не заюзать кроме крестов. Вот сишные можно. C++ с обёртками в обычные функции с extern "C" тоже можно.

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

Remote0 удаляет все инты меньше 50 или больше 60

разве? Remote0 удалает все инты меньше 50 или больше 60, а NewList и NewSlice оставляют все инты не меньше 50 и не больше 60 результат идентичный

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

да вот чет не особо

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

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

а в бенче первая цифра это количество итераций которые он "успел"?

ERROR: S client not available

что-то слишком уж круглое число

у меня получилось 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

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

это версия от @madgopher

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

запусти еще раз, что-то странно О___О

а шо не так?

BenchmarkRemote0Opt-4 медленнее, чем BenchmarkRemote0-4

так и есть

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

ору

версия какая?)

golang

твоя

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

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

а тфу

твоя

нет у тебя моей :D

я думал ты про версию бенча

go version go1.11 darwin/amd64

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

так и есть

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

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

неправильные пчелы!

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

@ruelephant https://github.com/golang/go/issues/27180

а мне то зачем это отдал?

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

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

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

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

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

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

не думай о наносекундах свысока ?

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

и на кластере у нас тоже

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

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

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

копейки

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

наш бенч уже перешел на уровень всепланетного запуска? ?