LINUX.ORG.RU

познать Rust

 


2

6

Доброго времени суток. Ищется материал по Rust, где:

1. В сжатой, но понятной форме изложено положение Rust в контексте других языков. В чём суть его новизны. В качестве базы ожидается C++, Java, Common Lisp. Желательно, с примерами кода.

2. Критика. Какие грабли уже проявили себя.

Желательный объём - до 5 страниц текста.

★★★★★

Последнее исправление: den73 (всего исправлений: 1)

Ответ на: комментарий от Deleted

Меня смущают нестандартизованные и популярные языки.

Даже джава или питон? Ну если под стандартами понимать ISO.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Freyr69

Что там может быть такого ужасного?

Дженерики иногда смотрятся громоздко, особенно с лайфтаймами. Макросы, опять же, не сильно изящные.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

либо там это «криво спроектированное говно» не нужно.

Подозреваю, что он о наследовании.

А то ведь Rust-овский drop не тянет на C++ные деструкторы по обозначенными выше причинам.

По каким?

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

А чего сразу джава? Для плюсов такое есть? Чтобы надёжно и быстро? У меня не всегда даже автодополнение нормально работает в QtCreator.

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

foror ★★★★★
()
Ответ на: комментарий от foror

Это показывает только то, что задача создания «мощных инструментов рефакторинга, интеллектуального автодополнения» и т.п. нетривиальна. Она требует существенных затрат и вложенных усилий. Тратить силы сразу и на язык и на такие инструменты - расточительство которе мало кто может себе позволить.

Weres ★★★
()
Ответ на: комментарий от foror

go разрабы вот до сих пор в виме кодят и ничего.

Gorthauer ★★★★★
()
Ответ на: комментарий от DarkEld3r

Можно найти работу, где не придётся копаться в древнем легаси.

Строительство зданий и сооружений :)

Или где оно, хотя бы, переписывается понемногу.

В .Net. При каждом обновлении фреймворка. С remotingа на WCF, с WCF на REST... Ну и да, с делегатов на лямбды... Но конкатенацию строк плюсиками в цикле никто из гениев переписывания не тронет аж с 2.0 :)

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от foror

Особенно, когда тебя забрасывают деньгами и есть возможность нанимать разрабов.

Издеваешься? У мозиллы нет кучи денег и я очень сомневаюсь, что они много ресурсов на раст выделяют. Хоть что-то дают и то хорошо.

Если бы они параллельно с языком «мега ИДЕ» делали, то сейчас были бы по прогрессу на несколько лет назад. Тоже плохой вариант. Опять же, плагины к разным ИДЕ имеются. Да, не идеальные, но пилятся понемногу.

И ты пропустил вопрос про С++. Язык до 21 века дожил, замену ему, в определённых сферах, сложно найти. Тем не менее, возможности ИДЕ отстают от той же джавы. И ничего, как-то живут люди.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Weres

Она требует существенных затрат и вложенных усилий

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

foror ★★★★★
()
Ответ на: комментарий от slackwarrior

Строительство зданий и сооружений :)

Ты о чём? Вот у нас на работе С++11 применяется. Со временем и на С++14 перейдём, пока что винда назад тянет. То есть это совсем не редкость.

В .Net.

Как там в .Net не знаю, но для плюсов есть инструменты типа clang modernize, которые помогают обновлять код.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

пока что винда назад тянет.

Везетвамнах. У нас кровавый ынтерпрайз и студия 2008 (стандарт матьего). И чтоб на серверах 2000 оффтопика все работало и чтоб на древней солярке и какой-то древнем редхате, где еще gcc не поддерживает с++11. Как-то ifdef выручает, но реально забодало.

anonymous
()
Ответ на: комментарий от DarkEld3r

Издеваешься? У мозиллы нет кучи денег и я очень сомневаюсь, что они много ресурсов на раст выделяют. Хоть что-то дают и то хорошо.

Что же вас каждого носом, что ли тыкать? Изучай https://www.opennet.ru/opennews/art.shtml?num=43192 К тому же, там лоби педерастов, а они то умеют деньги раздобыть среди своей братии. Так что перестань думать о бедственном положении мозилы.

Язык до 21 века дожил, замену ему, в определённых сферах, сложно найти

Потому что в ИТ, как и везде, большинство разрабов жрут, что дают, не задумываясь, что текущие возможности техники позволяют сделать более качественые инструменты, чем то, что делали в 70-90-х.

go разрабы вот до сих пор в виме кодят и ничего.

Тем не менее, возможности ИДЕ отстают от той же джавы. И ничего, как-то живут люди.

В джунглях папуасы тоже как-то живут, но я не хотел бы так жить.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от Manhunt

Некуда валить-то. Языки со сборкой мусора и прочим jit — не канают.

А раз «не канают» и другой альтернативы нет, то значит объективно не мешает.

Не взлетел даже D. D!!! И это во времена между C++98 и поправками от 2003г. С ту-у-у-пыми компиляторами и тупыми реализациями стандартной библиотеки, когда о кросс-платформенности и мультиархитектурности даже не стояло. Когда на C++ (а не на улучшенном C с классами) нельзя было писать без глюков.

