The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Выпуск языка программирования Rust 1.43"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск языка программирования Rust 1.43"  +/
Сообщение от opennews (?), 23-Апр-20, 23:37 
Опубликован релиз языка системного программирования Rust 1.43, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52797

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


4. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от rustgonewellemail (?), 23-Апр-20, 23:50 
ну всё, теперь и в Rust есть метапрограммирование шаблонов (обобщённых параметрически через T подстановку трейтов и их имплементаций) - теперь можно HKT и GAT делать прямо через макросы, ух! >_<
Ответить | Правка | Наверх | Cообщить модератору

1. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аномномномнимус (?), 23-Апр-20, 23:37 
Там уже есть goto и макросы? Надо срочно обмазаться
Ответить | Правка | Наверх | Cообщить модератору

2. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (2), 23-Апр-20, 23:42 
Не-не антикор обработка не для Rust, даже прямо наоборот
Ответить | Правка | Наверх | Cообщить модератору

3. "Выпуск языка программирования Rust 1.43"  +3 +/
Сообщение от Аноним (3), 23-Апр-20, 23:46 
Безусловный переход безусловно эффективен. Язык без такой базовой инструкции не может быть полноценным. Макросы это конечно хорошо, но говорить с машиной на понятном ей языке ещё лучше.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

32. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от A.Stahl (ok), 24-Апр-20, 07:04 
Попадалась мне в руки как-то довольно забавная книжка, так там автор на базе какого-то примера предложил отказаться от кучи операторов. Мол, а представьте что нет у нас while. И вообще никаких циклов нет. И того нет. И этого нет. Не серьёзно, конечно, предложил.

Не помню уж как называлась. Что-то старое из конца 80х - начала 90х. 128 советов чего-то там.

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск языка программирования Rust 1.43"  +3 +/
Сообщение от Аноним (39), 24-Апр-20, 08:22 
Николас Вирт всегда ратовал за простоту языка (все описание языка должно помещался на одной странице и быть понятным домохозяйке), контроль компилятора за памятью.

Также Николас говорил, что язык программирования, компилятор, ядро ОС и процессор должен разрабатывать одна команда. Только в этом случае можно достичь простоты и совершенства. Пример A2 https://en.m.wikipedia.org/wiki/Bluebottle_OS

Ответить | Правка | Наверх | Cообщить модератору

96. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (96), 24-Апр-20, 12:44 
Ну да, простоты, совершенства и полной бесполезности.
Ответить | Правка | Наверх | Cообщить модератору

117. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от аа (?), 24-Апр-20, 14:25 
Для обучения простые вещи полезны.
Ответить | Правка | Наверх | Cообщить модератору

119. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (119), 24-Апр-20, 14:39 
Java+ARM... но кое-кому это очень не понравилось
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

156. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Lex (??), 24-Апр-20, 21:57 
Жаба.. не понравилась... ну как же такое возможно !!111
Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (60), 24-Апр-20, 09:29 
>Мол, а представьте что нет у нас while

Так действительно while и не нужен.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

68. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Урри (?), 24-Апр-20, 10:12 
Scheme, в чистом языке вообще никаких циклов нет, но задачи все равно красиво и элегантно решаются.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

91. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от freehckemail (ok), 24-Апр-20, 12:09 
> Не помню уж как называлась. Что-то старое из конца 80х - начала 90х.

Уж не знаю, кого читали конкретно Вы, но Абельсон и Сассман издали SICP в 85м, и там вполне наглядно показывалось, что циклы есть синтаксический сахар.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

94. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от A.Stahl (ok), 24-Апр-20, 12:31 
Но очень вкусный и полезный сахар.

Ответить | Правка | Наверх | Cообщить модератору

100. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от freehckemail (ok), 24-Апр-20, 12:56 
> Но очень вкусный и полезный сахар.

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

Ответить | Правка | Наверх | Cообщить модератору

107. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от коржик (?), 24-Апр-20, 13:37 
упаси боже
Ответить | Правка | Наверх | Cообщить модератору

157. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Lex (??), 24-Апр-20, 21:59 
По большому счёту может оказаться, что, при нормально растущем стеке, не потребуются ни циклы, ни даже регистры..
Ответить | Правка | Наверх | Cообщить модератору

199. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (199), 25-Апр-20, 14:50 
Только не просто рекурсию, а рекурсию с tail call optimization.
Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

246. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от freehckemail (ok), 27-Апр-20, 10:59 
> Только не просто рекурсию, а рекурсию с tail call optimization.

Рекурсия без TCO -- это не рекурсия, а непонятно зачем нужный огрызок. =)

А ежели быть точнее, то когда мы говорим о рекурсии, мы естественно имеем в виду хвостовую рекурсию. Если язык её по умолчанию не предоставляет, а только вон как в случае C -- только в виде оптимизации, которая ещё и срабатывает от случая к случаю -- то толку от такой рекурсии мало, равно как и смысла обсуждать её. Это как обсуждать type inference в Scala -- номинально для галочки есть, но по факту кому от неё в таком виде прок...

Ответить | Правка | Наверх | Cообщить модератору

264. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от none (??), 30-Апр-20, 11:16 
>[оверквотинг удален]
> Рекурсия без TCO -- это не рекурсия, а непонятно зачем нужный огрызок.
> =)
> А ежели быть точнее, то когда мы говорим о рекурсии, мы естественно
> имеем в виду хвостовую рекурсию. Если язык её по умолчанию не
> предоставляет, а только вон как в случае C -- только в
> виде оптимизации, которая ещё и срабатывает от случая к случаю --
> то толку от такой рекурсии мало, равно как и смысла обсуждать
> её. Это как обсуждать type inference в Scala -- номинально для
> галочки есть, но по факту кому от неё в таком виде
> прок...

кстати type inFErence - в Scala очень полезен, как минимум без него исходники были бы в пару раз больше из за лишних описаний типов

Ответить | Правка | Наверх | Cообщить модератору

269. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от freehckemail (ok), 01-Май-20, 22:23 
>[оверквотинг удален]
>> имеем в виду хвостовую рекурсию. Если язык её по умолчанию не
>> предоставляет, а только вон как в случае C -- только в
>> виде оптимизации, которая ещё и срабатывает от случая к случаю --
>> то толку от такой рекурсии мало, равно как и смысла обсуждать
>> её. Это как обсуждать type inference в Scala -- номинально для
>> галочки есть, но по факту кому от неё в таком виде
>> прок...
> кстати type inFErence - в Scala очень полезен, как минимум без него
> исходники были бы в пару раз больше из за лишних описаний
> типов

Ну не в пару -- это Вы сильно преувеличиваете.

Если хотите посмотреть на то, каким type inference должен быть -- приглядитесь к ocaml. У языка строгая типизация, но указывать типы Вам придётся ровно в одном случае: при конструировании новых типов (ну и для функторов, разумеется). Дальше -- всё будет выведено автоматом.

Ответить | Правка | Наверх | Cообщить модератору

273. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от none (??), 06-Май-20, 10:11 
в ocaml это достигается "+." и подобными "особенностями",
а в scala есть интеропрерабильность с jvm и тайп классы - поэтому типов нужно указывать немного больше типов, но я лучше тип укажу чем пользоваться "+." и подобным
Ответить | Правка | Наверх | Cообщить модератору

274. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от freehckemail (ok), 07-Июн-20, 07:58 
> в ocaml это достигается "+." и подобными "особенностями",

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

А то, о чём говорите Вы -- это просто атавизмы из SML. Да, они вроде как в OCaml есть, но они так, для обратной совместимости.

Ответить | Правка | Наверх | Cообщить модератору

283. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от freehckemail (ok), 07-Июн-20, 15:25 
Аноним84701, цени своё время.
Ответить | Правка | К родителю #269 | Наверх | Cообщить модератору

142. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от little Bobby tables (?), 24-Апр-20, 18:40 
кто это
Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

247. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от tmplsr (?), 27-Апр-20, 13:49 
>Не помню уж как называлась. Что-то старое из конца 80х - начала 90х. 128 советов чего-то там.

"128 советов начинающему программисту?"

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

248. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от A.Stahl (ok), 27-Апр-20, 14:14 
Да, она. Весьма забавная была книжка в своё время.


Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от коржик (?), 24-Апр-20, 07:39 
всё что выглядит так assert!(...) - это макросы
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

45. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (45), 24-Апр-20, 08:47 
goto был и есть, даже в пакетной базе (только более свежее на гитхабе, новые изменения очень такие воодушевляющие и пока тестятся и дорабываются на гите)...
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

72. "Выпуск языка программирования Rust 1.43"  –2 +/
Сообщение от Аноним (72), 24-Апр-20, 10:18 
чем Rust лучше баш скриптов? разве у баша есть конкуренты?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

5. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от НяшМяш (ok), 24-Апр-20, 00:59 
Ничего не понял, но взял попкорн и ручку (наблюдать и записывать).
Ответить | Правка | Наверх | Cообщить модератору

165. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (165), 24-Апр-20, 23:49 
А чего не понял добавили хрени для того что бы вклинивать в язык новую хрень прям на уровне языка.
Интересно, а из макроса можно макрос определить ?
Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск языка программирования Rust 1.43"  –9 +/
Сообщение от 777 (??), 24-Апр-20, 01:35 
"Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем"
Возможность работы с указателями это плюс для настоящего программиста, для баклана - да, желательно вообще писать на php
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск языка программирования Rust 1.43"  +4 +/
Сообщение от Аноним (12), 24-Апр-20, 02:38 
Почему вот только у настоящих программистов потом ошибки и уязвимости из-за ошибок с указателями?
Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск языка программирования Rust 1.43"  +16 +/
Сообщение от OpenEcho (?), 24-Апр-20, 02:39 
>Возможность работы с указателями это плюс для настоящего программиста, для баклана - да, желательно вообще писать на php

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

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

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

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

27. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (27), 24-Апр-20, 05:47 
>Без обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе...

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

Типа "это язык несомненно альтернативно-нужный"?

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от OpenEcho (?), 24-Апр-20, 09:13 
> Это не так. Хаят язык, когда он чем-то не устраивает.

Есть ложка, а есть вилка...
Каждая создана для конкретного применения.
Не устраивает есть суп вилкой? Ну так юзай ложку...

Не задумывались, - как много веб продуктов написанно на С/С++ ?


> Или ты сторонник политкоррктности в отношении языков программирования?

Причем здесь политика, сестра проститутки которая?

Иди найди работу бэкенд/фронтенд разработчиком где требуются языки програмирования использующие "поинтеры", а когда (если) найдешь, поделись как долго искал...


> Типа "это язык несомненно альтернативно-нужный"?

Альтернативно нужный???
Назвать ведущий бэкенд язык альтернативным, - это конечно смело !

В бизнесе есть такое понятие: спрос и предложение.
Есть спрос - быстро и дешево делать веб приложения, именно поэтому любой хостинг предлагает ПЫХ, а не С++ как бэкенд.

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

