В чём его преимущество и недостатки перед Си?

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

>>1227132
>потоки без гонок данных
ето как?

>>1227135
https://doc.rust-lang.org/nomicon/races.html

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

>>1227137
Если ты не знаешь что такое многопоточность, то думать про гонки тебе еще очень рано.

>>1227137
Кыш блять

>>1227127 (OP)
>github.com

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

>>1228343
http://c-faq.com/decl/spiral.anderson.html
Да что ты говоришь?

>>1228345
Прости, я совсем не понял смысл того, что ты приложил этот линк.
Возможно это из-за того, что я длительное время программирую на С/С++ и потому мне все эти вещи кажутся логичными и сами собой разумеющимися. Но, ИМХО, взглянув поверхностно на листинг кода С ты сразу поймёшь что он делает.

>>1228353
Да ты что?
Ну ка, взгляни поверхностно вот сюда и расскажи что тут происходит: https://github.com/gcc-mirror/gcc/blob/master/liboffloadmic/runtime/offload_target.cpp#L157

>>1228360
Так и думал, что такая хуйня начнётся. Но ставил на то, что ты вытянешь что-нибудь из линуксового ядра. Само собой, чтобы понимать что делает, надо будет изучать контекст. Не хочу тратить на это своё время.

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

>>1228366
Мань ну что за чушь ты несешь?
Ты знаешь си, и очевидно читать код на си тебе проще.
С хуя ты решил что ты должен сразу понять код на неизветсном тебе языке? Открой еще код на хаскеле и удивляйся тому, что там тебе вообще ничего не понятно.

Ну и да, если ты думаеш что си это про понимать алгоритм, то ты находишь в информационном вакууме.
Вот хотя бы https://vilhena.wordpress.com/2010/07/04/quicksort-haskell-vs-c/

>>1228368
Ладно, возможно ты и прав.

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

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

>Rust - невероятно быстрый язык
По сравнению с питоном?

>для системного программирования
>без segfault'ов
Ахахах, ложь, для системного нужен unsafe, а значит будет тот же segfault, никаких плюсов тут нет.

>абстракции с нулевой стоимостью
Строки в utf8, всякие типажи плохо влияют на память, итд. Такие абстракции может и есть, но в большинстве...

>семантика перемещения
В С ненада (имхо), а в плюсах есть

>гарантированная безопасность памяти
Лул, но вот только его разработчики считают что например такая вещь как утечка памяти, это довольно безопасно.

>потоки без гонок данных
Неплохо.

>вывод типов
Имхо ухудшает читаемость кода.

>маленькая среда исполнения
По сравнению с питоном?

>эффективный FFI
Да вполне обычный.

Как написать веб-приложение (бек + фронт) на расте.
https://medium.com/@saschagrunert/a-web-application-completely-in-rust-6f6bdb6c4471

>>1227127 (OP)
Какой смысл делать unsafe-мод в языке, если это нарушает безопасность? Почему нельзя сделать unsafe-мод безопасным?

>>1228499
Просто не используй unsafe.

>>1228502
Хорошо, а почему нельзя сделать unsafe безопасным?

>>1228503
Что значит сделать безопасным? unsafe просто отключает некоторые проверки конпелятора, а значит и гарантии безопасности, которые эти проверки и дают. Он не делает автоматом код небезопасным, безопасность зависит от программиста.

>>1228505
>unsafe просто отключает некоторые проверки конпелятора
А вот нахуя их отключать, чтобы писать низкоуровневые вещи?

>>1228507
Нужно конкретные случаи смотреть.

>>1228507
Компилятор не всегда может понять что код безопасный. unsafe означает не "небезопасный", а то что безопасность кода гарантируется программистом.

>>1228541
>Компилятор не всегда может понять что код безопасный
Ну так сделайте компилятор нормальный, хуле.
Иначе какой смысл этого языка, кроме того, что он еще не такой перегруженный как кресты

>>1228553
> Ну так сделайте компилятор нормальный, хуле.
Это невозможно, поскольку подобная безопасность зачастую условлена особенностями операционной системы, сторонних библиотек или даже процессора. Например программируя для микроконтроллера, ты можешь знать, что работать определённым образом с областью памяти по адресу X безопасно, но компилятор-то об это не знает. Потому ты и используешь unsafe-блок.

>>1228558
>невозможно
Значит нужно переписать все с нуля, используя только 100% безопасные способы.

>>1228561
Это уже к производителя процессоров/операционных систем.

>>1228476
> его разработчики считают что например такая вещь как утечка памяти, это довольно безопасно.
Пруф?

>>1228581
http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/

>>1228507
http://huonw.github.io/blog/2014/07/what-does-rusts-unsafe-mean/

>>1228594
>2014
Принципиально не читаю то, что было написано более года назад. Неси другой пруф

>>1228606
Пруф?

>>1228583
>currently working on the Swift team at Apple

То Хоар, то этот. Там что, всю наиболее толковую растовскую команду яблочники скупили, чтобы работать над конкурирующим языком программирования? Тогда неудивительно, что раст перестал серьёзно развиваться.

>>1228787
Еще Слава тоже у них работает, реально крутая команда. Не понимаю, почему они до сих пор не пытаются захватить рынок языков. Свифт действительно неплохая попытка натянуть нормальный язык на привычное говнарям си-подобное говно.

>раст перестал серьёзно развиваться.
4.2

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

>>1228787
Да и к тому же он был VOLUNTEER, ну то есть просто слал патчи видимо, в самой команде его не было.

Почему у него такой ебанутый синтаксис? Читаю примеры кода и еле-еле понимаю его: https://github.com/rust-lang/rust/blob/master/src/test/run-pass/weird-exprs.rs

>>1228805
Тебя не смущает название файла?
Да, люди ебанутые и иногда пишут странную хуйню, и этот тест проверят что странная хуйня работает как надо.

Все предъявы итт по поводу "ебанутого синтаксиса" от недалекости. А любой лисп по вашему вообще хуйня для инопланетян? А хаскель и прочие идрисы?

Есть конкретные вопросы, типа "почему фича X использует такой синтаксис, а не такой"?

>>1228831
У лиспов как раз дзен-синтаксис, идеально простой и понятный, никаких "weird exprs", объясняется даже ребенку за минуту.

Но вопрос >>1228805-анона и вправду странный.

>>1228831
Идрис это же пару стпелочек для хипстеров, что там понимать в синтаксисе?

В общем ОП-хуй нехило так обосрался, несите старого.

>>1228476
> Быстрый
Да, быстрый
> unsafe
В си у тебя segfault может выпасть непонятно когда и где
В расте достаточно отдебажить unsafe куски чтобы они правильно исполняли "контракт"
> Влияют на память
Вообще не ебет, по памяти до программ на джаве ещё далеко, а по времени они действительно с нулевой или околонулевой стоимостью, в некоторых местах лучше си. Кстати чтобы на си написать как на расте нужно изъебнуться, а на расте как на си почти без проблем.
> Семантика перемещения
В расте она нативная и более эффективная и понятная, чем в крестах
> Утечки
Их уж поменьше чем в си где каждая библиотека предлагает по-своему очищать память и это точно безопаснее чем дважды юзнуть free. И вообще сам язык заставляет думать о том что пишешь, а не о том куда бы байтик перегнать
> Маленькая среда исполнения
По сравнению с почти любыми языками
> Вывод типов
Уж получше чем void

>>1229708
void\\
Не ебу как тут эскейпить, кароч если что там две звёздочки возле void

>>1229708
Мне кажется что все, кто думает "зачем нам другие языки, на сишке же все то же самое только быстрее работает" просто никогда не писали ничего сложнее laba1.cpp

>>1227127 (OP)
>Rust — невероятно быстрый язык

Где адекватные бенчмарки, которые это подтверждают?

>>1230203
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html

в среднем быстрее си

>>1230215
Как что-то может быть быстрее си? Он же "самый низкоуровневый из всех высокоуровневых"
мимо иду в свой питонотред

Какие русскоязычные растовские форумы сейчас наиболее популярны? С удивлением обнаружилось, что на cyberforum.ru до сих пор нет растовского раздела.

>>1230219
Лол, да я просто накидываю. В первых двух бенчмарках он там быстрее си. Ну видимо компилятор более эффективно накомпилял, бывает. Так-то они все примерно на одном уровне конечно, ну и синтетические бенчмарки - это конечно сферический такой показатель.

