Разработчики systemd рассматривают возможность внедрения Rust

вы пишете на том, на чём скажет менеджер или тимлид

Так и вижу: «мы набрали вас всех по объявлению о наборе java-программистов, но писать вы будете на go».

Я так устроился скалистом, а ушел эрлангистом. Всякое бывает.

Всё, чего нет в С++, нинужно. Как только появляется в С++, сразу становится нужным. Впрочем, ничего нового

Свое мнение я уже давно написал — в C++ не хватает модулей, и они влияют на скоростью компиляции только в положительную сторону. Я пытался начинать изучать C++ еще до C++11, и в том его состоянии кроме RAII и «безопасных макросов» по сути в нем никаких преимуществ над Си не было. С тех пор прошло время, и язык с безопасными макросами, RAII, замыканиями, и примитивным выводом типов мне уже нравится больше. Каких еще «фич из раста» не хватает в C++? Ума не приложу. Это же скорее Rust взял замыкания из C++, а не наоборот.

он тоже не однопроходной.

Тут можно подробнее? Страус в «Дизайн и эволюция С++» много рассуждает про то, почему они выбрали однопроходную модель

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

Свое мнение я уже давно написал — в C++ не хватает модулей, и они влияют на скоростью компиляции только в положительную сторону. Я пытался начинать изучать C++ еще до C++11, и в том его состоянии кроме RAII и «безопасных макросов» по сути в нем никаких преимуществ над Си не было. С тех пор прошло время, и язык с безопасными макросами, RAII, замыканиями, и примитивным выводом типов мне уже нравится больше. Каких еще «фич из раста» не хватает в C++? Ума не приложу. Это же скорее Rust взял замыкания из C++, а не наоборот.

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

Я боюсь, что книга уже устарела и компиляторы C++ поголовно двухпроходные

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

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

Какое-то время назад хотел вкатиться в Rust, мол «наконец норм язык сделали». Да, по синтаксису он получше C/C++ будет, и вроде как вывод типов продвинутый есть. Руки, конечно, так и не дошли. Тригерами стали два треда:

Посмотрел я этот ваш Rust (комментарий)
Посмотрел я этот ваш Rust (комментарий)

и

Гента распухла (комментарий)

После первого треда у меня начали закрадываться сомнения в том, что гарантии раста — это те гарантии, который я додумал ему по незнанию. Потом выяснилось, что Rust компилируется медленнее, чем C++, во что я сначала не мог поверить, потому что, казалось бы, ничего не может компилироваться дольше, чем C++. Оказывается, может.

В очередном растотреде я вывалил свои сомнения, и выяснилось, что они обоснованы, что обработка ошибок сырая, макросы сырые, гарантии безопасности в имеющемся виде непонятно кому нужны, компиляция очень долгая, а описание алгоритмов в safe форме оказывается жирнее, чем любой код C/C++, особенно учитывая отсутствие вывода типов в прототипах функций и необходимость описывать эти типы руками. И зачем этот ЯП нужен? «Чтобы было не как в C++»? «Я долго сомневался, но потом все-таки перешел на раст и возвращаться не хочется»? Вот забросят внезапно разработку раста — сразу захочется вернуться.

Я боюсь, что для совместимости с Си компиляторы С++ по прежнему однопроходные

Одно другому мешает?

Свое мнение я уже давно написал — в C++ не хватает модулей, и они влияют на скоростью компиляции только в положительную сторону.

В MS пока так:

VSO-1330581 «Throughput for Standard Library Header Units»

Header units are currently 4.6x faster than includes, but further improvement is probably possible.

https://github.com/microsoft/STL/issues/1694

Ждём новых оптимизаций от разработчиков компилятора…

Header units are currently 4.6x faster than includes, but further improvement is probably possible

Да, вот настолько заголовки замедляют компиляцию. Когда-нибудь до них дойдет, что второй фактор замедления компиляции — это раздельная компиляция. То есть, риторика «раздельная компиляция позволяет не компилировать то, что не менялось» не так уж и корректна, потому что сама раздельная компиляция замедляет себя же.