Даже Go от языка «системного программирования» сдулся до языка «сетевых служб», ага. А уж как старались, как старались...

И есть ли хоть одна объективная предпосылка (кроме чует моя левая полужопина), что Раст не повторит судьбу этих двух языков? Ни «ситуации», ни должного «бэкграунда»...

А вот кого полным-полно — так это нытиков, хипстеров, маргиналов и прочей розовосопливой части человечества.

Macil ★★★★★
()
Ответ на: комментарий от anonymous

Не, эскобар.жпег уместен в дихотомии rust — c++.

Hertz ★★★★★
()
Ответ на: комментарий от Macil

Не взлетел даже D. D!!! Даже Go

Долбаная. Сборка. Долбаного. Мусора.

А раз «не канают» и другой альтернативы нет, то значит объективно не мешает.

Реальная альтернатива называется «Rust».

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Macil

Не взлетел даже D. D!!!

D только в этом году научился сам себя компилировать. Спустя почти 15 лет разработки. Если это не убожество, то что тогда убожество?

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Надеюсь, что взлетит.

И я — надеюсь. Но уже давным-давно не верю.

Macil ★★★★★
()
Ответ на: комментарий от Weres

Ну и где же эти инструменты? Кроме как для Java никаких вменяемых IDE нет.

А для кого делать эти инструменты? Для скриптоты? Так это невозможно из-за ущербности скриптоты изначально. Кто остается популярным еще, кроме Java? Си? Так для него так же сложно написать подобный инструмент, ибо в 70-х, когда закладывался его дизайн, о таких инструментах не думали. Что там еще? С++/C#? Так для них есть необходимые интеллектуальные инструменты разработки. Для первого сделали сколько смогли, ибо дизайн ЯП также ущербен, если брать современные мерки. А больше то и нет никого на радарах.

foror ★★★★★
()
Ответ на: комментарий от Manhunt

D только в этом году научился сам себя компилировать.

А вот GHC как не умел, так и не умеет... Рантайм-то на C. И никто не парится. Почти за 25 лет.

Macil ★★★★★
()
Ответ на: комментарий от foror

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

И кто это должен сделать?

tailgunner ★★★★★
()
Ответ на: комментарий от foror

Что же вас каждого носом, что ли тыкать?

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Даже Java и Python. Python переболел той же болезнью, что и D: большие проблемы с обратной совместимостью. Java тоже болеет, время от времени.

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

А новое - в новый язык. Чтобы поисковые запросы не выкидывали на старое api по сути уже другого языка.

Deleted
()
Последнее исправление: merhalak (всего исправлений: 2)
Ответ на: комментарий от DarkEld3r

По каким?

Отсутствие наследование в языке. Да и вообще Rust-овский drop больше напоминает .NET-овский IDisposable.Dispose(), нежели C++ные деструкторы.

eao197 ★★★★★
()

У раста серьезная проблема с целевой аудиторией. Как ЯВУ для тырпрайза он совершенно не годится из-за своей параноидальной модели работы с памятью. У типичных индусов даже примеры скомпилировать не получится, не то что бы все это понять. Для стстемного программирования раст тоже выглядит переусложненным. Не представляю себе системщика, который бы променял свою «сишку» на такое чудо-юдо. Остается только сложная прикладуха, где нужно бодаться с C++. Ни у кого пока на этом поле не получилось. Тем более с новыми стандартами вообще не понятно нафига козе боян. Вот и выходит, что язык вроде неплохой, да только негде его применять по большому счету.

anonymous
()
Ответ на: комментарий от Weres

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

anonymous
()
Ответ на: комментарий от DarkEld3r

Один миллион - не куча денег.

Это 100 разрабов-месяцов или команда из 4 хороших разрабов на 2 года. Вполне хватит, чтобы запилить хорошую IDE. И конечно это не куча денег, но как я понимаю, Servo для них стратегический проект. А если они могут кинуть столько денег just for fun, то логически можно заключить, что для стратегических проектов могут бросить больше.

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

foror ★★★★★
()
Ответ на: комментарий от tailgunner

И кто это должен сделать?

Разве не очевидно? Тот кто заворил всю эту кашу.

foror ★★★★★
()
Ответ на: комментарий от anonymous

Эта задача тривиальна если из компилятора сразу нужные API торчат

Тривиальна, ага. Сколько там лет прошло от появления нужных API в LLVM до основанных на нем «мощных инструментов рефакторинга»? Много ли таких инструментов?

tailgunner ★★★★★
()
Ответ на: комментарий от Deleted

Java тоже болеет, время от времени.

Да ладно? Хочешь сказать, что джава нестабильнее стандартизованных плюсов?

Лучше бы язык сознательно стабилизировали и только багофиксом занимались

По сути, во всех версиях после 1.0 этим и занимаются.

