Really what you’d want is each class to implement a ton of tiny interfaces for each aspect of its behaviour. Most of the time you’d just implement all the interfaces from scratch. Occasionally though, you really do want to just override some tiny part, and you would do so through delegation, not inheritance. You’d keep the “base class” as a member, implement all the interfaces you care about (ideally a small subset of the “base class” interfaces), but forward some of them directly to the “base”. Clearly a language could benefit from supporting this kind of delegation strategy directly, to avoid tedious typing

Раст умеет форвардить нереализованные «интерфейсы» к «базовому классу»?

Раст умеет форвардить нереализованные «интерфейсы» к «базовому классу»?

Afaik, пока не умеет. https://github.com/contactomorph/rfcs/blob/delegation/text/0000-delegation-of...

И да, с моей колокольни, этого сахара очень не хватает.

Есть довольно-таки интересный бенчмарк http-фреймворков. Разработчики Rust написали новую супер-пупер-библиотеку futures, которой от силы 2-3 месяца, на базе которой, в качестве PoC, написали http-фреймворк, который назвали minihttp. Для сравнения взяли другие детища из других платформ и языков, среди которых:

• rapidoid — на Java, якобы, считается самым быстрым фреймворком
• Стандартная библиотека http на Go
• fasthttp — самая быстрая реализация на Go
• node.js

Результаты можно посмотреть здесь: https://aturon.github.io/blog/2016/08/11/futures/

Rust

Хруст :D

бенчмарк http-фреймворков

«Магистро велемуро штангенциркуль членомеро» проще говоря. Этих «фреймворков» уже 100500 понаписано и все один другого быстрее.

Где рефакторинг, отладка, проверка ошибок на лету и т.д?

Рефакторинга, ЕМНИП, ещё нигде нету, а что не так с остальным?

Это вообще про любой бенчмарк можно написать.

Так как я уже понял, что HKT в ближайшие лет 5 ждать не стоит, в этом треде поною про процедурные макросы, non-lexical lifetimes и оператор ?.

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

Есть такой прекрасный язык - D. У него издревле был форум, на котором чуть ли не ежедневно выливалась тыща хотелок. Потом всё привели в нормальный вид, DIP, отдельные списки «сделать в этом году» и всё такое. Так вот - DIP-ы висят по 3 года, список «сделать в этом году» кочует уже столько же почти без изменений. Понятно на что я намекаю?

Понятно на что я намекаю?

Да, что D никому не нужен.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go

Golang с GC потребляет меньше памяти чем Rust.
Код на Go короче и легче читается.
Оптимизация кода в Go слабее так как не LLVM или GCC.
Rust компилируется намного медленнее даже без оптимизаций.

Golang с GC потребляет меньше памяти чем Rust.

Отключаем встроенный jemalloc и получаем почти сишное потребление памяти.

Оптимизация кода в Go слабее так как не LLVM или GCC.
Rust компилируется намного медленнее даже без оптимизаций.

А так же это синтаксически буквально в 10 раз более убогий язык. Можно сравнить например скорость компиляции явы со скалой, как думаешь, в чём там подвох?

Пипец

Есть наш православный Си! Зачем все остальное?

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

Красота, а где можно глянуть какие RFC приняты, какие нет

https://github.com/rust-lang/rfcs/pulls

Кроме того, разработчики языка активно общаются на https://internals.rust-lang.org

Есть наш православный Си! Зачем все остальное?

Недовбросил. Поди подбери и попробуй еще разок.

Где рефакторинг, отладка, проверка ошибок на лету и т.д?

Возьми Vim и обмажь плагинами по вкусу

Гунь, ты бы хоть посмотрел, кто это пишет, и откуда ноги растут: http://www.hashmismatch.net/pragmatic-bare-metal-rust/

Проект, - баян, к тому же это обертка над FreeRTOS для рустеров, а не переписывание последней на этом вашем «безопасном».

С таким же успехом можно завернуть вам немножко бугурта через FFI.

А так же это синтаксически буквально в 10 раз более убогий язык.

Синтаксис не количественная величина, а качественная. В Golang всё отлично с этим.

В Golang всё отлично с этим.

Смею несогласиться с тем, что копипаста, кодогенерация и тонны лапши, как следствие, полное несоответствие DRY и вытекающие из этого проблемы — отлично.