ПЫХ вовсе не виноват, что на нем пишут много недоучек и создают о нем дурную славу, это не мешает тем, у кого руки растут из нужного места поднимать на нем проекты типа мордакниги.

(Кстати, я не ПЫХ програмист, - просто видение реальности не из розовых облаков)

Ответить | Правка | Наверх | Cообщить модератору

92. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Tita_M (ok), 24-Апр-20, 12:25 
Это раньше фейсбук на пыхе написан был. Сейчас, наверно, во всю используется языкр на него похожий, но со строгой статической типизацией. https://www.opennet.ru/opennews/art.shtml?num=50133 наверно наелись неочевидных ошибок и уязвимостей в коде на пыхе.
Ответить | Правка | Наверх | Cообщить модератору

104. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от OpenEcho (?), 24-Апр-20, 13:12 
> ....наелись неочевидных ошибок и уязвимостей в коде на пыхе

Ну давайте, показывайте ЯП, который не страдает этими симптомами...

Ответить | Правка | Наверх | Cообщить модератору

158. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Lex (??), 24-Апр-20, 22:05 
Пых вполне неплох и с задачами, для которых он изначально предназначен( своеобразный веб ) он справляется отлично.

То ли дело всякие монструозные динозавры типа жабы или плюсов.. или, даже, тормознутый питон :)

Кстати, так и какие языки «безальтернативно-нужные» ?

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

61. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от GentooBoy (ok), 24-Апр-20, 09:38 
>Без обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе...

Случай выше подходит под ваш ответ, но это не всегда так. ЯП это всегда компромисс на который пришлось пойти его создателям.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

20. "Выпуск языка программирования Rust 1.43"  +5 +/
Сообщение от qetuo (?), 24-Апр-20, 03:27 
Если тебе нужны указатели, то в Rust они есть. Но для реализации большого количества задач они не нужны и с успехом заменяются ссылками.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

23. "Выпуск языка программирования Rust 1.43"  +3 +/
Сообщение от наблюдающий_изда_лк (?), 24-Апр-20, 04:52 
Был уже тут один монарх, пяткой себя в грудь бил, все говорил о реализации блога на C++. То ли за 21 день собирался он это сделать, то ли за неделю. Но уже скоро год пройдет, а блога как небыло, так и нет.

Мораль: выбирай инструмент под задачу.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

46. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (46), 24-Апр-20, 08:48 
ну, treefrog все же есть и пока вроде жив. Думаю блог на нем можно было бы сделать (но не буду, у меня руки не оттуда, откуда надо)
Ответить | Правка | Наверх | Cообщить модератору

103. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от RibiKukan (ok), 24-Апр-20, 13:09 
Трепло запартное, бегом побежало за пруфами. Исполнять.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

159. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Lex (??), 24-Апр-20, 22:17 
Ну я имел дело с сайтом на пюсАх, правда, в качестве поддержки, а не разработки.

И до и после попадалось множество разных проектов( пых, жс итп ), но такого убогого *** как тот проект, я не встречал.
Казалось бы, плюсЫ типо_несравненно_круче того же пыха, но потом, правда, оказывается, что пых изначально пилился как подобие шаблонизатора для веб-страниц, на нем огромное множество наработок итп, тогда как плюсЫ - просто_уродливая_надстройка_над_Си_доя_ооп и в задаче генерации вебстраниц с возможностью норм доработок за приемлемое время, плюсЫ начисто проигрывают тому же пыху.

Как ни странно, но, да: «любой задаче свой инструмент»

Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от RibiKukan (ok), 25-Апр-20, 12:15 
>Ну я имел дело с сайтом на пюсАх, правда, в качестве поддержки, а не разработки.

У вас постоянные проблемы с логикой. Вы не знаете что такое С++ и никаком образом С++ от не С++ не отличите. Поэтому толку с этих рассуждений?

>И до и после попадалось множество разных проектов( пых, жс итп ), но такого убогого *** как тот проект, я не встречал.

Опять же - ты не отличаешь жопу от пальца.

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

Ты даже о вебе ничего не знаешь. Шаблонизатор и пых сдох лет 10 назад. К тому же только идиот будет писать какие-то шаблоны на крестах.

Запомни на будущие. Если кто-то из мира С/С++ использует текст - это залётный колхозник.

>на нем огромное множество наработок итп,

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


>тогда как плюсЫ - просто_уродливая_надстройка_над_Си_доя_ооп

Чини методичку. Как я и говорил - ты нихрена о С++ не знаешь. Да и о си тоже.

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

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

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

>Как ни странно, но, да: «любой задаче свой инструмент»

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

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

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


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

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

А уже те самые колхозники далее придумывают херню вида "под задачу".

Ответить | Правка | Наверх | Cообщить модератору

197. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от RibiKukan (ok), 25-Апр-20, 12:20 
Ну и самое интересное - эта методичка уже протухла. За пруфами далеко ходить не нужно. Колхозники типа тебя орали годами "пхп наше всё - под задачу". Гугл взял сишку, прикрутил к ней гц и ооп-надстройку и оказалось, что даже колхозники могут что угодно пилить.

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


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

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

160. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Анонимный Алкоголик (??), 24-Апр-20, 22:23 
> Был уже тут один монарх, пяткой себя в грудь бил, все говорил
> о реализации блога на C++. То ли за 21 день собирался
> он это сделать, то ли за неделю. Но уже скоро год
> пройдет, а блога как небыло, так и нет.
> Мораль: выбирай инструмент под задачу.

А что его делать-то? Любой веб-сервер плюс небольшой html-файл и вот простейший блог. А что? >:-)

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

24. "Выпуск языка программирования Rust 1.43"  +13 +/
Сообщение от Аноним (24), 24-Апр-20, 05:13 
Я этот комментарий вижу под каждой статьей про новую версию Rust (с вариациями в "остротах", но с тем же смыслом и к той же цитате). И каждый раз он собирает плюсы. И ведь никто не потрудится минуту поискать информацию и открыть для себя, что указатель - настолько же фундаментальная абстракция для Rust, как и для C. Многое говорит о местной аудитории.

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

67. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 24-Апр-20, 10:12 
> по умолчанию в Rust применяется особый тип указателя (ссылка), который также содержит в себе информацию о времени жизни памяти, на которую он ссылается

Мне кажется, так неправильно говорить. Возможно это формалистская придирка, но всё же...

"Указатель который содержит информацию о времени жизни" -- это в моём понимании, что-то типа std::rc::Rc, то есть указателя со счётчиком ссылок. Или, допустим, несуществующий в std, но всё же возможный Gc указатель, вида:

struct Gc<T> {
    p: *T,
    gc_bit: bool,
}

Вот такого рода указатели содержат информацию. И такого рода указателями тоже можно жонглировать в Rust, если использовать трейт AsRef, типа:

fn print_i32<T: AsRef<i32>>(i: T) { ... }

Но по умолчанию используются обычные ссылки, которые плюс-минус C'шные указатели, но с ограничениями на использование. С ними связана информация о времени жизни, но только в процессе компиляции.

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

Расслабься, это _нормальная_ ситуация. Иметь мнение важнее, чем иметь обоснованное мнение. Эта идея глубоко заложена в нашей культуре, она просматривается везде, например в школе сдать работу учителю, пускай и с бредовым содержимым, гораздо лучше, чем сдать пустой лист или не сдать ничего. За бредовое содержимое при некотором везении можно получить 3 из жалости. Если везения не случится, поставят 2, и скорее всего отвяжутся. А если не сдать ничего, то начнут пропесочивать, могут ещё и родителей подключить, и скорее всего заставят сдать.

> Многое говорит о местной аудитории.

Очень мало говорит. Если взять рандомную аудиторию, то с вероятностью существенно выше 0.5 она будет действовать именно так. Информации в утверждении о том, что аудитория именно такая -log(p), где 0.5<p<1.0, и это меньше 1 бита. Вот если бы аудитория была бы более вдумчивой и попадала бы в другую группу, для которой 0.0<p<0.5, то тогда можно было бы допустить что "много говорит", поскольку там без дополнительных исследований встречаемости таких аудиторий было бы невозможно ограничить -log(p) сверху.

Ответить | Правка | Наверх | Cообщить модератору

201. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от PnD (??), 26-Апр-20, 00:14 
Минусы под данным комментарием можно было бы рассматривать как "счётчик мак^w приматов" (но скаляр всё портит), однако по 2-му пункту таки имею возражение.
"Не тупи, сделай хоть что-то, не стой столбом etc." — вполне себе жизненная тактика. Потому что повышает шанс выжить в наиболее поганых ситуациях. И её надо (на мой вкус) закладывать в рефлексы. Нейронные матрицы, так сказать, обучать. Как раз задача для средней школы (ну и для родителей тоже).
Один из многочисленных минусов такой тактики Вы описа́ли. Но и пытаться зажмуривать всех придурков — тоже унылая антиутопия.
dnl пошёл задёргивать занавески…
Ответить | Правка | Наверх | Cообщить модератору

214. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 26-Апр-20, 06:58 
Я не сказал, то это свойство культуры плохо, я лишь сказал, что оно нормально в нашей культуре. Мысль о том, что это плохо -- это твоя мысль, а не моя. Хотя, отмечу, я с ней согласен. Я вообще с большим подозрением отношусь к любой норме -- норма всегда субоптимальна.
Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск языка программирования Rust 1.43"  –8 +/
Сообщение от Fracta1L (ok), 24-Апр-20, 08:17 
И правда, какое же это ойти будет без сишных дыр?
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

42. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Аноним (42), 24-Апр-20, 08:39 
У тебя какие-то проблемы с дырами.
Ответить | Правка | Наверх | Cообщить модератору

53. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Fracta1L (ok), 24-Апр-20, 09:06 
С дырами у всех проблемы
Ответить | Правка | Наверх | Cообщить модератору

144. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (144), 24-Апр-20, 19:19 
У тебя их целых 2, и обе не там. ;)
Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором  –4 +/
Сообщение от Аноним (7), 24-Апр-20, 01:50 
Ответить | Правка | Наверх | Cообщить модератору

35. Скрыто модератором  +1 +/
Сообщение от коржик (?), 24-Апр-20, 07:45 
Ответить | Правка | Наверх | Cообщить модератору

70. Скрыто модератором  –1 +/
Сообщение от Ordu (ok), 24-Апр-20, 10:17 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

87. Скрыто модератором  +/
Сообщение от Аноним (7), 24-Апр-20, 11:57 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

89. Скрыто модератором  +/
Сообщение от Аноним (7), 24-Апр-20, 11:58 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

8. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (8), 24-Апр-20, 02:10 
чем оно лучше чем Go?
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от leap42 (ok), 24-Апр-20, 02:29 
> чем оно лучше чем Go?

машинный код в 2 раза быстрее (в среднем), насколько я могу судить нелья разыменовать nil указатели (в Go, к сожалению это сплошь и рядом), гораздо больше языковых средств (если для вас это плюс)