А вообще, низкоуровневый\высокоуровневый не значит быстрый\медленный, ортогональные вещи.

>>1230234
Попробуй https://2ch.hk/pr/

>>1227131
>В чём его преимущество и недостатки перед Си?
В начале книги сказано http://shop.oreilly.com/product/0636920040385.do

>>1231156
Я на 100 всегда ставлю. 80 слишком мало. Ну и отступы - 2 пробела.

>>1231039
Погоди, а если твоя функция возвращает Result, то зачем ты везде пишешь unwrap, если можно писать ? и потом уже чекать ошибку

>>1231039
Полный пиздец, любой файл из Mojolicious (а оно на Perl, который считается нечитабельным), будет читабельнее и красивее.

>>1231257
>>1231156
>>1231248
Блядь, я вообще-то про имакс и вм, скрин на реддите нашел, бггг.

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

>>1231269
>бесполезные кружки вместо циферок у воркспейсов
Я не представляю, каким аутистом надо быть, чтобы циферки были полезны. Вот нахуя тебе циферки?

>надписи и иконки не выравненны по вертикали
С чего ты взял? Вроде по центральной линии выровнены как раз. Или ты не про кружки это уже?

>тень налазит на панель, а должно быть наоборот
Схуяли наоборот? Панель - это негатив спейс, кури хиги аппла.

>хули одноцветно
Ну пиздец, а тебе надо радугой? За этим к скалистам

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

>>1231269
А, ну и
>мне тож нравилось пока на превьюшку смотрел.
:3

>>1227127 (OP)
>пик2
А можно мне тоже самое, но без двоеточий?

>>1231348
Можно. Просто импортируешь нужные объекты и все.

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

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

>Схуяли наоборот? Панель - это негатив спейс, кури хиги аппла.
А хули у них тень как я хочу? Потому что блять панель она перед фоном, ебать ты довен, тралируешь чтоль меня? Ды я те с вертухи в печень дам, сразу блять поймешь с кем базаришь чепушило

>Ну пиздец, а тебе надо радугой? За этим к скалистам
Нет блять, я хочу чтоб текст можно было читать

>>1231290
Чмокаю в щечку но кулак летит в почку

>>1231350
Ну так и чего ж не импортировали?

>>1231255
Нахуя ты сравниваешь с питоном, если раст быстрее даже большинства компилируемых языков, типа haskell, swift, go? Компилятор генерирует почти тот же код что и сишный, весь твой "оверхед" и "рантайм" это проверка границ массива и unwind, ну и да, компилятор пока что не так хорош как gcc. В бенчмарках раст иногда оказывается быстрее. А в реальной жизни разница будет минимальна, если не в пользу раста за счёт удобных абстракций. let b = a.into_iter().map().filter().map().filter(), и иди ебись хотя бы с этим на си.
А насчёт move-семантики в c++, там нельзя перемещать сам объект, только вызывать move-конструктор или использовать ссылку, по сути это оверхед.

>>1231364
>типа haskell, swift, go?
Блять, ебать у тебя компилируемые языки, аххаха, сука, я аж проиграл. Они не сильно далеко от интерпретируемых, питон тоже компилировать можно, и яву.

>это проверка границ массива и unwind
Да много чего еще, я уже писал, и че? Я же говорю си + оверхед.

>В бенчмарках раст иногда оказывается быстрее
Хошь в моих бенчмарках си будет быстрее всегда?

>А в реальной жизни
В маня-мире твоем разве что, на чем там пишут высокопроизводительные системы? Плюсы и сишка.

>и иди ебись хотя бы с этим на си
type_t b = filter(map(into_iter(a)));
Че, без точки не мыслишь уже? Я уверен такая хуита нужна только потому что раст ограничивает мышление подобной хуитой, а в сишке такое не нужно будет и решится одним циклом. Видел долбаеба недавно которому нужно было из сишки исключения кидать в виде heap-allocated строк, ну не дебил ли? Можно было просто enum из кодов заебашить, хуйня эти ваши абстракции, в математику идите с ними и там ебитесь.

>>1231398
Что-то я погуглил и не нашел нормальной либы которая мне сделает filter(map(iter())) как в расте, дак ещё и без выведения типов тебе придется void f(void) юзать, но оно же тебе не нужно и в c++ auto просто так добавили.
Ты можешь писать как хочешь.
Пишут на си, что-то пишут на расте. Приведи пример твоего компилируемого языка не из 20 века как си и фортран, с чем ты хочешь сравнивать. Кроме крестов.

>>1231404
Ебучие звёздочки

>>1231404
>дак ещё и без выведения типов тебе придется void f(void) юзать
От ебанутый, ты понимаешь что Си это язык с широкими возможностями? Он блять примитивен но это не такая ограниченная параша как раст.

>Ты можешь писать как хочешь.
Уебывайте на вашей лодке капитан

>Пишут на си, что-то пишут на расте.
А че там нормального на расте пишут?

>не из 20 века
Ахаха, обидно что твой язычок 21 века унижает сишка из 60х? Пиздец, а давай наоборот, давай сравним первый компилятор сишки, и компилятор раста из 60х годов, ну епта, показывай исходники, будем собирать под эмулятором PDP-11.

>>1231407
Ды я смысл и так понял, даже не обратил внимание

>>1231408
Кароче давай я до вечера пятницы придумаю задачку
Что-нибудь на матрицы
На выходных или сколько тебе нужно времени напишешь на си
Погоняем тесты и бенчмарки, сравним количество кода

>>1231413
Ды мне пиздец влом, еслиб я знал фортран и матан то матрицы бы с тобой порешал, а так лучше в каэсочку поиграю

>>1231415
> Фортран
Ну а представь что ты не лабу профессору пишешь, а видеоигру или бизнес-логику
У нас как-то была лаба - написать сетевой чатик, только чтоб нормально работал, т.е. треды там, поллы, шифрование поверх tcp. Так вот писать на C это боль.

>>1231416
Фортран бест язык для матриц же, интель его пиздец как оптимизирует. Лабу я никогда не писал так как школу не заканчивал даж.

Писал борду на сишке, мне понравилось, разве что не смог подобрать нормальную либу для шаблонизатора и въебал lua, так как лень чет было.

>>1231408
>Си это язык с широкими возможностями

Тогда почему за последние 10 лет на этом языке не появилось ни одного нового крупного проекта?

>>1231432
>ни одного нового крупного проекта?
все современные проекты ориентированны на маркетинг, там нет технологий

>>1231416
>Ну а представь что ты не лабу профессору пишешь, а видеоигру

То я беру и качаю godot/unity/ue4.

> или бизнес-логику

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

>>1231398
>Хошь в моих бенчмарках си будет быстрее всегда?
А хочешь в моих бенчах всегда быстрее будет раст?

>>1231433
Технологии есть. В любом случае, людям не хочется начинать новый крупный проект на небезопасном языке, с которым большую часть времени придётся тратить на исправление багов вместо развития.

>>1231432
gtk, python, tarantool, да куча всего, смысл перечислять.

>>1231597
На клык хочешь?

>>1231690
>gtk, python, tarantool, да куча всего, смысл перечислять.

Перечисленные тобой проекты появились более 10 лет назад. Перечитай ещё раз вопрос.

Можете пояснить за unsafe? Захотелось мне потыкать Раст, решил сделать простенькую тулзу, которая взаимодействует с Xorg, но оказалось, что все взаимодействия с иксами приходится делать внутри unsafe. Это я делаю что-то не так или на практике unsafe используется в расте постоянно? Читал где-то, что unsafe вообще был введен для внутренних нужд языка и его использование в обычной жизни - это очень плохая идея

>>1231745
Ну вообще все вызовы через FFI считаются unsafe. Сделай свои safe-абстракции над функциями xorg'а и работай с ними.

>>1231738
gtk3 - 2011, python3 - 2008, tarantool - 2008. Да хуй знает, я новым ничем не пользуюсь, ну разве что uTox какой нить, но он не особо крупный.

>>1231753
> gtk3 - 2011, python3 - 2008,
Ты бы ещё минорные версии указал.

>>1231753
>gtk3 - 2011, python3 - 2008
Речь о новых проектах, а не о новой мажорной версии старого проекта.
>tarantool - 2008
А месяц? 10 уже стукнуло.
>uTox какой нить, но он не особо крупный
Соглашусь.

