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

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

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аномномномнимус (?), 23-Апр-20, 23:37	+/–
Там уже есть goto и макросы? Надо срочно обмазаться
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #34, #45, #72

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

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

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

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

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

7. Сообщение от Аноним (7), 24-Апр-20, 01:50	–4 +/–
Может свидетели ржавчины и на ночные сборки будут новости размещать? А то навязчивого спама не хватает) Ну и заголовки оживите, наподобие - Не ходите к врачам! Достаточно одной совецкой батарейки и двух шурупов.. Ну не мне вас учить сами знаете :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35, #70, #87, #89

8. Сообщение от Аноним (8), 24-Апр-20, 02:10	+/–
чем оно лучше чем Go?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #10, #17, #18, #30

9. Сообщение от leap42 (ok), 24-Апр-20, 02:29	+/–
> чем оно лучше чем Go? машинный код в 2 раза быстрее (в среднем), насколько я могу судить нелья разыменовать nil указатели (в Go, к сожалению это сплошь и рядом), гораздо больше языковых средств (если для вас это плюс)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #106, #162

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

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

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

13. Сообщение от OpenEcho (?), 24-Апр-20, 02:39	+16 +/–
>Возможность работы с указателями это плюс для настоящего программиста, для баклана - да, желательно вообще писать на php Без обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе... Машины не виноваты, что на них ездят дебилы, так же и с языками... Чем проще машины, тем больше охламонов на них ездят, так уж мир устроен (к сожалению)... Забивать гвозди микроскопом(поинтерами) конечно можно, но лучше все таки использоть инструменты по назначению и пых на своем месте не спроста уже десятилетия... Если ты узанал, что такое поинтеры, это далеко не значит, что ты хороший програмист... Как правило, люди пренебрегающие другие языки - самые страшные багописатели !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #27, #61

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

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

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

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

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

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

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

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

22. Сообщение от Андрей (??), 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ообщить модератору
Родитель: #18 Ответы: #28

23. Сообщение от наблюдающий_изда_лк (?), 24-Апр-20, 04:52	+3 +/–
Был уже тут один монарх, пяткой себя в грудь бил, все говорил о реализации блога на C++. То ли за 21 день собирался он это сделать, то ли за неделю. Но уже скоро год пройдет, а блога как небыло, так и нет. Мораль: выбирай инструмент под задачу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #46, #103, #160

24. Сообщение от Аноним (24), 24-Апр-20, 05:13	+13 +/–
Я этот комментарий вижу под каждой статьей про новую версию Rust (с вариациями в "остротах", но с тем же смыслом и к той же цитате). И каждый раз он собирает плюсы. И ведь никто не потрудится минуту поискать информацию и открыть для себя, что указатель - настолько же фундаментальная абстракция для Rust, как и для C. Многое говорит о местной аудитории. Разница с C лишь в том, что по умолчанию в Rust применяется особый тип указателя (ссылка), который также содержит в себе информацию о времени жизни памяти, на которую он ссылается (для нетривиальных случаев есть unsafe и обычные сырые указатели). Но для анонимуса это слишком сложно, можно же просто хейтить и ни во что не вдуплять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #67

25. Сообщение от Аноним (24), 24-Апр-20, 05:30	+1 +/–
> пока прямыми конкурентами являются такие языки как Malbolge, Brainfuck и пока с далеким отрывом  Var’aq )) Вы забыли в добавить пояснения: "мне кажется", "на мой вкус", "по моему неосведомленному мнению", "мне друг так сказал" и так далее. А то прочитает ваш комментарий наивный человек и подумает, что вы знаете, о чем пишете. Не вводите людей в заблуждение ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #80

27. Сообщение от Аноним (27), 24-Апр-20, 05:47	+/–
>Без обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе... Это не так. Хаят язык, когда он чем-то не устраивает. Или ты сторонник политкоррктности в отношении языков программирования? Типа "это язык несомненно альтернативно-нужный"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #55, #158

28. Сообщение от Анонимный Кактус (?), 24-Апр-20, 06:41	–1 +/–
> В Go-версии импортируются только системные библиотеки. В Rust-версии какие-то левые Потому что в Rust есть нормальный менеджер пакетов, а в Go нет? > n-body ... там SIMD на SIMDе и SIMD'ом поганяет. Хоршенько приправлено unsafe. И вообще похоже на макро-ассемблер Там несколько решений, первое хоть и не бьёт сишечку, но выглядит чисто и все ещё в два раза быстрее го https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #66

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

30. Сообщение от Аноним (31), 24-Апр-20, 06:49	+/–
>чем оно лучше чем Go? Порогом вхождения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

31. Сообщение от Аноним (31), 24-Апр-20, 06:51	+1 +/–
>Создатели языка не считают тебя идиотом. А с чего ты взял, что создатели Go считают?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #47

32. Сообщение от A.Stahl (ok), 24-Апр-20, 07:04	+/–
Попадалась мне в руки как-то довольно забавная книжка, так там автор на базе какого-то примера предложил отказаться от кучи операторов. Мол, а представьте что нет у нас while. И вообще никаких циклов нет. И того нет. И этого нет. Не серьёзно, конечно, предложил. Не помню уж как называлась. Что-то старое из конца 80х - начала 90х. 128 советов чего-то там.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #39, #60, #68, #91, #247

33. Сообщение от nonamenogame (?), 24-Апр-20, 07:30	+/–
https://www.phoronix.com/scan.php?page=news_item&px=Redox-OS...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #78

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

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

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

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

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

39. Сообщение от Аноним (39), 24-Апр-20, 08:22	+3 +/–
Николас Вирт всегда ратовал за простоту языка (все описание языка должно помещался на одной странице и быть понятным домохозяйке), контроль компилятора за памятью. Также Николас говорил, что язык программирования, компилятор, ядро ОС и процессор должен разрабатывать одна команда. Только в этом случае можно достичь простоты и совершенства. Пример A2 https://en.m.wikipedia.org/wiki/Bluebottle_OS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #96, #119

40. Сообщение от Аноним (42), 24-Апр-20, 08:37	+2 +/–
unsafe избавители ничем не лучше твоей любимой сишки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #44

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