Ответить | Правка | Наверх | Cообщить модератору

106. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (106), 24-Апр-20, 13:18 
Что ещё за nil указатели?
Ответить | Правка | Наверх | Cообщить модератору

169. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от leap42 (ok), 25-Апр-20, 03:48 
нулевые, те которое есть, но ни на какие реальные данные не ссылаются

так понятнее?

Ответить | Правка | Наверх | Cообщить модератору

162. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от anonymous (??), 24-Апр-20, 22:53 
> машинный код в 2 раза быстрее (в среднем)

Очень сильное заявление :)

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

170. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от leap42 (ok), 25-Апр-20, 03:51 
> Очень сильное заявление :)

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

Ответить | Правка | Наверх | Cообщить модератору

200. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от anonymous (??), 25-Апр-20, 17:51 
Если proof -- это benchmark game от Debian, то проблема в том, что эти игры очень далеки от реальной ситуации. Например, правилами этой игры искусственно запрещается использовать mem pool-ы, в то время, как в Go является более чем нормальной практикой применять sync.Pool, что во многих случаях забесплатно сильно снижает нагрузку на GC (а GC является единственной существенной причиной, почему Go может быть медленнее). Я писал свои варианты для этого benchmark game, которые работают намного быстрее (и код выглядел естественно для Go), но не отправлял эти варианты внимательно почитав правила.

Если у вас будут проблемы с производительностью в Go -- вы обратитесь за помощью. Лично я постараюсь вам помочь. Я ещё не сталкивался ни с одной проблемой производительности в Go, которую нельзя было разумно решить из-за ограничений языка.

Но если говорить о реальных Downsides, то это, в первую очередь, потребление памяти, минимальный размер бинария и т.п. Это не даёт свободно использовать Go, например, в Embedded, где вполне можно использовать тот же Rust.

Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск языка программирования Rust 1.43"  +6 +/
Сообщение от Аноним (7), 24-Апр-20, 02:32 
Это вообще разные по областям применения языки, надо спрашивать у сектантов чем это лучше C++ и почему там так много разных и явно лишних закорючек в синтаксисе :)
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

11. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (12), 24-Апр-20, 02:35 
Я слышал, что в Rust память безопасная, и без GC, это правда?
Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (7), 24-Апр-20, 02:43 
Не верь этим сказкам сынок, слухи они такие..
Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (12), 24-Апр-20, 02:55 
Все хочу найти язык с безопасной памятью
Ответить | Правка | Наверх | Cообщить модератору

77. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Урри (?), 24-Апр-20, 10:26 
Любой лисп, пых, руби.
Ответить | Правка | Наверх | Cообщить модератору

16. "Выпуск языка программирования Rust 1.43"  +3 +/
Сообщение от qetuo (?), 24-Апр-20, 02:59 
GC нет. Память безопасна в рамках работы с safe Rust. Чтобы стрелять в ноги, нужно явно указывать блок `unsafe`.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

19. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от qetuo (?), 24-Апр-20, 03:25 
"Закорючки" там не лишние, они обозначают лайфтаймы, которые являются уникальной фичей языка. В большинстве случаев выводятся компилятором, но в нетривиальных случаях нужно расставлять руками.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

21. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (7), 24-Апр-20, 04:20 
Не будьте таким серьезным, весьма предположительно, что тот анонимус может знать раст. Просто,
раст выглядит смешным, ну как брайнфак) вот люди и подшучивают по доброму
Ответить | Правка | Наверх | Cообщить модератору

110. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от коржик (?), 24-Апр-20, 13:55 
Ну да, режет глаза, но если привыкнуть, то поймёте, что сильно лучше и не получилось бы
Ответить | Правка | Наверх | Cообщить модератору

202. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (202), 26-Апр-20, 00:20 
Не совсем разные. Есть пересечения. Они оба лезут в системное программирование, и оба лезут в веб.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

17. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (7), 24-Апр-20, 03:21 
И вообще, память безопасная или нет, вопрос десятый, начиная с некоторой квалификации разработчика и использования RAII.
Вот такие реально важные для промышленности вопросы, как легкость и быстрота разработки (соответственно время выпуска продукта на рынок и норма прибыли у компании), удобство чтения кода, время вхождения в проект новых участников, стабильность языка - пока прямыми конкурентами являются такие языки как Malbolge, Brainfuck и пока с далеким отрывом  Var’aq ))
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

25. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (24), 24-Апр-20, 05:30 
> пока прямыми конкурентами являются такие языки как Malbolge, Brainfuck и пока с далеким отрывом  Var’aq ))

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

Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (7), 24-Апр-20, 10:54 
Ага, вот зайдет наконец на опеннет Лицо Принимающее Решения и капец, Var’aq на фронтэнд а Malbolge на бекенд, и правда поаккуратнее надо с советами
Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (127), 24-Апр-20, 16:37 
> память безопасная или нет, вопрос десятый,

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

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

132. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним84701 (ok), 24-Апр-20, 16:49 
>> память безопасная или нет, вопрос десятый,
> По вашему это нормально, что для индустрии важнее быстрее наклепать, чем безопаснее
> и надежнее сделать? А если дома строили и самолёты делали тоже
> с расчетом на скорость разработки? Почему мы не можем научиться у них?

Потому что мало кто хочет платить цену самолета или дома за хранилку фоток котиков?
https://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4... (верификация микроядра L4)

Ответить | Правка | Наверх | Cообщить модератору

134. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (7), 24-Апр-20, 17:08 
Нет это не нормально для Вас, но нормально для той системы в корой мы существуем - капиталистической.
Тут важна норма прибыли - накладные издержки будут сокращаться. См. катастрофу Боинг-737 MAX в Индонезии.
В любом случае, трудозатраты и инструмент должны быть адекватны задаче.

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

Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

140. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (127), 24-Апр-20, 18:07 
Да я, знаете, не столько за раст конкретно, сколько за безопасность памяти. Пример с авиаиндустрией я у Шнайера почерпнул из его "Практической криптографии". Там он вообще много требований на ЯП наложил.

А на Аде как, безопасная память?

Ответить | Правка | Наверх | Cообщить модератору

141. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (7), 24-Апр-20, 18:27 
Там есть сборщик мусора и своеобразное RAII - через переопределение процедуры Unchecked_Deallocation
Ответить | Правка | Наверх | Cообщить модератору

18. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от qetuo (?), 24-Апр-20, 03:22 
Создатели языка не считают тебя идиотом. Нормальный пакетный менеджер. Нет GC. Быстрее, причем намного. Бенчмарки смотри на https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

22. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Андрей (??), 24-Апр-20, 04:52 
> We ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.

binary-trees:

В Go-версии импортируются только системные библиотеки:

import (
   "flag"
   "fmt"
   "runtime"
   "strconv"
)

В Rust-версии какие-то левые:

extern crate typed_arena;
extern crate rayon;

-----------

regex-redux

В Go-версии:

import (
   "io/ioutil"
   "os"
   "fmt"
   "regexp"
)

В Rust-версии снова:

extern crate rayon;
extern crate regex;

-------------

n-body

Go:

import (
   "flag"
   "fmt"
   "math"
   "strconv"
)

Rust:

ну..... там SIMD на SIMDе и SIMD'ом поганяет. Хоршенько приправлено unsafe. И вообще похоже на макро-ассемблер.

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

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Анонимный Кактус (?), 24-Апр-20, 06:41 
> В Go-версии импортируются только системные библиотеки. В Rust-версии какие-то левые

Потому что в Rust есть нормальный менеджер пакетов, а в Go нет?

> n-body ... там SIMD на SIMDе и SIMD'ом поганяет. Хоршенько приправлено unsafe. И вообще похоже на макро-ассемблер

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

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Анонимм (??), 24-Апр-20, 10:02 
А что не так с гошным менеджером пакетов?
Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (31), 24-Апр-20, 06:51 
>Создатели языка не считают тебя идиотом.

А с чего ты взял, что создатели Go считают?

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

47. "Выпуск языка программирования Rust 1.43"  +3 +/
Сообщение от Аноним (47), 24-Апр-20, 08:48 
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

– Rob Pike

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск языка программирования Rust 1.43"  –2 +/
Сообщение от anoun (?), 24-Апр-20, 09:22 
>probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language

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

Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (74), 24-Апр-20, 10:19 
Старую собаку новым трюкам не научишь.
Ответить | Правка | Наверх | Cообщить модератору

112. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Совершенно другой аноним (?), 24-Апр-20, 14:01 
Имхо, там ключевое на ява/си/питон, а
"They’re typically, fairly young, fresh out of school"
и ещё более, имхо, ключевое:
"but we want to use them to build good software".
Из которого самое ключевое "to use them".
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

30. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (31), 24-Апр-20, 06:49 
>чем оно лучше чем Go?

Порогом вхождения.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

29. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (31), 24-Апр-20, 06:44 
Кто-нибудь ставил на реальное железо redox? https://www.redox-os.org/
Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от nonamenogame (?), 24-Апр-20, 07:30 
https://www.phoronix.com/scan.php?page=news_item&px=Redox-OS...
Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (78), 24-Апр-20, 10:49 
Лучше вот это почитай https://twitter.com/jeremy_soller/status/1251364826464411653
Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (-), 24-Апр-20, 08:05 
когда тип f16 добавят?
Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Аноним (57), 24-Апр-20, 09:18 
Сразу после того, как их завезут в LLVM
Ответить | Правка | Наверх | Cообщить модератору

38. Скрыто модератором  –4 +/
Сообщение от Fracta1L (ok), 24-Апр-20, 08:18 
Ответить | Правка | Наверх | Cообщить модератору

40. Скрыто модератором  +2 +/
Сообщение от Аноним (42), 24-Апр-20, 08:37 
Ответить | Правка | Наверх | Cообщить модератору

44. Скрыто модератором  +/
Сообщение от фррр (?), 24-Апр-20, 08:46 
Ответить | Правка | Наверх | Cообщить модератору

50. Скрыто модератором  –1 +/
Сообщение от Аноним (46), 24-Апр-20, 08:59 
Ответить | Правка | Наверх | Cообщить модератору

84. Скрыто модератором  +/
Сообщение от Аноним (84), 24-Апр-20, 11:45 
Ответить | Правка | Наверх | Cообщить модератору

122. Скрыто модератором  +/
Сообщение от Аноним (46), 24-Апр-20, 15:06 
Ответить | Правка | Наверх | Cообщить модератору

51. Скрыто модератором  +/
Сообщение от Аноним (42), 24-Апр-20, 09:00 
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

59. Скрыто модератором  +/
Сообщение от Fracta1L (ok), 24-Апр-20, 09:29 
Ответить | Правка | Наверх | Cообщить модератору

69. Скрыто модератором  +2 +/
Сообщение от Аноним (74), 24-Апр-20, 10:16 
Ответить | Правка | Наверх | Cообщить модератору

