Rust 1.6

Но опыт Java показывает, что аннотации подобных таких задч экономят много сил.

Так разве в джеве «слабые ссылки» в виде аннотаций сделаны?.. По моему, нет:

https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html

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

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

А было ли его использование обязательным, когда он был?

Нет.

Можно ли было обойтись без него?

Да.

В Go тоже был GC, в 2011-2012г.г. размен Go на Rust был шило на мыло, так что выпил GC это уже оптимизация под новую нишу.

Необходимые средства, делающие язык годным для ядерного кода (unsafe и ffi) на тот момент уже были.

Кстати, насколько я понимаю ffi в нынешнем виде запилили незадолго после unsafe, не так ли?

А когда именно это произошло?

Кстати, вот тут Патрик рассказывает об особенностях работы с динамической памятью в Rust до выпила встроенного GC.

Делать GC частью библиотеки предлагали еще в 2013 до его выпила, и соображения были примерно такие:

• GC нужен в серве для интеграции с движком JS, а так же для реализации движков различных динамических языков.
• Для разных применений нужны разные GC, соответственно не стоит оставлять GC частью языка, пусть обезьянка инженер сам выбирает, какой GC ему нужен.
• Rust дулают на замену C++, из всех фич Rust GC - единственное, что плохо сочитается с концепциями C++;
• GC сильно усложняет runtime lib, в имбеде иногда нет ресурсов на GC, луше выпилить, а то вдруг фрагментация возникнет...

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

Я бы не сказал, что на Idris'е трудно что-либо написать. Доказать — пожалуй, но это из-за того, что в доказательстве требуется указывать даже тривиальные вещи.
Clean не академический, он просто вымер.

Я читал.

В имбеде (во всяком случае в маленьких системах с ограниченными возможностями) C++ используется в основном, как C with classes.

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

Множественное наследование тоже нет (аналогично),

Шаблоны-классы используются (в ScmRTOS, например), но можно и без них обойтись, хоть и не типобезопасно, а можно сделать типобезопасную реализацию шаблонов на С.

Шаблоны функции - используются (видел 1 раз в прошивке для 3D-принтера), без них обойтись еще легче и никакого влияния на типобезопасность не будет.

Так что C или C++ - практически не важно.

GC - единственное, что плохо сочитается с концепциями C++;

http://en.cppreference.com/w/cpp/memory

Обрати внимание на секцию " Garbage collector support".

Это был вольный перевод слов Патрика:

Of these, the only language items that don’t have direct C++ equivalents are the garbage collection primitives. If those were eliminated, then Rust as a language would be every bit as freestanding as C++ is.

Так разве в джеве «слабые ссылки» в виде аннотаций сделаны?.. По моему, нет:

В Java слабые ссылки немного не для этого. Там же есть GC, который и так всё делает в плане работы с циклами в графах. Слабые ссылки нужны для интерфейса с ним. С их помощью делаются всякие кэши, которые держат ссылки на кэшируемые объекты. Если на объект уже никто не ссылается (кроме слабой ссылки), его еще можно достать из кэша до пока он не вычищен GC.

Т.е. для графов с циклами компилятору Java ничего нигде расставлять не нужно.

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

Ну а что ему стоит в if() {} его завернуть?

//Психиатр

А после этого приходят представители промышленности и пользуются

Немного другая сфера языков под задачу. Я помню про Буран и Пролог.

Я имею в виду «пользуются опробованными идеями», не готовыми языками. Тот же Rust использует идеи Cyclone, но не более. И если в половине созданных языков с линейными типами есть GC - я считаю это проверенной идеей.

«value can be used at most once»

... at the same time

Ы? Вообще за время жизни значения.

В Go тоже был GC, в 2011-2012г.г. размен Go на Rust был шило на мыло

Да блин, зачем ты это говоришь? Ты же не знаешь ровно ничего про Rust образца 2011 года. Он был совсем непохож на нынешний.

так что выпил GC это уже оптимизация под новую нишу.

Выпил GC - это обычное «не пригодилось».

Перестань натягивать сову на глобус.

Кстати, насколько я понимаю ffi в нынешнем виде запилили незадолго после unsafe, не так ли?

У тебя какая-то мания на unsafe. Но, поскольку unsafe в каком-то виде был уже в rustboot, его запилили раньше, чем «современный FFI», что бы ты этим термином не называл.

Кстати, вот тут Патрик рассказывает

Делать GC частью библиотеки предлагали еще в 2013

Спасибо, я знаю.

Был бы благодарен за конкретную ссылку

Конкретной ссылки нет. Это впечатление, сложившееся от регулярного чтения.

https://doc.rust-lang.org/std/io/index.html

А это «because they are traits, Read and Write are implemented by a number of other types, and you can implement them for your types too.» означает, что маразм iostream из цепепе крепчает? :-) Что сложнее, реализовать потомка std::streambuf из цепепе или вот это в русте? :-)

Я не совсем понял, что тебя не устраивает.

Я не совсем понял, что тебя не устраивает.

