Или Лёха, не знаю, кто бенч писал

Блин... Я это все прочитал. Целый день некогда было залезть в чат, а тут 500> сообщений. Роман совершенно прав, dangling pointers, pointer aliasing — это беда языка, если её не решить хоть каким способом. Скала, раст решили эту детскую проблему. Проблема очевидна только тем, кто её понимает. Начать понимать её можно только на больших командах (точнее разными командами на одном проекте), с очень разношерстной публикой от новичков до опытных. На проекте, где как обычно некогда разбираться, что делает чужой код/либа, но вдруг!! оказывается что она меняет твои данные (состояние), которые ты не ожидал для изменения! И не ты их сам сознательно поменял, а произошёл "side effect" и цепочка выполнения, которая к этому привела, оказалась "очень вычурной и витеиватой". Кто с этим сам не сталкивался, писал только "домашние" проекты, тот к сожалению мало понимает суть проблемы, увы.... Эта проблема отсутствует в скала, потому что заложена в языке, тк сделать мутацию как сайд-эффект можно только сознательно и тогда коллеги это внимательно изучат, насколько это оправдано. Раст решил это на уровне компилятора. Это же решение ОЧЕНЬ НЕОБХОДИМО в компиляторе Go. Но есть сомнения, как вообще создатели го относятся к этой идее? Какие были или нет контакты, комменты от них, Роман? Может имеет смысл бомбить их на почту, в гугл группе, в слак каналах? Какие кто знает "наиболее прямые точки доступа" к создателям языка и компилятора? Поставить star + watch в гитхабе — это почти ни о чем... Нужно больше усилий и я понимаю Романа и его постоянные попытки форсить и рекламировать свой proposal на канале. Но нужны другие, более "прямые и точные каналы", чтобы обращаться к "главным го разработчикам". Роман, думаю ещё стоило бы сделать более наглядные (то ли простые, то ли наоборот quiz, не очевидные примеры) с примером такого поведения, которое disaster. Да, иногда вы можете увидеть и дать кому то" по рукам" в своей команде, но лучше, чтобы за вас это делал компилятор!

Ты это

Не факт, что скорость работы программера будет выше на расте/скале чем на го, если взять рандомного прогера и потратить одинаковое время на изучение языка

ты так пишешь будто иммутабельные типы усложняют язык настолько что он начинает обрастать ржавчиной (превращается в Rust) 😅

Под "скоростью" я подразумевал немного другое, извините, не совсем точно выразился. Речь не про скорость кодинга или проектирования. Цена ошибки и цена её исправления, которая займёт время и нервы (а произойдёт она как правило на продакшн, и как бывает после свежего деплоя). Цену этого сложно вычислить "легко и точно". Но лучше и правильнее это сделать в языке и компилятором, даже за счёт "сложных проверок" или "увеличения времени компиляции", чем потраченными человеко-часами. Кто этого не понимает, увы, его убедить, что это важно сложно. Это только с опытом приходит, что лучше этого гемороя НЕ иметь и столкнуться "иногда", чем иметь заложеннвй в языке, для "супер скоростной компиляции".

Не факт, что скорость работы программера будет выше на расте/скале чем на го, если взять рандомного прогера и потратить одинаковое время на изучение языка

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

а разве в rust непродуманная система immutability?

В хаскеле вообще mutability нету (точнее есть, но оно в монады там спрятано).

То есть хаскель - это вообще иммутабельность, функциональщина, типизация возведённые в абсолют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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*)

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

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

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