На Rust запилили Coroutine, Go можно выкидывать?

Ага, мазохистам может быть «удобна» сложившаяся ситуация.

Так вкусовщина же, говорю. Кто-то для тебя мазохист, а для кого-то мазохист ты. Объективные критерие-то где?

Или ты правда хочешь сказать, что подключение библиотеки добавлением одной строчки в проекты хуже чем скачать сорцы и разбираться как это собрать?

Во многих случаях в cmake примерно одной строкой и делается. Иногда не делается, да

При том, что хватает любителей «оригинальных» систем сборки.

И что? Им не жить теперь? Если хватает, значит эти системы сборки имеют право на жизнь, как и разработчики, их использующие.

Откуда столько желания всех загнать в какой-то лагерь?

Забавно, да. Учитывая, что я говорю, что удобно иметь тулзу «из коробки», а ты отвечаешь, что их много. Как раз потому что стандартных и нет.

Стандартных нет, потому что условия разные. Давай еще начнем геноцид тех, кто использует rpm, а не deb. Или наоборот. И опять ты забываешь, что языки-то разные используются. Иногда даже в одном проекте и в одной системе сборки.

В расте зоопарка нет, например. Или он не нативный?

Он пока фактически не существует. В том смысле, что ничем себя не проявил. У меня просто мало проектов, где был бы задействован один язык.

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

И это, пожалуй, одно из немногих качеств C++, которые мне нравятся. Из-за этого я за свою практику успел использовать его в очень и очень разных условиях и проектах. От железок до GUI, от игр до распределенных систем и высоконагруженных backend'ов, от заточки под конкретные архитектуры и ОС до кроссплатформа.

ы?

Вот. Пока нестабильная функция, но судя по обсуждениям, скоро станет стабильной.

Ну и на границе потоков всегда можно обработать.

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

Не вместо. Ну и вторая функция к «обработке ошибок» может вообще отношения не иметь. Отсутствующее значение может быть вполне валидной ситуацией.

Не вместо

Ты же не можешь уже достать ошибку? Значит именно вместо.

Ну и вторая функция к «обработке ошибок» может вообще отношения не иметь

«Позволяет» и «может отношения не иметь» никак не противоречат друг-другу.

// 1

go и rust - это разные языки и для разных целей. один - это такой питон, но сделанный прилично, а второй - это такая типобезопасная сишечка.

Мда. В итоге «мы не делаем нормальные исключения, но дадим вам костыли».

один - это такой питон, но сделанный прилично, а второй - это такая типобезопасная сишечка.

Go похож на Python, а Rust на Си только областью применения.

Проверяет и кидает исключение.

Да ладно? Почему я другое вижу:

The behavior is undefined if *this does not contain a value

В бусте аналогично. Да, там есть отдельные методы, которые кидают исключение, но это выстрелить, причём случайно (ведь проще разыменовать, а не нужные методы дёргать), в ногу проще простого.

в rust тоже можно не заморачиваться с Option.

В безопасном коде нельзя. Более того, с Option работать удобно. Так что нет искушения прибегать к unsafe чтобы что-то выгадать (кроме производительности, но это, опять же, не тот случай).

Аналогично - игнорирование и «съедание» ошибки.

Нет.

Можно - unsafe

Случайно - нельзя. В этом и разница.

а еще можно выпасть в panic через unwrap

Это не неопределённое поведение. И вполне может быть желательным.

Тебе не кажется, что ты сам себе противоречишь?

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

В плюсовом optional тоже есть подобные методы. Вот только там обратиться случайно к инициализированному значению возможно. В расте - нет.

я скорее про стиль использования

жабе

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

Объективные критерие-то где?

Лёгкость использования.

Во многих случаях в cmake примерно одной строкой и делается.

Да, Cmake немного спасает. Жаль только он не единственный, да и местами мог быть лучше. Ну и главное - сам либы скачивать и собирать он не умеет.

И что? Им не жить теперь?

Как по мне, то да. Для публичных проектов, по крайней мере.

Откуда столько желания всех загнать в какой-то лагерь?

Когда-то я думал точно так же. Раздражали языки навязывающие форматирование и т.д. Потом пришло понимание, что единообразность - это хорошо и удобно.