>>1231356
>Нахуя кружки, убирай их
Эм, у меня нет никаких кружков. Ты в порядке? Цепочку постов перечитай, аутист склерозный.

>я те пишу тект и иконки
Кружки - это и есть иконки, мимоКО. Алсо, успокоительных прими.

>А хули у них тень как я хочу?
Шизофазия.

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

>>1231398
>хуйня эти ваши абстракции
Лол, байтоеб сферический, в вакууме.

>>1231690
>На клык хочешь?
Так ты хуйню какую-то пишешь. Раст сопоставим с С, судя по бенчам там разницы около 3-7%, где между ними. Если хочешь это опровергнуть, то напиши свои бенчи и скинь исходники в тред, что бы аноны могли оценить насколько ты оптимально их написал. Или уползай под шконарь сразу.

>>1231782
gtk3 полностью переписали же, питон хз.

>>1231824
Ага, а Java обгоняет С++ на некоторых тестах, а хесель быстрее С на некоторых тестах, а питон.. ну такого я еще не слышал. Выше уже расписали что раст = си + оверхед, на си можно всегда написать быстрее, особенно учитывая gcc vs rustc.

>>1231789
>Эм, у меня нет никаких кружков
Я про твой анальный кружок

>Кружки - это и есть иконки, мимоКО. Алсо, успокоительных прими.
Текст ты там где видешь хуйло? Кого ты из себя строишь, ты бы у меня на районе кони шаркнул, ты че аще быкуешь дегенерат современного образования? Ты против меня сявка и штрих позорный, ты не разбираешься не в чем и никогда не разберешься даже в своей жизни!

>Шизофазия.
>Дислексия
Долбоебия у тебя, понял пидор, а теперь брысь под лавку!

>>1231796
А ты прям полон сил? Ну давай пиши тесты, потом будем оптимизировать версии.

>>1232116
Можно написать быстрее
Вот только сколько ты будешь ебаться с кодом чтобы достичь того же уровня производительности и функционала

>>1232117
>того же уровня производительности
Ты ебанутый? Выше растеры сами пишут что раст кое где обгоняет сишку, по случайности написанного кода.

>>1232118
Ты блять уже пишешь будто сишка интерпретируемая хуйня с которой надо ебаться чтоб к расту приблизиться.

>>1232116
>gtk3 полностью переписали же
Во-первых, это не так. Во-вторых, даже если бы было так, то многие проекты в процессе своего развития переписывались до неузнаваемости по сравнению с изначальной версией (Initial release), но это не делает их новыми.

>>1232146
Ну могли бы и язык сменить, поломали ж совместимость, я больше про это. Ну похуй, забей.

>>1231432
Сам спросил, сам отвечу:

wayland
Initial release: 30 September 2008

systemd
Initial release: 30 March 2010

>>1232116
>Ага, а Java обгоняет С++ на некоторых тестах, а хесель быстрее С на некоторых тестах, а питон.. ну такого я еще не слышал.
Дурик, а джава у вас без гц идет что ли, что бы её с сями сравнивать?

>Выше уже расписали что раст = си + оверхед
Мне твои мантры не интересны. Вот тебе пруфы из реального мира.
https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html

Раст это безопасные кресты, постепенно приближающиеся к С. При этом, на самом С крупный проект сделать не реально.

>>1232384
Это стандартное современное железо. Пруфы гони, что на старом железе хуже работать будет.

>>1232277
>джава у вас без гц идет что ли, что бы её с сями сравнивать?
А раст у нас без оверхеда? Ты че сука тролишь? Да ди нахуй чмошник, в рот тя ебал
в расте еще ща напишут абстракций хуже питона будет

>Вот тебе пруфы из реального мира.
>https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html
>https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/pidigits-rust-3.html (один из 2 двух примеров где раст "выигрывает")
>По ссылке раст почти везде сливает, даже и по 5 секунд.

>При этом, на самом С крупный проект сделать не реально.
Собственно только матанопетух не осиливший сишку и мог такую хуйню нести, не удивлен. А теперь подумай/посчитай
сколько строк в windows/linux.

Написал небольшую хуйню, которая должна будет работать на моем сервере, но когда пытаюсь запустить бинарник на нем, мне выдает `/lib64/libc.so.6: version `GLIBC_2.18' not found`. Я понимаю, что проблема в том, что на моей пекарне стоит версия новее чем на сервере, и нужно при компиляции указать версию glibc, которую нужно использовать, но как это сделать я в гугле не нашел. Или может быть можно как-то статично сликовать нужную версию?

И еще один вопрос, какого хуя программа на ~50 строк уже весит 5мб? Из зависимостей есть только bufstream. Релиз версия билда весит столько же.

>>1227127 (OP)
Есть теоретическая задача написать игровой движок уровня UE4, так вопрос в том, почему на Rust лучше/хуже писать чем на С/С++, каковы преимущества/недостатки Rust в этом проекте вы видите, например как скорость разработки, подверженность непонятным багам, скорость выполнения инструкций, многопоточность и т.д?
Мне реально интересно и хочется узнать ваше мнение.

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

>>1232651
> Никому он нахуй так же будет не нужен, т.к. никто не знает Раст
Тот же юнити на цпп, а сами игоры на шарпе/жс.

Ржавчина — memory-safe, значит она гарантирует, что ни один используемый объект не будет случайно удален. Однако, memory leaks are memory-safe, значит нет гарантий удаления неиспользуемых объектов. Как эта проблема решается?
В няшной все просто — если ты точно знаешь, что пришло время освободить память, то делаешь free и не ломаешь голову.
А как тут быть, если используешь какой-нибудь RefCell, а он затупил и начал течь?

>>1232689
RefCell сам по себе не затупит и течь не начнёт. Memory leaks в safe Rust возможны, только если ты наделаешь циклических ссылок в Rc/Arc или сделаешь mem::forget. Ещё один вариант - это если ты проебёшься с FFI, но это уже unsafe.

>>1232643
Напишите в шапку раз это такая платина. Ну и проблема с glibc никуда не делась, а эта проблема была первостепенной для меня.

>>1232723
>Напишите в шапку раз это такая платина

Для Go, где тоже толстые бинарники, так и сделали https://2ch.hk/pr/res/1159767.html

>>1232642
Лучше на C или С++, так как для них куча библиотек, и куча документации к этим библиотекам, и все вопросы давно решены.

Плюсы раста, ну пожалуй в cargo, иии ну хз, мб если те язык больше нравится, то еще это.

>>1232642
>игровой движок уровня UE4

Задай себе вопрос: через сколько лет он устареет?
Мне кажется, что Rust лучше выбирать для долгоживущих проектов.

>>1232837
>через сколько лет он устареет?
Что значит устареет?

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

>>1233196
Мне кажется это уже не будет проблемой языка. Проблема раста (по крайней мере для гейдева), что там
1) только совсем недавно появились средства для работы с SIMD и они ещё не до конца оптимизированы.
2) совсем нет аналога constexpr из C++. Появится только ближе к концу года.
3) совсем нет инлайн ассемблера. Даже интрисиков.

Но макросы там - это конечно вещь. С ними даже рефлексию можно замутить (так например работает serde - библиотека для (де)сериализации).

>>1233211
>совсем нет аналога constexpr
Разве макросы не покрывают это?

>>1233219
Частично. Можно использовать билд-скрипты (которые тоже пишутся на расте), но это уже скорее выглядит как костыль. Да и с организацией кода будут проблемы.

>>1233219
Еще есть lazy_static

>>1233803
static и const это совсем разные вещи.

>>1233808
Что интересного делают через constexpr на крестах?

>>1233811
Некоторые и игори полностью на них писали: https://jguegant.github.io//jguegant.github.io/blogs/tech/meta-crush-saga.html

>>1233813
По ссылкам не ходи. Можно пример ИТТ?

>>1233822
> файл с состоянием игры, написанным на C++
Впрочем конкретно там не C++, а просто строка с символами, которую в компил-тайме разбирают constexpr функции.

>>1233822
Это все классно и замечательно. Но можно не хитровыебанный пример?

>>1233822
Что только люди не делают, лишь бы лисп не изучать. ну реально, это же пиздец как уродливо

>>1233813
А примеры реального применения то есть?

>>1232837
>Задай себе вопрос: через сколько лет он устареет?