42. Сообщение от Аноним (42), 24-Апр-20, 08:39	+2 +/–
У тебя какие-то проблемы с дырами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #53

43. Сообщение от фррр (?), 24-Апр-20, 08:45	+/–
Приведи пример такого кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #49

44. Сообщение от фррр (?), 24-Апр-20, 08:46	+/–
Лучше. 5% unsafe лучше, чем 100% сишного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #50, #51

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

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

47. Сообщение от Аноним (47), 24-Апр-20, 08:48	+3 +/–
"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ообщить модератору
Родитель: #31 Ответы: #58

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

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

50. Сообщение от Аноним (46), 24-Апр-20, 08:59	–1 +/–
хорошая мантра. Наверно позволяет не задумываться об этих 5%? Ну типа: 5 не 100, все равно я уделал сишников! В 5% кода можно наделать столько же ошибок, как и в 100%
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #84

51. Сообщение от Аноним (42), 24-Апр-20, 09:00	+/–
Никакой связи. Ложка дегтя в бочке меда портит всю бочку меда. Эскобар.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #59

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

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

54. Сообщение от Онаним (?), 24-Апр-20, 09:10	+/–
> У кобола синтаксис близок к разговорному английскому и почему на нем ничего > не пишут сейчас? Не модно. "синтаксис близок к разговорному английском" - это во-первых не так, а во-вторых, даже если допустить, что так - не меньшее безумие, чем пресловутые хипстерские поделки. Потому и не пишут. Ещё одна проблема всех хипстерских поделок - они рассчитаны на недалёкого писателя, к которому внезапно почему-то надо адаптировать сам язык. При этом хипстота, "знающая" "как правильно", забывает, что на вкус и цвет все фломастеры разные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #56

55. Сообщение от OpenEcho (?), 24-Апр-20, 09:13	+1 +/–
> Это не так. Хаят язык, когда он чем-то не устраивает. Есть ложка, а есть вилка... Каждая создана для конкретного применения. Не устраивает есть суп вилкой? Ну так юзай ложку... Не задумывались, - как много веб продуктов написанно на С/С++ ? > Или ты сторонник политкоррктности в отношении языков программирования? Причем здесь политика, сестра проститутки которая? Иди найди работу бэкенд/фронтенд разработчиком где требуются языки програмирования использующие "поинтеры", а когда (если) найдешь, поделись как долго искал... > Типа "это язык несомненно альтернативно-нужный"? Альтернативно нужный??? Назвать ведущий бэкенд язык альтернативным, - это конечно смело ! В бизнесе есть такое понятие: спрос и предложение. Есть спрос - быстро и дешево делать веб приложения, именно поэтому любой хостинг предлагает ПЫХ, а не С++ как бэкенд. С точки зрения здравой логики, да, С-шная програма значительно более продуктивна, чем тот же ПЫХ, но она и значительно более дорога в создании и сопровождении. ПЫХ вовсе не виноват, что на нем пишут много недоучек и создают о нем дурную славу, это не мешает тем, у кого руки растут из нужного места поднимать на нем проекты типа мордакниги. (Кстати, я не ПЫХ програмист, - просто видение реальности не из розовых облаков)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #92

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

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

58. Сообщение от anoun (?), 24-Апр-20, 09:22	–2 +/–
>probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language Т.е. Пайк считает, что те, кто учил жабу/сишку/пистон, необратимо искалечили свой мозг и уже неспособны выучить нормальный язык?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #74, #112

59. Сообщение от Fracta1L (ok), 24-Апр-20, 09:29	+/–
Уровень мышления псевдотехнарей во всей красе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #69

60. Сообщение от Аноним (60), 24-Апр-20, 09:29	+/–
>Мол, а представьте что нет у нас while Так действительно while и не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

61. Сообщение от GentooBoy (ok), 24-Апр-20, 09:38	+1 +/–
>Без обид, но вот когда люди, начинают хаить какой-то язык, то это первый признак хренового програмиста - в принципе... Случай выше подходит под ваш ответ, но это не всегда так. ЯП это всегда компромисс на который пришлось пойти его создателям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

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

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

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

65. Сообщение от Аноним (46), 24-Апр-20, 10:02	+5 +/–
угу. И главное как пишут! Поубивал бы некоторых
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #99

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

67. Сообщение от 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ообщить модератору
Родитель: #24 Ответы: #201

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

69. Сообщение от Аноним (74), 24-Апр-20, 10:16	+2 +/–
Так ты еще и гуманитарий. Так и запишем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #81

70. Сообщение от Ordu (ok), 24-Апр-20, 10:17	–1 +/–
Да ладно, эта новость довольно показательная -- она выбивается из тренда: очень мало изменений, и все они несущественны. То есть декларации о намерениях стабилизировать язык, видимо, прекращают быть декларациями и становятся стабилизацией. Ещё пара таких новостей, и тогда они станут нормой, и вот тогда, действительно, они перестанут быть новостями. Их можно будет засунуть в мини-новости или вообще не писать о них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

71. Сообщение от Аноним (71), 24-Апр-20, 10:17	+/–
Пардон, он не сложный, он уродский
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #83, #183

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

73. Сообщение от Аноним (71), 24-Апр-20, 10:18	+/–
Ты перепутал с перлом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #76, #79

74. Сообщение от Аноним (74), 24-Апр-20, 10:19	+1 +/–
Старую собаку новым трюкам не научишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

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

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

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

78. Сообщение от Аноним (78), 24-Апр-20, 10:49	+1 +/–
Лучше вот это почитай https://twitter.com/jeremy_soller/status/1251364826464411653
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

79. Сообщение от Аноним (79), 24-Апр-20, 10:52	+/–
А на Перле сейчас вполне пишут?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

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

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

82. Сообщение от Ordu (ok), 24-Апр-20, 11:12	+1 +/–
> 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 {} \;
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #114, #148, #149

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

84. Сообщение от Аноним (84), 24-Апр-20, 11:45	+/–
Только ты знаешь что тестировать и где тестировать. Да и тестировать надо меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #122

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

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

87. Сообщение от Аноним (7), 24-Апр-20, 11:57	+/–
А было бы неплохо, иначе где еще троллить (по доброму шутить) над фанатами раста (лицами навязывающими окружающим подход делать простые вещи сложно)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