Но вообще я ж не против «альтернативных реализаций». Вот только тут есть нюанс. Скажем, есть у нас система сборки «из коробки». И если она чем-то не устраивает, то создают новые. И они или стимулируют развиваться стандартную или сами становятся стандартными. Всё здорово.

И совсем другое, если тупо ничего нет. И каждый лепит костыли как может. В соседней теме цитировали одного из разработчиков буста. На вопрос, что он больше всего хотел бы от языка - это как раз пакетный менеджер.

Из-за этого я за свою практику успел использовать его в очень и очень разных условиях и проектах. От железок до GUI, от игр до распределенных систем и высоконагруженных backend'ов, от заточки под конкретные архитектуры и ОС до кроссплатформа.

Не вижу как это связано с тем, что у языка нет единой двигающей силы с деньгами.

В итоге «мы не делаем нормальные исключения, но дадим вам костыли».

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

javacard в твоей банковской карте плачет от своей неподходящести.

Как-никак, мой основной инструмент - С++. И я был бы очень рад, если бы либы подключались так же легко, как в языках, где есть свой «менеджер пакетов».

мне тут несколько раз доказывали что в C++ это не нужно, я не верил

врали что ли?

Она разве прям на них исполняется? там же блоб вроде обычный. Да и обкусанная она.

прямо там. Но обкусаная, да.

Вот как раз таки мне не нравится, что «практически исключения». Сейчас тебя дисциплинирует то, что нельзя просто так взять и обработать панику, это именно ситуация, когда софтина вываливается. Поэтому когда ты что-то делаешь с IO, например, тебя заставляют проверять результат, а не просто сказать «unwrap, а там разберёмся».

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

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

javacard в твоей банковской карте плачет от своей неподходящести.

К джаве это относится чисто формально. Сборки мусора там нет, кстати.

Случайно - нельзя.

Повторяю вопрос(может пропустил ответ). Чем так уж сильно отличается _ от unsafe в данном случае?

В этих двух языках до сих пор не запилили классы?

врали что ли?

Они-то может и не врали, но это не значит, что если бы «стандартный» менеджер пакетов для С++ появится, то куча народу не вздохнули бы с облегчением.

А то ты сам не знаешь как это бывает. Спроси ты про лямбды то С++11, то многие начали бы рассказывать, что они не нужны. Думаю и сейчас такие имеются. И так практически с любой фичей - её надо распробовать. Ну и консервативность.

Не вижу как это связано с тем, что у языка нет единой двигающей силы с деньгами.

Блин, читай D&E. Это все следствие «философии» Страуструпа. Там же он пишет, насколько хорошо, что никто не взял C++ под свое крыло, но при этом широко использовали.

И да, я согласен с философией, когда язык не выбирает что-то за тебя.

javacard в твоей банковской карте плачет от своей неподходящести.

Ты программировал javacard? Там такой огрызок от Java, что называть его Java - кощунство :)

но это не значит, что если бы «стандартный» менеджер пакетов для С++ появится, то куча народу не вздохнули бы с облегчением.

Я не очень понимаю, каким ты его видишь. И чем тебе не подходят нативные пакетные менеджеры?

а класса не нужны, до тебя еще не дошло?

Вот как раз таки мне не нравится, что «практически исключения».

Ну я сторонник исключений (где надо), так что тут мы во мнениях не сойдёмся.

Поэтому когда ты что-то делаешь с IO

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

Тем более, что это не везде соблюдается и хорошо, а то у нас вообще все функции возвращали бы Option/Result из-за того, что аллокация может быть неудачной.

И чем тебе не подходят нативные пакетные менеджеры?

Тем, что в нативных нет, например, mio. И не будет еще долго. А если наконец появится - будет фиксированная версия, благословленная дистрибутивом.

Да, там есть отдельные методы, которые кидают исключение, но это выстрелить, причём случайно (ведь проще разыменовать, а не нужные методы дёргать), в ногу проще простого.

А еще в std::vector можно пользоваться не at, а опасным оператором []. Жуть.

В безопасном коде нельзя. Более того, с Option работать удобно

Было бы все было так радужно и удобно - не было бы пачек unwrap в реальном коде. А по факту, используя повсеместно Result, ты замусориваешь код заглушками как тут:

    fn to_i32(&self) -> Rect<i32> {
        Rect::new(Point2D::new(self.origin.x.to_i32().unwrap(),
                               self.origin.y.to_i32().unwrap()),
                  Size2D::new(self.size.width.to_i32().unwrap(),
                              self.size.height.to_i32().unwrap()))
    }