Это первый качественный, а не количественный ответ гофера на этот арнумент. Но у Go тем не менее синтаксис богаче не становится.

Такой вопрос. Какое есть адекватное решение сделать дефолтную реализацию некоторых методов для трейта. Хотелось бы получить нечто похожее на абстрактные классы из c++

Шта? Использую Sublime. До QtC как до луны.

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

node.js

Он тормоз по умолчанию. Ничего удивительного.

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

оператор ?.

Уже давно в nightly.

меня от %langname% отпугивает тот факт, что написанное на этом языке можно переиспользовать только в этом языке. Скажем, нааисал я клевую либу на %langname%, а что если завтра полюблю %otherlangname%? Переписывать эту либу на %otherlangname%? Какое бездарное повышение энтропии вселенной!

Какой объем проекта? Сколько внешних зависимостей? Дополнение крейтов из зависимостей - самая большая боль.

Дебаггер я и в плюсах не юзаю, так что не страшно. Если что-то хитрое - RUST_BACKTRACE с головой.

не стыдно такое в теме про Rust писать)

Какой объем проекта?

< 5000 SLOC

Сколько внешних зависимостей?

diesel-rs

Дополнение крейтов из зависимостей - самая большая боль.

Натравил racer на ~/.cargo, нормально перемалывает (после первой сборки и резолва зависимостей, конечно)

Модерн с обмазыванием C++14 STL или с ручным управлением памятью?

Не стыдно такое про %langname% писать?

Откуда Вы все беретесь? Поколение реддита, блджад.

5000 SLOC

У меня ~14. Без нормальной IDE уже тяжеловато.

Модерн с обмазыванием C++14 STL или с ручным управлением памятью?

При чём тут C++? Тем не менее? я пишу на С++11/Qt с QSharedDataPointer. STL не перевариваю.

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

Специально для нас придумали Vala и gobject-intospection.

А дебаггер сильно спасает когда нужно написать что-то использующее хотя бы пару потоков?

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

А вот это чего же? https://github.com/redox-os/redox/graphs/commit-activity Такое впечатление, что сдохло так и не родившись.

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

Такое впечатление, что сдохло так и не родившись.

Мне, в общем, без разницы, но даже я смог найти https://github.com/redox-os/kernel

Ну вот там как раз пара человек, несмотря на то, что это «collaborative effort». Не спас их раст.

The kernel code was getting increasingly messy to the point where only the original writer would be able to find and fix bugs. Fortunately, the kernel of Redox is relatively small and such a project is estimated to take only a few months.

Написали кривое поделие, теперь переписывают))

Их с таким подходом не спас бы вообще ни один язык.

Не спас их раст.

И какой вывод ты из этого делаешь?

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

Так generics и templates это кодогенерация в виде тонн лапши.
Генерация контейнеров по типам данных?
В Go встроенный тип Map:

map[string]int // массив чисел, индексация строками
map[*T]struct{ x, y float64 } // массив структур, индекс указатель на T
map[string]interface{} // массив любых типов(пустой интерфейс), индекс строками

Функции наверно лучше обобщать интерфейсами(duck typing).
Код Go производит впечатление обратное «лапше».

Пока что у меня создается впечатление, что rust не слишком подходит для написания чего-то сложнее небольшой специализированной библиотечки. Из-за отсутствия полноценной (а не для галочки) поддержки ООП. При этом, даже без такой полноценной поддержки, он уже становится монструозен...

Ну а что касается системного программирования, то, видимо, преимущества Rust по сравнению с C по большей части мнимые.

trait Foo {
    fn foo(&self) {
      // default implementation
    }
    fn bar(&self);
}

http://rustbyexample.com/trait.html

Или я не понял вопроса?

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

Создается впечатление, что ты мало знаешь о Rust.

Из-за отсутствия полноценной (а не для галочки) поддержки ООП

Да? Странно, что отсутствие «полноценной (а не для галочки) поддержки ООП» не помешало Си.

Ну а что касается системного программирования, то, видимо, преимущества Rust по сравнению с C по большей части мнимые.

Это заключение сделано на основании... чего?

Поддерживает ООП значительно лучше, чем Си. Си тоже

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

?

преимущества Rust по сравнению с C по большей части мнимые

Лол.