88. Сообщение от Anonymqwe (?), 24-Апр-20, 11:57	+/–
Машинно оптимизируется он, потому что 30 лет процессоры под него проектируют, в ущерб теоретической производительности и чистоте дизайна Я не найду сейчас ссылки, где эта тема раскрывается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #98

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

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

91. Сообщение от freehck (ok), 24-Апр-20, 12:09	+/–
> Не помню уж как называлась. Что-то старое из конца 80х - начала 90х. Уж не знаю, кого читали конкретно Вы, но Абельсон и Сассман издали SICP в 85м, и там вполне наглядно показывалось, что циклы есть синтаксический сахар.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #94, #142

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

93. Сообщение от фррр (?), 24-Апр-20, 12:30	+1 +/–
Это в теории, а на практике тормозную скриптуху пихают везде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #95, #97

94. Сообщение от A.Stahl (ok), 24-Апр-20, 12:31	+/–
Но очень вкусный и полезный сахар.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #100

95. Сообщение от A.Stahl (ok), 24-Апр-20, 12:42	+/–
> Это в теории, а на практике тормозную скриптуху пихают везде. А ведь что мешает сделать интерпретатор Си(с классами) с тем чтобы приучать питонистов и прочих к нормальному языку?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #101, #102, #113

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

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

98. Сообщение от Аноним (96), 24-Апр-20, 12:50	+/–
Конечно не найдешь, потому что это полная чушь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #121

99. Сообщение от Аноним (96), 24-Апр-20, 12:51	+1 +/–
Некоторых ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #154

100. Сообщение от freehck (ok), 24-Апр-20, 12:56	+1 +/–
> Но очень вкусный и полезный сахар. Кто ж спорит. Но тем не менее это сахар. А без сахара легко обойтись. Обеспечьте в языке рекурсию -- и циклы в принципе уже не обязательны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #107, #199

101. Сообщение от Аноним (7), 24-Апр-20, 12:59	–1 +/–
Я в детстве дотнетнировал, как аноним со стыдом в признаюсь сием постыдном грехе (но всегда после мыл руки!) Вот думаю если анонимусу хочется как интерпретатор С (с классами) он тоже может подотнетнировать (после мойте руки, клавиатуру, соблюдайте гигиену!) И таки да, без шуток, питон - НОРМАЛЬНЫЙ язык. Аноним использовал в работе за эти десятилетия C, С++ (98, 11), C#, Java, Python, Ruby, Dart, LSL (моя любовь), Bash, QuakeC и даже Perl. Просто для каждой задачи нужен свой инструмент. Учите матчасть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #105, #109

102. Сообщение от Аноним (105), 24-Апр-20, 13:05	+1 +/–
Уже https://root.cern.ch/cling
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

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

104. Сообщение от OpenEcho (?), 24-Апр-20, 13:12	+/–
> ....наелись неочевидных ошибок и уязвимостей в коде на пыхе Ну давайте, показывайте ЯП, который не страдает этими симптомами...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

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

106. Сообщение от Аноним (106), 24-Апр-20, 13:18	+/–
Что ещё за nil указатели?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #169

107. Сообщение от коржик (?), 24-Апр-20, 13:37	+/–
упаси боже
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #157

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

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

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

111. Сообщение от коржик (?), 24-Апр-20, 13:58	+1 +/–
я дотнетирую, мне обидно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

112. Сообщение от Совершенно другой аноним (?), 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".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

113. Сообщение от bOOster (ok), 24-Апр-20, 14:09	+/–
>> Это в теории, а на практике тормозную скриптуху пихают везде. > А ведь что мешает сделать интерпретатор Си(с классами) с тем чтобы приучать > питонистов и прочих к нормальному языку? Этож Бейсик? НЕ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

114. Сообщение от bOOster (ok), 24-Апр-20, 14:15	+1 +/–
> Это работало офигенно, машинный код получался прямо как задумано Кем задумано? Мужчинами которые умеют С?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #120

115. Сообщение от bOOster (ok), 24-Апр-20, 14:18	+/–
> Питон хорош только тем, что для него наплодили библиотек почти для всех > случаев жизни. Именно библиотеки и есть ремесло...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

116. Сообщение от bOOster (ok), 24-Апр-20, 14:22	+/–
> Я же больше не дотнетнирую! зачем минус то поставили!) Взгляд бросил прочитал - детонирует ) MS43 от Siemens очень умеет это обходить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

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

118. Сообщение от bOOster (ok), 24-Апр-20, 14:30	+/–
> Если люди с питона, руби и прочей тормозной скриптухи перейдут на раст, > то это будет хорошо. А эти люди знают что такое бинарный поиск?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

119. Сообщение от Аноним (119), 24-Апр-20, 14:39	+/–
Java+ARM... но кое-кому это очень не понравилось
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #156

120. Сообщение от Ordu (ok), 24-Апр-20, 14:41	+/–
> Кем задумано? Мне кажется, там понятно написано кем, но ежели я ошибаюсь, то скажу прямо и без ложной скромности: мною так было задумано. Как задумывал, так и вышло. Если бы я на асме писал, я бы пожалуй результат в одном регистре возвращал: если ошибка, значит rax содержит код ошибки, если нет ошибки, значит rax содержит результат, а CF флаг в регистре флагов использовал бы для того, чтобы дать возможность отличить ошибку от результата. Так было бы ещё круче: call my_func jc handle_error Но как такую задумку объяснить компилятору -- я не знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #123

121. Сообщение от Ordu (ok), 24-Апр-20, 14:43	+1 +/–
https://queue.acm.org/detail.cfm?id=3212479
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #130

122. Сообщение от Аноним (46), 24-Апр-20, 15:06	+/–
это если ты хороший разработчик, и понимаешь чего ожидать. Что-то мне кажется, что если программа на 95% безопасна, то на остальные 5% некоторые могут и забить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