Гента распухла (комментарий)

У растохейтеров каждый день 33 несчастья. У меня стоит две версии тулчейна полностью, в каждом одной документации на 450 мб - 1.9 гб. Откуда там распухло на 15 гб, вообще не представляю.

У растохейтеров каждый день 33 несчастья. У меня стоит две версии тулчейна полностью, в каждом одной документации на 450 мб - 1.9 гб. Откуда там распухло на 15 гб, вообще не представляю.

СборОчка же ж. Бинарники раста бегают более-менее, пусть и чуток больше в байтах аналогичных крестовых/сишных. Но сборка толстая до ужаса — 15 Гб нужно именно чтобы собрать раст. И нет, я не готов смириться со светлым будущим, где софт будет собираться еще медленее, чем сейчас, при этом требуя в разы больше дискового пространства. А представь на секунду, что «светлое будущее» наступило, весь софт писан на расте, такой безопасный из себя. И вот ты его пытаешься компилировать. Про компилирование целой ОС, вроде генту, я и вовсе молчу.

нехватка памяти.

Там не паника. (:

под Линем

ставишь инсталлером

Поднимается же рука такое писать.

https://www.linux.org.ru/search.jsp?q=%D1%82%D1%91%D0%B3&range=ALL&interval=ALL&user=torvn77&_usertopic=on&sort=DATE&section=

шта

Тёг вместо тега.

Вроде как всё таки паника.

Зачем ты собираешь Rust?

Откуда там распухло на 15 гб,

Подозреваю гентопроблемы. Человек не отличает «гентушник должен страдать собирая компилятор Rust вручную, когда есть -bin» от «на расте нельзя успешно разрабатывать свои проекты». Где-то между этими двумя утверждениями стираяется граница.

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

А представь на секунду, что «светлое будущее» наступило, весь софт писан на расте, такой безопасный из себя. И вот ты его пытаешься компилировать. Про компилирование целой ОС, вроде генту, я и вовсе молчу.

Существование генту не является необходимостью для светого будущего.

Но кроме этого… теоретически можно все crates разложить на статические или динамические библиотеки и тогда все будет собираться так же как и сейчас. Просто по дефолту этого не делают, собирают все зависимости каждый раз заново в рамках cargo. Но вон Дебиан не ленится и выкладывает Rust библиотеки в обычных -dev пакетах. Может хотят то же что и ты

Какая будет скорость сборки на твоих плюсах если бы все библиотеки для КАЖДОГО приложения собирали ВСЕ зависимости каждый раз заново? Например тот же gcc, включи все stages и все зависимости во время сборки

У крейтов есть фичи и они могут передаваться между крейтами по цепочке. Количество возможных комбинаций растёт очень быстро. Так что собирать все крейты заранее просто непрактично.

Не понял что не так с Посмотрел я этот ваш Rust (комментарий)?

Поднимается же рука такое писать.

Зато всё работает, а не как обычно при установке из реп.

Но это же как use флаги. В Gentoo их можно настраивать и в этом основная ценность дистрибутива. И они уходят потом в ./configure --with.... В других дистрах приходится принять решение что включить. Для Раста по идее ничего кардинально не меняется. Просто соберут несколько вариантов пакетов. И дебиан это делает для раста. Поищи все librust-... пакеты

Ну у гентушников своя альтернативная система ценностей.

Поискал. О_о Это безумие. Зачем они так? Хотя, я увидел только -dev пакеты.

И? Я вижу, что ты пытаешься донести какую-то мысль, но не понимаю какую и зачем.

Линь и инсталлер — это ещё цветочки.

Зато всё работает, а не как обычно при установке из реп.

Если ты имеешь в виду, что разработчики раста - упоротые мудаки, которые не осилили сделать пакетируемый тулчейн, то тут я с тобой согласен на 100%.

А вот если ты хочешь сказать что next-next-finish в линуксе это хорошо, то я вынужден промолчать.

Зачем ты собираешь Rust?

Не «собираешь Rust», а «собираешь Rust-ом». В данном случае появилась двусмысленность, потому что Rust собирается сам себя. А если бы компилятор Rust был написан на хорошем языке, то и сам бы собирался быстро.

Какая будет скорость сборки на твоих плюсах если бы все библиотеки для КАЖДОГО приложения собирали ВСЕ зависимости каждый раз заново? Например тот же gcc, включи все stages и все зависимости во время сборки

«Моих» плюсах? Я до сих пор считал, что ничего дольше, чем кресты, собираться не может. Rust меня удивил.

Видел zig?

Он меня удивил размером helloworld :)