81. Скрыто модератором  –1 +/
Сообщение от Элитный линуксоид (?), 24-Апр-20, 10:56 
Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск языка программирования Rust 1.43"  +3 +/
Сообщение от Аноним (41), 24-Апр-20, 08:37 
Скажу за себя: код на расте крайне сложно воспринимать, а это сама по себе проблема.
Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от фррр (?), 24-Апр-20, 08:45 
Приведи пример такого кода.
Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (47), 24-Апр-20, 08:54 
1. #[cfg()]
2. macro_rules! mac_trait {
       ($i:item) => {
           trait T { $i }
       }
   }
Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от фррр (?), 24-Апр-20, 09:49 
А что тут сложного для линуксоида? Даже типичный bash сложнее.
Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (71), 24-Апр-20, 10:17 
Пардон, он не сложный, он уродский
Ответить | Правка | Наверх | Cообщить модератору

83. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Анонимм (??), 24-Апр-20, 11:25 
Макросы уродуют любой язык. Но людям очень хочется иметь макросы из-за больших возможностей, которые они дают.
Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (127), 24-Апр-20, 16:38 
Кроме Лиспа, Лисп прекрасен с макросами
Ответить | Правка | Наверх | Cообщить модератору

207. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от burjui (ok), 26-Апр-20, 02:50 
Лисп прекрасен только как идея. Читать код на любом из лиспов - задача не для слабонервных, и скобочки тут - самая безобидная из причин.
Ответить | Правка | Наверх | Cообщить модератору

183. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 25-Апр-20, 07:13 
> Пардон, он не сложный, он уродский

Невозможно не согласиться.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

208. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от burjui (ok), 26-Апр-20, 02:58 
Вопрос в том, насколько хорошо ты знаком с Rust? Пример кода выше я распарсил за секунду, несмотря на его спорные эстетические качества. По-моему, это главная проблема местных критиков - нежелание прикладывать усилия для изучения языка и выделять на это время. Все хотят, чтобы Rust был понятен и радовал глаз вот прям сразу. При этом никого не удивляет, что с естественными языками так не бывает, даже если алфавит тот же, что и в родном языке. Что-то я не вижу жалоб на то, что описание освежителя воздуха на казахском плохо читается.
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

48. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 24-Апр-20, 08:53 
Безумный синтаксис - болезнь почти всех хипстерских поделок. А потом они визжат, что их новый мегаязык не востребован, и начинают заниматься словесным унижением остальных, так и оставаясь со своими 0.1% условного "рынка".
Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (42), 24-Апр-20, 09:02 
У кобола синтаксис близок к разговорному английскому и почему на нем ничего не пишут сейчас? Не модно.
Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 24-Апр-20, 09:10 
> У кобола синтаксис близок к разговорному английскому и почему на нем ничего
> не пишут сейчас? Не модно.

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

Ещё одна проблема всех хипстерских поделок - они рассчитаны на недалёкого писателя, к которому внезапно почему-то надо адаптировать сам язык. При этом хипстота, "знающая" "как правильно", забывает, что на вкус и цвет все фломастеры разные.

Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 24-Апр-20, 09:13 
Добавлю про безумие - это взаимосвязано, и все эти языки просто, ну банально, неэффективны. Ни в плане возможностей синтаксиса, ни в плане производительности, C-подобный синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется, и позволяет при _достаточной грамотности_ творить достаточно чУдные вещи, обходя оптимизатор. Всего этого хипстерские поделки лишены, они упёрты в процесс ("писателя"), нежели в достижение таковым писателем результата.
Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (63), 24-Апр-20, 09:52 
Ну нет, _минимум_ - это все-таки синтаксис Лиспа. Вот там уж действительно и машине все очевидно, и никаких лишних символов-закорючек нет
Ответить | Правка | Наверх | Cообщить модератору

146. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 24-Апр-20, 20:18 
> в C нет пристойного механизма обработки ошибок

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

Ответить | Правка | Наверх | Cообщить модератору

147. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 24-Апр-20, 20:18 
Сорян, я следующему по тексту отвечал, но промахнулся.
Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

82. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Ordu (ok), 24-Апр-20, 11:12 
> C-подобный синтаксис требует _минимум_ специальных обёрток

Это верно только до тех пор, пока ты ограничиваешь себя теми техниками программирования, которые требуют минимум специальных обёрток в C. Загляни в glibc, там есть, например, функция sort. Эта функция работает вызывая функцию сравнения элементов с передачей этих элементов указателями. Если тебе нужно быстро сортировать, то неплохо было бы функцию сравнения элементов внедрить в код сортировки -- это позволит оптимизатору сделать всё сильно лучше. Но в C это невозможно без специальных обёрток, которые привнесут в C программирование с generic типами как в C++. Альтернатива -- писать реализацию sort под каждую комбинацию типа контейнера и типа элемента. Можно ещё попробовать макрос запилить, для генерации таких реализаций, но макроязык в C немногим лучше sed'а, ради такой мелочи лучше его не использовать.

Хочешь ещё один пример? Я разочаровался в C лет десять назад, когда задумался о том, что в C нет пристойного механизма обработки ошибок, и попытался изобрести что-нибудь вменяемое. Всякие там non-local exits, типа longjmp и тому подобные, я не считал вменяемыми, и решил что раз есть возвращаемое значение, то в нём можно передавать информацию об ошибке. Но отказываться от того, чтобы возвращать return'ом из функции результат работы, и возвращать его присвоением указателю, мне тоже не хотелось. В результате я пришёл к чему-то в стиле:

enum error_t {
    NO_ERROR = 0,
    // тут перечисление всяких других констант
}

struct my_func_returns {
    int ret;
    error_t err;
}

struct my_func_returns my_func(...) {
    ...
    return (struct my_func_returns){ .ret = 42, .err = NO_ERROR };
}

Это работало офигенно, машинный код получался прямо как задумано, такой как я бы на ассемблере сделал: функция возвращала два значения в двух регистрах, в одном возвращаемое значение, в другом код ошибки. Но это порождало такое количество boilerplate, то я пришёл к выводу, что это не вариант. Я пытался придумать что-нибудь с макросами, чтобы хотя бы на вызывающей стороне получалось что-нибудь пристойное, чтобы обработка ошибок не перемешивалась бы с основной логикой. Но в C совершенно убогий макроязык, он работает очень локально, не въезжает в синтаксис с которым работает, и поэтому тупо навтыкать на каждое возвращаемое значение по метке, и после каждого вызова функции делать проверку и goto на метку -- это не вариант: меткам всё равно имена надо назначать вручную, и всё равно получается куча формальной писанины, которая нужна только потому, что мне моча в голову ударила работать с ошибками по каким-то правилам.

В C++ же и в Rust это делается _элементарно_. Вместо объявления бесчисленного множества структурок типа my_func_returns, мы можем объявить тип навроде хаскелловского Either (в C++ это std::expected, в Rust -- это std::result::Result) и теперь мы можем не парится обо всех этих объявлениях структур my_func_result:

C++:
expected<int, error_t> my_func(...) {
    ...
    return 42;
}

Rust:
fn my_func -> Result<i32, Error> {
    ...
    Ok(42)
}

В C++, в Haskell, в rust в стандартных библиотеках есть уже готовые типы для комбинации возвращаемого значения и ошибки в возвращаемый тип, но если бы их не было, написать их не представляет никаких проблем. В C такой подход возможен, но непрактичен, без специальных обёрток, поэтому ни в какой стандартной библиотеке его не встретишь, и сам использовать не будешь: проще переключится на C++, и писать на C с классами^W^W с std::expected.

> относительно хорошо _машинно_ оптимизируется

Относительно чего он о хорошо оптимизируется? Все эти UB лезут в C как раз потому, что он плохо оптимизируется. Он хорошо оптимизировался под PDP-11, программист писал на высокоуровневом ассемблере; компиляторы, стремясь к максимальной оптимизации делали только то, что укладывается в принцип наименьшего удивления (least surprise principle). Но по мере изменения аппаратных платформ он стал оптимизироваться хуже, и разрыв между наивными ожиданиями программиста и реальностью всё увеличивается и увеличивается. На полном серьёзе люди ломают копья в спорах о том, должен ли оптимизатор следовать принципу least surprise или принципу максимальной оптимизации.

> позволяет при _достаточной грамотности_

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

rust требует некоторой грамотности, чтобы одолеть borrow checker, но фишка в том, что если грамотности нет, то ты borrow checker не одолеешь. У тебя будет два пути -- либо обрести необходимую квалификацию и забороть borrow checker, либо расчехлить unsafe и обойти borrow checker. Первое хуже наличия грамотности только тем, что требует времени, в течение которого твоя продуктивность будет близка к нулю. Второе же -- палево, потому как детектится элементарным: find . -name '*.rs' -exec grep -H unsafe {} \;

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

114. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от bOOster (ok), 24-Апр-20, 14:15 

> Это работало офигенно, машинный код получался прямо как задумано

Кем задумано?
Мужчинами которые умеют С?

Ответить | Правка | Наверх | Cообщить модератору

120. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 24-Апр-20, 14:41 
> Кем задумано?

Мне кажется, там понятно написано кем, но ежели я ошибаюсь, то скажу прямо и без ложной скромности: мною так было задумано. Как задумывал, так и вышло. Если бы я на асме писал, я бы пожалуй результат в одном регистре возвращал: если ошибка, значит rax содержит код ошибки, если нет ошибки, значит rax содержит результат, а CF флаг в регистре флагов использовал бы для того, чтобы дать возможность отличить ошибку от результата. Так было бы ещё круче:

call my_func
jc handle_error

Но как такую задумку объяснить компилятору -- я не знаю.

Ответить | Правка | Наверх | Cообщить модератору

123. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 24-Апр-20, 15:07 
>[оверквотинг удален]
> Мне кажется, там понятно написано кем, но ежели я ошибаюсь, то скажу
> прямо и без ложной скромности: мною так было задумано. Как задумывал,
> так и вышло. Если бы я на асме писал, я бы
> пожалуй результат в одном регистре возвращал: если ошибка, значит rax содержит
> код ошибки, если нет ошибки, значит rax содержит результат, а CF
> флаг в регистре флагов использовал бы для того, чтобы дать возможность
> отличить ошибку от результата. Так было бы ещё круче:
> call my_func
> jc handle_error
> Но как такую задумку объяснить компилятору -- я не знаю.

Вот это демагогия :))

Компилятору обьяснять не надо, он вообще-то тупой.. А вот когда программист не знает что такое прерывания и как из него сделать exception...
И да... на x86 какой бы он не был - жизни нет

Ответить | Правка | Наверх | Cообщить модератору

125. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 24-Апр-20, 16:29 
> Компилятору обьяснять не надо, он вообще-то тупой..

Мне надо получить результат от компилятора, и значит мне как-то надо высказаться на языке программирования так, чтобы получить именно тот результат, который я хочу. То есть объяснить компилятору. Так что ещё надо посмотреть, кто именно тут тупой.

> А вот когда программист не
> знает что такое прерывания и как из него сделать exception...

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