123. Сообщение от bOOster (ok), 24-Апр-20, 15:07	+/–
>[оверквотинг удален] > Мне кажется, там понятно написано кем, но ежели я ошибаюсь, то скажу > прямо и без ложной скромности: мною так было задумано. Как задумывал, > так и вышло. Если бы я на асме писал, я бы > пожалуй результат в одном регистре возвращал: если ошибка, значит rax содержит > код ошибки, если нет ошибки, значит rax содержит результат, а CF > флаг в регистре флагов использовал бы для того, чтобы дать возможность > отличить ошибку от результата. Так было бы ещё круче: > call my_func > jc handle_error > Но как такую задумку объяснить компилятору -- я не знаю. Вот это демагогия :)) Компилятору обьяснять не надо, он вообще-то тупой.. А вот когда программист не знает что такое прерывания и как из него сделать exception... И да... на x86 какой бы он не был - жизни нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #125

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

125. Сообщение от Ordu (ok), 24-Апр-20, 16:29	+/–
> Компилятору обьяснять не надо, он вообще-то тупой.. Мне надо получить результат от компилятора, и значит мне как-то надо высказаться на языке программирования так, чтобы получить именно тот результат, который я хочу. То есть объяснить компилятору. Так что ещё надо посмотреть, кто именно тут тупой. > А вот когда программист не > знает что такое прерывания и как из него сделать exception... Эксепшны для истеричек. Большинство ошибок не фатальные и обрабатываются на месте, может быть надо пару стековых фреймов снять, для ясности, и там будет понятно как обрабатывать. Но из-за этого запускать механизмы размотки стека? И ради того, чтобы эти механизмы могли бы вызывать все деструкторы, стек ещё приводить в состояние, которое позволяет в рантайме найти все эти деструкторы, которые надо вызвать? Сложность ради сложности? > И да... на x86 какой бы он не был - жизни нет Язык C позиционируется как кроссплатформенный, и, наверное, это хорошее оправдание тому, что компилятор нельзя научить использовать регистр флагов для возврата булевских значений. Но факт остаётся фактом, сделать идеально на нём нельзя. То есть если даже задаться целью добавить в компилятор возможность генерировать такой код, то совершенно непонятно какие именно высказывания на C должны приводить к этому. В случае же с Rust'ом, это возможно, по-крайней мере в теории. enum с двумя вариантами, типа Result'а -- это вещь которая семантически идентична тому, о чём я говорю, осталось лишь научить компилятор передавать недостающий бит информации через флаг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #150, #153