Меня не устраивает маразмо-дизайн iostream в цепепе :-) И не только меня :-) Интереса ради, хочется узнать как с этим в русте :-)

Read это одна функция, которая читает в предоставленный буффер байты из твоего источника. Write, соответственно, пишет. Чтобы реализовать, надо написать реализацию этой одной функции. Всё крайне просто.

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

Тем более, Rust легко встраивать в другие языки

? Как например дернуть код на Rust из Python.

С помощью ffi. В официальной документации(учебник фактически) есть пример для python-а(https://doc.rust-lang.org/book/rust-inside-other-languages.html вроде есть и перевод). Некие умельцы даже писали расширение для похапэ.

С помощью ffi.
https://doc.rust-lang.org/book/rust-inside-other-languages.html

Так это наоборот, крайне неудобно, топорно и масса ручной работы. Так все умеют. А удобно, это, например, так:

char const* foo() { return "foo"; }
char const* bar() { return "bar"; }

object choose_function(bool selector)
{
    if (selector)
        return python::make_function(foo);
    else
        return python::make_function(bar);
}

BOOST_PYTHON_MODULE(make_function_test)
{
    def("choose_function", choose_function);
}

>>> from make_function_test import *
>>> f = choose_function(1)
>>> g = choose_function(0)
>>> f()
'foo'
>>> g()
'bar'

Не так давно видел пример вызова кода на rust'e из node.js. Работа в данном направлении ведется очень активная.

Ну а что ему стоит в if() {} его завернуть?

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

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

В Java слабые ссылки немного не для этого.

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

Это не часть ядра языка, это часть стандартной библиотеки, в Rust был специальный тип указателей @.

То есть С++ рантайм не включает в себя GC в обязательном порядке, a рантайм Rust должен был включать.

Выпил GC - это обычное «не пригодилось».

It might be possible to create a language that presents only a simple, fully automatic memory management system at first, and which surfaces the machinery of safe manual memory management* only when the programmer requires it for maximum performance. This would ease the learning curve, as programmers would be able to write many, perhaps most programs without ever learning how to manage memory at all.

Пригодилось!

А потом, когда обезъянки хипстеры лисперы члены ЦА научились писать на Rust, сообществу провели по губам сделали вот так:

In short, I think that Rust as a language should focus on roughly the same application domain as C++ does.†

Important to this effort is to have as small of a runtime as possible, just as C++ does, leaving higher-level abstractions to libraries. And, in fact, we are almost there already.

Ну то есть сообщество сообществом, а цели и интересы чёрного властелина спонсора превыше всего.

Перестань натягивать сову на глобус.

Ну, я же не виноват, что глобус выполнен в форме дилды, а сова явно ведет распутный образ жизни. XD

Пригодилось!

В мысленном эксперименте.

Ну то есть сообщество сообществом, а цели и интересы чёрного властелина спонсора превыше всего.

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

глобус выполнен в форме дилды

А, окей. Ты не можешь перестать.

Тылгуннер, скажи ка, вот эта порнография fn - это сообщество так захотело? Не могу представить, чтобы на трезвянку кто-то желал такого синтаксиса. Открываешь первый же хеловорд и уже нужен рвотный пакетик. Для консистентности надо бы еще trt, strct, tp и прочие рептилоизмы. Или вот синтаксис лайфтаймов - из всех закорючек выбрали парный символ, уже семантически занятый. В результате в любом редакторе сразу слетает подсветка, если его специально не научить расту. Вот на ЛОРе, например, вся копипаста - нечитаемый мусор. Впечатление, что это специально мин понакидали на уровне простейшего синтаксиса, чтобы сразу закрепить репутацию вырвиглазного говна. А то вдруг кто-то начнет на этом писать даже. Ну и чем дальше в лес, тем толще партизаны. Из-за обилия сущностей натуральный комбинаторный взрыв при их описании с использованием всех возможных скобок, стрелок, закорючек. Обработка ошибок в стиле callback hell. Макросы так просто феерия в жанре «кот на клавиатуре». Ну просто дали оторваться ученым-маньякам по полной, чтобы обычный кодер в ужасе убегал (тут то мы ему и покажем Го, будут слезы счастья).

callback hell

Вижу нравится тебе это выражениe. Ну хорошо хоть не dll hell. А что? Настолько же «похоже».

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

вот эта порнография fn - это сообщество так захотело?

Нет. Тараканы в голове Грейдона заставили его сделать это.

Или вот синтаксис лайфтаймов - из всех закорючек выбрали парный символ, уже семантически занятый.

А это сделало сообщество. И это блестящее решение.

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

Хватит с нас и одной Ады.

Обработка ошибок в стиле callback hell. Макросы так просто феерия в жанре «кот на клавиатуре». Ну просто дали оторваться ученым-маньякам по полной, чтобы обычный кодер в ужасе убегал (тут то мы ему и покажем Го, будут слезы счастья).

Чушь.

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

Pyramid of doom не в Rust появилась.

Нет, им покажут не Го, а F#, сейчас главный спонсор некрософт же!

Ну, кажется, тема выдохлась. Давайте что-ли подведем итоги, кто хочет.

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

Что есть хорошего, с моей колокольни.

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

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

Программирование в большом гораздо проще на Rust, чем на С++. К нашим услугам единообразно оформленные модули, макросы и пакетный менеджер. Привет, Maven! Нет никакой необходимости вводить такие драконовские стайл-гайды, как гугловский. И это большой плюс Rust перед C++ уже сейчас.

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

Теперь минусы.

Один и очень серьезный. Нет совместимости с унаследованным кодом и библиотеками С++, которых очень много, и которые никто на Rust переписывать ради афинных типов и программирования в большом не будет.

Короче, я для себя мотивации дальше углубляться в Rust не нашел. С++ lock-in :) Последний так же хорошо развивается, и проблемы программирования в большом (модульность) обещают решить в ближайшие 2-3 года. Это не так уж и много. В остальном, библиотеки рулят.