> И да... на x86 какой бы он не был - жизни нет

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

В случае же с Rust'ом, это возможно, по-крайней мере в теории. enum с двумя вариантами, типа Result'а -- это вещь которая семантически идентична тому, о чём я говорю, осталось лишь научить компилятор передавать недостающий бит информации через флаг.

Ответить | Правка | Наверх | Cообщить модератору

150. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 24-Апр-20, 20:23 
> компилятор нельзя научить использовать регистр флагов для возврата булевских значений

Это банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании легко может убить этот самый регистр флагов. Опять же - упёрлись в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый код чуть сложнее, чем кажется.

Ответить | Правка | Наверх | Cообщить модератору

175. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Ordu (ok), 25-Апр-20, 05:52 
>> компилятор нельзя научить использовать регистр флагов для возврата булевских значений
> Это банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании
> легко может убить этот самый регистр флагов. Опять же - упёрлись
> в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый
> код чуть сложнее, чем кажется.

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

Ответить | Правка | Наверх | Cообщить модератору

182. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 25-Апр-20, 07:12 
Если бы хотя бы 0.01% программистов была нужна эта фича, уже давно подсуетились бы. Но похоже там цифра тех, кому это реально может понадобиться, колеблется ещё на несколько порядков ниже.
Ответить | Правка | Наверх | Cообщить модератору

188. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 07:31 
> Если бы хотя бы 0.01% программистов была нужна эта фича, уже давно
> подсуетились бы. Но похоже там цифра тех, кому это реально может
> понадобиться, колеблется ещё на несколько порядков ниже.

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

В языке в котором есть тип bool, можно было бы сделать, чтобы возвращение bool происходило бы через CF. Но в C нет типа bool, в нём вместо bool используется int, и компилятор не имеет никакой возможности догадаться, что в возвращаемом int'е используется только два значения.

То есть без изменения языка невозможно присобачить возвращения bool'а через CF. А вот чтобы изменять язык, эта фишка должна быть нужна не 0.01% программистов, а хотя бы 10%.

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

Ответить | Правка | Наверх | Cообщить модератору

215. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 26-Апр-20, 08:26 
>>> компилятор нельзя научить использовать регистр флагов для возврата булевских значений
>> Это банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании
>> легко может убить этот самый регистр флагов. Опять же - упёрлись
>> в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый
>> код чуть сложнее, чем кажется.
> Если бы я писал на ассемблере, то я бы легко мог бы
> сохранить CF в нужном мне состоянии. Компилятор, если бы он задался
> целью, тоже мог бы, но проблема в том, что нет такой
> кодовой фразы на C, которая бы перед ним поставила такую цель.

ВОт это брЕЕд...

Давай, чтобы не прослыть треплом - напишика код который флаг переполнения контролирует, особенно для беззнака. :)))))

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

220. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 26-Апр-20, 11:26 
Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и clc. Но бывают и другие способы, которые могут быть удобнее в зависимости от ситуации.
Ответить | Правка | Наверх | Cообщить модератору

221. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 26-Апр-20, 11:55 
> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и
> clc. Но бывают и другие способы, которые могут быть удобнее в
> зависимости от ситуации.

Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться.

Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

223. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 26-Апр-20, 12:48 
>> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и
>> clc. Но бывают и другие способы, которые могут быть удобнее в
>> зависимости от ситуации.
> Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться.

Дитятко, любая из этих мнемоник -- реальный код. Поставь её на отдельной строчке в .asm/.s файле, и она будет реальным кодом. Открой любой учебник по ассемблеру, и ты узнаешь, ассемблер очень простой язык, гораздо проще всех этих ваших rust, C и тому подобных.

Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

228. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 26-Апр-20, 14:38 
>>> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и
>>> clc. Но бывают и другие способы, которые могут быть удобнее в
>>> зависимости от ситуации.
>> Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться.
> Дитятко, любая из этих мнемоник -- реальный код. Поставь её на отдельной
> строчке в .asm/.s файле, и она будет реальным кодом. Открой любой
> учебник по ассемблеру, и ты узнаешь, ассемблер очень простой язык, гораздо
> проще всех этих ваших rust, C и тому подобных.

Ты че идиот? Еще толпа операций неявно меняют флаги переполнения. Хотя в целом понятно, очередной псевдо-программист. Слышал звон, да явно не знает где он. Хотя таких много последнее время. Ни строчки кода не написано, зато гуглом поиском хорошо пользуется.

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

229. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 26-Апр-20, 14:56 
> Ты че идиот?

Нет ты.

> Еще толпа операций неявно меняют флаги переполнения.

99% (или около того) этой "толпы" находятся в группе арифметических операций.

> Ни строчки кода не написано, зато гуглом поиском хорошо пользуется.

Какие строчки кода ты хочешь от меня увидеть? Вот смотри:

stc
ret

Выставили CF вернули управление. CF сохранился выставленным. Подойдёт?

Что-то мне подсказывает что нет, не это тебе интересно. Но мне не понятно, какие именно непреодолимые проблемы ты видишь на пути возврата бита из функции через CF. Поскольку я не понимаю, что именно непонятно тебе, я не могу просветить тебя и научить тебя, как это делать. Если тебе что-то интересно, ты спрашивай, но постарайся в вопросе донести информацию о том, что именно тебе непонятно, иначе совершенно неясно как отвечать на твои вопросы.

Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

233. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 26-Апр-20, 16:06 
Я как бы вас понимаю, убитых и загнобленных x86 архитектурой. Но то что ты написал выше - не живет в природе, что подтверждает что ты теоретик. Перед ret тебе как минимум надо будет pop-ить несколько регистров которые ты использовал в функции а это зачастую может повлиять на флаг переполнения. А чушь которую ты напишешь дальше - что типа ты stc будешь ПРОВЕРЯТЬ и Выставлять сразу перед ret я даже обсуждать не хочу - данных вычислений уже акутальных в регистрах не будет. Там будут pushеные в начале функции значения. Далее, если ты щас вздумаешь сболтнуть что будешь результат таскать и сверять через память для установки cf, то опять таки не стоит выеденного яйца, вытащить результат из стека будет стоить дешевле чет ...рней заниматься с флагами переполнения.
И да, не надо мне щас лапшу вешать что ты настолько крут что с 12 регистрами общего назначения сможешь без стека обойтись - не стоит. Не смеши меня и народ.  
Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

235. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 26-Апр-20, 18:55 
> Перед ret тебе как минимум надо будет pop-ить
> несколько регистров которые ты использовал в функции а это зачастую может
> повлиять на флаг переполнения.

Нет, не может. Содержимое идущее в регистр из стека не меняет флагов. Изменение %rsp командой pop тоже не меняет CF, хотя %rsp при этом и меняется посредством сложения. Единственный способ изменить флаги из стека -- это popf.

А, хотя не, есть ещё iret.

> А чушь которую ты напишешь дальше -
> что типа ты stc будешь ПРОВЕРЯТЬ и Выставлять сразу перед ret
> я даже обсуждать не хочу - данных вычислений уже акутальных в
> регистрах не будет. Там будут pushеные в начале функции значения.

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

   ; бла-бла-бла,
   ; кладём в %rax возвращаемое значение
   add $N, %rsp ; снимаем к чертям локальные переменные со стека
           ; оставляя пока себе локальные значения регистров, которые нам ещё понадобяться
   <тут проверка на ошибку, которая для более показательной сложности не CF выставляет, а ZF>
   pop %<saved-reg> ; восстанавливаем регистры, повторяя это для каждого сохранённого регистра
   jz 1f ; если ошибка приключилась
   clc
   ret
1:
   stc
   ret

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

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

   ; бла-бла-бла
   syscall
   test $0, %rax
   clc
   jns  1f
   neg %rax
   stc
1:
   pop <все те регистры, которые испортил syscall, и которые мы не должны портить>
   ret

Только чтобы конвеер не сбивать в случае, когда всё идёт хорошо, лучше всё от 1: и до ret перенести куда-нибудь выше по коду, дабы переход случался назад. И я вот думаю, что практически наверняка есть какой-нибудь хитрый способ проверить %rax на отрицательность, который заполнит нам CF так как надо, но неохота думать.

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

Эмм... Не хочу тебя огорчать, но у меня всегда было плохо с арифметикой, и ещё в досовские времена я ненавидел работать с переменными на стеке, потому что для этого надо было считать их смещение от того значения sp которое было на входе в функцию. Кроме того, мне кошмарно не нравилось занимать целый регистр адресом стекового фрейма, а если не занимать, то в 16-битном режиме было невозможно было косвенно адресовать память через sp. Поэтому у меня выработалась гнусная привычка писать под _стековую_ машину, ну то есть я жонглирую регистрами, а когда мне их не хватает, я делаю push, потом, когда появляется свободный регистр, извлекаю значение обратно при помощи pop. Такие интересные эффекты случаются, когда случается вписать в цикл несбалансированное количество push/pop -- это просто нечто. Хотя, в досе, как правило это кончалось наглухо висящей машиной.

Дурацкая привычка, я не спорю, единственный бонус -- компактность кода, которая бонусом могла быть разве что в 16-битном досе. Но, как бы там ни было, на amd64 есть _КУЧА_ регистров, и тут гораздо проще обходиться без адресации в глубины стека.

Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

249. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Совершенно другой аноним (?), 27-Апр-20, 16:56 
Имхо, проблема в том, что когда писали компилятор C под x86 (ещё во времена MSDOS, разные там BCC) c calling convention для них выглядел следующим образом:

z = func(2, 1);

push 1
push 2
call func
add sp,4
;значение z располагается в ax

после этого флаг CF уже был потерян. Потом уже придумали разные pascal, fastcall и прочее. Ну и кроме того - это для 86 архитектуры, видимо, был отдельный регистр флагов, который можно анализировать командами условных переходов. Для других архитектур всё могло быть немного иначе.

Кроме того, например, Вы написали (с таким хитрым возвратом, как Вы описали) следующий код:
ret_t ret;

ret = my_func(1, 2, 3, 4);
z = a + b * d / f + 4000;
if (ret.err)
{
}

для того, чтобы флаг CF не потерялся, его придётся где-то записать в стек, или ещё куда, сразу после возврата, чтобы после вычисления выражения вытащить и таки проанализировать.

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

Кстати, то, что Вы предлагаете, по-моему, подавали на включение в стандарт C2X, правда не знаю с каким результатом.

Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

255. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Orduemail (ok), 29-Апр-20, 08:47 
> после этого флаг CF уже был потерян.

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

> для того, чтобы флаг CF не потерялся, его придётся где-то записать в
> стек, или ещё куда, сразу после возврата, чтобы после вычисления выражения
> вытащить и таки проанализировать.

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

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

Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

153. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Forthemail (ok), 24-Апр-20, 20:26 
Исключения и явный возврат ошибок в расте принципиально мало отличаются. Это вопрос реализации.
Представь себе, что добавили конструкцию try catch в rust в виде синтаксического сахара поверх обычного механизма Result.
Чем тут method()?other_method()?yet_another_method()? от
try {
method.other_method.yet_another_method
} catch {
}
Сильно различаются?
Возврат Result это тот же checked_exception в Java, только соус другой.


Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

173. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 05:48 
> Исключения и явный возврат ошибок в расте принципиально мало отличаются. Это вопрос
> реализации.
> Представь себе, что добавили конструкцию try catch в rust в виде синтаксического
> сахара поверх обычного механизма Result.

Не получится. Одна из основных задач Result -- помочь программисту не забыть обработать ошибки: ты не сможешь добраться до значения, которое вернула функция, не распаковав обёртку из Result'а. Кроме того, тип Result'а может меняться по мере последовательных возвратов: ? проверяет Result, и если он Err, то он либо возвращает его как есть, либо если возвращаемый тип ошибки отличается от того, который в наличии, он пытается сделать from -- то есть сгенерить ошибку нужного типа, из той, что прилетела.

try/catch ты можешь не писать, и исключение продолжит разматывать стек. Result ты не можешь не развернуть, если хочешь работать с результатом функции. Чтобы такое было возможно, компилятор должен генерить всякий специальный код, который будет отрабатывать даже тогда, когда всё идёт норм. Я не вдавался в подробности, но, судя по всему, там нужна какая-то специальная огранизация стека. Там возникают всякие интересности, вида обработки вложенных ошибок, когда исключение вылетело в процессе размотки стека из-за другого исключения.

Передача ошибки возвращаемым значением сильно другая, стек разматывается не принудительно, Result -- это не non-local exit. throw -- это погрейженный longjmp, если присмотреться. Result -- это способ прокинуть информацию об ошибке при помощи return.

А насчёт синтаксического сахара, фишка в том, что в rust есть макрос try!, который в использовании похож на try/catch, но этот макрос заменили синтаксическим сахаром оператора ?.

> Чем тут method()?other_method()?yet_another_method()? от
> try {
> method.other_method.yet_another_method
> } catch {
> }
> Сильно различаются?

Если забить на различия в реализациях (на которые на мой взгляд нельзя забивать, они принципиально разные), то тогда отличия только в том, что try/catch многословнее и неудобнее.

В расте же я могу сделать что-то типа:

let ret = method().map_err(|_| "Method failed".to_string())?
    .other_method().map_err(|_| "Other method failed".to_string())?
    .yet_another_method().map_err(|_| "Yet another method failed".to_string())?;

После этого мой код будет выкидывать разные ошибки, в зависимости от того, в каком месте он обломался. В случае же с try/catch ты сможешь понять откуда исключение вылетело только если тебе повезёт, и эти все методы будут выкидывать разные типы исключений.

Помимо этого, Result имеет и другие методы, кроме map_err. Например ok_or_else -- если метод вернул вместо значения ошибку, я могу вызвать другой метод, который вернёт хоть какое-нибудь значение. try/catch можно использовать таким образом, но тебе придётся каждый вызов заворачивать в отдельный try/catch. Это можно, но сильно многословно.

Ответить | Правка | Наверх | Cообщить модератору

181. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 25-Апр-20, 07:11 
map_err(|_| ...)?;
Глаза снова вытекли.
Ответить | Правка | Наверх | Cообщить модератору

187. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 07:22 
> map_err(|_| ...)?;
> Глаза снова вытекли.

У тебя все глаза сразу вытекают? Или как так выходит, что они вытекают, вытекают, и всё равно что-то остаётся?

Ответить | Правка | Наверх | Cообщить модератору

191. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 25-Апр-20, 08:45 
Я стараюсь не кормить глаза говносинтаксисом регулярно, поэтому они вытекают редко, только вот в таких вот дискуссиях.
Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

189. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 07:54 
> map_err(|_| ...)?;
> Глаза снова вытекли.

Кстати, а ты не напомнишь, как в C делаются лямбды? То есть, в C такого нет понятно -- ни в K&R, ни даже в c99 -- но в gcc есть возможность как-то сделать, я точно помню, что возможность была, я просто не помню как это надо было делать. Что-то типа такого:

map_err((return_type_t)(*)(input_type_t val) { return "Method failed" })

Или там какое-то ключевое слово нужно вставить куда-то, типа __function__? Или может надо ещё одну пару скобочек добавить вокруг аргумента map_err, чтобы парсер C не запутался бы?

А, точно, скобочки, только фигурные:

map_err({return_type_t fn(input_type_t val) { return "Method failed" } fn})

Что-то типа этого ведь, так? А если мы ещё хотим гарантированно не получать варнингов о неиспользуемом val, то к нему какой-нибудь атрибут надо приделать, типа:

map_err({return_type_t fn(input_type_t val __gcc_attribute__((unused))) { return "Method failed" } fn})

Многословно, зато глаза не вытекают, да.

Ответить | Правка | Наверх | Cообщить модератору

192. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 25-Апр-20, 08:46 
Многословно, да, но всё равно несколько более упорядоченно.
Осталось только придумать, на хрена вообще такая конструкция.
Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

195. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Forthemail (ok), 25-Апр-20, 11:34 
> try/catch ты можешь не писать, и исключение продолжит разматывать стек.

Как будто From для Result это бесплатно, открываешь машинный код и видно, что теперь везде есть ветки проверки результата на Ok и если не Ok, то вызов From, а затем return с результатом преобразования. Чем это тебе не разматывание стека? :) Точно также получается кучка преоборазований поэтапно с возвратом в каждую функцию выше и дропом всего, что надо дропнуть.
С исключениями теоретически и на практике это может быть не нужно, например если в Java ты бросаешь исключение без заполнения stack trace, а это легко сделать, то фактически будет выполнен переход сразу на тот try catch какой надо. Весь стек ниже будет просто выброшен без пустопорожних преобразований как в Result и From.
> Одна из основных задач Result -- помочь программисту не забыть обработать ошибки:

Я исключения из Java в пример привожу, там есть checked exception.
Если это checked exception, ты просто обязан сделать одно из двух, либо поставить try catch, либо указать, что ты его пробрасываешь выше в throws метода.
Это от Result становится неотличимо по поведению, только синтаксически.
Хорошо, пусть у тебя будет:
let ret = method().map_err(|_| "Method failed".to_string())?
А если тебе надо обработать ошибку, то будет уже иное:
if let Err(e) = method() {
} else {
}
Может быть match менее многословно?
match mathod() {
    Ok(_) => {}
    Err(_) => {}
}
Да по мне таже фигня.

Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

198. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 13:34 
>> try/catch ты можешь не писать, и исключение продолжит разматывать стек.
> Как будто From для Result это бесплатно, открываешь машинный код и видно,
> что теперь везде есть ветки проверки результата на Ok и если
> не Ok, то вызов From, а затем return с результатом преобразования.
> Чем это тебе не разматывание стека? :) Точно также получается кучка
> преоборазований поэтапно с возвратом в каждую функцию выше и дропом всего,
> что надо дропнуть.

В rust'е обработка Result'ов проверяется на этапе компиляции компилятором.
> С исключениями теоретически и на практике это может быть не нужно, например
> если в Java ты бросаешь исключение без заполнения stack trace, а
> это легко сделать, то фактически будет выполнен переход сразу на тот
> try catch какой надо. Весь стек ниже будет просто выброшен без
> пустопорожних преобразований как в Result и From.

А это как раз неудобно. Вот смотри, тебе вылетела ошибка FileNotFound. Ты поймал её в main. И чё?

Твой код, парсящий toml/json/что-то ещё из файла, может не знать, как надо правильно реагировать на FileNotFound. Где-то чуть выше по стеку всё равно не ясно, но зато семантика ошибки другая, скажем ConfigFileDoesntExist. А ещё несколькими стековыми фреймами выше всё очень просто -- надо не читать Config из файла, а создать дефолтный.

Если ты присмотришься к ошибке разматывающей стек и примеришь её к каждому стековому фрейму, ты увидишь что смысл ошибки меняется по мере размотки. И Result позволяет это отметить в ошибке с минимум накладных расходов. Даже From писать не обязательно, всегда можно сделать map_err. Вот когда map_err получаются большими -- там хорошо вынести их логику в impl From.

>[оверквотинг удален]
> А если тебе надо обработать ошибку, то будет уже иное:
> if let Err(e) = method() {
> } else {
> }
> Может быть match менее многословно?
> match mathod() {
>     Ok(_) => {}
>     Err(_) => {}
> }
> Да по мне таже фигня.

Я согласен, что checked exception в java по семантике то же самое, что и Result. Различия только в синтаксисе и в деталях реализации.

А насчёт многословности, if let, и match редко нужны для Result'а, как правило оно разруливается иными путями. То есть нужно иногда, и очень полезно в тех случаях, но это редко случается. if let и match описываются в туториалах, потому что это способы общего назначения. Как и что будет сделано в частном случае -- сложно описать или даже перечислить подходы. Это уже от тебя зависит: тебе следует почитать доку на Result и посмотреть что он позволяет сделать с ошибкой.

Например, обработка ошибки может выглядеть так:

let config = read_config_file().unwrap_or(Config::default());

Или если ты сделал

impl Default for Config { ... }

то можно так:

let config = read_config_file().unwrap_or_default();

Ответить | Правка | Наверх | Cообщить модератору

148. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 24-Апр-20, 20:20 
> в C нет пристойного механизма обработки ошибок

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

> невозможно без специальных обёрток, которые привнесут в C программирование с generic типами как в C++

Это ты сам себе придумал, что я только про чистый C? Нет, я про синтаксис, и только про синтаксис. C, C++, C#, Java и т.п. Прелесть в том, что базовый синтаксис вполне расширяем, и не нужно изобретать велосипеды.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

190. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 08:27 
>> в C нет пристойного механизма обработки ошибок
> В тебе говорит тот самый юзер, которого я описывал. Что такое ошибка
> вообще? Это код возврата из процедуры, обычно. Ну вот от этого
> и пляши. Можно ещё взять плюсы и играться эксепшнами, которые немножко
> задачу облегчают, и при этом логике не противоречат. И синтаксис не
> ломают.

Эксепшны ломают логику: это нелокальный выход, a la longjmp. Синтаксис у них получше, чем в моём C'шном варианте -- это бесспорно. Но тоже не фонтан, если честно. В C++ есть expected, вот он делает именно то, что я выше написал на C, но в гораздо более приятном синтаксисе.

>> невозможно без специальных обёрток, которые привнесут в C программирование с generic типами как в C++
> Это ты сам себе придумал, что я только про чистый C? Нет,
> я про синтаксис, и только про синтаксис. C, C++, C#, Java
> и т.п. Прелесть в том, что базовый синтаксис вполне расширяем, и
> не нужно изобретать велосипеды.

Расширяем, угу. Особенно это видно в C++, чем заканчиваются расширения. Но даже в C, вещи типа:

int (*arr[8])(int)

Оччень расширяемо. Да. Спиралевидно.