126. Сообщение от Аноним84701 (ok), 24-Апр-20, 16:29	+2 +/–
> C-подобный синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется, Т.е. дать ссылочку на такой "хорошо оптимизирующий машинно" и минимальный (а не на миллионы строк) компилятор С вас не затруднит? > и позволяет при _достаточной грамотности_ творить достаточно чУдные вещи, обходя оптимизатор Правда, в осносновном в прохладных былинах и других, более лучших чем наша, реальностях лапшеразвеши^W комментаторов опеннета :( Потому что в моем варианте реальности, к сожалению, "недостаточно грамотные" неосиляторы из разработчиков ядра, (g)libc, (де)кодировщиков видео, BLAS и т.д, вместо "обхода оптимизатора" средствами "прекраснейшего и эффектнейшего синтаксиса" -- напихали ламерских интринсиков/ассемблерных вставок :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #151

127. Сообщение от Аноним (127), 24-Апр-20, 16:37	+1 +/–
> память безопасная или нет, вопрос десятый, По вашему это нормально, что для индустрии важнее быстрее наклепать, чем безопаснее и надежнее сделать? А если дома строили и самолёты делали тоже с расчетом на скорость разработки? Почему мы не можем научиться у них?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #132, #134

128. Сообщение от Аноним (127), 24-Апр-20, 16:38	+/–
Кроме Лиспа, Лисп прекрасен с макросами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #207

129. Сообщение от anonimous (?), 24-Апр-20, 16:40	+/–
>Похоже синтаксис близкий к разговорному причина отказа от использования языков программирования. Угу, например все уже отказываются от SELECT * FROM Planets WHERE Radius BETWEEN 3000 AND 9000
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #163

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

131. Сообщение от Аноним (131), 24-Апр-20, 16:47	+1 +/–
Не якобы и не в теории, а на практике: https://www.opennet.dev/opennews/art.shtml?num=51475
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #136

132. Сообщение от Аноним84701 (ok), 24-Апр-20, 16:49	+/–
>> память безопасная или нет, вопрос десятый, > По вашему это нормально, что для индустрии важнее быстрее наклепать, чем безопаснее > и надежнее сделать? А если дома строили и самолёты делали тоже > с расчетом на скорость разработки? Почему мы не можем научиться у них? Потому что мало кто хочет платить цену самолета или дома за хранилку фоток котиков? https://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4... (верификация микроядра L4)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

133. Сообщение от Аноним (133), 24-Апр-20, 16:59	–1 +/–
Из википедии: > Rust (язык программирования) > Объектно-ориентированное программирование как таковое языком не поддерживается Отсюда вопрос: как на этом г-не программировать графический интерфейс (GUI)?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #135, #137, #139, #145, #193

134. Сообщение от Аноним (7), 24-Апр-20, 17:08	–1 +/–
Нет это не нормально для Вас, но нормально для той системы в корой мы существуем - капиталистической. Тут важна норма прибыли - накладные издержки будут сокращаться. См. катастрофу Боинг-737 MAX в Индонезии. В любом случае, трудозатраты и инструмент должны быть адекватны задаче. Насчет раста, язык сырой, до сих пор вносят изменения - самолеты тут вообще не при делах, для авиации используют язык Ада - и в штатах и в россии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #140

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

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

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

138. Сообщение от Вебмакака (?), 24-Апр-20, 17:53	–1 +/–
Синтаксис С это шляпа полная. Достаточно вспомнить, что до clang'а нормально анализировать даже сорцы на чистом С было нечем, даже надёжной подсветки в IDE не было. >относительно хорошо _машинно_ оптимизируется Далол, постоянно проверять ассемблер, процесс оптимизации от бога. Аппаратные возможности процов затащили в стандарт всего-то через 10 лет после того, как они стали нужны. Лучший системный язык эвар.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #152

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

140. Сообщение от Аноним (127), 24-Апр-20, 18:07	+/–
Да я, знаете, не столько за раст конкретно, сколько за безопасность памяти. Пример с авиаиндустрией я у Шнайера почерпнул из его "Практической криптографии". Там он вообще много требований на ЯП наложил. А на Аде как, безопасная память?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #141

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

142. Сообщение от little Bobby tables (?), 24-Апр-20, 18:40	+/–
кто это
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

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

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

145. Сообщение от коржик (?), 24-Апр-20, 20:09	+4 +/–
Сложно. И не из-за того что нет ооп, а вследствие ограничений на уникальное владение ссылками. То есть, если в обычных языках интерфейс является кучей слабосвязанных объектов, где все могут мутировать всех, то в расте у вас так просто не получится реализовать MVC или MVVM. Например, у вас приложение на дотнете и есть вью-модель, коротую с одной стороны мутирует с домен, а с другой приходят события от графического представления, и тоже меняют значения внутри неё. Для дотнета всё нормально. Но в расте получается так, что вью-моделью владеют и домен и вью. Если у вас UI живет в отдельном потоке - то тут проблем будет еще больше. Иметь доступ до одного и того же значения из двух потоков тоже не в стиле раста. И получается что тот же GTK (https://gtk-rs.org/) как бы есть, но программировать на нём без крепких как сталь нервов вы не сможете. Выход - событийная модель и ELM подобные фреймворки, вот например https://github.com/antoyo/relm , библиотека поверх GTK. Или вот https://github.com/hecrj/iced
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #194

146. Сообщение от Онаним (?), 24-Апр-20, 20:18	+/–
> в C нет пристойного механизма обработки ошибок В тебе говорит тот самый юзер, которого я описывал. Что такое ошибка вообще? Это код возврата из процедуры, обычно. Ну вот от этого и пляши. Можно ещё взять плюсы и играться эксепшнами, которые немножко задачу облегчают, и при этом логике не противоречат. И синтаксис не ломают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

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

148. Сообщение от Онаним (?), 24-Апр-20, 20:20	+/–
> в C нет пристойного механизма обработки ошибок В тебе говорит тот самый юзер, которого я описывал. Что такое ошибка вообще? Это код возврата из процедуры, обычно. Ну вот от этого и пляши. Можно ещё взять плюсы и играться эксепшнами, которые немножко задачу облегчают, и при этом логике не противоречат. И синтаксис не ломают. > невозможно без специальных обёрток, которые привнесут в C программирование с generic типами как в C++ Это ты сам себе придумал, что я только про чистый C? Нет, я про синтаксис, и только про синтаксис. C, C++, C#, Java и т.п. Прелесть в том, что базовый синтаксис вполне расширяем, и не нужно изобретать велосипеды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #190

149. Сообщение от Онаним (?), 24-Апр-20, 20:20	–2 +/–
> fn my_func -> Result<i32, Error> Глаза вытекают уже на ->
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #168, #176

150. Сообщение от Онаним (?), 24-Апр-20, 20:23	–1 +/–
> компилятор нельзя научить использовать регистр флагов для возврата булевских значений Это банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании легко может убить этот самый регистр флагов. Опять же - упёрлись в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый код чуть сложнее, чем кажется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #175

151. Сообщение от Онаним (?), 24-Апр-20, 20:24	+/–
> "хорошо оптимизирующий машинно" и минимальный Это ваши личные половые требования. Мне достаточно первого пункта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #155

152. Сообщение от Онаним (?), 24-Апр-20, 20:24	+/–
> до clang'а нормально анализировать даже сорцы на чистом С было нечем, даже надёжной подсветки в > IDE не было Поржал, пошёл дальше. Спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

153. Сообщение от Forth (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, только соус другой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #173

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

155. Сообщение от Аноним84701 (ok), 24-Апр-20, 21:02	+/–
>>> относительно хорошо _машинно_ оптимизируется >> "хорошо оптимизирующий машинно" и минимальный > Это ваши личные половые требования. Мне достаточно первого пункта. Что, не все верят анонимным опеннетным комментаторам на слово? Некоторые  еще и каких-то пруфов требуют? Совсем оборзели, да! 🙄
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #161

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

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

158. Сообщение от Lex (??), 24-Апр-20, 22:05	+/–
Пых вполне неплох и с задачами, для которых он изначально предназначен( своеобразный веб ) он справляется отлично. То ли дело всякие монструозные динозавры типа жабы или плюсов.. или, даже, тормознутый питон :) Кстати, так и какие языки «безальтернативно-нужные» ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

159. Сообщение от Lex (??), 24-Апр-20, 22:17	+/–
Ну я имел дело с сайтом на пюсАх, правда, в качестве поддержки, а не разработки. И до и после попадалось множество разных проектов( пых, жс итп ), но такого убогого *** как тот проект, я не встречал. Казалось бы, плюсЫ типо_несравненно_круче того же пыха, но потом, правда, оказывается, что пых изначально пилился как подобие шаблонизатора для веб-страниц, на нем огромное множество наработок итп, тогда как плюсЫ - просто_уродливая_надстройка_над_Си_доя_ооп и в задаче генерации вебстраниц с возможностью норм доработок за приемлемое время, плюсЫ начисто проигрывают тому же пыху. Как ни странно, но, да: «любой задаче свой инструмент»
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #196, #197

160. Сообщение от Анонимный Алкоголик (??), 24-Апр-20, 22:23	+/–
> Был уже тут один монарх, пяткой себя в грудь бил, все говорил > о реализации блога на C++. То ли за 21 день собирался > он это сделать, то ли за неделю. Но уже скоро год > пройдет, а блога как небыло, так и нет. > Мораль: выбирай инструмент под задачу. А что его делать-то? Любой веб-сервер плюс небольшой html-файл и вот простейший блог. А что? >:-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

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

162. Сообщение от anonymous (??), 24-Апр-20, 22:53	+/–
> машинный код в 2 раза быстрее (в среднем) Очень сильное заявление :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #170

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

164. Сообщение от anonymous (??), 24-Апр-20, 23:17	+/–
Уже не все так просто. А LINQ? IEnumerable<int> scoreQuery = from score in scores where score > 80 select score;
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

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

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

167. Сообщение от Аноним84701 (ok), 25-Апр-20, 00:06	+/–
> Так ты про пруфы или про одновременно "хорошо и минимального размера", Т.е. ты сам не понял, что написал? Если "синтаксис требует _минимум_ специальных обёрток, относительно хорошо _машинно_ оптимизируется,", то где же "хорошо и минимального размера"? Синтаксис-то, если верить анониму, позволяет. Или можешь дать ссылку на  код "_достаточной грамотности_" посложнее хеловрота, который без интирсиков и ассемблерных вставок будет в сборке с O0 быстрее работать чем c О2 (т.е. "обходить оптимизатор")? Ну или можешь еще что-то придумать -- это ведь ты сделал весьма смелые заявления и  соотв. "бремя доказательства" на тебе. >  личные половые требования > болезный? Вах, какие аргументативные аргументы!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #179

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

169. Сообщение от leap42 (ok), 25-Апр-20, 03:48	+/–
нулевые, те которое есть, но ни на какие реальные данные не ссылаются так понятнее?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

170. Сообщение от leap42 (ok), 25-Апр-20, 03:51	+/–
> Очень сильное заявление :) что с ним не так? два разных компилятора генерят разный машинный код. решение одной и той же задачи на этих языках будет работать с разной скоростью. между прочим мой тезис подтвердили ниже и позже, с пруфами, но независимо от меня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #200

173. Сообщение от 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ообщить модератору
Родитель: #153 Ответы: #181, #195

175. Сообщение от Ordu (ok), 25-Апр-20, 05:52	–1 +/–
>> компилятор нельзя научить использовать регистр флагов для возврата булевских значений > Это банально не нужно и вообще контрпродуктивно, потому что add/sub в фреймировании > легко может убить этот самый регистр флагов. Опять же - упёрлись > в "оптимизацию" (кавычки не случайны), но забыли про то, что генерируемый > код чуть сложнее, чем кажется. Если бы я писал на ассемблере, то я бы легко мог бы сохранить CF в нужном мне состоянии. Компилятор, если бы он задался целью, тоже мог бы, но проблема в том, что нет такой кодовой фразы на C, которая бы перед ним поставила такую цель.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #182, #215

176. Сообщение от Ordu (ok), 25-Апр-20, 05:59	+/–
>> fn my_func -> Result<i32, Error> > Глаза вытекают уже на -> Я лишь могу выразить соболезнования. Если твое глаза вытекают от этого диграфа, то значит ты никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательными для освоения. Очень образовательными. И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа. А почему именно этого? От += не вытекают? А от триграфов типа <<= не вытекают?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #177, #178

177. Сообщение от Онаним (?), 25-Апр-20, 07:05	–1 +/–
> никогда не сможешь освоить не только rust, но ещё и Haskell, ещё и OCaml, и вероятно кучу других языков программирования, которые могут быть очень увлекательными Я оперирую критерием полезности, а не увлекательности. При этом гораздо увлекательнее, когда ты имеешь на руках нужный тебе практический результат на нормальных языках, а не десяток "освоенных" ненужных языколяпов в теории. Это как совковый кругозор - вроде и знают много, а толку нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #185

178. Сообщение от Онаним (?), 25-Апр-20, 07:07	+/–
> И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа. Я сказал "уже", если ты не понял. Остальное там ещё хуже. > А почему именно этого? От += не вытекают? А от триграфов типа <<= не вытекают? += и <<= легко бьётся на две операции: + = и << =, которые имеют смысл. Но суть не в этом. Глаза вытекают не от символов, а от самого построения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #186

179. Сообщение от Онаним (?), 25-Апр-20, 07:08	+/–
Тут не аргументы, тут как раз факты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #222

180. Сообщение от Онаним (?), 25-Апр-20, 07:09	–1 +/–
> где требуется real-time код, компактность и быстродействие Тут определённо "не" пропущено :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

181. Сообщение от Онаним (?), 25-Апр-20, 07:11	+/–
map_err(|_| ...)?; Глаза снова вытекли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #187, #189

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

183. Сообщение от Онаним (?), 25-Апр-20, 07:13	–1 +/–
> Пардон, он не сложный, он уродский Невозможно не согласиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

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

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

186. Сообщение от Ordu (ok), 25-Апр-20, 07:21	+/–
>> И всё лишь потому, что у тебя глаза вытекают из-за какого-то диграфа. > Я сказал "уже", если ты не понял. Остальное там ещё хуже. Это "уже" очень показательно, если ты не понял. Остальное можно не слушать, после этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

187. Сообщение от Ordu (ok), 25-Апр-20, 07:22	+/–
> map_err(|_| ...)?; > Глаза снова вытекли. У тебя все глаза сразу вытекают? Или как так выходит, что они вытекают, вытекают, и всё равно что-то остаётся?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #191

188. Сообщение от 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ообщить модератору
Родитель: #182

189. Сообщение от 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ообщить модератору
Родитель: #181 Ответы: #192

190. Сообщение от 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ообщить модератору
Родитель: #148

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

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

193. Сообщение от Аноним (193), 25-Апр-20, 10:46	+/–
А это бред. ООП в Расте есть. Просто весь полиморфизм реализован через интерфейсы, а не через наследование. https://doc.rust-lang.org/book/ch17-00-oop.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #218

194. Сообщение от Forth (ok), 25-Апр-20, 11:12	+1 +/–
Если бы только в UI вызывало проблемы. Любое модульное приложение, где модули ничего друг о друге не знают кроме публичных интерфейсов лего наваять в Java например. Легко написать тесты как модульные так и интеграционные. На расте это превращается в жесть с дженериками, иначе тесты хрен напишешь. Можно конечно передавать всё как dyn Trait, но тогда начинается веселье с borrow checker который уже не может отследить, на что ссылка из структуры заимствуется. P.S. Самое удивительное, что разработка все равно получается продуктивная, хотя повозится приходится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

195. Сообщение от Forth (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(_) => {} } Да по мне таже фигня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #198

196. Сообщение от RibiKukan (ok), 25-Апр-20, 12:15	+1 +/–
>Ну я имел дело с сайтом на пюсАх, правда, в качестве поддержки, а не разработки. У вас постоянные проблемы с логикой. Вы не знаете что такое С++ и никаком образом С++ от не С++ не отличите. Поэтому толку с этих рассуждений? >И до и после попадалось множество разных проектов( пых, жс итп ), но такого убогого *** как тот проект, я не встречал. Опять же - ты не отличаешь жопу от пальца. >Казалось бы, плюсЫ типо_несравненно_круче того же пыха, но потом, правда, оказывается, что пых изначально пилился как подобие шаблонизатора для веб-страниц Ты даже о вебе ничего не знаешь. Шаблонизатор и пых сдох лет 10 назад. К тому же только идиот будет писать какие-то шаблоны на крестах. Запомни на будущие. Если кто-то из мира С/С++ использует текст - это залётный колхозник. >на нем огромное множество наработок итп, А ну да, это ещё одна проблема колхозников. Вы не отличаете жопу от пальца везде. Колхозник не может отличить язык и либу. Ты там определись с методичкой - что тебе даёт профит. Если язык как таковой - зачем тебе тонны говнолиб? Если говнолибы, то причём тут язык? >тогда как плюсЫ - просто_уродливая_надстройка_над_Си_доя_ооп Чини методичку. Как я и говорил - ты нихрена о С++ не знаешь. Да и о си тоже. >и в задаче генерации вебстраниц с возможностью норм доработок за приемлемое время, плюсЫ начисто проигрывают тому же пыху. Опять же - проблема с методичкой. Гененрируют веб-страницы только колхозники с помойки. Так было всегда. Потуги про приемлемое время в основном сводится к тому, что колхозник попросту не может ни во что, кроме примитивной херни. Паре трюков на пхп обезьяну можно научить. Так же можно научить перепащивать с СО. С крестами, даже с той породией на кресты о которых кукарекаешь ты - такое не прокатит. >Как ни странно, но, да: «любой задаче свой инструмент» Это нелепая херня. Никаких инструментов не существует. Если проще. Есть требования и есть задачи, где эти требования минимальны. И мир так работает. Сложные и мощные вещи остаются там, где в них есть крайняя необходимость. Они с куда большим профитом во всём могут применяться везде. Но, такого кол-во людей нет. Поэтому те, кто могут занимаются придумываем говна, что-бы вчерашний поломой мог сгенерировать хтмл-страницу. И именно это называется под задачу. Давай попроще. Может ли условный шумахер на s-классе возить колхозников в ашан? По мнению идиотов - нет. Реально - да, причём куда лучше. Но проблема в том, что шумахеров мало, как и мало машин представительского класса. Лучшее может выполнять задачи худшего, но задач всегда больше, чем могут обеспечить лучшие. Поэтому вариант один - пытаться организовать выполнение таким образом, что-бы худшие могли делать хоть что-то. А уже те самые колхозники далее придумывают херню вида "под задачу".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

197. Сообщение от RibiKukan (ok), 25-Апр-20, 12:20	+/–
Ну и самое интересное - эта методичка уже протухла. За пруфами далеко ходить не нужно. Колхозники типа тебя орали годами "пхп наше всё - под задачу". Гугл взял сишку, прикрутил к ней гц и ооп-надстройку и оказалось, что даже колхозники могут что угодно пилить. Потому как никакого "под задачу" не существует. Не существует какой-то задачи для скриптухи. Причина проста - рядовой птушник ничем, кроме юзанья api не занимается. И все трюки, которым его научили сводятся к вызову функций. Всё это есть везде, в любой "языке". Поэтому да, ты выше правильно спалился. Тебе как колхознику нужно api и пару педалей. Какие это будут педали - похрен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

198. Сообщение от 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ообщить модератору
Родитель: #195

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

200. Сообщение от 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ообщить модератору
Родитель: #170

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

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

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

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

205. Сообщение от Аноним (202), 26-Апр-20, 00:42	+/–
При чем тут школьники?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

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

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

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

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

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

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

212. Сообщение от Аноним (202), 26-Апр-20, 06:06	+/–
миссклик. так вот > Если сравнивать синтаксис Раста и Плюсов то окажется, что не так уж раст и страшен, а в некоторых случаях и превосходит Плюсы проще в базовой форме, когда не уходишь в дебри, но, когда смотришь на некоторые новые фичи 20 плюсов, понимаешь, что вообще-то можно (и, возможно, лучше) вложить время и в изучение раста :) А кроме плюсов у него по сути нет конкурентов. И то, плюсы скорее из-за популярности вытягивают, при этом до сих пор не имя имея дефолт пакетного менеджера и системы сборки (не cmake единым), что позорно для языка такого уровня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