С 1999 только молодеет - выкинули UnrealScript, прикрутили блюпринты, грофон стабильно увеличивают.

>>1233977

С 98, тащемта, в 99 унрил дурнамент уже вышел.

>>1233196
>Это тот момент, когда движок придётся практически полностью переписывать для соответствия современным реалиям.

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

На "актуальных языках" (кстати, сколько их там было, убийц крестов за все эти годы с выхода Unreal?) - в основном поделки уровня "я сделял по туториалу DirectX свой школофреймворк и обзову его движком". Немного у них правда получилось в жанре говнопесочниц - ну, когда полный фрактал отсоса (жабка + хуёвый код на ней) и графоний уровня PS1, требующий топ пекарню, чтобы со всеми наворотами играть стал нормой.

К слову, есть и удачные примеры, на чистом сисярпе без юньки и с достаточно норм перфомансом при таких-то фичах написана Space Engineers:

https://github.com/KeenSoftwareHouse/SpaceEngineers

>>1232837
>Мне кажется, что Rust лучше выбирать для долгоживущих проектов.

Мне кажется, ты не совсем понимаешь, что такое игровой движок.

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

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

Открою тебе секрет - игры пишут не программисты. Максимум - это штат скрипт кодерков, максимум пара байтоёбов, спешащих на помощь, когда дело касается профайлинга и оптимизации и всё. На 90% игра делается силами сценаристов, художников, геймдизайнеров, моделлеров, музыкантов итд.

И вот создать хотя бы такой же толковый инструмент для этих 90% ты не осилишь.

> Photoshop
> Задай себе вопрос: через сколько лет он устареет?
> Мне кажется, что Rust лучше выбирать для долгоживущих проектов.

>>1233986
>Открою тебе секрет - игры пишут не программисты. Максимум - это штат скрипт кодерков, максимум пара байтоёбов, спешащих на помощь, когда дело касается профайлинга и оптимизации и всё. На 90% игра делается силами сценаристов, художников, геймдизайнеров, моделлеров, музыкантов итд.

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

> Game studio Ready At Dawn switching to Rust for all new development
https://twitter.com/AndreaPessino/status/1021532074153394176

>>1234224
https://twitter.com/andreapessino/status/625009717580992513
Суровый чувачок!

>>1233983
>кстати, сколько их там было, убийц крестов за все эти годы с выхода Unreal
Два (сисярп и ди).

>>1232487
>А раст у нас без оверхеда? Ты че сука тролишь? Да ди нахуй чмошник, в рот тя ебал
>в расте еще ща напишут абстракций хуже питона будет
Ты совсем долбоёб сравнивать оверхед в виде дополнительных проверок и оверхед в виде гц? Не, ну точно же долбоёб. В расте благодаря его проверкам можно сделат оптимизации компилятора, на которые пока что положен болт. Раст вполне сможет со временем перегнать С, а вот джава никогда.

>По ссылке раст почти везде сливает, даже и по 5 секунд.
Он 5 секунд слил только в 1 тесте. Во всех остальных раст отстает на доли секунд. А теперь вспоминаем, что при этом у них ещё нихуя не оптимизированный компилятор.

>Собственно только матанопетух не осиливший сишку и мог такую хуйню нести, не удивлен. А теперь подумай/посчитай

>сколько строк в windows/linux.
А еще давай посчитаем сколько человекочасов это заняло. садись два

>>1234531
>Ты совсем долбоёб сравнивать
Де я сравниваю хуйло ты ебаное? Иди нахуй чмошник, мать твоя шлюха сегодня хуем подавится

>Раст вполне сможет со временем перегнать С
Блять ебанутый, пиздец какой же ты поехавший, сейчас просто разъебу тебя и пойду отдыхать, с таким долбаебом смысла нет разговаривать просто

>Он 5 секунд слил только в 1 тесте.
А я писал что во всех? Не, знаешь что, иди ты нахуй

>>1234536
>КУДАХ БАБАХ КУКАРЕКУ
Ох уж эти школьники.

>>1234536
>Де я сравниваю хуйло ты ебаное? Иди нахуй чмошник, мать твоя шлюха сегодня хуем подавится
Так ты же кукарекашь, мол у раста ОВЕРХЕД, и он НАМНОГО медленнее С. Увы, реальность ссыт тебе в глаза, где раст не только на равне с С но и имеет потенциал стать быстрее.

>Блять ебанутый, пиздец какой же ты поехавший
У тебя врети?


>По ссылке раст почти везде сливает, даже и по 5 секунд.
>Значительно сливает только в 1
>КУКАРЕКУ! А я писал что во всех?
Ясно все с тобой.

>>1233991
А ещё студиям может быть выгодно тем, что:
1) Софт на расте сложнее взломать.
2) Даже если исходники доступны, то конкурентам сложнее будет скопипастить код, ибо для этого придётся сначала вникнуть в новый язык.

>>1234616
>1) Софт на расте сложнее взломать.
Принцип неуловимого Джо?
>2) Даже если исходники доступны, то конкурентам сложнее будет скопипастить код, ибо для этого придётся сначала вникнуть в новый язык.
Вы пропустили драму с WestWorld / Fallout Shelter?
Что бы сделать "новую" игру достаточно жпеги заменить и всего делов то.

>>1234616
>Софт на расте сложнее взломать.

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

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

> то конкурентам сложнее
> ААА-студии

Порву шаблоны - они друг с другом и наработками делятся и помогают в проектах. И годноту регулярно на GDC и Siggraph выкладывают. Нет у них конкурентов, тупо по причине денег, которых у других нет, чтобы делать подобные проекты. Это в мелком софтонаебизнесе возня и ворование "laba1.cpp" друг у друга, у крупных ребят уже всё это давно пройдено.

>>1232384
>Обсуждение языка программирования Rust.
>Выложил системные требования одноименной игры.
>Мама, смотри, я троллю /pr.

>>1234531
> оверхед в виде дополнительных проверок
Что за проверки?

>>1234552
>Сейчас напишу дяденьке что он школьник, вдруг ему будет так же обидно как и мне!

>>1234599
Кукарекает твой батя петух под шконкой, блять конечно медленнее, но я же не говорю что это блять как питон, так что иди нахуй, быдло

>где раст не только на равне с С но и имеет потенциал стать быстрее
Жава быстрее, я в тестах видел, иногда обгоняет плюсы! Ряя!212 D-Lang убица крестов, подумаешь оверхед в виде GC, быстрее я скозал!2121 Мам скажи им, я нихочу осознавать сваю ниправоту!21212

>Ясно все с тобой.
Хуйло безглазое, прочитай еще раз, я сказал что раст сливает и по 5 секунд, ты блять там где видишь хотя бы "сливает в паре тестов по 5 сек"? А нигде, ты понимаешь что ты хуйло и никто по сравнению со мной, и пытаешься на какой то хуете выкрутиться, но выкрутиться может только твоя мать на моем хуе

>>1234751
>Что за проверки?
Выхода за границы array например.

>>1234343
>Суровый чувачок!
Ряяяя, программисты должны не поднимать ничего тяжелее ложки, и по 18 часов в день сидеть за монитором.

>>1234343
> Основатель игровой студии
> Выглядит как орк третьего уровня с INT = 2.5
> Самая известная игра студии - говнокинцо The Order: 1886
> Обвинил во всех проблемах C++ и собирается переходит на Rust
Все сходится.

>>1234884
> блять конечно медленнее
Настолько медленнее, что они практическим одинаковы. Одно с легкостью заменяется другим без каких либо дробеков.
>>1234884
>Жава быстрее, я в тестах видел, иногда обгоняет плюсы!
Нет дурич, разрабы компилятора раста говорили что в нем возможны оптимизации, которые в С невозможны.

>Хуйло безглазое, прочитай еще раз, я сказал что раст сливает и по 5 секунд
Даун еще раз, значительно сливает он только в 1 тесте. Во всех остальных на равне.

>>1235167
>Во всех остальных на равне.
Ты че уебок, каждый может зайти и посмотреть как твой раст хуяст сливает сишке, усе иди нахуй даже такому чмошнику отвечать не буду, нахуй нужно.

>>1234921
Программист-бодибилдер — редкое явление.
Но, видимо, он уже сам не программирует, а только руководит программистами.

>>1234918
А еще какие например?