Причем авторы servo не пользуются в этом файле Result, оно им нахрен не упало, им только приходится пользоваться стандартным (и ненужным тут) трейтом. А вот, если б упало, и они еще сверху бы добавили своих Result - код бы стал еще веселее :).

// 1

И кстати хорошо, что авторы языка дали возможно забить на проверку и тупо писать .unwrap(), иначе этот кусок кода был гораздо больше.

// 1

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

Это понятно. Но какое отношение «всякие сверхнагруженные сервисы» имеют к играм и подобному? Совсем другие требования по нагрузке на оборудование и интерактивности.

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

Minecraft приуныл.

Неофициальный, да. Но в официальной версии есть движение в этом направлении.

работает еще хуже

Ты проверял?

Ты проверял?

Ага, пару поделок своих пытался переписать. Ну и еще хотел плеер (да, да очередной, написать). Вывод такой, что лучше уже ява.

а класса не нужны, до тебя еще не дошло?

Нужны. Читай Б.Мейера и там где он описывает ту или иную проблему и ее решение с помощью классов, предложи что-то свое взамен.

Тем, что в нативных нет, например, mio.

Так и в «стандартном менеджере языка» может чего-то не оказаться. И решать ты будешь примерно так же - поднимешь свой источник.

А если наконец появится - будет фиксированная версия, благословленная дистрибутивом.

И это хорошо. Нужно что-то дополнительное - делай свой источник. В стандартном менеджере будет тоже самое.

Повторяю вопрос(может пропустил ответ). Чем так уж сильно отличается _ от unsafe в данном случае?

Пропустил. Повторяю - в расте нельзя использовать значение, если вернулась ошибка. В Go - можешь.

Блин, читай D&E.

Читал. И что? Правильно я понимаю, что по другим пунктам возражений нет?

Реквестирую подробности. Что конкретно плохо?

Я не очень понимаю, каким ты его видишь.

Таким как Cargo или Cabal.

И да, я понимаю, что в ближайшее время (а то и вообще) ничего такого не появится.

И чем тебе не подходят нативные пакетные менеджеры?

Тем, что они не под все платформы? И тем, что они разные.

Тем, что в нативных нет, например, mio.

Так и в «стандартном менеджере языка» может чего-то не оказаться.

В «стандартизированном» mio есть.

А если наконец появится - будет фиксированная версия, благословленная дистрибутивом.

И это хорошо.

Кому как.

Нужно что-то дополнительное - делай свой источник.

Случай mio показывает, что со «стандартизированным менеджером» его сделают за тебя. Автор крейта, ага.

Случай mio показывает, что со «стандартизированным менеджером» его сделают за тебя. Автор крейта, ага.

Покажи мне репу с deb и rpm

зачем? всякое ненужно в систему тащить?

зачем? всякое ненужно в систему тащить?

Почему не нужное? «Нужное» == «то, что используется»

Ну я захочу же свой deb-пакет сделать. Мне нужно в зависимости прописать.

А еще в std::vector можно пользоваться не at, а опасным оператором []. Жуть.

Вообще-то, да - жуть. Учитывая, что как правило, у компилайтора есть возможность понять безопасно ли сейчас обращение. И в расте это есть - если мы итерируемся по контейнеру, то иметь дело с Option не приходится. Если же обращаемся по случайному индексу - то да, надо проверить.

Было бы все было так радужно и удобно - не было бы пачек unwrap в реальном коде.

Сколько ещё раз повторить, что unwrap и undefined behaviour - разные вещи?

пользоваться стандартным (и ненужным тут) трейтом. А вот, если б упало, и они еще сверху бы добавили своих Result - код бы стал еще веселее :).

Result - не трейт. И что значит «добавили своих Result»?

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

Не дали.

Но если бы они не дали и unwrap, то количество желающих писать на языке действительно сильно убавилось бы.

Они-то может и не врали, но это не значит, что если бы «стандартный» менеджер пакетов для С++ появится, то куча народу не вздохнули бы с облегчением.

Не стандартный, не для именно С++, но зато масса платформ и библиотек:

https://www.pkgsrc.org/#index5h1