213. Сообщение от Ordu (ok), 26-Апр-20, 06:32	+/–
> В си есть ООП. Если мы используем такое определение для "есть ООП", которое позволяет сказать, что в C есть ООП, то тогда нам придётся признать, что в Rust'е тоже есть ООП. Rust не хуже C позволяет жонглировать указателями на функции, и создать вручную vtable там не проблема нисколько. > При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция. Это вопрос к анониму выше, он почему-то считает, что без ООП невозможно программировать гуй.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

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

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

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

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

218. Сообщение от Онаним (?), 26-Апр-20, 10:51	+/–
> весь полиморфизм реализован через интерфейсы, а не через наследование. Очередная зубодробительная новшествА, которая ну ладно, право на жизнь имеет, но в очень ограниченной среде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193

219. Сообщение от Онаним (?), 26-Апр-20, 11:05	+/–
> В си есть ООП. Ядро полно ООП, гтк полон ООП. > При чём ГУИ тут вообще, ГУИ это только ГУИ абстракция. Там где надо ООП, люди берут плюсы, и не мучаются :) Или дотнетик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

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

221. Сообщение от bOOster (ok), 26-Апр-20, 11:55	+/–
> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и > clc. Но бывают и другие способы, которые могут быть удобнее в > зависимости от ситуации. Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220 Ответы: #223