const std = @import("std");

pub fn main() void {
    std.io.getStdOut().writeAll("Hello World!",) catch unreachable;
}

2048 байт для Windows x64 и 2040 байт для Linux x64.

https://imgur.com/a/xqwrEro

https://ziglearn.org/chapter-1/

Не понял что не так с Посмотрел я этот ваш Rust (комментарий)?

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

Смотрим сюда:

https://www.cplusplus.com/reference/string/wstring/

50 функций, менее десяти сложных вспомогательных типов данных. А теперь посмотри сюда:

https://doc.rust-lang.org/std/string/struct.String.html

70 одних трейтов, 90 методов на одном только String. Это ТИПИЧНАЯ ситуация для Rust.

Если ты имеешь в виду, что разработчики раста - упоротые мудаки, которые не осилили сделать пакетируемый тулчейн, то тут я с тобой согласен на 100%

Я так понимаю, имеется в виду позиция разрабов «rust можно ставить только через rustup»? Ну это неизбежная побочка у нестабильного языка.

Видел zig?
Он меня удивил размером helloworld

Там у них прям упор на аскезу, плана «никаких скрытых команд и платежей». Соответственно, язык очень просится на машинную генерацию своего кода. То есть, писать на нем в таком виде, в котором он есть, неэффективно.

Вроде как всё таки паника.

Так ведь там написано:

The default behavior of this function is to print a message to standard error and abort the process.

Панику можно перехватить, аборт - нет.

Элементарно, ватсон: хорошо там, где нас нет хорош язык до тех пор, пока ты на нем не начал интенсивно писать.

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

На бумаге красивый язык для написания надежных программ. По факту…