//Психиатр

Удаление исключений — вещь спорная, но я записываю скорее в плюсы. Так как в модели С++ исключения очень сложно реализовать эффективно и с ними легко убивается производительность.

Ага, а ещё если исключение генерирует деструктор, то легко может убиться и программа :-) Но главная проблема исключений - это неизбежная раскрутка стека, что в оппозит сигнальному протоколу Common Lisp делает исключения C++ лишь серенькой возможностью отделять код обработки ошибок от основного кода :-) Ну да ладно, ведь C++ чуть-чуть более высокоуровневый язык по сравнению с C :-)

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

Сочувствую :-)

Программирование в большом гораздо проще на Rust, чем на С++.

В чём же это? :-)

К нашим услугам единообразно оформленные модули, макросы и пакетный менеджер. Привет, Maven!

Нафиг оно надо? :-) Пока, Maven! :-)

Нет никакой необходимости вводить такие драконовские стайл-гайды, как гугловский.

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

И это большой плюс Rust перед C++ уже сейчас.

У джавы есть преимущества перед C++, это очевидно :-) (См. Tiobe.)

Один и очень серьезный. Нет совместимости с унаследованным кодом и библиотеками С++, которых очень много, и которые никто на Rust переписывать ради афинных типов и программирования в большом не будет.

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

Короче, я для себя мотивации дальше углубляться в Rust не нашел. С++ lock-in :) Последний так же хорошо развивается, и проблемы программирования в большом (модульность) обещают решить в ближайшие 2-3 года. Это не так уж и много. В остальном, библиотеки рулят.

Ну и правильно :-) С мейнстримом как-то безопаснее :-)

Ну да ладно, ведь C++ чуть-чуть более высокоуровневый язык по сравнению с C :-)

Немного не так. С++ такой же низкоуровневый, как и С. Но с добавлением достаточно развитых «дешевых» абстракций. И только «дешевых». Дорогие «абстракции» ломают парадигму и функциональную нишу этого языка. Зачем нам скрещивать ежа и ужа? У С++ есть своя немальнькая ниша где он и только он (плюс его аналоги) эффективен. Все попытки протащить какие-то другие языки в эту нишу с треском провалились. Хочется развитых абстракций, за которые согласен платить в рантайме, используй Haskell, Lisp, да что угодно. Можешь даже Mercury, если задача требует.

//Психиатр

Можешь перейти на Edge. :D

В Java слабые ссылки немного не для этого. Там же есть GC, который и так всё делает в плане работы с циклами в графах. Слабые ссылки нужны для интерфейса с ним. С их помощью делаются всякие кэши, которые держат ссылки на кэшируемые объекты. Если на объект уже никто не ссылается (кроме слабой ссылки), его еще можно достать из кэша до пока он не вычищен GC.

Тогда это не WeakReference, а SoftReference. Если на объект не осталось ни одной strong ссылки, то weak протухает. Soft же протухает при GC, если не удаётся обычным образом вычистить достаточно памяти.

я бы даже сказал statically. Но это видимо отголоски опыта с RTOS.

Справедливости ради, есть real-time GC, которые позволяют уменьшить недетерминизм и время остановки до некоторой заданной величины.

суровые embedded-щики будут писать на одном подмножестве Rust-а со своим набором библиотек...

Я тут zinc.rs кумарнул для stm32l*. Требуется напильник, но в общем и целом получается прикольно. Мне на первый взгляд нравится гораздо больше чем коцаный C++ или всё делать на С.

Я себе запиливал шаблонную обёртку над портами контроллера, которая на основе дефайнов из sdk инстанцировала экземпляры для условно PORTA PORTB и т.п. Соответственно если ты пытался заюзать несуществующий порт, ну там, портировал прошивку с одного на другой контроллер в рамках семейства, получал ошибку компайлтайма. Не то, что бы особо нужно или важно, но мне было удобнее писать что-то типа Port<A>.Set(i), нежели *(PORTA_OFFSET) |= (1 << i);

На вкус и цвет, как говориться, я обычно делаю нижний уровень, который абстрагирует всякие там порты, пины, UARTы и т.д., а дальше просто пишется что-то вроде dbg_port_send(«Hello world!», 13);