>>1235307
Смысл проверок в расте заключается в том, что во-первых они явные, а во вторых компилятор не даст тебе забить хуй на их обработку без unsafe:
https://play.rust-lang.org/?gist=77e39f7df2fa278650a11783359a4acf&version=stable&mode=debug&edition=2015

>>1235310
Некоторые проверки можно перенести из компил-тайма в рантайм. Тот же RefCell позволяет обойти borrow-checker и все проверки времени жизни переменной проводятся во время выполнения программы.

>>1235311
И это тоже.

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

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

>>1235314
>в половине тестов в 1.5 раза медленнее
>хуй целых пизда десятых
Школьник, ты?

>>1235326
Мне эти >>1235207 тесты вообще кажутся странным. Вот если бы Си конпелировался при помощи clang+llvm, то сравнение было бы честным. А то возможно вся разница в пирформансе исходит из разницы между машинным кодом, который генерит llvm и gcc.

>>1235333
>пирформансе
Точно ты.

>>1235338
Да я я я. Что я?

>>1235326
>в половине тестов в 1.5 раза медленнее
Ну и где эта половина? Ты даже считать не научился, а лезешь за низкоуровневые языки тереть.

>>1235339
>>1235341
>эти школоманявры
Ясно.

>>1235342
От того что ты называешь собеседника школьником, сам умнее не становишься.

>>1235343
>эти характерные школофразы
Понятно.

>>1235346
Если не перекроешь каждый пост тебя что, мамка не похвалит. Давай, назови меня ещё раз школьником. На большее у тебя ума не хватит.

>>1235351
Слабовато. Плохо обзываешься, негодно. Ну же, постарайся ещё раз.

>>1235359
Во, умничка. Ещё и боевую картинку прикрепил. Родина гордится тобой.

>>1235371
Нет никаких проблем с производительностью. Есть требования делать сразу 100k rps.

>>1235389
>100k rps.
Это много?

>>1235342
Все, ты уползти решил? Ну ладно, мой тебе совет быть более гибким. Язык не понацея, а инструмент, если он устарел, то его стоит закопать и перейти на более совершенные технологии.

>>1235397
>понацея
Школьники, школьники never change.

>>1235399
Спс, что поправил мою орфографию. Хотя это и очевидная очепятка.

>>1235401
Ну не траль плз..

>>1235403
>плз..
Обожаю плачущих школьников - вы такие няши :3

>>1235391
Да.

>>1235412
Соболезную.

Мод, забань этих кукарек уже, развели срач ни о чем.

Свежих новостей вам в ленту:
https://this-week-in-rust.org/blog/2018/07/24/this-week-in-rust-244/

>>1235476
- >>1234944 (OP)

>>1235333
А то что там для Си несколько реализаций отличающихся в производительности в несколько раз тебя не смутило. Тестирование на алгоритме длиной в пару сотен строк - так себе показатель.

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

>>1235644
Не перекатишься. Rust используют не для написания говна для GC, на нем пишут системный код, а он нихуя не твоя Java, извини. Вангую перекатишься в Go. Как раз и вакансий побольше будет.

>>1235415
Ну уже немного больше получилось. 100к в худшем случае. В среднем 500k rps.

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

>>1235684
Ты понимаешь насколько это ортогонально написанию веба? Если да, то вперде – увлекательный мир аллокаторов, ассемблерных инструкций и дрочьбы на архитектуры.

>>1235653
>Как раз и вакансий побольше будет.
Если смотреть на динамику сегодня, то через 2-3 года на делфи вакансий будет больше, чем на го

>>1235207
Ахах, блять я говорил что отвечать не буду, но ахаха, пиздец какой то, вон раст сливает везде, хули тебе еще надо? Мдаа

>>1235333
Так блин, в этом и суть, будут же выбирать инструмент где все лучше, гцц например а не шланг, заметь там еще и оптимизации, и march=native. Какой смысл тестировать просто код?

Думал заюзать WASM, а там бинарник с regex под 700 кб со всеми оптимизациями. При этом каждый бинарник грузится по 1с и больше. Похуй, пойду дальше ебаться с жс.

>>1235974
Не извращайся, а попробуй скомпилить регексы как программу под dos/4g с вводом-выводом через консоль и запускать в бровзере на dosbox под emscripten. Рад был помочь, если что.

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

>>1236330
Как раз обычный бинарник с итераторами и всякими функциями из std довольно мало весит, это все regex. Идея была написать лексер+парсер (переписать с перла), но чет перехотелось.

>>1236619
Растовское довольно мало - это для фронтэнда вообще-то запретительное дохуя:
>leap@beaver-box:~/Workspace/learn.rust/hello$ rustc +nightly --target wasm32-unknown-unknown hello.rs -C lto -C opt-level=3 -C debuginfo=0
>leap@beaver-box:~/Workspace/learn.rust/hello$ ls -la hello.wasm
>-rwxrwxr-x 1 leap leap 390811 Jul 28 16:05 hello.wasm
Эти ~400кб еще ведь компилироваться должны. У юзера пердак взорвется быстрее, чем типичная мобилка 2013-14 г.в. перемолет два десятка мегабайт байт-кода. Кроме того, сам язык способствует раздуванию кода: каждый трейт, каждое статически разрешимое применение полиморфизма для него повод сделать специализированную под еще один тип копию методов (т.н. мономорфизация - то, из-за чего, например, кресты имеют больше жирка, чем сишечка).

Wasm тоже то ещё говно. На числодробилках он часто бывает медленнее чем даже чистый js (была где-то демо-страница с фильтрами видео - там wasm отставал часто на треть). Да и чтение спецификаций навевает мысли, что 1) без среды js его использовать не получится; 2) в статических компиляторах авторы не разбираются нихуя, ибо вместо абстрактного SSA с кучей атрибутов в помощь оптимизатору там какой-то галимый байт-код уровня курсача в заборостроительном вузе.

>>1236812
Я через wasm-gc прогонял, там около 150 КБ было на несложную программу.
Насчёт компиляции хуй знает, по идее должно же быть быстрее того же asm.js, для того он и создавался вроде.
Ну и ни о каком полиморфизме речь не шла, у меня был юзкейс прогнать бинарные данные и заюзать пару структур данных, но видимо проблема в крейтах, не особо оптимизированных в плане размера экзешника, а писать самому долго выйдет.
Си для этого видимо лучше подходит.

>>1236847
Да, я глянул на получившийся код, там действительно 150кб и наберется, остальное - что-то похожее на таблицу символов (которую debuginfo должен был убрать, не?). Такой объем уже вполне вписывается в типичный (больной ожирением) сайт. Но все же от хеллоуворлда я ожидал примерно вдесятеро меньшего объема =(

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

> Такой объем уже вполне вписывается в типичный (больной ожирением) сайт.
Суть в том, что JS использует regex-парсер встроенный в движок браузера, а код на wasm тащит свой собственный. Как вариант можно использовать ffi, но тогда толку от wasm не будет. И да, переход на си тут погоды не сделает, ведь регекс парсер на си тоже будет весить дохуя.

Вообще сейчас wasm - это оочень узкоспециализированная хуёвина. Вот когда добавят как минимум API для прямого доступа к DOM, тогда уже и можно весть хоть какую-то речь о замене js.

>>1236860
Ну, можно подковать блоху и сделать свой компилятор регулярок сразу в код, работающий со стандартными типами. А еще можно варить свою сталь и ковать свои гвозди, чувствуя себя первопроходцем :) А так, даже API ждать не надо - все разумные кейсы (состоящие в использовании нативного кода в вебе) уже покрыты с достаточным удобством и эффективностью emscripten-ом, я сам года три назад писал бота для игры, отгадывая примитивные капчи tesseract-ом под js, а еще раньше играл в демку на unreal engine. Шарить код между клиентом и сервером заманчиво, но на практике не получается - из применений такого подхода в продакшене я знаю только фреймворк meteor, и он неудобное тормознутое говно. Короче, даже доведи мазила его до совершенства, wasm не особо нужен.

>>1236901
> сделать свой компилятор регулярок сразу в код, работающий со стандартными типами
На расте такой кстати был. И размер у него был обычно больше чем у простого парсера, поскольку размер зависит от количества регулярок и пропорционально увеличивается.
> emscripten-ом
Ну, wasm это его дальнейшее развитие. В движке Firefox, например, и emscripten, и wasm выполняет один компилятор. Отличаются только парсеры.

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

>В движке Firefox, например, и emscripten, и wasm выполняет один компилятор.
Ты, наверное, asmjs имеешь ввиду. В прошлом году была статься от мазилы, называлась "why webassembly is faster than asm js", там про движок не было, зато указывалось, что wasm быстрее asmjs в среднем на 5%, но при этом парсится быстрее "на порядок". Если учесть, насколько прожорливее за последние десять лет стали браузеры, меня такие цифры не впечатляют совсем, особенно учитывая отсутствие поддержки wasm старыми браузерами. Так что мне мазила со своим хайпом про wasm очень сильно напоминает Тома Сойера и его забор.

На каком языке программирования вы в основном писали код перед тем как перешли на rust?

>>1237177
Петон.

>>1237177
Си и питон

>>1237177
Haskell

>>1237177
С++/Python
На Rust еще не перешел, но планирую частично перекатиться.

>>1237177
Ассемблер, Си, Паскаль, Питон

>>1237190
>>1237453
>>1237763
Как вам, в сравнении с Си и питоном?

Коре девелоперы там не хотят нормальную IDE запилить на расте для раста?

>>1237769
Пока Раст уступает Сишечке только в работе с интринсиками (simd и т.п.), ядрёными низкоуровневыми деталями типа выравнивания в структурах и простоте создания компиляторов. В остальном всё намного лучше: безопасная работа с памятью; высокоуровневый код с околонулевой стоимостью абстракций (напр. можно сделать целую цепочку из filter/fold/map над итераторами и она часто будет по скорости 1 в 1 как написанный на циклах вручную код); единая система сборки с менеджером зависимостей, позволяющая в большинстве случаев сделать git clone/cargo build и сразу получить рабочий бинарник; продуманная модульная система, позволяющая с самого начала писать код в виде независимых модулей, которые потом можно вынести в отдельных крейт, не меняя кода; хорошая поддержка пространств имен, позволяющая реэкспорт для создания нескольких версий интерфейсов (т.е. можно делать API v1/v2/v3, ссылающийся на одни и те же реализации методов).

По сравнению с Петоном: менеджер зависимостей гораздо удобнее (не надо загаживать систему всякими site и прочей поеобтой); система типов гораздо сложнее и иногда (в начале изучения - очень даже часто) требует перепахивать непродуманный код, но при этом помогает ловить ошибки, избавляя от необходимости тривиальных модульных тестов; полная статическая компиляция, избавляющая от идиотии с опечатками в именах переменных; Юникод поддерживается в виде utf8 и не ебет мозги с ошибками перекодировки, всплывающими в рантайме. Из минусов - это все-таки компилируемый язык, и быстро накатать программку в двадцать строк не получится, придется расшаркиваться с указанием зависимостей и т.п.

>>1237938
Раст также как и си написан на ассемблере?

>>1237840
RLS пилят.

>>1237938
> только в работе с интринсиками
Активно добавляют. И то, и другое. В ночнушке уже даже интрисики для cortex-m появились, такие же как и в Си - ARM C Language Extensions, он же ACLE.
> выравнивания в структурах
Уже давно есть.
[repr(C)] - для совместимости с Си.
[repr(align(..))] - для выравнивания.

Кстати, по-умолчанию (т.е. в структурах где не указано [repr(C)]) раст перемещает внутренности, чтобы они занимали меньше всего места.

>>1237938
> идиотии с опечатками в именах переменных
Зато есть идиотия с неявным перекрытием переменных. Т.е. когда пишешь.

let foo = 1;
...
// Здесь foo == 1
...
let foo = 2;
...
// А здесь уже foo == 2
...

С их любовью к явности могли бы и добавить какой-нибудь кейворд для явного перекрытия.

>>1237938
Годно расписал, анон, сохрани на пастебин для будущей шапки!

>>1237970
>let foo = 1;
>...
>let foo = 2;
Я конечно дико извиняюсь, но что здесь неявного? Это довольно часто используется (не только в расте, вообще во всех языках с лексическим скоупом), так что добавлять по умолчанию варнинг для таких вещей было бы не очень удобно, имхо. Может линтеры спасут отца русской демократии?

>>1237969
Да, интринсики делают, но в rust 2018 оно не попало, к сожалению. Насчет элайнмента я имел ввиду более сложные случаи (см. статью "Unsafe Zig is Safer than Unsafe Rust") - такое легко получается, если писать кодеки и архиваторы.

Еще огорчение вызывает отсутствие фиксированного ABI, мы не можем, подобно Маленькиммягким, сделать Rust 2018 Runtime Redistributable, чтобы тем самым сократить объем кода в присутствии стандартных библиотек и позволить обновлять рантайм независимо от приложений.

>>1237970
А я бы сказал, что это даже удобно: если ты не курильщик, у тебя методы все равно помещаются на экране, так что можно делать "let num = "4.2e1"; let num = num.parse::<i64>();" и не плодить новые имена. Язык все равно не позволит тебе читать неиспользуемую переменную, так что мало разницы, есть перед приваиванием let или нет.

>>1237977
> Я конечно дико извиняюсь, но что здесь неявного?
Именно то, что компилятор перекрывает переменную, при этом неважно хочешь ли ты этого или нет. Ещё веселее начинается, когда пишешь что-то вроде

let foo = ...
...
{
...
let foo = ...
...
}
...
> Может линтеры спасут отца русской демократии?
Спасут, но сама фича кажется достаточно вредной. Забавно, кто-то недавно создавал тред на реддите с критикой этой же фичи, так растофанаты сразу назвали его "плохим программистом", а необходимость этой фичи оправдывали тем, что им лень придумывать имена для переменных.

>>1237979
> Еще огорчение вызывает отсутствие фиксированного ABI
Это у всех низкоуровневых языков такая хуйня, в том числе у С/С++. Просто последние релизятся реже.

>>1237981
Как раз C это пример фиксированного ABI, учитывая, что все остальные языки его используют, чтобы договариваться между собой. У D он тоже фиксированный, у C++ он фиксированный в пределах одного вендора. Это ведь не так сложно, на самом деле - определить правила построения имен символов и документировать таблицы типов и виртуальных методов. В определенных пределах можно поддерживать даже трейты с шаблонами, заменив мономорфизацию (т.е. подстановку кода) на непрямой вызов методов трейтов и шаблонов через указатели. И это НУЖНО, т.к. пока даже систему плагинов в приложении сделать нельзя без написания интерфейса в стиле C.

>>1237938
Спасибо за развёрнутый ответ.

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

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

>Спасут, но сама фича кажется достаточно вредной.
Ну мне было бы неприятно, например, срефакторить кусок кода из одного места в отдельную функцию и внезапно обнаружить, что он не компилится потому что где-то в области видимости есть какая-то другая переменная с тем же именем. Это как бы нарушает лексический скоуп, глобальное состояние начинает влиять на твой конкретный кусок кода. Теперь нельзя просто написать let foo = 42 - надо перед этим проверить всю программу на отсутствие "foo" в том же скоупе. Это же пиздец. Глобальное состояние - это плох. Все должно быть локальным по максимуму.

>>1238002
Ага, и в пределах версии конпелятора. В линуксмирке пакетный менеджер скачает нужный редист, а в винде обычно либо вместе с программой распространяют библиотеки, либо установщик нужной версии редиста.
>>1238001
> Раз ты явно создаешь другую переменную с тем же именем
Я могу случайно создать переменную с тем же именем. Никакой явности тут нет.

>>1238002
Да, признаю, тупанул - микрософт разбаловал меня!

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

>>1238005
Когда-то кто-то сделал такой же аргумент про присваивания, хлопнул дверью и ушел придумывать функциональное программирование. Ведь ты уже сказал, что var1 = 1, а теперь говоришь, что var1 = 2, ты что, вруша?

>>1238009
> Ведь ты уже сказал, что var1 = 1, а теперь говоришь, что var1 = 2, ты что, вруша?
Т.е. вся твоя аргументация по сути представляет из себя
> ебланы, пишущие не помещающиеся на экране методы
Ты прям как те реддитохомячки, у тебя тоже все вокруг - неправильные программисты.

>>1238009
> микрософт разбаловал меня!
Выпуском редистов каждые два года (этьо если не считать сервис паки к ним)? Ну-ну.

>>1238005
>Я могу случайно создать переменную с тем же именем.
А еще ты можешь случайно запустить ядерные ракеты по Калифорнии. В чем проблема-то, але? Если ты создашь другой биндинг с тем же именем, то в этом биндинге будет ровно то, что ты в него положил. Потому что ты его как бы создал. Явно. Если ты при этом по тому же имени хочешь одновременно обращаться еще и к глобальному биндингу, то у тебя шизофрения. ЯВНАЯ

>>1238009
>ебланы, пишущие не помещающиеся на экране методы, и без этого найдут способ прострелить себе ногу.
this

>>1238012
Нет, я не иду на принцип, а просто не вижу разницы между "let хуемое = 1" и "хуемое = 1" в контексте возможности прострелить себе ногу. Если б я считал себя д'Артаньяном, я бы обитал в C++-треде и славил искусство боя этим благородным обоюдоострым клинком без рукояти.

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

>>1238014
Строго говоря говоря, меняется стандартная библиотека, а структура vtbl и схема именования живет уже лет двадцать. Но да, совместимость получается в пределах версии, признаю ошибку. MS обещает совместимость только для C (а GCC, бородатая пидорасина, её нарушает, когда из функции возвращаются struct-ы).

Так, пацаны. C++ разроботчег хир. Хочу вкотиться в ваш язык, но вакансий пока не вижу. Как думаете, лет через 5 появится?

С чего лучше с нуля начать: с Си или сразу Rust?

>>1238096
Если умеешь в раст и говоришь по английски, кидай линк на гитхаб, мы хайрим на раст.

>>1238146
Я думаю что лучше начать с Си, на нём же изучить структуры данных и алгоритмы.

>>1238176
Не слушай упоротого. Хочешь изучать алгоритмы, учи хаскель.

>>1238179
>Haskell
И кто более упоротый? Или моё мнение об этом языке ошибочно?

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

>>1237938
>Пока Раст уступает Сишечке только в работе с интринсиками (simd и т.п.), ядрёными низкоуровневыми деталями типа выравнивания в структурах и простоте создания компиляторов.

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

>>1238220
> отсутствия нужных мне библиотек
Сделай.

>>1238220
Каких например?

>>1238196
>прикладной навык
Это. Пожалуй, посмотрю в сторону Haskell, спасибо.

>>1238146
Для раста ещё нет обучающей литературы, по которой можно начать с нуля. Существующая литература рассчитана на тех, кто уже программирует на другом языке, знает про указатели и т.п. К тому же есть потребность в переписывании сишных библиотек на раст.

>>1237769
слооожнааа
непаняяятнаааааааааааа

>>1238272
Жаль.
А я как раз хотел вкатываться в программирование с раста.

>>1238272
> указатели
Рокетсаенс блядь.

>>1238220
Ну так Раст - не язык хеллоуворлдов. Пока ты пишешь тонкие обертки над парой-тройкой больших качественных библиотек - всё кажется збс, а потом вдруг обнаруживаешь себя в болоте, где квакают три системы сборки на разных версиях autotools, две cmake (одна из них древнией версии с кучей локальных скриптов), один ядреный makefile на две тысячи строк и дирижирует всем твой хипстерский meson, скрипт сборки которого нифига не похож на милоту из туториала. Это не говоря уже о полной жопе с согласованием типов данных, когда вдруг обнаруживаешь, что какая-то библиотека написана из расчета, что int у тебя unsigned и имеет ширину 32 бита, а выравнивание идет строго по 8 байт. И обнаружишь ты это в рантайме, когда твою софтину хватит segfault из-за срыва стека сразу на выходе из функции. С Растом такой хуйни не бывает - любой вменяемый проект на нем собирается одним и тем же cargo, не привязан к одной архитектуре и добавляется к проекту парой строчек в dependencies.

>>1238286
Рокетсаенс, да. Я вот прочитал статью "Pointers Are Complicated, or: What's in a Byte?", поежился и почувствовал, будто перейдя на Раст увернулся от падающего на меня ведра с помоями.

>>1238314
>а потом вдруг обнаруживаешь себя в болоте, где квакают три системы сборки на разных версиях autotools, две cmake (одна из них древнией версии с кучей локальных скриптов), один ядреный makefile на две тысячи строк и дирижирует всем твой хипстерский meson

Откуда столько? Почему из репов либы не ставишь?

>>1238373
Это утрированно, но не так что бы очень. Была одна либа на cmake, два разных проекта на autotools походу разных версий (у них разные аргументы на кросскомпиляцию), один кустарный make-проект, всё это использовалось в проекте на старой версии cmake и я по частям переводил все это на meson, чтобы хоть как-то работало. Репы не использовал потому это должно было кросс-компилироваться под mingw-w64, а у крестовых пакадж-менеджеров (conan, vcpkg, buckaroo) репозитории пусты, как магазины при социализме.

>>1238146
>>1238179
Сука, ёб твою мать, чувак же ясно написал, что он начинает С НУЛЯ.
Для изучения ОСНОВ ПРОГРАММИРОВАНИЯ нужен Си и Ассемблер, а не Хаскель, блядь.

>>1238887
Братишь, основы программирования это хаскель и схема. А си и ассемблер это основы байтоебли под конкретное железо.

>>1238889
Тыскозал? То есть через списки и монадки новичку станет понятно как работает процессор и оперативная память?

>>1238944
Новичек хочет быть программистов, а не схемотехником.
99% прикладных программистов хуй клали на то как работает ОС, не то что проц.
Если он новичок, пускай учится использьзовать алгоритмы и структуры данных абстрактно, а не думать о пейджфолтах.

>>1238944
Эх, сейчас бы с помощью си изучать, как работает процессор и память...

>>1238944
Начинать надо с основ. Ты вот понимаешь как работает молекула? Как ионы и позитроны крутятся на орбитах? Как Глюоны и кварки влияют на свойства проводимости? Нет? Тогда ты хуёвый программист и ничего не поймёшь. Начинай с этого, пото углубляйся в химию фоторезиста, потом изучай процессоры и только потом Ассемблер. А уже после С, С++ и только затем раст. Иначе ты нихуя не поймёшь.

>>1239014
Не собрал свой процессор - не программист.

>>1239014
Да ты одинэсник, я посмотрю. Лепишь свои сраные молекулы на мутную каменюку субстрата, и еще все сроки еще просераешь. Настоящий программист потратил день на написание волновых функций - и был свет!

Если по теме, то перед Растом действительно рекомендуется промышленно пососать кактусца, потратив хотя бы полгода на резьбу по говну мамонта в виде легаси проектов на C+, чтобы не возникало вопросов, почему язык такой мнительный и почему нельзя хуяк-хуяк, как в Петоне. В любом случае, Раст в первую очередь низкоуровневый язык, и без хотя бы поверхностного знания крестов в системном программировании делать нечего.

>>1238196
Однако, Haskell тред не так активен.

>>1239070
По хаскелю больше книжек для вкатывальщиков, плюс там нет срачей на тему "раст нинужен".

>>1239067
Не совсем правда. В раст можно вкатываться со стороны хаскеля и пользоваться функциональными абстракциями без байтоебли и unsafe. Для бытовых задач этого за глаза.

>>1239146
Оно не окупится для бытовых задач - мало библиотек и много кропотливой работы по слежению за переменными, ненужной в языках с GC (и я гадаю, а не должен ли следить за лайфтаймами компилятор). Для mission critical тоже не то, там традиционно рулит spark и формальная верификация. Имхо, основные применения - всякие сетевые сервисы, игры, тяжелый прикладной софт - всё то, где нужны где-то 90% надежности и производительности.

>>1239168
Я это и имел ввиду под бытовыми задачами. За лайфтаймами и так компилятор следит, не понял что ты хотел сказать.

>>1239177
Я хотел сказать, что раз уж компилятор делает escape analysis, то он мог бы сам назначать лайфтаймы. Я пока просто не могу из головы придумать ситуацию, когда явное указание лайфтайма убережет меня от ошибки в коде.

Ну и бытовые задачи для большинства из нас, по моему впечатлению - это формочки виндовые шлепать да сайтики настраивать =) Раст привлекает как раз тем, что он позволяет хардкор типа вусмерть оптимизированных библиотек со встроенным jit-ом и метапрограммами, для ширпотреба он overkill.

>>1239224
> Я хотел сказать, что раз уж компилятор делает escape analysis, то он мог бы сам назначать лайфтаймы.
Ты просто путаешься. Лайфтаймы там нужны не для объектов, а для ссылок. Компилятор не может знать сколько ссылка (т.е. грубо говоря указатель) должен жить.

>>1239224
fn foo<T>(x: &'a T, y: &'b T) -> T
Компилятор тут не может сам угадать что ты пытаешься сделать.

>>1239229
>fn foo<T>(x: &'a T, y: &'b T) -> &T
Быстрофикс.
Вообще плюшки типа NLL потихоньку завозят, так что чем дальше в лес, тем умнее уомпилятор.

И вот например очень прикольное использование лайфтаймов.

Допустим у тебя есть JSON и ты хочешь десериализовать его в объекты. Но в жсоне много строковых данных и было бы неплохо эти строки не копировать, а в объектах просто вместо строк оставлять умные указатели (внутри которых будет указатель на начало строки и длина строки, в расте это именуют слайсом) на оригинальную строку жсона. И когда удалится последний объект с указателем, удалять и оригинальную строку. Таким образом можно сделать zero-copy десериализацию (ценой правда хранения полного жсона в памяти).

И, кстати, серде уже так умеет. А время жизни десериализованных структур отслеживается как раз встроенными в раст лайфтаймами. https://serde.rs/lifetimes.html

>>1239228
>>1239229
Да, извините, я туплю, по другому-то не получается позволить переменной пережить свой скоуп, не используя GC =/ Просто думал терминами функций а-ля C, когда время жизни динамической переменной чаще всего определялось в контексте, где она создана, напр. когда контролы на форме делаются членами класса и прибиваются со всеми потомками в деструкторе. А вот с лямбда-функциями так же не получится :(

>>1239238
Это называется reference counting, анон (: Я по твоей ссылке сходу понял только что зачем-то простую концепцию присыпали эльфийскими рунами. Но я обязательно разберусь, спасибо за пищу для размышлений.

>>1239269
> Это называется reference counting, анон
А раст может делать это без счётчика ссылок (точнее счётчик ссылок работает во время компиляции). Тупо отслеживая время жизни переменных и прописывая код уничтожения куда надо.

>>1239340
Не говори глупостей. Смотри документацию на std::rc::Rc

>>1239384
Ты дурак? Rc (вместе с RefCell) используются как ангалог растовских лайфтаймов и borrow-checker'а в рантайме. А я тебе про компил-тайм говорю.

>>1239340
Феерически идиотское решение. Когда в java объясняются immutable strings, как раз такой пример приводят, когда объясняют, что увлекаться ими не стоит. Когда ты что-то парсишь, последнее, что тебе надо - это привязанный, как слон за хобот, исходный жсон - что случится, если ты не копировал результат, а взял его из парсера. Это не говоря уже о том, что таких результатов может быть много, и они могут быть шрапнелью раскиданы по приложению.

>>1239386
> Феерически идиотское решение.
Так никто не заставляет. Можно объявить структуру как со слайсами и лайфтаймами, так и с нормальными строками и использовать по надобности.

>>1239387
Ну и другой пример: у жсона есть куча строк, но тебе нужна всего одна. Тогда для десериализации делаешь структуру со слайсами, а нужную строку после десериализации копируешь, а оригинальную структуру (с жсон-строкой) удаляешь. Тут уже увеличение перформанса будет сразу видно и никаких подводных камней.

>>1239389
То есть это такой способ обойти чекер лайфтаймов, который как раз и защищает от скрытых утечек памяти в этом случае =) И ты в любом случае скорее ограничишь весь кустарный парсинг одним скоупом и возьмешь просто слайсы от данных, а не всю эту тряхомудию. Я могу представить, что мне потребуются указатели внутрь данных, но я в любом случае объединю их в один объект, к его лайфтайму и привяжу данные.

>>1239497
> То есть это такой способ обойти чекер лайфтаймов
Дядя, ты дурак. Повторюсь, лайфтаймы используются для ссылок. При копировании с ссылки в новую строку какие там лайфтаймы были у ссылки побоку. У новой строки будет своё время жизни. Вся суть в том, чтобы копировать только одну, нужную строку, вместо копирования КАЖДОЙ строки внутри жсона.

>>1239386
> Это не говоря уже о том, что таких результатов может быть много, и они могут быть шрапнелью раскиданы по приложению.
> быть шрапнелью раскиданы по приложению.
Это словарное определение говнокода.

>>1239516
Я это знаю. Вся эта херомудия нужна, чтобы грохнуть исходные данные ровно когда исчезнет последняя ссылка внутрь, учитывая, что эта ссылка может быть выведена за пределы скоупа (т.е. обычных & недостаточно), я правильно понимаю?

Что-то давно никто не спрашивал почему hello_world.exe такой жирный и зачем нужен этот ваш раст, когда я и на си левой пяткой пишу без проблем.

Почему хеллоуворлд на расте такой жирный?

>>1242674
Двачую, я на си пишу, все умещается в 64 килобайта и НИ ЕДИНОГО СЕГФОЛТА

>>1242697
>64 килобайта

Это слишком много для си.

>>1242674
>Почему хеллоуворлд на расте такой жирный?

4.6 MB, хотя смотря с чем сравнивать, например, первая версия операционной системы колибри весит почти в два раза меньше в распакованном виде https://archive.kolibrios.org/f/releases/kolibri_0.1.0.0_src.zip

Вы чё, совсем ебанутые? Щас бы мегабайты считать. Нахер идите отсюда.

>>1243067
Разработчики браузеров давно не считают.

>>1243077
>Разработчики браузеров давно не считают.

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

>>1243081
Опять быдлокодерам с народом не повезло.

На расте можно писать высокоуровневые приложения типа веб сервисов?

>>1243276
Здесь мнения обычно варьируются от "раст отличный язык для веб-приложений" до "писать веб на расте будет только поехавший кретин".

>>1243285
Напиши свое мнение.

>>1243290
Веб уровня веб-сервера (как нжинкс например), либо какая-то ресурсоемкая обработка или необходимость обработать 300кк запросов в наносекунду (какие-нибудь счетчики статистики или другие метрики, апи, в общем ниша go) как по мне вполне ок. Но когда пытаются на расте сделать какие-то рельсы https://rocket.rs/ с шаблонизаторами, хтмлем и прочим, то ощущение что что-то пошло не так и не туда. Вряд ли это когда-нибудь принесёт какой-то профит, разве что если с веб-макаки перекатываешься, возможно стоит попробовать с веба и начать, но тоже сомнительно.
я не >>1243285

>>1243295
>https://rocket.rs/
По-моему суть в том, чтобы УВЕЛИЧИТЬ УНИВЕРСАЛЬНОСТЬ - ну типа вот взял какой-нибудь крестовик раст и сразу опа, может и сайтики писать, и никакие руби ему учить ненужно. Ну то есть ничего плохого в этом точно нет, пусть даже на убийцу рор оно и не претендует.

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


Заебали

>>1243276
У нас почти весь бекэнд на расте.
Юзаем actix + actix-web.

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

>>1243081
Новый ноут раз в два года - это значит ты, анон, из каждых двух лет месяц горбатишься на рукожопых калифорнийских смузихлебов. За всю жизнь это сколько - два года рабства на одни только ноуты? Да на хую я такой прогресс вертел. Лучше я за это время отращу бороду и хуйню под ногтями.

>>1243441
Эрланг так-то гораздо практичнее сабжа для бэка, хотя может у вас специфика какая-то.

Может быть.

Существуют ли драйвера на расте для популярных операционных систем?

>>1243932
Хеллоу ворлды.

>>1243936
Правда жирные. Целых 4,6 МБ, так что лучше взять СИшечку и вместить его меньше чем в 64 КБ.

>>1244341
Я так и сделал, но не словил ни одного сегфолта, ЧЯДНТ?

Байтоебы, зачем в 2018 году мерить размеры бинарников?

>>1235389
Могу ошибаться, но для 100k вроде достаточно java с netty

>>1244588
Я сеньор в enterprise 300к/сек, но в твоём коде нихуя не понял, что происходит кроме сишного кода, хотя когда-то пилил курсач на asm. Испытываю комплекс неполноценности. Даже не знаю, стоит ли углубиться в байтоёбство чисто для себя, или хуй забить.