По факту ты на языке писать даже не пробовал, зато про факты рассказываешь. (:

обработка ошибок сырая

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

макросы сырые

Почему?

гарантии безопасности в имеющемся виде непонятно кому нужны

Это одна из основных фич языка. Хочешь сказать, что никто кроме тебя, не разобрался и просто повелись на рекламу? Или может всё-таки кому-то да нужны?

а описание алгоритмов в safe форме оказывается жирнее, чем любой код C/C++

А это просто враньё, особенно про «любой код».

особенно учитывая отсутствие вывода типов в прототипах функций и необходимость описывать эти типы руками

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

Ну а я по прежнему считаю, что явная и конкретная сигнатура функций - это благо для читающего код.

Вот забросят внезапно разработку раста — сразу захочется вернуться.

Ага, уже вот-вот забросят. Гугл, фейсбук, амазон и прочие специально подключились, чтобы забросить посильнее.

именно по этим причинам взлетит обязательно sarcasm mode off

макросы сырые

Не то что в сях, вот где макросы что надо.

но это следствие, а не причина, никто же раст до сишки не придумал sarcasm mode off

https://www.cplusplus.com/reference/string/wstring/ 50 функций, менее десяти сложных вспомогательных типов данных.

Ага, только ты забыл о перегрузке. Одних только конструкторов 11 штук, операторов присваивания - шесть, операторы сравнения тоже не в единственном экземпляре и т.д. Про специализацию std::hash ты тоже забыл.

70 одних трейтов, 90 методов на одном только String. Это ТИПИЧНАЯ ситуация для Rust.

Осталось объяснить почему гибкое и удобное API - это плохо.

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

Ну это неизбежная побочка у нестабильного языка.

Ну так это проблема мозиллы, не?

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

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

По факту ты на языке писать даже не пробовал, зато про факты рассказываешь

Пробовал, но о-о-очень мало. Мне недавно тыкали на то, что у меня в коде строки лишний раз копируются — пардон, что вы хотите от человека, который начинает знакомиться с объектом, у которого 70 трейтов и 90 методов? Кстати:

>> len(dir(''))
78

Строки питона проще будут, хотя, казалось бы, они с ног до головы слеплены из специализированных функций — но нет, в расте специализированных функций больше.

обработка ошибок сырая

Или всё-таки не «сырая», а «не такая, как мне нравится»?

Можно сказать «не такая, как мне нравится». Можно сказать «мне не нравится, когда мой код завален бесполезными вспомогательными конструкциями». Желающими сейчас припомнить Go сразу отвечу — при разработке Go допустили ошибки, и обработка ошибок — одна из них.

Это одна из основных фич языка. Хочешь сказать, что никто кроме тебя, не разобрался и просто повелись на рекламу? Или может всё-таки кому-то да нужны?

Да, хочу сказать. Хочу сказать, что корпорации понимают, зачем им нужен этот ЯП, остальные — нет, в большинстве своем. Как не понимали, зачем нужен PHP/Python/Java/C/C++. Просто пипл хавает что дают.

Вот забросят внезапно разработку раста — сразу захочется вернуться.

Ага, уже вот-вот забросят. Гугл, фейсбук, амазон и прочие специально подключились, чтобы забросить посильнее

Да я не спорю, что этот груз с нами уже надолго. Я рассуждаю по поводу мотивации. А мотивация такая: крупные корпорации поддержали — значит, язык не сдохнет. Увы, против рыночка не попрешь.

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

В соседнем треде я приводил аргумент, что на самом деле Perl/PHP/Python/Ruby/JS — это языки в которых тип «выводится» везде, но во время выполнения. И это чудовищно популярно, на текущий момент это намного популярнее всех языков с явным описанием прототипов.

Не то что в сях, вот где макросы что надо

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

Ага, только ты забыл о перегрузке. Одних только конструкторов 11 штук, операторов присваивания - шесть, операторы сравнения тоже не в единственном экземпляре и т.д. Про специализацию std::hash ты тоже забыл

Да, перегружены конструкторы. Да, перегружено присваивание? Всё? Может быть давай тогда пройдемся по методам трейтов у std::string::String? Там счет пойдет на сотни.

70 одних трейтов, 90 методов на одном только String. Это ТИПИЧНАЯ ситуация для Rust.

Осталось объяснить почему гибкое и удобное API - это плохо

Давай не путать гибкость с перегруженностью. Гибкость подразумевает тонкость.

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

Через 10 лет половина этих функций устареет.

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

Мы общались в куче тем, так что всего и не упомню. Но разве я тут противоречил процитированному? Действительно паттерн матчинг или система сборки (пусть даже из коробки) совсем не изобретение раста и есть много где. И так со многими фичами. Хотя бороу чекер, кажется, есть только в расте (из живых и не экспериментальных языков). Лично для меня «киллер фичами» являются явный ансейф, бороу чекер и просто современность языка (куда уже и входит наличие паттерн матчинга, карго и т.д.).

Но как это всё относится к тому, что язык хвалят только те, кто на нём не писал?

Впрочем, какая-то доля истины тут есть. Вот только те, кто на расте пишет, недовольны совсем не тем, что ты тут и в соседних темах перечисляешь.

пардон, что вы хотите от человека, который начинает знакомиться с объектом, у которого 70 трейтов и 90 методов?

Ну вот не надо тут. Про владение и лишние копирование и расто-букваре рассказывают и клиппи лишние клоны (включая неявные) показывать умеет. Ну и наконец, как человек топящий за минимальную «зашумлённость» сигнатур, ты должен уметь читать документацию, раз уж не хочешь получать информацию из типов.

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

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

Строки питона проще будут

Может быть, но из процитированного это никак не следует.