222. Сообщение от Аноним84701 (ok), 26-Апр-20, 12:23	+/–
> Тут не аргументы, тут как раз факты. Пока что налицо лишь факты онанимного балабольства. Впрочем, от "знатока", не различающего синтаксис и семантику - ничего иного и не ожидалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

223. Сообщение от Ordu (ok), 26-Апр-20, 12:48	+/–
>> Есть две ключевые инструкции, про которые тебе будет интересно узнать: stc и >> clc. Но бывают и другие способы, которые могут быть удобнее в >> зависимости от ситуации. > Реальный код давай. Тут три четверти псевдо-программистов умеют гуглом пользоваться. Дитятко, любая из этих мнемоник -- реальный код. Поставь её на отдельной строчке в .asm/.s файле, и она будет реальным кодом. Открой любой учебник по ассемблеру, и ты узнаешь, ассемблер очень простой язык, гораздо проще всех этих ваших rust, C и тому подобных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #228

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

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

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

229. Сообщение от Ordu (ok), 26-Апр-20, 14:56	+/–
> Ты че идиот? Нет ты. > Еще толпа операций неявно меняют флаги переполнения. 99% (или около того) этой "толпы" находятся в группе арифметических операций. > Ни строчки кода не написано, зато гуглом поиском хорошо пользуется. Какие строчки кода ты хочешь от меня увидеть? Вот смотри: stc ret Выставили CF вернули управление. CF сохранился выставленным. Подойдёт? Что-то мне подсказывает что нет, не это тебе интересно. Но мне не понятно, какие именно непреодолимые проблемы ты видишь на пути возврата бита из функции через CF. Поскольку я не понимаю, что именно непонятно тебе, я не могу просветить тебя и научить тебя, как это делать. Если тебе что-то интересно, ты спрашивай, но постарайся в вопросе донести информацию о том, что именно тебе непонятно, иначе совершенно неясно как отвечать на твои вопросы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228 Ответы: #233

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

235. Сообщение от 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 есть _КУЧА_ регистров, и тут гораздо проще обходиться без адресации в глубины стека.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233 Ответы: #249

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

246. Сообщение от freehck (ok), 27-Апр-20, 10:59	+/–
> Только не просто рекурсию, а рекурсию с tail call optimization. Рекурсия без TCO -- это не рекурсия, а непонятно зачем нужный огрызок. =) А ежели быть точнее, то когда мы говорим о рекурсии, мы естественно имеем в виду хвостовую рекурсию. Если язык её по умолчанию не предоставляет, а только вон как в случае C -- только в виде оптимизации, которая ещё и срабатывает от случая к случаю -- то толку от такой рекурсии мало, равно как и смысла обсуждать её. Это как обсуждать type inference в Scala -- номинально для галочки есть, но по факту кому от неё в таком виде прок...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #264

247. Сообщение от tmplsr (?), 27-Апр-20, 13:49	+/–
>Не помню уж как называлась. Что-то старое из конца 80х - начала 90х. 128 советов чего-то там. "128 советов начинающему программисту?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #248

248. Сообщение от A.Stahl (ok), 27-Апр-20, 14:14	+/–
Да, она. Весьма забавная была книжка в своё время.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247

249. Сообщение от Совершенно другой аноним (?), 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, правда не знаю с каким результатом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235 Ответы: #255

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

255. Сообщение от Ordu (ok), 29-Апр-20, 08:47	+/–
> после этого флаг CF уже был потерян. Может быть. Мне более правдоподобной кажется гипотеза о том, что это было слишком заморочно для компиляторов тех лет. > для того, чтобы флаг CF не потерялся, его придётся где-то записать в > стек, или ещё куда, сразу после возврата, чтобы после вычисления выражения > вытащить и таки проанализировать. Если мы возвращаем Result, то такое вряд ли случится, потому как он требует обработки. То есть его можно записать в переменную и обработать после, но как правило он обрабатывается сразу. Хотя функция часто досрочно завершается и возвращает этот Result, а завершение может потребовать арифметики, а это значит дополнительная возня со флагом, только для того, чтобы завершиться. С другой стороны, это всё происходит в случае ошибки, и скорость её обработки менее важна, чем скорость работы без ошибки. Но, в общем, я согласен, что тут бабка надвое сказала, стоит оно того или нет. Это надо испытывать на реальных приложениях, затачивать оптимизатор под эти реальные приложения, приспосабливать приложения к оптимизатору, и потом смотреть что получилось. Сложно, долго, и нафиг нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249

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

268. Сообщение от коржик (?), 30-Апр-20, 19:19	+/–
> Просто та область применения для которой раст разработали уже давно занята, оттого > фанаты языка такие назойливые. Вот же сволочи назойливые! Уже и новость про новую версию раста комментируют!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

269. Сообщение от freehck (ok), 01-Май-20, 22:23	+/–
>[оверквотинг удален] >> имеем в виду хвостовую рекурсию. Если язык её по умолчанию не >> предоставляет, а только вон как в случае C -- только в >> виде оптимизации, которая ещё и срабатывает от случая к случаю -- >> то толку от такой рекурсии мало, равно как и смысла обсуждать >> её. Это как обсуждать type inference в Scala -- номинально для >> галочки есть, но по факту кому от неё в таком виде >> прок... > кстати type inFErence - в Scala очень полезен, как минимум без него > исходники были бы в пару раз больше из за лишних описаний > типов Ну не в пару -- это Вы сильно преувеличиваете. Если хотите посмотреть на то, каким type inference должен быть -- приглядитесь к ocaml. У языка строгая типизация, но указывать типы Вам придётся ровно в одном случае: при конструировании новых типов (ну и для функторов, разумеется). Дальше -- всё будет выведено автоматом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #273, #283

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

274. Сообщение от freehck (ok), 07-Июн-20, 07:58	+/–
> в ocaml это достигается "+." и подобными "особенностями", Да не, этими особенностями никто не пользуется. Обычно мы просто дёргаем модуль, подменяющий операторы, которые мы хотим использовать, на те, что работают с нужными типами. Необходимость смешивания крайне редка, в этих случаях просто дёргаем нужное явно. Посмотрите на библиотеки Core от JaneStreet -- там это практикуется в каждом модуле. А то, о чём говорите Вы -- это просто атавизмы из SML. Да, они вроде как в OCaml есть, но они так, для обратной совместимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273

283. Сообщение от freehck (ok), 07-Июн-20, 15:25	+/–
Аноним84701, цени своё время.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269

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

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