Я -- увы -- не могу найти статью, где раскрывалось уродство и неоднозначность этого синтаксиса. Но зато я нашёл статью[1], объясняющую как не напарываться на неоднозначность. Не столь показательно, но всё равно даёт представление о проблеме.

[1] https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL53-...

Ответить | Правка | Наверх | Cообщить модератору

149. "Выпуск языка программирования Rust 1.43"  –2 +/
Сообщение от Онаним (?), 24-Апр-20, 20:20 
> fn my_func -> Result<i32, Error>

Глаза вытекают уже на ->

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

168. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Anonymqwe (?), 25-Апр-20, 01:40 
Вы объявление лямбда-функции никогда не видели?
Ответить | Правка | Наверх | Cообщить модератору

176. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 05:59 
>> fn my_func -> Result<i32, Error>
> Глаза вытекают уже на ->

Я лишь могу выразить соболезнования. Если твое глаза вытекают от этого диграфа, то значит ты никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательными для освоения. Очень образовательными.

И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа. А почему именно этого? От += не вытекают? А от триграфов типа <<= не вытекают?

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

177. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 25-Апр-20, 07:05 
> никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательными

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

Ответить | Правка | Наверх | Cообщить модератору

185. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Ordu (ok), 25-Апр-20, 07:21 
>> никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательными
> Я оперирую критерием полезности, а не увлекательности. При этом гораздо увлекательнее,
> когда ты имеешь на руках нужный тебе практический результат на нормальных
> языках, а не десяток "освоенных" ненужных языколяпов в теории. Это как
> совковый кругозор - вроде и знают много, а толку нет.

Ты программируешь только потому, что тебе платят деньги? Или может ещё и потому, что это увлекательно?

Ответить | Правка | Наверх | Cообщить модератору

178. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 25-Апр-20, 07:07 
> И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа.

Я сказал "уже", если ты не понял. Остальное там ещё хуже.

> А почему именно этого? От += не вытекают? А от триграфов типа <<= не вытекают?

+= и <<= легко бьётся на две операции: + = и << =, которые имеют смысл.
Но суть не в этом. Глаза вытекают не от символов, а от самого построения.

Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

186. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 25-Апр-20, 07:21 
>> И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа.
> Я сказал "уже", если ты не понял. Остальное там ещё хуже.

Это "уже" очень показательно, если ты не понял. Остальное можно не слушать, после этого.

Ответить | Правка | Наверх | Cообщить модератору

88. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Anonymqwe (?), 24-Апр-20, 11:57 
Машинно оптимизируется он, потому что 30 лет процессоры под него проектируют, в ущерб теоретической производительности и чистоте дизайна

Я не найду сейчас ссылки, где эта тема раскрывается.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

98. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (96), 24-Апр-20, 12:50 
Конечно не найдешь, потому что это полная чушь.
Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Ordu (ok), 24-Апр-20, 14:43 
https://queue.acm.org/detail.cfm?id=3212479
Ответить | Правка | Наверх | Cообщить модератору

130. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Anonymqwe (?), 24-Апр-20, 16:43 
Спасибо, кажется, именно эту статью я имел в виду
Ответить | Правка | Наверх | Cообщить модератору

126. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Аноним84701 (ok), 24-Апр-20, 16:29 
> C-подобный синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется,

Т.е. дать ссылочку на такой "хорошо оптимизирующий машинно" и минимальный (а не на миллионы строк) компилятор С вас не затруднит?

> и позволяет при _достаточной грамотности_ творить достаточно чУдные вещи, обходя оптимизатор

Правда, в осносновном в прохладных былинах и других, более лучших чем наша, реальностях лапшеразвеши^W комментаторов опеннета :(
Потому что в моем варианте реальности, к сожалению, "недостаточно грамотные" неосиляторы из разработчиков ядра, (g)libc, (де)кодировщиков видео, BLAS и т.д, вместо "обхода оптимизатора" средствами "прекраснейшего и эффектнейшего синтаксиса" -- напихали ламерских интринсиков/ассемблерных вставок :(

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

151. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 24-Апр-20, 20:24 
> "хорошо оптимизирующий машинно" и минимальный

Это ваши личные половые требования. Мне достаточно первого пункта.

Ответить | Правка | Наверх | Cообщить модератору

155. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним84701 (ok), 24-Апр-20, 21:02 
>>> относительно хорошо _машинно_ оптимизируется
>> "хорошо оптимизирующий машинно" и минимальный
> Это ваши личные половые требования. Мне достаточно первого пункта.

Что, не все верят анонимным опеннетным комментаторам на слово? Некоторые  еще и каких-то пруфов требуют? Совсем оборзели, да! 🙄

Ответить | Правка | Наверх | Cообщить модератору

161. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 24-Апр-20, 22:38 
Так ты про пруфы или про одновременно "хорошо и минимального размера", болезный?
Ответить | Правка | Наверх | Cообщить модератору

167. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним84701 (ok), 25-Апр-20, 00:06 
> Так ты про пруфы или про одновременно "хорошо и минимального размера",

Т.е. ты сам не понял, что написал? Если "синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется,", то где же "хорошо и минимального размера"? Синтаксис-то, если верить анониму, позволяет.
Или можешь дать ссылку на  код "_достаточной грамотности_" посложнее хеловрота, который без интирсиков и ассемблерных вставок будет в сборке с O0 быстрее работать чем c О2 (т.е. "обходить оптимизатор")?
Ну или можешь еще что-то придумать -- это ведь ты сделал весьма смелые заявления и  соотв. "бремя доказательства" на тебе.

>  личные половые требования
> болезный?

Вах, какие аргументативные аргументы!

Ответить | Правка | Наверх | Cообщить модератору

179. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 25-Апр-20, 07:08 
Тут не аргументы, тут как раз факты.

Ответить | Правка | Наверх | Cообщить модератору

222. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним84701 (ok), 26-Апр-20, 12:23 
> Тут не аргументы, тут как раз факты.

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

Ответить | Правка | Наверх | Cообщить модератору

138. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Вебмакака (?), 24-Апр-20, 17:53 
Синтаксис С это шляпа полная. Достаточно вспомнить, что до clang'а нормально анализировать даже сорцы на чистом С было нечем, даже надёжной подсветки в IDE не было.

>относительно хорошо _машинно_ оптимизируется

Далол, постоянно проверять ассемблер, процесс оптимизации от бога.

Аппаратные возможности процов затащили в стандарт всего-то через 10 лет после того, как они стали нужны. Лучший системный язык эвар.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

152. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 24-Апр-20, 20:24 
> до clang'а нормально анализировать даже сорцы на чистом С было нечем, даже надёжной подсветки в
> IDE не было

Поржал, пошёл дальше. Спасибо.

Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Додо (?), 24-Апр-20, 09:55 
У Ruby синтаксис близок к разговорному английскому, и на нем вполне пишут.
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

65. "Выпуск языка программирования Rust 1.43"  +5 +/
Сообщение от Аноним (46), 24-Апр-20, 10:02 
угу. И главное как пишут! Поубивал бы некоторых
Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (96), 24-Апр-20, 12:51 
Некоторых ?
Ответить | Правка | Наверх | Cообщить модератору

154. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (46), 24-Апр-20, 20:43 
ну, тех, которых не удается убедить больше не писать на руби
Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (71), 24-Апр-20, 10:18 
Ты перепутал с перлом.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

76. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (74), 24-Апр-20, 10:22 
Похоже синтаксис близкий к разговорному причина отказа от использования языков программирования. Под каток уже попали кобол, руби, перл.
Ответить | Правка | Наверх | Cообщить модератору

129. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от anonimous (?), 24-Апр-20, 16:40 
>Похоже синтаксис близкий к разговорному причина отказа от использования языков программирования.

Угу, например все уже отказываются от

SELECT * FROM Planets WHERE Radius BETWEEN 3000 AND 9000

Ответить | Правка | Наверх | Cообщить модератору

163. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от anonymous (??), 24-Апр-20, 23:09 
Это всё же язык запросов, а не язык программирования.
Ответить | Правка | Наверх | Cообщить модератору

164. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от anonymous (??), 24-Апр-20, 23:17 
Уже не все так просто. А LINQ?

IEnumerable<int> scoreQuery = from score in scores where score > 80 select score;

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (79), 24-Апр-20, 10:52 
А на Перле сейчас вполне пишут?
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

75. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (74), 24-Апр-20, 10:20 
На руби тоже давно ничего не пишут, только поддерживают старые велосипеды.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

209. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от burjui (ok), 26-Апр-20, 03:04 
Пока что визжат и занимаются словесным унижением, как раз-таки, его противники, что наглядно видно по засилью соответствующих комментариев под новостями о Rust, включая ваш. А мы молча пишем код, пока на нас не набрасывается стая визжащих макак, кидающая фекалии в синтаксис.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

216. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 26-Апр-20, 10:48 
Смысл? Я спокойненько пишу на C, C++, PHP, без проблем правлю баги в софте на Java и ECMA, благо они все похожи. Разбираться с чем-то альтернативным смысла нет.
Ответить | Правка | Наверх | Cообщить модератору

225. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от burjui (ok), 26-Апр-20, 13:18 
Ну пиши, никто тебе не мешает. Но нет, пришёл в новость о Rust и написал over 9000 комментов про то, как у тебя глаза вытекают. Ну так не смотри! Иди и дальше любуйся на прекрасный C++ и нюхай неземной аромат PHP.
Ответить | Правка | Наверх | Cообщить модератору

236. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 26-Апр-20, 19:03 
Если так не нравятся коментарии - графоманией можно заниматься в ящик ближайшего стола, а не в сеть.
Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 24-Апр-20, 11:47 
Очередной шажок превратить дорогих программистов  в ремесленников?
Ответить | Правка | Наверх | Cообщить модератору

86. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от фррр (?), 24-Апр-20, 11:55 
Если люди с питона, руби и прочей тормозной скриптухи перейдут на раст, то это будет хорошо.
Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Аноним (7), 24-Апр-20, 12:02 
Эй, вам надо пачитать книжка! Rust и питон и руби - языки разных областей применения! Не пересекающихся почти полностью.
Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от фррр (?), 24-Апр-20, 12:30 
Это в теории, а на практике тормозную скриптуху пихают везде.
Ответить | Правка | Наверх | Cообщить модератору

95. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от A.Stahl (ok), 24-Апр-20, 12:42 
> Это в теории, а на практике тормозную скриптуху пихают везде.

А ведь что мешает сделать интерпретатор Си(с классами) с тем чтобы приучать питонистов и прочих к нормальному языку?


Ответить | Правка | Наверх | Cообщить модератору

101. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (7), 24-Апр-20, 12:59 
Я в детстве дотнетнировал, как аноним со стыдом в признаюсь сием постыдном грехе (но всегда после мыл руки!) Вот думаю если анонимусу хочется как интерпретатор С (с классами) он тоже может подотнетнировать (после мойте руки, клавиатуру, соблюдайте гигиену!)

И таки да, без шуток, питон - НОРМАЛЬНЫЙ язык. Аноним использовал в работе за эти десятилетия C, С++ (98, 11), C#, Java, Python, Ruby, Dart, LSL (моя любовь), Bash, QuakeC и даже Perl.

Просто для каждой задачи нужен свой инструмент.
Учите матчасть.

Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (105), 24-Апр-20, 13:13 
Питон хорош только тем, что для него наплодили библиотек почти для всех случаев жизни.
Ответить | Правка | Наверх | Cообщить модератору

115. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 24-Апр-20, 14:18 
> Питон хорош только тем, что для него наплодили библиотек почти для всех
> случаев жизни.

Именно библиотеки и есть ремесло...

Ответить | Правка | Наверх | Cообщить модератору

166. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от anonymous (??), 24-Апр-20, 23:53 
Библиотеки то, в основном, не питоне. Их из него только вызывают.
Да и переносят когда надо без проблем, вот например с питона на джулию инструмент машинлёнеров уже перенесли
https://github.com/cstjean/ScikitLearn.jl
Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

109. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (7), 24-Апр-20, 13:49 
Я же больше не дотнетнирую! зачем минус то поставили!)
Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

111. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от коржик (?), 24-Апр-20, 13:58 
я дотнетирую, мне обидно
Ответить | Правка | Наверх | Cообщить модератору

116. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 24-Апр-20, 14:22 
> Я же больше не дотнетнирую! зачем минус то поставили!)