А вообще делать каждый раз новый язык не практично. Фрагментация только увеличится и пользы мало будет.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Да и вообще Rust-овский drop больше напоминает .NET-овский IDisposable.Dispose(), нежели C++ные деструкторы.

Это ещё почему? Drop, точно так же, как и деструктор, вызывается при выходе из скоупа. Вручную звать необходимости нет, в отличии от Dispose, хотя возможность и имеется (как и в С++).

Отсутствие наследования, как по мне, к деструкторам не особо относится.

DarkEld3r ★★★★★
()
Ответ на: комментарий от foror

но как я понимаю, Servo для них стратегический проект

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

Это серьезный вопрос, ответ на который Rust-овский drop не дает.

Ну и похожесть на IDisposable проистекает прямо из примеров из штатной доки по Rust-у:

impl<T> Drop for Box<T> {
    fn drop(&mut self) {
    ...
    }
}
Как по мне, как такое же подмешивание интерфейса/трайта к типу, как и имплементация интерфейса в C#.

Ну и, кстати говоря, IDisposable в C# ориентирован на плотное использование в сочетании с конструкцией using. А на using можно смотреть как на один из частных случаев лайфтаймов Rust-а.

Так что для меня лично Rust-овский Drop — это больше IDisposable, нежели C++ные деструкторы.

eao197 ★★★★★
()
Ответ на: комментарий от foror

пилят то проект по сложности на уровне современных ОС

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

anonymous
()
Ответ на: комментарий от DarkEld3r

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

А поисковый запрос python 3 может найти библиотеки 3-ей версии для python 2.

Deleted
()
Ответ на: комментарий от eao197

А деструкторы в C++ вынуждены жить с такой вещью, как наследование.

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

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

Этот вопрос эквивалентен тому, что делать, если исключение вылетает во время исполнения деструктора, вызванного другим исключением. Java ответ на этот вопрос даёт в виде suppressed-исключений. C++ и Rust просто делают abort().

Ну и похожесть на IDisposable проистекает прямо из примеров из штатной доки по Rust-у

Просто в Rust нет «особенных» методов вроде конструкторов и деструкторов, которые по сути интерфейсы, обязательные для реализации всеми типами. Здесь это просто ещё один трейт (пусть и с особенной поддержкой от компилятора).

ilammy ★★★
()
Ответ на: комментарий от eao197

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

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

Как по мне, как такое же подмешивание интерфейса/трайта к типу, как и имплементация интерфейса в C#.

Я бы не сказал. Просто в расте методы реализуются «извне» класса. Ну и для популярных вещей сделаны трейты.

А на using можно смотреть как на один из частных случаев лайфтаймов Rust-а.

На это тоже можно смотреть как на «частный случай лайфтаймов»:

{
    ObjectWithDestructor o;
}
Но это уже натягивание совы на глобус. Выгода деструкторов, как и дропа как раз в том, что не надо их руками звать. Даже через «частичную автоматизацию» через using.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Legioner

нормальные шаблоны

У них же дженерики.

anonymous
()
Ответ на: комментарий от Gorthauer

Такая же скорость кода, но при этом гарантии безопасности.

А точно такая же? Был медленнее.

anonymous
()
Ответ на: комментарий от Legioner

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

Как раз все круто в крестах сделано. Мне не хватает деструкторов и RAII в других языках...

anonymous
()
Ответ на: комментарий от DarkEld3r

Наследования (данных) - нет, поэтому и нет связанных с этим возможностей.

Собственно, об этом и речь: нет наследования, поэтому Drop в Rust не есть полный эквивалент деструкторов в C++.

Для меня важно другой аспект взаимосвязи деструкторов и наследования: допустим, у нас был базовый класс A, от него отнаследовали B, от него отнаследовали C. Изначально явно определенный деструктор был у A и у C, а у B его не было. Потом в B реализовали деструктор. Но ни для кого ничего не изменилось. Потому, что для B деструктор таки был, просто он генерировался полностью компилятором.

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

Покажите как сделать RAII в CL.

anonymous
()
Ответ на: комментарий от anonymous

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

Читайте D&E. Модель с рестартами и сигналами была отброшена, как требующая больших ресурсов и как бесполезная на практике.

anonymous
()
Ответ на: комментарий от DarkEld3r

Выгода деструкторов, как и дропа как раз в том, что не надо их руками звать. Даже через «частичную автоматизацию» через using.

Вот кстати да. Деструкторы и Drop определяются автором объекта. Использование using — пользователем объекта. Если Drop можно дописать постфактум и после этого он автоматически станет вызываться везде, где его следует вызывать, то после реализации IDisposable ещё следует везде руками расставлять using.

ilammy ★★★
()
Ответ на: комментарий от maloi

Зато должны юзать везде try-with-resource, чтобы что-то нормально закрывалось. Жесть.

anonymous
()
Ответ на: комментарий от eao197

Поля структуры (читай: базовые классы) дропаются вне зависимости от того, что написано в реализации drop() для структуры. drop() — это кастомизируемая пользовательская часть того, что вызывается при завершении времени жизни объекта.

ilammy ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.