Взгляд бросил прочитал - детонирует ) MS43 от Siemens очень умеет это обходить.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

102. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (105), 24-Апр-20, 13:05 
Уже https://root.cern.ch/cling
Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

113. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 24-Апр-20, 14:09 
>> Это в теории, а на практике тормозную скриптуху пихают везде.
> А ведь что мешает сделать интерпретатор Си(с классами) с тем чтобы приучать
> питонистов и прочих к нормальному языку?

Этож Бейсик? НЕ?

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

97. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (7), 24-Апр-20, 12:46 
Потому что rust - язык без сборщика мусора, якобы предназначен для низкоуровневых вещей - к примеру драйвера (в теории), какие то еще приложения где требуется real-time код, компактность и быстродействие. Так что на практике люди используют "презренные" пехи и руби там где надо. Вы пишете драйвера на питоне? На чем вы будете делать макет алгоритма? на расте?
Просто та область применения для которой раст разработали уже давно занята, оттого фанаты языка такие назойливые.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

124. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от menstenebris (?), 24-Апр-20, 16:00 
Автовыведение типов и синтаксический сахар позволяют на rust писать почти так же компактно как на python. При этом предоставляет более низкий порог вхождения чем с++. Я пробовал писать и системные демоны и веб апи, и даже встраивать в python. При должных навыках код получается быстрый и компактный, не такой читаемый как python, но более читаемый чем с++. У rust сейчас одна проблема это сложность создания библиотек и от того их количество.
Ответить | Правка | Наверх | Cообщить модератору

184. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Онаним (?), 25-Апр-20, 07:16 
Ты уж меня извини, но с его синтаксисом там скорее не сахар, а смесь перцев с говном.
Ответить | Правка | Наверх | Cообщить модератору

204. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (202), 26-Апр-20, 00:40 
Нормальный там синтаксис.
Достаточно немного его попытаться изучить чтоб понять логичность каждой чёрточки. И насколько сложно сделать иначе без потерь.
Ответить | Правка | Наверх | Cообщить модератору

210. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (7), 26-Апр-20, 03:12 
Вот в этом то и главный косяк этого языка, слишком много телодвижений даже для тривиальных задач.
Конечно в языке все его черточки логичны, суть в том что их слишком много :)
А растовский сахар он такой, вредный, диабет можно заработать.
Ответить | Правка | Наверх | Cообщить модератору

211. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (202), 26-Апр-20, 05:57 
Попытаться немного изучить = лишние телодвижения?)
Если сравнивать синтаксис Раста и Плюсов
Ответить | Правка | Наверх | Cообщить модератору

212. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (202), 26-Апр-20, 06:06 
миссклик. так вот

> Если сравнивать синтаксис Раста и Плюсов

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

А кроме плюсов у него по сути нет конкурентов. И то, плюсы скорее из-за популярности вытягивают, при этом до сих пор не имя имея дефолт пакетного менеджера и системы сборки (не cmake единым), что позорно для языка такого уровня.

Ответить | Правка | Наверх | Cообщить модератору

224. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от menstenebris (?), 26-Апр-20, 13:05 
По началу мне тоже так казалось. Много лишнего кода ради проверки всех возможных состояний, но это только от незнания, когда изучил чуть лучше оказалось что для всего уже написан специальный сахар после применения которого код сжался в два раза, примерно до 130% от кода на python. Зато действительно не было такого чтобы собранный код упал на проде. Как написал так он без изменений уже 6 месяцев работает 24/7.
Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

217. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 26-Апр-20, 10:49 
Настолько нормальный, что доля условного "рынка" годами держится в районе 0, а в писателях в основном школота, которой ещё без разницы, что осваивать, и которая потом всё равно перейдёт на что-то более вменяемое.
Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

131. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (131), 24-Апр-20, 16:47 
Не якобы и не в теории, а на практике: https://www.opennet.ru/opennews/art.shtml?num=51475
Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

136. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (136), 24-Апр-20, 17:12 
Это какая-то синтетика. Школьники драйвера не пишут и поэтому раст для драйверов не используют.
Ответить | Правка | Наверх | Cообщить модератору

205. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (202), 26-Апр-20, 00:42 
При чем тут школьники?
Ответить | Правка | Наверх | Cообщить модератору

180. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Онаним (?), 25-Апр-20, 07:09 
> где требуется real-time код, компактность и быстродействие

Тут определённо "не" пропущено :)

Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

268. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от коржик (?), 30-Апр-20, 19:19 
> Просто та область применения для которой раст разработали уже давно занята, оттого
> фанаты языка такие назойливые.

Вот же сволочи назойливые! Уже и новость про новую версию раста комментируют!

Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

203. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (202), 26-Апр-20, 00:37 
Все они пересекаются в вебе и скриптах, и раст это делает быстрее.
Была история одного мейнтейнера реп руби. Снижение времени парсинга логов с 16 часов до нескольких минут :)
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

118. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от bOOster (ok), 24-Апр-20, 14:30 
> Если люди с питона, руби и прочей тормозной скриптухи перейдут на раст,
> то это будет хорошо.

А эти люди знают что такое бинарный поиск?

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

108. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Аноним (7), 24-Апр-20, 13:46 
Дорогие программисты превращаются в дешевых не с помощью инструментов вроде раста - это же просто язык, кстати довольно сложный. А с усовершествованием методов сверхэксплуатации в ИТ индустрии (гибкие методики к примеру), методы тейлоризма при эксплуатации, создание резервной рабочей армии, выносом заказов в другие страны с дешевым трудом.
Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

206. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (202), 26-Апр-20, 00:46 
Цена программиста не зависит от сложности языка
А вот писать легче, чем на UB и UB++, им будет удобнее.
Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

133. "Выпуск языка программирования Rust 1.43"  –1 +/
Сообщение от Аноним (133), 24-Апр-20, 16:59 
Из википедии:

> Rust (язык программирования)
> Объектно-ориентированное программирование как таковое языком не поддерживается

Отсюда вопрос: как на этом г-не программировать графический интерфейс (GUI)?

Ответить | Правка | Наверх | Cообщить модератору

135. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Аноним (136), 24-Апр-20, 17:08 
Для начало покажи хотябы одну графическую тулзу на раст. У если найдешь в ее коде и посмотри)
Ответить | Правка | Наверх | Cообщить модератору

137. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Анонимм (??), 24-Апр-20, 17:41 
Во-первых, чёткого определения ООП до сих пор нет. Во-вторых, https://github.com/redox-os/orbtk
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

139. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (127), 24-Апр-20, 18:04 
А по вашему ГУИ без ООП невозможен? На Си нельзя писать с ГУИ?
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

143. "Выпуск языка программирования Rust 1.43"  +2 +/
Сообщение от Аноним (3), 24-Апр-20, 18:47 
В си есть ООП. Ядро полно ООП, гтк полон ООП.
При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция.
Ответить | Правка | Наверх | Cообщить модератору

213. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Ordu (ok), 26-Апр-20, 06:32 
> В си есть ООП.

Если мы используем такое определение для "есть ООП", которое позволяет сказать, что в C есть ООП, то тогда нам придётся признать, что в Rust'е тоже есть ООП. Rust не хуже C позволяет жонглировать указателями на функции, и создать вручную vtable там не проблема нисколько.

> При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция.

Это вопрос к анониму выше, он почему-то считает, что без ООП невозможно программировать гуй.

Ответить | Правка | Наверх | Cообщить модератору

219. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 26-Апр-20, 11:05 
> В си есть ООП. Ядро полно ООП, гтк полон ООП.
> При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция.

Там где надо ООП, люди берут плюсы, и не мучаются :)
Или дотнетик.

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

145. "Выпуск языка программирования Rust 1.43"  +4 +/
Сообщение от коржик (?), 24-Апр-20, 20:09 
Сложно. И не из-за того что нет ооп, а вследствие ограничений на уникальное владение ссылками.

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

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

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

И получается что тот же GTK (https://gtk-rs.org/) как бы есть, но программировать на нём без крепких как сталь нервов вы не сможете. Выход - событийная модель и ELM подобные фреймворки, вот например https://github.com/antoyo/relm , библиотека поверх GTK. Или вот https://github.com/hecrj/iced

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

194. "Выпуск языка программирования Rust 1.43"  +1 +/
Сообщение от Forthemail (ok), 25-Апр-20, 11:12 
Если бы только в UI вызывало проблемы.
Любое модульное приложение, где модули ничего друг о друге не знают кроме публичных интерфейсов лего наваять в Java например. Легко написать тесты как модульные так и интеграционные.
На расте это превращается в жесть с дженериками, иначе тесты хрен напишешь.
Можно конечно передавать всё как dyn Trait, но тогда начинается веселье с borrow checker который уже не может отследить, на что ссылка из структуры заимствуется.

P.S. Самое удивительное, что разработка все равно получается продуктивная, хотя повозится приходится.

Ответить | Правка | Наверх | Cообщить модератору

193. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Аноним (193), 25-Апр-20, 10:46 
А это бред. ООП в Расте есть. Просто весь полиморфизм реализован через интерфейсы, а не через наследование.

https://doc.rust-lang.org/book/ch17-00-oop.html

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

218. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от Онаним (?), 26-Апр-20, 10:51 
> весь полиморфизм реализован через интерфейсы, а не через наследование.

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

Ответить | Правка | Наверх | Cообщить модератору

254. "Выпуск языка программирования Rust 1.43"  +/
Сообщение от zo0Memail (ok), 28-Апр-20, 17:22 
Все нравится, нормальный релиз!
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру