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

"Выпуск языка программирования Rust 1.75 и unikernel Hermit 0.6.7"	+/–
Сообщение от opennews (??), 29-Дек-23, 19:34
Опубликован релиз языка программирования общего назначения Rust 1.75, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60364
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 29-Дек-23, 19:34	–29 +/–
Очень радостно, что раст уже в ядре. Лет через 15 всё ядро уж точно будет переписано на это чудо техники!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #10, #17, #235

2. Сообщение от Аноним (-), 29-Дек-23, 19:48	–1 +/–
> В состав добавлен оптимизатор BOLT Ну раз добавлен... ладно, хорошо хоть не "на код положен" Хотя если "прирост скорости сборки до 24.7%", то можно и ценой 10.9% роста размера инструмента. Сейчас что ссд, что память стоят копейки, зато нищуки перестанут лезть в ядро.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #6

3. Сообщение от Аноним (-), 29-Дек-23, 19:52	+1 +/–
Версия ядра 1.0 вышла в 1994 году, те, будем считать, 30 лет. Так что переписать (и дописать новое) за 15 - это будет отличный результат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5

4. Сообщение от name (??), 29-Дек-23, 19:53	+2 +/–
Ага, embedded == нищуки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #14

5. Сообщение от Тот_ещё_аноним (ok), 29-Дек-23, 19:57	–2 +/–
Переписывать быстрее и нейронки вполне помогают
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #7, #15, #16

6. Сообщение от Тот_ещё_аноним (ok), 29-Дек-23, 19:59	–1 +/–
Следующую АЭС, для питания богатых сборок, построят напротив вашего дома
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8

7. Сообщение от Аноним (-), 29-Дек-23, 19:59	–1 +/–
Не спасибо, ими разве что лефтпады править. Более того, переписать просто в лоб не получится, скорее всего нужно будет менять код и взаимосвязи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Аноним (-), 29-Дек-23, 20:04	+/–
пф..! АЭС это уже прошлый век, вот если бы термояд (например Mr. Fusion Home Energy Reactor)))... но придется ограничиться солнечными панелями на крыше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11

10. Сообщение от Аноним (10), 29-Дек-23, 20:15	+3 +/–
>Лет через 15 всё ядро уж точно будет переписано на это чудо техники! Особенно учитывая, что переписывание на БезопасТном идёт намного медленнее, чем написание на Сишке. А на разработку ядра затрачено 32 года, то ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #12, #13

11. Сообщение от Аноним (10), 29-Дек-23, 20:18	+1 +/–
Э, нет, солнечных панелей вам даже на один лишь браузер будущего не хватит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

12. Сообщение от Аноним (12), 29-Дек-23, 20:26	–4 +/–
> медленнее, чем написание на Сишке Ты посчитал только написание или добавил "закладывание багов", поиск багов, тестирование, исправление и тд? Если нет, то верю. СИшка - это же пхп времен 70х. Для тех кто не освоил ассемблер и фортран, но нужно быстро х-к-х-к и продакшн.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #22

13. Сообщение от Советский инженер (ok), 29-Дек-23, 20:28	+1 +/–
> А на разработку ядра затрачено 32 года да, только ведь код добавлялся не линейно. а платиновые спонсоры скажут "надо" и работа закипит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #25, #138

14. Сообщение от Советский инженер (ok), 29-Дек-23, 20:30	+/–
>Ага, embedded для embedded придумали кросскомпиляцию
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

15. Сообщение от Аноним (15), 29-Дек-23, 20:41	–1 +/–
Особенно хорошо нейронки справляются со sql. Только не плачь, когда выпнут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

16. Сообщение от Аноним (16), 29-Дек-23, 20:41	+3 +/–
Нейронками можно и из Раста в Си конвертировать все нужное и тем самым избавится от лишних зависимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #19

17. Сообщение от Tron is Whistling (?), 29-Дек-23, 20:51	+/–
Они таки закопают ведро. Лицензия на редхат в разрезе 5 лет не сильно дешевле лицензий на винду... винде правда кал костов добавляет, но если мы берём сервис, который на аутентификацию в самой ос не завязан - кала надо мало. Для переходного периода из коробки уже есть WSL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #77

18. Сообщение от Аноним (16), 29-Дек-23, 20:57	+18 +/–
Глупо изучать новый сырой язык со сложным синтаксисом только ради защиты от небольшой части ошибок, связанных с неправильным управлением памятью. Проще воспользоватся инструментами вроде cppcheck или другими статическими анализаторами. Вот кстати большой список таких инструментов: https://github.com/analysis-tools-dev/static-analysis
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #23, #35, #184

19. Сообщение от Анонин (?), 29-Дек-23, 20:59	+/–
Если конвертить из Раста в Си, то получишь все недостатки си, только на расте. Куча unsafe, проблем с памятью и примитивность структур и кода. И никакая нейронка тебе тут не поможет. Так лучше вообще не делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #29

20. Сообщение от Аноним (20), 29-Дек-23, 21:00	+3 +/–
Хоть один адекватный человек на сайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #50

21. Сообщение от Аноним (25), 29-Дек-23, 21:04	–1 +/–
> При работе с голыми указателями ("*const T" и "*mut T") могут потребоваться операции добавления смещения к указателю. лет через 10 до С дорастёт по удобству работы с памятью
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #27

22. Сообщение от Аноним (16), 29-Дек-23, 21:05	+/–
А что, поиск багов, тестирование, исправление ошибок - это то, в чем программы на Rust не нуждаются?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #31

23. Сообщение от Анонимусс (?), 29-Дек-23, 21:09	+/–
> от небольшой Ахаха! Серьезно?? Посмотри сколько дыреней из-за проблема с памятью! Просто открой CVE лист для любого большого си проекта и там сплошные use-after-free или запись за пределы буфера. А статический анализ тебе поможет только в самых примитивных случаях. Как хорошо, что решения, касающиеся ядра, принимают профи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #56

24. Сообщение от Анонин (?), 29-Дек-23, 21:10	+2 +/–
Удобство работы с памятью в си - это "куда хочу, туда и пишу". Проблема что очень часто пишут мимо))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #26

25. Сообщение от Аноним (25), 29-Дек-23, 21:15	+/–
> а платиновые спонсоры скажут "надо" и работа закипит так уже сказали и Торвальдс разрешил, но сам он не увидел пользы от раста и энтузиазма нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

26. Сообщение от Аноним (25), 29-Дек-23, 21:20	+1 +/–
> Проблема что очень часто пишут мимо гипервизоры перехватят если что, можно ведь и прямо дёртуть не тот бит и спалить чего или стереть однократно программируемую память и окирпичить проц - никакие расты не помогут от отсутсвия закладок или ошибок в железе или просто отсутствии инфы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #53

27. Сообщение от Аноним (16), 29-Дек-23, 21:23	+2 +/–
В стандарте С17 будут подвижки с безопасностью, а пока для критичных проектов есть MISRA, например. В последние годы подняли такой шум с ней, что можно подумать остальные языки программирования будут сидеть ничего не делая. В С++ сейчас безопасность памяти это одна из основных задач над которой трудятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #28, #37

28. Сообщение от Аноним (12), 29-Дек-23, 21:31	+/–
> В стандарте С17 будут подвижки с безопасностью Напомните, какой сейчас год?) Сколько лет уходит, чтобы стандарт попал в ядро? В каком году в ядре начали использовать С11 вместо уже окаменевшего C99? > критичных проектов Есть Ада Спарк. Мисра тоже неплоха, но запрет на динамические аллокации сильно сужает применимость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #32, #188

29. Сообщение от Аноним (16), 29-Дек-23, 21:33	+/–
Нет конечно. Нейронки лучше всего программируют на том языке, для которого больше база в датасете, а это в первую очередь C и C++. Поэтому такой код получится еще лучше и безопаснее, чем на Расте. Она еще и пофиксит другие баги, не связанные с управлением памяти, от которых Раст вообще никак не защищает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #30, #148

30. Сообщение от Анонин (?), 29-Дек-23, 21:38	+2 +/–
А что будет в датасете? Куча дырявого кода многолетней выдержки? Грязные хаки и срезание углов? Вот обучишь на таком - оно тебе такое же и выпрограммирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #39

31. Сообщение от ИмяХ (ok), 29-Дек-23, 21:41	+/–
Нуждаются в гораздо меньшей степени, чем у сишных прог.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #36

32. Сообщение от Аноним (16), 29-Дек-23, 21:41	+/–
В ядре начали использовать С11 в 2012 году, полную поддержку обеспечили конечно позже, учитывая размеры проекта не вижу тут ничего ненормального. SPARK конечно хорошо для своих задач, повзволяет формально верифицировать ПО. Удивлен что приложения для блокчейна пишут не на нем, а на разгильдяйском Solidity.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #34

34. Сообщение от Аноним (12), 29-Дек-23, 21:49	+/–
Ядро перешло на с11 в 2022 году. Попробуем оценить в каком перейдут на c17, если сейчас практически 2024. Я думаю где-то 2029-2030. > Удивлен что приложения для блокчейна пишут не на нем, Думаю потому что слишком дорого. А блокчейн много на чем пишут, в том числе и на расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #41

35. Сообщение от Аноним (85), 29-Дек-23, 21:51	+1 +/–
> Глупо изучать новый сырой язык со сложным синтаксисом только ради защиты от небольшой части ошибок, связанных с неправильным управлением памятью Господи, в каждой новости о Rust начинается один и тот же цирк, снова и снова... Вам не надоело еще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #38, #187

36. Сообщение от Аноним (16), 29-Дек-23, 21:57	+/–
"в гораздо меньшей" - это сколько именно, и откуда эти данные? А если сравнить не с Си, а например с программой Java, где вообще управлять памятью не нужно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #43, #129

37. Сообщение от Аноним (25), 29-Дек-23, 21:59	+/–
> есть MISRA, например она платная для начала. Намного хуже что в gcc практически невозможно включить все варнинги и санитайзеры внятным способом и для проверки мисра-комплиант надо ещё внешний чекер. В платных компиляторах наверно лучше с этим но я ими не пользуюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #42

38. Сообщение от Анонимусс (?), 29-Дек-23, 22:08	+3 +/–
Конечно им не надоело! Они одни и те же ошибки повторяют уже лет 30-40.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #51

39. Сообщение от Аноним (39), 29-Дек-23, 22:09	+/–
Это скорее к кодовой базе Раста относится, им же главное побыстрее и побольше, часто пользуются трансляторами из Си, представляю какая там лапша.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

41. Сообщение от Аноним (39), 29-Дек-23, 22:19	+2 +/–
Так это окончательно объявили. А если проблемы с управлением памятью настолько реальны, как нас убеждают, то внедрение механизмов безопасности могут форсировать и скорее всего форсируют. Даже самые отъявленые фанаты Раста признают, что переписать ядро на Расте просто нереально, ни к 2030, ни к 2050. А блокчейн много где и на С++ пишут, немало видел на Java, бывало и на Котлине, там зоопарк огого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #44, #130

42. Сообщение от Аноним (39), 29-Дек-23, 22:23	+/–
Платный стандарт, а он и для С внезапно платный (чистовик), и ГОСТы на практике и много еще чего. PVS-Studio вроде предлагал бесплатную лицензию на один год для проектов с открытым исходным кодом. Наверняка есть и другие пути для некоммерческого проекта, а коммерческие пусть платят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #54

43. Сообщение от Аноним (43), 29-Дек-23, 22:27	–1 +/–
Микрософт насчитал что как минимум на 70%. Ссылки с отчётами легко гуглятся
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #49, #52

44. Сообщение от Аноним (12), 29-Дек-23, 22:29	+/–
Так все ядро никто даже и не собирается переписывать. Как раз самые отъявленные фанаты это понимают) Но переписать самые проблемные части, начать писать новый функционал, начать писать драйвера, чтобы одна паршивая овца не роняла всю систему - это вполне реальное развитие событий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #48

46. Сообщение от Аноним (39), 29-Дек-23, 22:36	+3 +/–
Не очень понятно, зачем нужен недописаный Hermit, когда есть уже готовые стабильные проекты IncludeOS, Nanos, наконец Unikraft.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #197, #283

48. Сообщение от Аноним (39), 29-Дек-23, 22:41	+/–
Ну так эту проблему (в целом довольно надуманную) и решает введение нового стандарта и новых инструментов обнаружения утечек, и не нужно это странное двуязычие, или даже скорее мультиязычие, потому что за Растом в ядро наверняка последуют и другие языки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #58

49. Сообщение от Витюшка (?), 29-Дек-23, 22:43	+1 +/–
Это не правда, у тебя даже прочитать не получилось без ошибок. А ты надеешься на Rust 🤨😀 Там не говорилось что нужно меньше дебажить, тестировать и ловить ошибки. Там говорилось что 70% CVE фиксятся с помощью Rust, они в основном связаны с выходом за границы массива и т.п. Надеюсь разницу между ошибкой и уязвимостью объяснять не нужно. С++ и Zig тоже устраняют эти классы ошибок. А Zig и поболее чем, процентов 90-95%.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #223

50. Сообщение от Аноним (129), 29-Дек-23, 22:45	+4 +/–
Мне кажется это единственная причину батхерта в сторону раста, когда уже убито множество человекочасов на изучение C++, а тут набирает популярность прямой конкурент, который позволяет проще писать поддерживаемый производительный код с минимизацией выстрелов в ногу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #59, #62

51. Сообщение от Аноним (129), 29-Дек-23, 22:46	+1 +/–
Вы про use after free и разыменовывание нулевого указателя?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #63

52. Сообщение от Аноним (39), 29-Дек-23, 22:46	+/–
Эти ссылки в основном из предвзятых источников. Зато если копнуть глубже часто попадаются статьи, в которых описывается негативный опыт использования Раста и уход с него на другие языки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #79, #143, #192

53. Сообщение от Аноним (129), 29-Дек-23, 22:48	+/–
Опыт дебага утечек памяти, или used after free или разуменовывание нулевого указателя вспоминается как страшный сон, брр..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #61

54. Сообщение от Аноним (25), 29-Дек-23, 22:48	+/–
> Платный стандарт, а он и для С внезапно платный (чистовик) поддержка различных стандартов С и С++ в gcc есть а мисры я там не наблюдаю > PVS-Studio вроде предлагал бесплатную лицензию это внешний анализатор, так можно и Frama-C ещё вспомнить, только много кто этим пользуется ? Rust удобен тем что весь анализ кода в одном открытом бесплатном компиляторе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #73

56. Сообщение от Витюшка (?), 29-Дек-23, 22:49	+1 +/–
Серьёзно. Потому что С++ это не С. И Rust взял очень многое напрямую из C++. Например, модель памяти и move семантику (она немного другая в Rust, более слабая, но из С++). Те в целом получается +- что на Rust, что на C++ одинаково.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #60, #72

58. Сообщение от Аноним (12), 29-Дек-23, 22:51	+/–
Проблема не надуманная. Как ни откроешь новость про CVE в ядре - то там почти всегда проблемы с памятью. И намного реже с логикой. > и решает введение нового стандарта почему тогда его до сих пор нет?) > и новых инструментов обнаружения утечек и их тоже нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #65

59. Сообщение от Аноним (39), 29-Дек-23, 22:51	+/–
Негативное восприятие всего лишь потому что вместо С++ со его реальными недостатками пропагандисты Раста всем навязывают C++ номер два с таким же убогим синтаксисом, без ООП, зато с CoC и повесточкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #68

60. Сообщение от Аноним (129), 29-Дек-23, 22:55	+/–
Сразу видно человека, не писавшего на расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #64

61. Сообщение от Анонин (?), 29-Дек-23, 22:57	+1 +/–
Ну, от утечек памяти раст не защищает и не гарантирует их отсутствие. Прямо в доке так написано. А вообще не знаю языка, который бы гарантировал их отсутствие. Даже хаскель периодически течет. Возможно что-то с формальной верификацией, но это очень специфические вещи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #118

62. Сообщение от Витюшка (?), 29-Дек-23, 23:04	+/–
Проблема в самом языке. Очень он неудачный получился. Не замена С++, а как правильно здесь сказали, С++2. Да, получше. Да, чуток получше, чуток безопаснее. А гемора с ним намного больше. Уже не один проект он него отказался, хотя явно там фанатики были. Тащили до конца, но не вышло. А что он появился - для С++ это здорово. Это значит часть программистов ушла туда и начала снова и заново переписывать всё, от Hello World до очень серьезных вещей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #66, #102, #144

63. Сообщение от Анонимусс (?), 29-Дек-23, 23:04	+1 +/–
А как же выход за пределы буфера?? Тут целое созвездие стандартных проблем. Вот прям из последнего https://www.opennet.ru/opennews/art.shtml?num=60326 - запись за пределы выделенного буфера (2 шт.) https://www.opennet.ru/opennews/art.shtml?num=60338 - use-after-free, double-free https://www.opennet.ru/opennews/art.shtml?num=60361 - Use after free
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #81, #116

64. Сообщение от Витюшка (?), 29-Дек-23, 23:05	+/–
Жду раз...б по фактам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #75, #83

65. Сообщение от Аноним (39), 29-Дек-23, 23:12	+/–
Как нет, только что же обсуждали :) Какая избирательная память. >инструментов обнаружения утечек Ой сколько я могу их накидать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #78

66. Сообщение от Аноним (129), 29-Дек-23, 23:15	+2 +/–
И что в нем прям очень неудачного? Мне кажется, одно лишь отсутствие нулевых указателей это эпик вин, не говоря о других удобных и полезных вещах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #85, #117

68. Сообщение от Аноним (129), 29-Дек-23, 23:17	+1 +/–
Мне кажется, про раст вы знаете чисто из комментариев на опеннете. Вместо ООП есть куда более удобные механизмы, синтаксис куда доканичнее и понятнее чем в плюсах, если сравнивать аналогичные конструкция.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #100, #141

70. Сообщение от Аноним (70), 29-Дек-23, 23:20	+4 +/–
Оказывается, здесь столько системных программистов, которых так заботит безопасность обращения к памяти на нулевом уровне ядра! Куда же делись прикладные программисты, которым ехать, а не шашечки?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80, #82, #91, #120, #232

72. Сообщение от Анонимусс (?), 29-Дек-23, 23:30	+1 +/–
>> для любого большого си проекта > Потому что С++ это не С. Прям Капитан Очевидность пожаловал. И? При чем тут с++? В ядре его нету. И не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #104

73. Сообщение от Аноним (39), 29-Дек-23, 23:31	+/–
Ну так внешнего анализатора и достаточно чтобы получить грубо говоря 90% преимуществ Раста и еще выловить баги которые и Раст никак не помогает предотвратить. И главное для этого не нужно менять свой основной язык, что для многих означает потерю работы. Уже есть коммерческие решения для MISRA, свободные как обычно будут с задержкой, в GCC процесс идет. Пока что можно пользоватся бесплатной версией PVS-Studio и аддоном MISRA для CppCheck. Глупо считать что Раст предлагает в этом что-то уникальное или новое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #96, #109

74. Сообщение от Аноним (74), 29-Дек-23, 23:36	+5 +/–
Какой же мерзкий синтаксис. Пока что самый адекватный синтаксис у конпиляемых "системных" языков - это Ada.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87, #88, #121, #284

75. Сообщение от Аноним (129), 29-Дек-23, 23:37	+/–
Откройте багтрек любой крупной программы на С или С++, либо новости об очередных учзвимостях. В топе ошибок - ошибки работы с памятью. Также 100% уверен, что проекты на С или С++ ловили в проде падения, из-за обращений к нулевым указателям. Не только С и С++, но и все где есть null. Пока в принципе есть такая возможность стрелять в себе в ноги, это будут делать, даже самые топовые разработчики.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #132, #254

77. Сообщение от commiethebeastie (ok), 29-Дек-23, 23:37	+/–
А смысл сравнивать стоимость рхел и венды?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

78. Сообщение от Аноним (12), 29-Дек-23, 23:39	+/–
Накидать ты то можешь, не сомневаюсь. А вот какие из них реально что-то гарантируют? Вот целая куча дыреней в OpenSSL/LibreSSL https://www.opennet.ru/opennews/art.shtml?num=58622 - чтение из области вне границ буфера - Use-after-free - двойное освобождение памяти - некорректное разыменование указателя - разыменование указателя NULL (x2) ну и еще одна логическая проблема, которая решается нормальными типами При этом ворнинги включены, оба проекта обмазаны санитайзерами по самое немогу - и memory, и thread, и еще куча других https://github.com/openssl/openssl/actions/runs/4124496105 Там даже фаззинг какой-то есть. И что? Помогли тебе анализаторы? Как тогда они смогли собрать практически полное булщит-бинго?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #84

79. Сообщение от Аноним (-), 29-Дек-23, 23:44	+/–
Да, нас все обманывают, но Аноним-39 расскажет правду! Если кто-то неоситор, то это не показатель
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

80. Сообщение от Аноним (80), 29-Дек-23, 23:45	–1 +/–
Прикладники ничего не знают про эти "вещи в себе". Вот например: > всю необходимую функциональность, не привязываясь к ядру ОС и системным библиотекам А как это чудо взаимодействует с железом? Как отправляет пакеты в сеть? Как записывает на диск? Как рисует на мониторе? Чует моё сердце, что создали очередной "виртуально-абстрактный гипервизор в контейнере" не имеющий никакого прикладного применения и рады до ушей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #135

81. Сообщение от Аноним (100), 29-Дек-23, 23:45	+3 +/–
А могли бы просто проверить статическим анализато... постой, да они же так и сделали, ахахаха!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

82. Сообщение от Анонин (?), 29-Дек-23, 23:45	+1 +/–
> которым ехать, а не шашечки Это те, которым говняк-говняк и в прод? Да куча их, посмотри выше по ветке))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

83. Сообщение от Аноним (-), 29-Дек-23, 23:49	+/–
Опыт гугла подойдет? security.googleblog.com/2021/04/rust-in-android-platform.html Расскахывают и про проблемы с/с++, и про сложности санитайзеров Результат через год security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language. Большую часть нового кода пишут не на с++, а на расте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #90

84. Сообщение от Аноним (100), 29-Дек-23, 23:49	+/–
Лол, да ты только потому знаешь об этих багах что их как раз выявили и пофиксили с помощью тех самых анализаторов. Л - логика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #89, #94

85. Сообщение от Аноним (85), 29-Дек-23, 23:50	+1 +/–
Чел, не ведись на троля. Если ты не в курсе, Витюшка - это знатный местный критик Раста, который не в зуб ногой ни в Расте, ни в C++. Он из темы в тему постит забористую дичь, причем повторяет одну и ту же чушь даже после того, как в предыдущей теме его ткнули носом в факты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #98

87. Сообщение от Аноним (91), 29-Дек-23, 23:52	–3 +/–
(Мысли вслух) Где же вас таких обучают, в каком ПТУ? Почему вам синтаксис дороже семантики?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #92

88. Сообщение от Аноним (100), 29-Дек-23, 23:53	+5 +/–
Я что-то после новостей про Паскаль по нему заностальгировал. Конечно, по нынешним меркам он многословный и фигурные скобки привычнее, но все же насколько по-человечески выглядит код! И да, Ада очень близка к нему, к тому же по-настоящему безопасна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #103

89. Сообщение от Аноним (12), 29-Дек-23, 23:54	+/–
1. Пруфы в студию. Ну, что именно эти баги были найдены именно санитайзерами. 2. Как этот код попал в кодовую базу, если бы санитайзер просто не пропустил бы PR? (вопрос риторический) ну и вопрос со звездочкой 3. Сколько лет эти дырени спокойненько жили в либах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

90. Сообщение от Аноним (85), 29-Дек-23, 23:54	+/–
РебятаБ не ведитесь на тролля. Он вам сейчас заведет свою старую шарманку о том, что в Расте нет безопасной работы с памятью, и вообще все его пользователи - некомпетентные дураки, не раскусившие заговор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #99, #133

91. Сообщение от Аноним (91), 29-Дек-23, 23:56	+/–
Почему-то под ехать ваша братия всю дорогу понимает недоязычки с нулевой гибкостью, "нюансы" которых нужно специально "изучать" (вместо изучения теории категорий, например), чтобы программа работала корректно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

92. Сообщение от Аноним (100), 29-Дек-23, 23:56	+4 +/–
А почему нужно обязательно налажать или в одном, или в другом? Почему бы и то, и другое не сделать нормально?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #95

94. Сообщение от Анонин (?), 29-Дек-23, 23:59	+/–
Вот хороший пример https://www.opennet.ru/opennews/art.shtml?num=59906 "Уязвимости в библиотеках X.Org, две из которых присутствуют с 1988 года" - выход за границы буфера - исчерпание стека при обработке специально оформленных данных - целочисленное переполнение приводящее к переполнению кучи - чтение из областей вне границ выделенной памяти Эти дыры старше половины посетителей опеннета)) Ой, как же их не замечали столько-то лет? Есть же так много прекрасно работающих инструментов для этого))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #106

95. Сообщение от Аноним (91), 29-Дек-23, 23:59	+/–
Потому что "нормально" не бывает. Синтаксис это на 90% вкусовщина. Это как выбирать компьютер по цвету системного блока. Блондиночный критерий. Синтаксис можно легко переделать (и языки с гибкой семантикой дают для этого лёгкую методу), а семантику без переписывания самого языка не переделать при всём желании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #101, #107, #173, #277

96. Сообщение от фнон (?), 30-Дек-23, 00:00	+/–
> Ну так внешнего анализатора и достаточно чтобы получить грубо говоря 90% преимуществ Раста Интересная цифра! А можно, хотя бы примерно, методику ее расчета? Пока похоже на "пальцем в небо". > и еще выловить баги которые и Раст никак не помогает предотвратить. А можно примеры? Если ты о фаззинге - то для раст тоже есть внешние инструменты. > И главное для этого не нужно менять свой основной язык, что для многих означает потерю работы. Вот скажу честно, мне плевать сколько бракоделов-неосиляторов пойдут работать дворниками. Они за 30 лет не научились память чистить не больше одного раза и за буфер не выходить, так что совершенно не жалко. Гугл за 2 месяца переучивает людей с Python, Java и Go, на Раст - без потери производительности. Если эти "профи" не могут выучить новый язык, то они просто плохие программисты. (То что они ʼне хотятʼ - в это я охотно поверю) > Пока что можно пользоватся бесплатной версией PVS-Studio и аддоном MISRA для CppCheck. Глупо считать что Раст предлагает в этом что-то уникальное или новое. Выше покащали пример, что куча санитайзеров работала... и не сработала. И на минуточку это криптография! opennet.ru/openforum/vsluhforumID3/132453.html#78
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #111

98. Сообщение от Аноним (100), 30-Дек-23, 00:01	–1 +/–
Витюшка пытался вкатится в программирование на Rust, задал тут невинный вопрос, так растоманы его вместо ответа обложили хренами с ног до головы. Достойно встретили новичка, что ни говори, вот у него теперь и аллергия на Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #105

99. Сообщение от Анонин (?), 30-Дек-23, 00:03	+/–
Подождите, это же тот зиганутый, который в двух темах рассказывал про то какой раст ненадежный, а вот Зиг!.. Он еще смайликами почти каждое свое сообщение метил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

100. Сообщение от Аноним (100), 30-Дек-23, 00:04	+/–
Вот поэтому те кто с ООП на короткой ноге в Раст ни ногой, у тех все чего нет "нинужно". Попиши без ООП большой проект, особенно математический - захлебнешся в лапше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #124, #175

101. Сообщение от Аноним (74), 30-Дек-23, 00:05	+1 +/–
> Синтаксис это на 90% вкусовщина. Всё что нужно знать о современных "IT специалистах" 👆
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #221

102. Сообщение от фнон (?), 30-Дек-23, 00:05	+3 +/–
Давай по новой, Витюшка, все фигня! (с) Ты опять пришел позориться своими "знаниями" в области Раст? В этот раз будешь заливать про зиг, свою уникальную задачу, когда "несколько потоков одновременно пользуют один кусок памяти" и прочие ламповые истории? Или ты, сегодня, придумал что-то новое?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #128

103. Сообщение от Аноним (74), 30-Дек-23, 00:08	+1 +/–
Ada, в отличии от паскаля, может в многопоточность и асинхронность. Хотя, вроде, в fpc что-то такое есть, но оно очень сырое и не_стандартизированное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #220

104. Сообщение от Аноним (100), 30-Дек-23, 00:08	–1 +/–
Будет Rust в ядре - будет и С++. Иначе будет неинклюзивно, а это нарушение CoC.md
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #115

105. Сообщение от фнон (?), 30-Дек-23, 00:08	+2 +/–
Неа, он пришел со словами ваш раст овно, а воот зиг и крабон огого! На вопрос "почему? что  тебя не получилось?", начал рассказывать чушь, которую можно развеять просто открыв документацию. > Достойно встретили новичка, что ни говори, вот у него теперь и аллергия на Rust. Минус конкурент)? С чего ты решил, что я хороший и добрый человек)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #122

106. Сообщение от Аноним (100), 30-Дек-23, 00:10	+/–
Вот также будут и в 2050 находить ошибки в немногочисленных легаси проектах на Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #110

107. Сообщение от Аноним (74), 30-Дек-23, 00:12	+/–
> Это как выбирать компьютер по цвету системного блока. Кстати, именно так и нужно выбирать. Лично для меня, тактильные и визуальные ощущения от устройства, гораздо важнее, чем подкапотное железо. Да и многим людям тоже, не зря у Apple столько ярых поклонников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #108

108. Сообщение от Аноним (74), 30-Дек-23, 00:13	+/–
П.с. если что, это был sarcasm ‼
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #113

109. Сообщение от Аноним (25), 30-Дек-23, 00:14	–1 +/–
> Уже есть коммерческие решения для MISRA соблюдение правил мисры не даёт никаких гарантий а гигантское ядро по ним написать шансов ноль > Глупо считать что Раст предлагает в этом что-то уникальное или новое он даёт гарантии и это по умолчанию - достаточно просто собрать прожект, назови если такой неглупый аналог для С. С тем же пивасом вспотеешь парсить логи и всё равно найдёшь только незначительную часть ошибок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #112

110. Сообщение от Анонин (?), 30-Дек-23, 00:16	+/–
Будут находить именно use-after-free, buffer-overrun и тд?))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #114

111. Сообщение от Аноним (100), 30-Дек-23, 00:17	+/–
Ты сначала посмотри на количество вакансий для разработчиков на Rust, а потом рассуждай тут про дворников. А то может оказатся что для любителя Раста совмещать работу дворника с домашним проектом на любимом языке может оказатся еще не самым плохим вариантом )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #123

112. Сообщение от Аноним (100), 30-Дек-23, 00:23	+1 +/–
Раст дает гарантии только по ограниченному классу ошибок, остальные лови ручками как и в любом другом языке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #190

113. Сообщение от Аноним (100), 30-Дек-23, 00:26	+1 +/–
Думал сарказм, а оказалось правдой. У растоманов так бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

114. Сообщение от Аноним (100), 30-Дек-23, 00:40	+/–
А что, баги в программах перечисленными категориями исчерпываются? ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #125

115. Сообщение от Анонимусс (?), 30-Дек-23, 00:43	+/–
Раст в ядре с версии 6.1. Сейчас версия 6.7-rc7. Ну и где там С++?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

116. Сообщение от Аноним (129), 30-Дек-23, 01:11	+/–
Если за пару десятилетий люди так и не научились писать без таких ошибок, значит никогда не научатся и это by design своцство языка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #151

117. Сообщение от Витюшка (?), 30-Дек-23, 01:15	–2 +/–
Отсутствие нулевых указателей также есть и в Zig. Это большой win, как ты сказал. Но в C++ это делается буквально парой строчек. Пользовательский тип, который инкапсулирует сырой указатель, пара переопределенных операторов, move конструкторы и готово. Проверяй в конструкторе что указатель не null.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #126

118. Сообщение от Аноним (129), 30-Дек-23, 01:15	+/–
Да, я больше про использование памяти после освобождения,  либо же забыть освободить память и получить утечку. Это прям регулярная проблема в софте на С и С++. Языки со сборкой мусора или моделью как в rust доказывают, что такая проблема реальная и что она достаточно большая,  чтобы ее решали люди и другие люди с удовольствием пользовались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

120. Сообщение от Аноним (129), 30-Дек-23, 01:20	+/–
Я тут. Помимо безопасной работы с памятью без сборщика мусора, там есть еще много удобных zero-cost абстракций и нет проблем с нулевыми указателями, которые регулярно всплыывют и на c++, и в go и в питоне и в jvm языках и в других. Также модель, по которой происходит работа с памятью прекрасно работает и с другими ресурсами, как параллельность или же забыть освободить какой-то mutex.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #137

121. Сообщение от Аноним (129), 30-Дек-23, 01:22	+1 +/–
А что конкретно не так с ним? Как такие же абстракции более лаконично и понятно описывать? Обычно, это пишут только те, кто не разобрался в языке и не писал на нем, а знает только из новостей и комментариев про то какой же ужасный синтаксис.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #149

122. Сообщение от Витюшка (?), 30-Дек-23, 01:24	–3 +/–
Да ты не переживай, ты мне не конкурент. Про Carbon я вообще ничего не говорил. Это как Rust, да получше, но не настолько чтобы на него переписывать код, если это не Hello World. Ну у Google денег много, они могут баловаться. А там где я что-то в документации недоглядел. Так я признаю. Какой же я тролль. Принципиально это сути, конечно, не меняет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #171

123. Сообщение от Анонимусс (?), 30-Дек-23, 01:25	+/–
Количество вакансий просто убийственный аргумент))) А ведь JSников и пыхеров еще больше чем сишников...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

124. Сообщение от Аноним (129), 30-Дек-23, 01:26	+2 +/–
Я писал на java  и на python, давно когда-то на C++, но композиция и интерфейсы как в go или rust (особенно в rust, по сравнению с go) удобнее и лаконичнее, нежели ООП и прекрасно работают и в масштабных проектах. Математические библиотеки прекрасно себя чувствует и пишутся на rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #196

125. Сообщение от Анонин (?), 30-Дек-23, 01:27	+/–
Нет конечно. Но тут кто-то считал, что для CVE - 70% проблемы с памятью. И в это охотно верится. И исключение - огромный плюс к безопасности. А баги в логике будут любых языках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

126. Сообщение от Аноним (129), 30-Дек-23, 01:31	+1 +/–
Это разные вещи - принципиально не выразимо или же можно сделать если очень захотеть и другие будут тоже правильно делать. Rust не единственный язык, который отказался от null, но он самый популярный и развитый из онных
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #139

128. Сообщение от Витюшка (?), 30-Дек-23, 01:36	–1 +/–
Есть кое-что поинтереснее и посвежее. Есть код мьютекса (спинлока). Естественно это суперкритичный к качеству и надёжности код. Естественно написан на Rust. Докажи, пожалуйста, с помощью Rust (который безопасный по памяти и гонкам данных!) что этот код: 1. Действительно даёт mutual exclusion доступ к критической секции (т.е. работает корректно) 2. Является deadlock-free 3. Является starvation-free А то у вас одни hello world только безопасные 😀 Надо на реальных примерах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #131

129. Сообщение от Аноним (129), 30-Дек-23, 01:36	+/–
Как минимум, ошибки обращения к освобожденной памяти, или же ошибки не вызова free или де падения от обращения по нулевому указателю не нужно решать и дебажить как класс. Это регулярные ошибки или уязвимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #147, #191

130. Сообщение от Аноним (129), 30-Дек-23, 01:43	+/–
Проблемы с управлением памятью есть, это подтверждает наличие языков со сборкой мусора, которые появились очень давно. Не было бы проблемы с управлением памятью,  никто бы не создавал такие языки и они бы не были популярными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

131. Сообщение от Аноним (129), 30-Дек-23, 01:46	–1 +/–
А открыть и прочитать тот же rustbook не судьба?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #136, #146

132. Сообщение от Витюшка (?), 30-Дек-23, 01:48	+/–
Я открыл крупный проект на Rust. А что это у нас тут такое по тегу safety? https://github.com/servo/servo/issues/25726 https://github.com/servo/servo/issues/19870 Что это тут у нас? 😨 Гонки данных??? https://github.com/servo/servo/issues/21186 Так Rust же не позволяет гонки данных в compile time???
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #134

133. Сообщение от Витюшка (?), 30-Дек-23, 01:51	+/–
Ты лучше ответь выше про гонки данных. Их же в Rust нет благодаря borrow checker, все ловятся в compile time. И про мьютекс)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

134. Сообщение от Аноним (129), 30-Дек-23, 01:55	+/–
где там: - использование памяти после free - забыли освободить память - паденич из-за обращения к null указателю ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #142

135. Сообщение от Витюшка (?), 30-Дек-23, 01:58	+/–
Операционная система и есть библиотека. А исполняться оно должно в виртуальной машине на виртуальном процессоре, считай аналог голого железа. А не в контейнере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

136. Сообщение от Витюшка (?), 30-Дек-23, 02:07	+1 +/–
Это не ответ (и почему-то я на 100% уверен что там такого нет). Но ты не сливайся так сразу. Ты сюда пиши))) Я жду ответа от Rust гуру. Вы должны защитить поруганную честь и достоинство этого языка. Всё таки упор на безопасность!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #163, #172

137. Сообщение от Витюшка (?), 30-Дек-23, 02:09	–2 +/–
Отлично! Я тебя нашёл. Да что там освобождение мьютекса! Давай хотя бы сначала попробуем написать мьютекс безопасный на Rust! Есть код мьютекса (спинлока). Естественно это суперкритичный к качеству и надёжности код. Естественно написан на Rust. Докажи, пожалуйста, с помощью Rust (который безопасный по памяти и гонкам данных!) что этот код: 1. Действительно даёт mutual exclusion доступ к критической секции (т.е. работает корректно) 2. Является deadlock-free 3. Является starvation-free
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #160, #167, #176

138. Сообщение от Аноним (10), 30-Дек-23, 02:12	–1 +/–
Ага, 9 женщин родят ребёнка через месяц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #150

139. Сообщение от Витюшка (?), 30-Дек-23, 02:17	–1 +/–
А потом говорят что это я Rust не знаю? Вы сами то его знаете, программисты на Rust? Всё там прекрасно принципиально выразимо. И никаких гарантий что какой-то кривожоп не понапишет race conditions которые десятками лет отлавливать будешь потом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #162

141. Сообщение от Аноним (10), 30-Дек-23, 02:25	+3 +/–
Вы отождествляете ООП и синтаксис конкретной реализации (C++)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

142. Сообщение от Витюшка (?), 30-Дек-23, 02:29	+/–
Use after free открытый с 2018 года https://github.com/servo/servo/issues/21459 https://github.com/servo/servo/issues/27473
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #168, #181

143. Сообщение от Вы забыли заполнить поле Name (?), 30-Дек-23, 04:23	+/–
> описывается негативный опыт использования Раста и уход с него на другие языки. Не ради тролинга можно ссылки на статьи?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #157

144. Сообщение от Вы забыли заполнить поле Name (?), 30-Дек-23, 04:29	+/–
> Уже не один проект он него отказался, хотя явно там фанатики были. Тащили до конца, но не вышло. Можно ссылки, что за проекты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #158

146. Сообщение от Аноним (146), 30-Дек-23, 06:34	+/–
В гугл я тоже посылать умею. Слив защитан.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #156, #165

147. Сообщение от Аноним (147), 30-Дек-23, 07:45	+/–
Замечательно. Только существует множество инструментов для C и C++ которые помогают устранить этот класс ошибок и без Раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #178

148. Сообщение от Аноним (148), 30-Дек-23, 08:03	+/–
Большая база в датасете формируется датасатанистом. Поэтому чего там будет больше ты знать не можешь. А если просто тупо скормить гитхаб/гитлаб то больше там будет яваскрипта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

149. Сообщение от Аноним (147), 30-Дек-23, 08:05	+1 +/–
Ага, программист должен иметь минимум три года опыта разработки на Rust чтобы оценивать качество его синтаксиса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #154, #177

150. Сообщение от Аноним (148), 30-Дек-23, 08:09	+3 +/–
Ага, ведь ядро это 1 большой файл на С 😂
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

151. Сообщение от Аноним (147), 30-Дек-23, 08:12	+/–
Если за пару десятилетий люди так и не научились писать без таких ошибок, то им и Раст не поможет, только запрет на профдеятельность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #169

152. Сообщение от Аноним (147), 30-Дек-23, 08:22	+1 +/–
Больше всего радует, что на волне всего этого хайпа вокруг memory safety наконец-то начали шевелится разработчики C и C++. Глядишь, наконец-то ограничат возможность прострелить себе ногу хотя бы в дефолтном окружении.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #153

153. Сообщение от An (??), 30-Дек-23, 09:32	+/–
А что за "шевеления"? Особенно в контексте C интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #159

154. Сообщение от Аноним (223), 30-Дек-23, 10:26	+1 +/–
Не обязательно три. Только когда начнёшь осознавать концепции и почему так сделано. Если хочется больше сахара - можно намазать макросов. Тут просто многие синтаксические вещи сделаны по-другому. И практика показывает, что плюсы начинают пытаться это повторять потому что так удобнее (типа явного self)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #203

156. Сообщение от Витюшка (?), 30-Дек-23, 10:55	+/–
Ответ - никак. Твой Rust ни черта этого не умеет. В книге The Art of Multiprocessing Programming корректность доказывается с помощью построения логических теорем, с доказательством на листочке. По индукции или методом от противного. На листочке, ручками! Это самые сложные, самые частые ошибки, самые опасные. И где твой хвалёный Rust? Где твоя защита? Где твой borrow checker? Если вы даже мьютекс не можете написать безопасный?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

157. Сообщение от Витюшка (?), 30-Дек-23, 11:15	+/–
https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-... Пока искал эту статью наткнулся на https://github.com/codic12/worm. Был написан на Rust, переписан на Nim. Помню такие примеры, но где именно попадались и про что там не вспомню. Вот ещё https://news.ycombinator.com/item?id=21967668 > I used to do this in Rust but I switched to zig for maintainability and readability over Rust Конечно это вообще прям хобби проект. Но ценность не в этом. А в том что у них была полная свобода в выборе языка, они любили и выбирали Rust, потом вынужденно, но добровольно, отказывались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #164

158. Сообщение от Витюшка (?), 30-Дек-23, 11:19	+/–
Я выше в соседней ветке подробно ответил. https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-... Помню больше, конечно, но найти не смогу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #174

159. Сообщение от Витюшка (?), 30-Дек-23, 11:23	+/–
Есть proposal чтобы добавить defer. Те какие-то попытки есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #161, #166

160. Сообщение от Аноним (12), 30-Дек-23, 11:27	+1 +/–
Напиши такой мьютекс на "безопасном" зиге. Он же лучше и безопаснее раста, правда ведь?) Давай, ты же такой крутой погромист. Ну и нас повеселишь заодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #195

161. Сообщение от фнон (?), 30-Дек-23, 11:34	+/–
Коммитет обсудит это лет 3-5, потом добавят в стандарт, через 10-15 лет попадет в ядро
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

162. Сообщение от Аноним (162), 30-Дек-23, 11:34	+/–
Мы же обсуждали прлблему нулевых указателей. Тут вам возразить нечем и соскакиваете с темы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #183

163. Сообщение от Аноним (162), 30-Дек-23, 11:37	+/–
Зачем мне в комментариях цитировать то что и так описано в книге, а чтобы грамотно по полочкам разложить, это минимум пост нужно писать, а не комментарий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #207

164. Сообщение от Аноним (12), 30-Дек-23, 11:39	–1 +/–
Ну, есть пример пары неосиляторов. Они пытались писать на расте как на и си, и чсх у них это не получилось. Поэтому они перешли на более сишные язычки. Но как частный случай может быть доказательством чего либо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

165. Сообщение от Аноним (162), 30-Дек-23, 11:42	+/–
В комментариях не уместит нормальное объяснение. А если пытаешься, то в ответ "гы гы, какой же раст безопасный, если я в пару строчек могу сделать утечку памяти", хотя безопасность языка она исключении других ошибк. Аналогично и с другим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #185

166. Сообщение от Анонин (?), 30-Дек-23, 11:46	+/–
Этот proposal маринутеся еще с 2020 года (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2542.pdf) В конце 2021 вышла вторая его версия https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm И если бы его таки добавали, то в C23... в который он уже не попал))) И в следующий тоже. Так что пока нет никаких предпосылок к его принятию. Вообще на уровне ядра могли бы свой самописный defer сделать. Или сделать на уровне GNU C Extensions.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #179, #222

167. Сообщение от фнон (?), 30-Дек-23, 11:55	+/–
Пук в лужу конечно знатный, но как троллинг унылый. Ты лучше скажи так: "Вот пример deadlock-free и starvation-free мьютекса, написанный на языке N, для которого это все доказано! Он используется в проекте М и дает ему непревзойденную надежность. Сможете так же на Раст сделать? " А то пока это теоретическое балабольство, зато на умную книжку сослался (ты ее вообще читал?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #198

168. Сообщение от Аноним (162), 30-Дек-23, 11:56	+/–
Вы тупо гуглите по ключевым словам без понимания сути issue?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

169. Сообщение от Аноним (162), 30-Дек-23, 11:58	+/–
Значит закрываем программирование, потому что такие ошибки были и периодически появляются практически во всех крупных и средних проектах. И никто так и не научился за десятилетия не допускать ошибок в программировании. Правда, в языках со сборщиком мусора или моделью как в rust таких проблем нет в принципе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

170. Сообщение от Аноним (-), 30-Дек-23, 12:09	+2 +/–
>Применение "-C codegen-units=1" при сборке Android позволило снизить размер инструментария на 5.5% и увеличить его производительность на 1.8%, при этом время сборки самого инструментария увеличилось почти в два раза. Размер меньше, а время сборки медленей. >были применены оптимизации при помощи утилиты BOLT, которые позволили довести прирост скорости сборки до 24.7%, но размер инструментария при этом вырос на 10.9%. Размер чуть больше, а время сборки быстрее. Хм ... не, я лучше посижу на чистой сишке.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #186, #226

171. Сообщение от Анонин (?), 30-Дек-23, 12:17	+1 +/–
> А там где я что-то в документации недоглядел. > Принципиально это сути, конечно, не меняет. Ахахаха! Но вообще ты прав, в твоем случае это принципиально ничего не меняет))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

172. Сообщение от Анонин (?), 30-Дек-23, 12:27	+/–
Чувак, уж кому-кому, а тебе мы точно ничего не должны)) Нам про раст уже ничего доказывать не нужно. Более того, если ты думаешь, что твои жиденькие набросы могут хоть как-то задеть "честь и достоинство этого языка"... то лучше обратиться к профильному специалисту и полечить свое самомнение и проблему одушевления предметов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

173. Сообщение от Аноним (-), 30-Дек-23, 12:38	+/–
Кто не понял, поясню синтаксис - это грубо говоря набор "Literal" или "слов". Чем их количество меньше и сами слова интуитивно понятны, тем читабельность лучше. А семантика должна придавать набору ключевых слов и имён переменных общий логический смысл. И этот общий смысл слов необязательно может быть быстро понят программистом, который переходит на другой язык программирования. >Синтаксис это на 90% вкусовщина. Согласен. Но давайте вглянем на Раст глазами чистосишника. Раст обладает развитым синтаксисом, что само по себе подразумевает мощный семантический аппарат. И всё это нагромождение "Literal" воспринимается как "наркоманский синтаксис". Если Раст учит человек никогда не программировавший, то восприятие "наркоманского синтаксиса" не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #275

174. Сообщение от Аноним (1), 30-Дек-23, 12:55	+/–
Ну так уже 24 год на дворе, раст 5 лет назад был не тот, что сейчас. Мне бы хотелось линк сего года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #180

175. Сообщение от DEF (?), 30-Дек-23, 12:57	+/–
В математических проектах ООП ненужно вообще. Julia использует ФП и множественную диспетчеризацию, которая гораздо мощнее и лучше, чем ООП.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

176. Сообщение от Аноним (162), 30-Дек-23, 13:00	+/–
Я так понимаю, все преимущества, такие как безопасность работы с памятью, zero cost абстракции, отсутствие null по сравнению с С/С++ вы игнорируете и все сводите к одному вопросу? Который, по сравнению с теми же плюсами куда проще решается на rust. С точки зрения использования абстракций, на прикладном уровне, тут rust переиспользует модель работы с памятью и следит на уровне компиляции, что если был взят, например lock, то он обязательно будет освобожден. В том же go периодически всплывают ошибки, что забыли прописать defer для лока и такое, естественно,  потом дебажится в рантайме. Rust не священный грааль, но определенный класс проблем и ошибок там отлавливается на уровне компиляции, а не в рантайме. Как-то детальнее описывать, как компилятор помогает избегать множественного владения и облегчает написание параллельного кода не буду, потому что требует обяснить много деталей и написать много текста, чего случайные комментаторы на опеннет не достойны. Тем более что потом закончится все "а докажи теперь это все с помощью формальной верификации"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #206

177. Сообщение от Аноним (162), 30-Дек-23, 13:01	+2 +/–
Достаточно осилить rustbook, который большинство критиков синтаксиса даже не открывали дальле первой странички, чтобы большинство вопросов к синтаксису отпало
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

178. Сообщение от Прохожий (??), 30-Дек-23, 13:09	+/–
Замечательно. Только этими инструментами или не пользуются (они ведь опциональны), или они находят далеко не все классы таких ошибок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #182

179. Сообщение от Аноним (10), 30-Дек-23, 13:17	+1 +/–
>Или сделать на уровне GNU C Extensions. На уровне GNU Extensions можно много чего добавить. Например, MISRA можно было бы, -fmisra. Сразу все требования, понимаю, трудновато реализовать, но можно постепенно добавлять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

180. Сообщение от Аноним (162), 30-Дек-23, 13:20	+/–
Типичное когнитивное искажение, когда человек ищет по ключевым словам подтверждения своих убеждений, а что с этим не соотносится- просто игнорирует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174

181. Сообщение от Советский инженер (ok), 30-Дек-23, 13:28	+/–
>https://github.com/servo/servo/issues/21459 This testcase is crashing during the final GC when the JSContext is being destroyed. И на чем же этот GC & JSContext написаны? не на С++ случайно? очередной обчирон от витюши 🤷‍♂️
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #189, #194, #199

182. Сообщение от Витюшка (?), 30-Дек-23, 13:54	+1 +/–
А что, Rust находит все классы ошибок? Я вот выше и ниже задавал вопрос про мьютексы. Ответь на него, пожалуйста. Напиши так, чтобы в Rust ошибки многопоточного программирования не проявлялись. А то оказывается что Rust не может гарантировать даже самые базовые банальные вещи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #209

183. Сообщение от Витюшка (?), 30-Дек-23, 13:58	+/–
Нет, это замечательно. Эта ошибка которая должна быть исправлена в новом языке. Я только это приветствую. Речь то не об этом была.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

184. Сообщение от Аноним (184), 30-Дек-23, 14:00	+/–
> Проще воспользоватся инструментами вроде cppcheck или другими статическими анализаторами Гугл утверждает что это (и не только это) слабо помогает их андоидовским (и не только) си/плюсовым проектам. А вот задействование раста взамен си/плюсов в новых системных компонентах помогает просто ошеломительно: https://security.googleblog.com/2022/12/memory-safe-language... В этом вопросе я больше гуглу поверю, чем тебе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #243

185. Сообщение от Витюшка (?), 30-Дек-23, 14:09	–1 +/–
Многопоточное программирование сейчас абсолютно везде, даже в роутерах домашних, на мобилках, десктопах, лэптопах, серверах. Это самый критичный код, потому что отловить его в тестах вообще невозможно. Заметить тоже - никто тебе никакой exception не кинет. Тихонько перезапишет память и всё. А выходы за границы массивов и 90% что умеет Rust можно и в C++ сделать. В принципе это прям банальные вещи, их в runtime можно и нужно ловить. Автор книги The Art of Multiprocessing programming - это основоположник lock free алгоритмов, гуру, эксперт мирового уровня. И я не вижу как Rust хоть как-то решает проблему многопоточного программирования и особенно lock free алгоритмов. И ещё ни один специалист здесь ни разу не смог ответить на мои вопросы. В основном хиханьки да хаханьки в стиле "сам дурак" и "всё в Rust book написано"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

186. Сообщение от fyjy (?), 30-Дек-23, 14:16	+/–
Звучит логично. Или программа использует меньше памяти, или работает быстрее. Обычная задачка на оптимизацию алгоритмов. Было бы интересно услышать "гуру чистой сишки", как реализовать одновременно "быстрее и меньше памяти"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #242, #280

187. Сообщение от Аноним (187), 30-Дек-23, 14:17	+/–
Ща закон примут и все мигом начнут писать без ошибок. А пока всё "AS IS", никакие безопасТные языки от тотальной безоТвеТсТвенносТи в профессии не помогут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

188. Сообщение от Аноним (188), 30-Дек-23, 14:36	+/–
>В каком году в ядре начали использовать С11 вместо уже окаменевшего C99? Такого события не было - C11 начали использовать вместо окаменевшего C89.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #216

189. Сообщение от Аноним (162), 30-Дек-23, 15:37	+/–
Там по трейсу видно что корень проблемы идет в c++, над которой уже идет обвязка к rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

190. Сообщение от Аноним (184), 30-Дек-23, 15:47	+/–
только этот ограниченный класс составляет 70% ошибок, причем многие из них - критические, позволяющие хакнуть программу/систему. Можно сформулировать и так - подавляющее большинство ошибок, которые являются критическими и позволяют взломать систему и получить над ней контроль - как раз из этого самого "ограниченного класса ошибок".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

191. Сообщение от C00l_ni66a (ok), 30-Дек-23, 16:47	+/–
>ошибки не вызова free Не туда воюешь, "Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

192. Сообщение от C00l_ni66a (ok), 30-Дек-23, 16:51	+/–
Да, также как и нередко встречаются те, кто использует санитайзеры и прочие анализаторы при написании на безопастном. Зачем, если "всемогущий компилятор" даёт "гарантии"? Вопрос риторический.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #213

194. Сообщение от Витюшка (?), 30-Дек-23, 16:51	–2 +/–
То Раст безопасный, то теперь оказывается нет))) А какая разница что там внизу вызывается? Я даже не хочу углубляться на набросы про С++. Обвязка то должна быть безопасной? Ради этого же всё делалось? Или вы не можете написать безопасную обвязку над "небезопасными" языками - те ради чего вообще создавался Раст?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #230, #250

195. Сообщение от Витюшка (?), 30-Дек-23, 16:52	+/–
Так я и написал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #202

196. Сообщение от C00l_ni66a (ok), 30-Дек-23, 16:59	+/–
>Я писал на java  и на python, давно когда-то на C++ Я писал секретный проект CIA на расте в 200kk LOC, переписал на него целиком ядро winglows (тоже секретный проект, так что сурсов не будет) и "композиция и интерфейсы" там менее "удобны и лаконичны", чем в NASM. Математические библиотеки на расте - анъюзабл булщыт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

197. Сообщение от fyjy (?), 30-Дек-23, 16:59	+/–
Потому что опенсорс - это про NIH, велосипедостроение и 'фигня какая-то, я точно лучше сделаю'. Так всегда было, независимо от языков программирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #229

198. Сообщение от Витюшка (?), 30-Дек-23, 17:01	+/–
Тебя просят написать простой алгоритм на Раст, с доказательством корректности (20 строчек кода!!!!). Ну что может быть проще? Какая разница применяется он где-то или нет? Сам код есть (Filter lock), доказательство корректности тоже. Перепиши на безопасном Раст и покажи что Раст гарантирует корректную работу мьютекса. Но нееееет.... Типичный программист на Раст ни ... не знает ни алгоритмы, ни математику, ни многопоточное программирование, ни структуры данных, ни lock free. Вообще ничего не знает, но ходит и кричит про безопасный Раст, не разбираясь, естественно в безопасности и корректности программ тоже. Такой, типичный Шариков. Который не может написать 20 строчек кода!!!! И показать что они будут работать корректно. Давай я пишу на Zig и доказываю корректность,а ты на Rust и доказываешь корректность с помощью borrow checker?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #205

199. Сообщение от C00l_ni66a (ok), 30-Дек-23, 17:02	+/–
То есть безопастный использует нибищапащные либы на клятi сикрестах???? Не может такого быть! Почаще в лефтпады заглядывай и смотри, сколько там ансейфов, бтв.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #231

202. Сообщение от fyjy (?), 30-Дек-23, 17:11	+/–
> Так я и написал Так я тоже написал! Супер мьютекс на раст, но код я показать не могу - он секретный по заказу марсиан. Может ты свой покажешь)? А то балаболить и фантазировать все умеют
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

203. Сообщение от C00l_ni66a (ok), 30-Дек-23, 17:13	–1 +/–
>Если хочется больше сахара - можно намазать макросов. У растовиков и без "сахара" - сплошной коричневый слой макросов по проектам всегда размазан. Плата за отрицательную выразительность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154

205. Сообщение от Аноним (-), 30-Дек-23, 17:16	+/–
> Типичный программист на Раст ни ... не знает ни алгоритмы, ни математику, > ни многопоточное программирование, ни структуры данных, ни lock free. Вообще ничего > не знает, но ходит и кричит про безопасный Раст, не разбираясь, естественно в безопасности и корректности программ тоже. Написал человек который даже доку не читад /_- > Такой, типичный Шариков. Который не может написать 20 строчек кода!!!! И показать  что они будут работать корректно. Это было типа "на слабо"? Да кто ж так троллит?! Ты просто жалок!! > Давай я пишу на Zig и доказываю корректность,а ты на Rust и доказываешь корректность с помощью borrow checker? Хм, даже инетересно как ты корректность докажешь. Только не на бумажке, на ней и для ассемблера можно сделать. Пусть Зиг тебе ее автоматичекси выведет. Ну давай валяй, показывай свое творение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #210

206. Сообщение от Витюшка (?), 30-Дек-23, 17:18	+/–
Ясно, как обычно. Когда дело доходит до конкретного вопроса или просьбы написать 20 строк кода... программисты на Раст либо съезжают с темы, либо начинают разглагольствовать про "сводите к одному вопросу". А написать 20 строк безопасного кода на Раст не могут. В принципе это всё что нужно знать про Раст, его безопасность и программистов его проповедующих. Готов написать на Zig, ты на Раст. Я доказываю корректность кода на листочке, потому что по-другому не умею и не знаю как, ты доказываешь корректность (20 строк кода!) с помощью гарантий Раст - borrow checker, владение, типы... в общем извращайся как хочешь. Но с помощью самого компилятора. По рукам? Или как всегда...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #212

207. Сообщение от C00l_ni66a (ok), 30-Дек-23, 17:19	+/–
>Зачем мне в комментариях цитировать то что и так описано в книге Чтобы показать, что это действительно есть в книге, а не является плодом больного воображения анонима.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

209. Сообщение от Аноним (12), 30-Дек-23, 17:50	–1 +/–
Окстись уже. Зачем ты задаешь тупые вопросы? Раст не находит все классы ошибок. Он предотвращает именно те, для которых был сделан и они прекрасно описаны в документации. Самый большой класс проблем с владением. А все остальные он не предотвращает. Ну вот как можно быть таким... недалеким? Открой уже доку и прочитай наконец!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

210. Сообщение от Витюшка (?), 30-Дек-23, 17:53	+/–
Если основоположник lock free алгоритмов доказывает их "на бумажке", то я буду делать также)) Наверное в безопасном коде он разбирается гораздо лучше чем 99,999999% программистов на Раст. Да и вообще любых программистов в мире. Я же не бегаю и не кричу о безопасном Zig, который избегает гонок данных, имеет безопасную работу с памятью и т.п. Вы же кричите об этом на каждом шагу. Так покажите на практике эту безопасную работу, как она поможет в написании алгоритма в 20 строчек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #211, #215

211. Сообщение от Аноним (211), 30-Дек-23, 17:59	+/–
> Так покажите на практике эту безопасную работу, как она поможет в написании алгоритма в 20 строчек. Т.е просто слился? банально(( Я думал ты будешь кидать сюда куски своего кода и показывать свое превосходство над "незнакомыми анонимами в интернете", а ты только языком мести можешь(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

212. Сообщение от Аноним (211), 30-Дек-23, 18:00	+/–
А давай! Кидай сюда свой зигокод, а я кину на раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #218, #239, #241

213. Сообщение от Витюшка (?), 30-Дек-23, 18:02	+/–
Это слишком сложные вопросы для. Разве они понимают что такое компилятор, что он в принципе может и нет? Для них это такая магический чёрный ящик, который делает "хорошо и безопасно" каким-то образом. Каким разбираться не обязательно 😀
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #217

215. Сообщение от Аноним (12), 30-Дек-23, 18:02	+/–
> Я же не бегаю и не кричу о безопасном Zig, который избегает гонок данных Ты при этом сам придумал, что Раст полностью позволяет избегать гонок и докапываешься до всех "А докажите коррекность с помощью раста!!11", хотя он это не гарантирует. Почитаей уже доку! Вот тебе цитата с Rustonomicon: "Safe Rust guarantees an absence of data races, which are defined as:     two or more threads concurrently accessing a location of memory     one or more of them is a write     one or more of them is unsynchronized" ВСЁ! Не больше и не меньше! (Хотя это не так мало, зигушка и в это не может...) То что ты нафантазировал - твои личные проблемы. "Data races are mostly prevented through Rust's ownership system: it's impossible to alias a mutable reference, so it's impossible to perform a data race. Interior mutability makes this more complicated, which is largely why we have the Send and Sync traits. However Rust does not prevent general race conditions." https://doc.rust-lang.org/nomicon/races.html При этом все что оно гарантирется - гарантируется автоматически! А что не гарантируется, то можно доказать на бумажке. И будет абсолютно тоже самое. Ну, если конечно не накосичишь в расчетах, ты же не мировое светило по мультитредингу...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

216. Сообщение от Аноним (10), 30-Дек-23, 18:09	+/–
>вместо окаменевшего C89 for (int i=0; .... вроде бы, уже очень давно можно было писать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

217. Сообщение от Аноним (-), 30-Дек-23, 18:38	+/–
> Это слишком сложные вопросы для. Разве они понимают что такое компилятор, что > он в принципе может и нет? А эти 'Они' с тобой сейчас в одной комнате? Как ты можешь знать, что они понимают, что нет? > Для них это такая магический чёрный ящик, который делает "хорошо и безопасно" каким-то образом. Не исключаю, что если они, как и ты, не читали документацию, то для них это 'магия и черный ящик' > Каким разбираться не обязательно 😀 Ну ты не разбираешься, доку не читаешь, зато с умным видом рассуждаешь) Хорошо что ты на зиг пишешь, мне хоть за колегу не стыдно :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

218. Сообщение от Витюшка (?), 30-Дек-23, 19:48	+/–
Наконец-то первый программист на Rust, осиливший 20 строк кода. Уважаю 💪 Сейчас до компьютера дойду. Будем писать очень простой, но корректный, мьютекс для двух статичных потоков - алгоритм Питерсона (Peterson lock). Доказательство корректности моего кода - практически напрямую следует из доказательства в книге The Art Multiprocessing programming. Я буду ждать доказательства на Rust на borrow checker. То что ты сможешь написать 20 строк кода я не сомневаюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #240

220. Сообщение от _ (??), 30-Дек-23, 19:51	+/–
fpc - сам себе стандарт. В стандартном Pascal даже классов нет. И кстати он (fpc) - неплох. К нему даже Lazarus сделали :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

221. Сообщение от JB (??), 30-Дек-23, 20:43	+/–
Мне кажется, вы поспешили обозвать его специалистом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

222. Сообщение от Аноним (25), 30-Дек-23, 21:05	+/–
> на уровне ядра могли бы свой самописный defer сделать в ядре есть автоматическое управление ресурсами устройств https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

223. Сообщение от Аноним (223), 30-Дек-23, 21:06	+/–
cve по сути критические ошибки. те это только усиливает мою мысль. если конпелятор находит больше ошибок за тебя, то и соотвественно дебажить и тестировать тоже меньше. простая логика. >С++ и Zig тоже устраняют эти классы ошибок почему тогда и плюсовом коды тоже постоянно кучу дыр находят?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

226. Сообщение от Аноним (226), 30-Дек-23, 21:56	–2 +/–
>были применены оптимизации при помощи утилиты BOLT И тут же рядом фанатики Раста пишут, что у них все утилиты в одном компиляторе в отличии от ненавистной им Сишки. Сравнивать они естественно будут с output ванильного компилятора Си, без сторонних оптимизаций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

229. Сообщение от _ (??), 30-Дек-23, 23:06	+/–
Как будто что то плохое ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #278

230. Сообщение от Аноним (230), 30-Дек-23, 23:09	+/–
Ну так обвязка, несмотря на использование unsafe безопасна. Она запаниковала в рантайме, вместо того чтобы молчаливо обращаться к памяти, к которой не должна. В safe части языка такое не скомпилируется даже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

231. Сообщение от Аноним (230), 30-Дек-23, 23:12	+/–
И в чем противоречие использовать обвязки к либам на плюсах? В rust unsafe очень лимитированы, по сравнению со всей кодовой базой, да и unsafe не отключает всех проверок. В C++ в unsafe всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #246

232. Сообщение от _ (??), 30-Дек-23, 23:13	+/–
>Куда же делись прикладные программисты, которым ехать, а не шашечки? Прикладные уже давно не пишут на С. На С++ не так давно - но тоже редкость. На расте писать они не будут тоже, это уже видно. Иди ко ты в топик где обсуждают Java, JS\TS, Python и прочую жесть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #285

235. Сообщение от Аноним (235), 31-Дек-23, 00:01	+/–
Жаль, что времени этого не будет? )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

239. Сообщение от OpenEcho (?), 31-Дек-23, 02:47	+/–
> А давай! > Кидай сюда свой зигокод, а я кину на раст. А вы мужики молодцы! (без прикола) К шоу готов: 🍿🍿🍿
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

240. Сообщение от OpenEcho (?), 31-Дек-23, 02:50	+/–
> Наконец-то первый программист на Rust, осиливший 20 строк кода. Уважаю 💪 Если вы не будете друг друга прикалывать, то из этого может что то получиться, что интересно почитать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

241. Сообщение от Витюшка (?), 31-Дек-23, 10:29	+/–
Мой вариант. https://gist.github.com/likern/9df0d97b3551236b456716d95f282f83 Жду твоего :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #244

242. Сообщение от Аноним (242), 31-Дек-23, 15:45	+1 +/–
скомпилировать с -O3
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #251

243. Сообщение от Аноним (243), 31-Дек-23, 17:58	+/–
Просто никто про эти инструменты еще не знает. Ни GOOGLE, ни kernel.org, ни MICROSOFT. Если им сообщить, то ошибки в их проектах перестанут появляться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

244. Сообщение от Аноним (12), 31-Дек-23, 18:47	+/–
> Мой вариант. > https://gist.github.com/likern/9df0d97b3551236b456716d95f282f83 https://github.com/k-walter/rads/blob/main/src/sync/peterson.rs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241 Ответы: #256

246. Сообщение от C00l_ni66a (ok), 31-Дек-23, 21:34	+/–
> И в чем противоречие В том, что бищапащность в безопастном мгновенно исчезает, как только ты линкуешься с либой, которая занимается хотя бы каким-то менеджментом памяти. И никакие обмазки тут не помогут. > unsafe очень лимитированы, по сравнению со всей кодовой базой > unsafe не отключает всех проверок. И это всё никак не поможет, потому что легко может произойти что-то вроде этого: play[dot]rust-lang[dot]org/?version=stable&mode=debug&edition=2021&gist=9d167c7dd188c2995d550474fa28107e Да-да, это протечка ансейф лямбды в сейф-контекст. И учитывая приматоподобную сущность разработчиков ржавого - нет никаких гарантий, что ~~данный баг~~ данная фича уникальна. >В C++ в unsafe всё. Твои баззворды и жонглирования терминами на меня не сработают. В крестах нет понятия "unsafe".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231 Ответы: #248, #249

248. Сообщение от Аноним (-), 31-Дек-23, 21:43	+1 +/–
> И никакие обмазки тут не помогут. Работаешь с любой сторонней не-раст либой как с unsafe. Просто потому что ты не можешь знать что они там на кодили. Поэтому весь ffi идет unsafe. > И это всё никак не поможет, потому что легко может произойти что-то вроде этого: play[dot]rust-lang[dot]org/?version=stable&mode=debug&edition=2021&gist=9d167c7dd188c2995d550474fa28107e Ну так у тебя "бажина" локализована в unsafe секции > Твои баззворды и жонглирования терминами на меня не сработают. В крестах нет понятия "unsafe". Не, в крестах нет понятия safe)) Взял и попортил что угодно где угодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #252

249. Сообщение от Аноним (-), 31-Дек-23, 21:43	+/–
> В том, что бищапащность в безопастном мгновенно исчезает, как только ты линкуешься с либой, которая занимается хотя бы каким-то менеджментом памяти. И никакие обмазки тут не помогут. Сразу видно спеца! При линковке с любой либой из дыряшки ты можешь получить чужую память просто ошибке в парсинге строки в коде "не либы". Уязвимости вида "30 раз нажал энтер - получил рут" как раз показывает, что криворучки не могут нормлаьно писать ни в либе, ни в основной программе. И вообще не нужно тянуть всякий мусор в свой проект) > Да-да, это протечка ансейф лямбды в сейф-контекст. И учитывая приматоподобную сущность > разработчиков ржавого - нет никаких гарантий, что ~~данный баг~~ данная фича уникальна. Ого, и это рассказывает фанаты дярявости, которая пророждает 70% ошибок в крупных проектах. Да по сравнению с этими приматами, амебы до сих пор не смогли буфер писать без переполнения. > Твои баззворды и жонглирования терминами на меня не сработают. В крестах нет понятия "unsafe". Зато есть понятие "какаю в чужую память"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #253

250. Сообщение от Аноним (-), 31-Дек-23, 21:51	+/–
> То Раст безопасный, то теперь оказывается нет Витюшка, ты опять не в состоянии в доку заглянуть и прочитать в каких случаях Раст безопасный? Там же немного, всего пара абзацев... Неужели это тебе так сложно? Или после тайпскрипта у тебе вообще мозг атрофировался? > Или вы не можете написать безопасную обвязку над "небезопасными" языками Безопасную обвязку к другим языкам (без GC) создать в принципе невозможно - потому никто не в состоянии проверить, что они там наовнокодили - даже сами авторы - и все держится на "мамой клянуcь" погромиста. > ради чего вообще создавался Раст? Чтобы все было написано на нем разумеется) Чтобы по максиму использовать safe code и safe либы (если ты не в курсе - существует #![forbid(unsafe_code), который позволяет вообще все либу писать только на safe подмножистве)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

251. Сообщение от Аноним (-), 31-Дек-23, 21:55	–2 +/–
А потом долго и судорожно ищешь куда бы поставить барьер, чтобы порядок выполнения был таким как ты написал, а не как захотелось компилятору.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242 Ответы: #273

252. Сообщение от C00l_ni66a (ok), 31-Дек-23, 21:59	–1 +/–
> Ну так у тебя "бажина" локализована в unsafe секции У тебя краткосрочная память только три буквы вмещает? Используешь нибищапащную функцию в ансейф лямбде -> используешь ансейф лямбду в сейф контексте -> получаешь всё что угодно, но только не бищапащность. Разжевал простейшую двусвязную логическую цепь специально для растовиков, можешь поблагодарить. > Не, в крестах нет понятия safe)) Твоя софистика по прежнему не работает, выдумывай оригинальнее. >Взял и попортил что угодно где угодно. Также как в расте и вообще любом ЯПе. Если ЯП не позволяет выполнять команды программиста - это не ЯП, по определению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248

253. Сообщение от C00l_ni66a (ok), 31-Дек-23, 22:02	+/–
> При линковке с любой либой из дыряшки ты можешь получить чужую память > просто ошибке в парсинге строки в коде "не либы". Причём тут сишка? > И вообще не нужно тянуть всякий мусор в свой проект) Согласен, а растовики должны прекратить его пропагандировать. > Ого, и это рассказывает фанаты дярявости Пруфай, что тут есть какие-то фанаты дырявости кроме тебя. > Зато есть понятие "какаю в чужую память" Какие ещё у тебя есть отклонения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #255

254. Сообщение от anonymous (??), 31-Дек-23, 22:45	+/–
Поэтому придумали Java. Ну и не только поэтому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

255. Сообщение от Аноним (-), 31-Дек-23, 23:01	+/–
>> И вообще не нужно тянуть всякий мусор в свой проект) > Согласен, а растовики должны прекратить его пропагандировать. Хм... а кто это знамениты Григорий, чтобы все указывать? Может он великий пограммист? Что-то я такого не слышал)  А может он сходит куда-нибудь? Так что кушай что дали и молчи, умные дядьки разберутся что для современных яп хорошо, а что нет. >> Ого, и это рассказывает фанаты дярявости > Пруфай, что тут есть какие-то фанаты дырявости кроме тебя. Пруф: Дано: сишка и с++ дырявые (70% ошибок с памятью) -> серьезные компании типа гугл и майкрософт заменяют их на раст Фанаты этих языков -> фанаты дырявости >> Зато есть понятие "какаю в чужую память" > Какие ещё у тебя есть отклонения? Не у меня слава богу все норм, а вот когда пограммист на нагадил в соседнюю память и теперь CVE с получением рута, то к сожалению меня это тоже касается
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #271

256. Сообщение от Витюшка (?), 01-Янв-24, 00:36	+/–
Не знал что под личиной русского парня скрывался K. Walter.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #257, #258

257. Сообщение от Аноним (-), 01-Янв-24, 02:40	+/–
В интернете никто не знает что ты кот (c)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256

258. Сообщение от Аноним (-), 01-Янв-24, 12:37	+/–
Т.е. именно по коду тебе сказать не нечего? Не то чтобы я был сильно этому удивлен... скорее это было более чем очевидно) Кстати заметь, ни одного unsafe.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #259, #260

259. Сообщение от Витюшка (?), 01-Янв-24, 18:52	+/–
А что я должен должен сказать по коду? Куча синтаксического шума и никаких гарантий корректности. Так вот возвращаемся к моему основному вопросу. КАК Rust гарантирует корректность этого кода и почему? Или умный программист ВРУЧНУЮ проверил все инварианты и написал корректный код на небезопасном языке Rust? Как он мог этого сделать и на любом другом, например. В Zig минимум синтаксического шума, и только по делу. Моя версия,на неё равняться не стоит. Это черновик. Там volatile уйдет, потому что я написал некорректный код (volatile в Java и C++ имеет разную семантику, т.к. я volatile ни разу в жизни и не использовал, наверное, естественно этого не знал. Нужен atomic чистый). Но я это знаю, что ошибка, знаю какая и как исправить. А как в этом поможет Rust?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #262

260. Сообщение от Витюшка (?), 01-Янв-24, 19:05	+/–
В этом и фишка, ни одного unsafe и язык является абсолютно небезопасным. И в этом коде можно сделать ошибку где угодно. Не только логическую. Вплоть до того что поменять два условия местами и код логически такой же, а в многопоточной программе уже будет ошибка. И почему-то "безопасный" Rust тебе об этом ничего не расскажет. И ловить ты её будешь несколько лет. И код этот очень сложный, понять где закралась ошибка будет очень сложно. Т.е. от Сишки Rust не сильно отличается. Возникает вопрос....и стоило ли писать этот язык с кучей ограничений, если в итоге вся эта безопасность разваливается на каждом шагу? Может, стоило сделать просто более безопасный С, с проверкой границ массивов (а не с ограничениями) в runtime и т.п.? И вот Rust превращается.. превращается...в Zig :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #264

262. Сообщение от Аноним (-), 01-Янв-24, 22:51	+/–
> А что я должен должен сказать по коду? Куча синтаксического шума и никаких гарантий корректности. Что должен? Должен проверить код. Что можешь? А ничего ты не можешь, ты же не умеешь в раст. Мог бы скачать репу и прогнать тесты. Тесты оно проходит test sync::peterson::tests::race_conditions ... ok test sync::peterson::tests::sequential_works ... ok test sync::peterson::tests::mutual_exclusion ... ok test result: ok. 12 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 13.88s > Так вот возвращаемся к моему основному вопросу. КАК Rust гарантирует корректность этого кода и почему? Я тебе писал уже кучу раз в этой теме - ОТКРОЙ ДОКУ и прочитай что именно гарантирует раст. Все что гарантируется, гарантируется автоматически. Все что не гарантируется - доказываешь на бумажке, покрываешь тестами. > Или умный программист ВРУЧНУЮ проверил все инварианты и написал корректный код на безопасном языке Rust. Программист молодец! > В Zig минимум синтаксического шума, и только по делу. А откуда ты это знаешь, если на твой код равняться не стоит? Вдруг ты что-то забыл? В раст тоже все по делу. Вот ты написал все в кучу внутри структуры PetersonMutex, тут разделил на отдельные имплементации, чтобы код был более читабельным (но только разумеется для того, кто понимает что там написано) > Это черновик. ... я написал некорректный код ... Черновик или нерабочий код? Если мы оба за точность терминологии, то это явно момент, который неплохо бы прояснить))) > Но я это знаю, что ошибка, знаю какая и как исправить. А как в этом поможет Rust? Как поможет раст исправить ошибку в Зиг коде? Даже не знаю что ответить...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259 Ответы: #265

264. Сообщение от Аноним (-), 01-Янв-24, 23:26	+/–
> В этом и фишка, ни одного unsafe и язык является абсолютно небезопасным. > И в этом коде можно сделать ошибку где угодно. Не только логическую. Не любую. А ту ошибку, отсутствие которой не гарантируется safe подмножеством. Ну, пожалуйста, ну открой доку и прочитай! Я тебе даже ссылку скину doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html doc.rust-lang.org/nomicon/races.html Надоело повторять одно и тоже! > И ловить ты её будешь несколько лет. Неплохой наброс... Пруфов конечно не будет, да? > Т.е. от Сишки Rust не сильно отличается. Пхахаха. Сишка позволяет тебе сделать так:     double *ptr = (double*)malloc(sizeof(double) * 10);     double *ptr2 = ptr;     free(ptr);     free(ptr2); И будет классический дыряшечный double-free. А теперь повтори это в безопасном расте. Попробуй напр. в playground. > Возникает вопрос....и стоило ли писать этот язык с кучей ограничений, если в итоге вся эта безопасность разваливается на каждом шагу? Конечно стоит. Потому что ты будет задумываться о реально сложных вещах, а рутину будет тебе подсказывать компилятор. > Может, стоило сделать просто более безопасный С, с проверкой границ массивов (а не с ограничениями) в runtime и т.п.? В runtime слишком дорого. Плюс там не только проверка границ массивов. > И вот Rust превращается.. превращается...в Zig :)) Слава богу нет)) Потому что в твоем zig делаешь:     const allocator = std.heap.page_allocator;     var memory1 = try allocator.alloc(u8, 2);     var memory2 = memory1;     allocator.free(memory1);     allocator.free(memory2); И наслаждаться "Segmentation fault at address 0x7f55bb3e5000" Та же сишка, только в профиль. И что, помог тебе твой Zig?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #260 Ответы: #266

265. Сообщение от Витюшка (?), 01-Янв-24, 23:28	+/–
В общем по существу ответить нечего. Вывод спора простой. Большинство программистов на Rust ничего сложного написать не могут, даже попытаться. Кидают чужие имплементации. И при этом рассказывают про безопасность. Обеспечить которую они не могут, да и даже не понимают как обеспечивать. Вывод второй. Rust даст тебе какие-то дополнительные гарантии, ну допустим, но типичный Rust программист налажает в куче других мест. В логике, в синхронизации, и т.п. Вывод третий. Крутой программист и на Rust напишет хороший корректный код. Правда он его же и на С++ напишет, и на Zig. > Что должен? Должен проверить код. Что можешь? А ничего ты не можешь, ты же не умеешь в раст. Мог бы скачать репу и прогнать тесты. Тесты оно проходит Тесты написанные самим автором? Ну ты насмешил:)) Обидно что я код могу написать, а ты...или твой коллега нет?) Ты как определил что я не могу в Rust коде разобраться?))) Сам придумал и поверил?) > А откуда ты это знаешь, если на твой код равняться не стоит? Вдруг ты что-то забыл? volatile убери и будет всё Ок. > Вот ты написал все в кучу внутри структуры PetersonMutex Ясно. Когда совсем нечего ответить начинают придираться к запятым 😄 Там не всё в кучу. Там отдельная единая имплементация. А твои "интерфейс" это конечно ужасный говнокод. Но ты этого не знаешь. На каждый класс, наверное, пишешь интерфейсы и фабрики синглионов фабрик классов?) Да вы батенька...кодер. Вот когда появится несколько имплементации (если, когда-нибудь...а скорее всего никогда ) то я просто в compile time проверю все функции и их сигнатуры у структуры - что есть методы lock и unlock 🔓 в структуре и всё. > Как поможет раст исправить ошибку... Увиливаешь. Никто не мешает использовать volatile в Rust коде и совершить такую же ошибку. Только я знаю что ошибки могут быть и поэтому полез гуглить про volatile. А типичный программист на Rust, свято веря в безопасность, и проверки компилятора естественно никуда лезть и читать не будет. Нет warning? Значит безопасно. Компилятор всё проверил. В итоге мой код будет лучше, качественнее, надёжнее, безопаснее чем у Rust фанатиков. > Черновик или нерабочий код? Рабочий я оставлю чтобы троллить на следующих новостях про Rust. Мне не к спеху поправить. Знал что никто даже и 20 строк кода сам написать не сможет. Оказался прав 😀 Выложили бы своё - тут же поправил бы. В общем картина Rust программистов очень печальная и удручающая
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #268

266. Сообщение от Витюшка (?), 02-Янв-24, 00:37	+/–
Ну и как же ты не в runtime отловишь выход за границы массива? Очень хочу послушать гуру Раста, как они это делают в compile time. Опять будете рассказывать что я там что-то не так прочитал? Товарищи, вы путаетесь в показаниях. То вы говорите что то что Rust гарантирует... очень ограничено. А значит в compile time это не проверить (вроде это очевидно?)...а тут же на голубом глазу что runtime проверки якобы очень дороги 😀 Либо одно, либо другое. Те в Rust просто забивают и никакие проверки не делают? А про гарантии borrow checker Rust я прекрасно осведомлён и что он гарантирует знаю. В моём Zig не вышла ещё версия 1.0. И эта лишь детали имплементации, не успели ребята написать ещё эту фичу. https://github.com/ziglang/zig/issues/6004 Очевидно что аллокатор будет уметь ловить практически все известные ошибки аллокации памяти. Включая double free. * Detect double free, and emit stack trace of: //!    - Where it was first allocated //!    - Where it was freed the first time //!    - Where it was freed the second time В принципе все эти ошибки можно и нужно детектировать. И Zig это и делает. Например double lock на мьютексе из своего потока. Аллокатор тоже много чего детектирует, но не всё ещё. И если ты говоришь что для Rust это дорого и он всё это не детектирует - получается он менее безопасный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264 Ответы: #267

267. Сообщение от Аноним (-), 02-Янв-24, 01:21	+/–
Ты вообще за дискуссией следишь? Ты спросил про Си >>> Может, стоило сделать просто более безопасный С, с проверкой границ массивов >> В runtime слишком дорого. > Ну и как же ты не в runtime отловишь выход за границы массива? Вот ты сам придумал? что они не в рантайм. А тебе ответили "почему не добавят". Хватит уже приписывать мне то, что я не говорил. В си нет слайсов и итераторов, которые в расте неплохо так нивелируют рантайм проверки. > То вы говорите что то что Rust гарантирует... очень ограничено. Нет, я такого не говорил. Это ты считаешь, что оно ограничено. А я сказал, что раст покрывает конкретный сабсет, ошибки из которого очень распространены в системном и не только программировании и порождают море CVE. > Либо одно, либо другое. > Те в Rust просто забивают и никакие проверки не делают? Это уже какая-то шизофрения... > А про гарантии borrow checker Rust я прекрасно осведомлён и что он гарантирует знаю. Ну-ну)) Ты еще в прошлой теме показал как прекрасно ты знаешь раст. И продолжаешь в этой) > В моём Zig не вышла ещё версия 1.0. > И эта лишь детали имплементации, не успели ребята написать ещё эту фичу. Ахахаха! Такая крохотная деталь имплементации! Вот оно чё, Михалыч! > https://github.com/ziglang/zig/issues/6004 Висит открытая с 2020 года. > Очевидно что аллокатор будет уметь ловить практически все известные ошибки аллокации памяти. Абсолютно неочевидно! Может к тому моменту они проедят донаты и забросять это поделие. Или сыграет bus-factor. Сейчас есть просто факт - это не работает в "готовом для прода" Zig'е. > В принципе все эти ошибки можно и нужно детектировать. И Zig это и делает. Так делает или это еще не реализовано? Реализовано или "еще не всё" > И если ты говоришь что для Rust это дорого и он всё это не детектирует - получается он менее безопасный. Еще раз повторю - про раст я такого не сказал. Вопрос был про си, ответ был про си. Меня восхищает твое умение додумывать вещи, которые собеседник не говорил, а потом героически их опровергать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266 Ответы: #269

268. Сообщение от Аноним (-), 02-Янв-24, 01:35	+/–
> В общем по существу ответить нечего. Т.е ты слился? Я не особо удивлен. > Большинство программистов на Rust ничего сложного написать не могут, даже попытаться. Я тебе предоставил чужой рабочий код на Раст, а ты мне какой-то свой багованый полуфабрикат на Zig. Представляешь, ты умудрился ошибиться в 50 строках кода! О какой квалификации вообще может идти речь... Лучше бы нашел чужой рабочий вариант, посмотрели бы его. > Вывод второй. Rust даст тебе какие-то дополнительные гарантии, ну допустим, но типичный Rust программист налажает в куче других мест. В логике, в синхронизации, и т.п. Феерическое предположение, на уровне "если бы бабушка была дедушкой". Да и с чего он вдруг налажает? Ты по своему опыту судишь? Ну не все такие программеры как ты. > Вывод третий. Крутой программист и на Rust напишет хороший корректный код. Правда он его же и на С++ напишет, и на Zig. Причем тут с++? Там и смартпоинтеры и raii есть. Может ты с Си спутал? Если да, то это ложное предположение. Как жаль, что таких программистов не нашлось для ядра. Хотя гугл меняет С и С++ в андроиде на раст, что показательно. > На каждый класс, наверное, пишешь интерфейсы и фабрики синглионов фабрик классов О, ты опять показываешь свое "прекрасное" знание раста - в нем нет классов. > я просто в compile time проверю все функции и их сигнатуры у структуры - что есть методы lock и unlock Да, это ооочень круто. Вот только мои "интерфейсы" проверяются в compiletime))) > А типичный программист на Rust, свято веря в безопасность, и проверки компилятора естественно никуда лезть и читать не будет. Ты опять делаешь бредовые выводы и обобщаешь... > В итоге мой код будет лучше, качественнее, надёжнее Ахаха, сам себя не похвалишь - никто не похвалит))) Может будет, а может бы будешь #ыдлокодить на тайпскрипте, кто знает... Но пока что ты уже обделался)) > Мне не к спеху поправить. Поверь, уже его никто не ждет. > В общем картина Rust программистов очень печальная и удручающая Да, нам просто удручающе приходится общаться с такими как ты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #265 Ответы: #270

269. Сообщение от Витюшка (?), 02-Янв-24, 02:11	+/–
Про героическое додумывание - это лучше к зеркалу подойти. При чём тут вообще С? С чистым С Rust никто никогда не сравнивал. А вы всё пытаетесь спуститься пониже...на С... чтобы более выигрышно смотреться. Мы про С++ говорили, говорим и будет говорить. И про Zig. Про интерфейсы или как ты там их назвал в Rust - речь была про то что всё это и гораздо больше делается в Zig. Интерфейсы это очень ограниченный инструмент. Zig позволяет это. Zig позволяет гораааздо больше. Про это речь шла. Что такое интерфейс? Просто набор сигнатур функций который необходимо реализовать, может параметризованный. В Zig можно сделать любые проверки всего что может быть вычислено в compile time. Например как сделать в Rust интерфейс - у которого все методы будут начинаться с названия "start"? Или никак, или через какой-то убогий синтаксис макросов. С помощью какого-то корявого синтаксиса. В Zig это делается легко на обычном же Zig. Когда вас тыкаешь в Rust, где сотни критичных багов безопасности, вы почему-то начинаете кричать что это было 5 лет назад. Например что-то там с тихими переполнениями вычислений. Однако это было не "5 лет назад", а в "стабильной production ready версии языка 1.64". Вот и вся безопасность. Но что-то про Rust ты такого не говоришь > Сейчас есть просто факт - это не работает в "готовом для прода" Zig'е что это не готовая поделка 😀 Сравнивать стабильную версию языка с 64 релизами с языком 0.11, у которого уже это есть из коробки. Ну... такое, не делает чести Rust Слайсы и итераторы это и есть runtime проверки. Но ты этого не знал. Ну что же, не удивительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267

270. Сообщение от Витюшка (?), 02-Янв-24, 02:26	+/–
Ну у вас с логикой всё печально. Я говорю "давай напишем код" и проверим у кого больше гарантий.У меня, ручками или у Rust. Выяснилось что сам ты написать на Rust ничего не можешь. Не то что безопасно, а вообще никак. Так об этом и речь! Парень, ты жиденько обделался. Rust тебе не помог, а сам ты не могёшь. Как и все в этой ветке защитники. У вас только на словах всё безопасно. На деле 0 строк кода 😀 Смешно ей богу. "Лучше бы взял", а может тогда тебя сразу на помойку выкинуть и взять того парня который тот код и написал?) Он, уверен, и на С++ без ошибок напишет. Вам предложили написать 20 строк кода но и с этим вы не справились. А так да, есть крутые программисты, которые пишут на Rust. Только язык тут ни при чём. Они крутые и на чистом С и на С++. С небезопасный? Берешь С++ и всё. А так на что вы способны? Отправлять JSONчики клиенту, а всю реальную работу кто-то завал бы написал? Многопоточку там безопасную. Так хватит JS или Go за глаза.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268

271. Сообщение от C00l_ni66a (ok), 03-Янв-24, 00:09	+/–
>знамениты Григорий Таблетки прими, а то уже совсем безсвязную ересь пишешь. >Так что кушай что дали и молчи Это твоя прерогатива, как фанатика. >умные дядьки разберутся что для современных яп хорошо, а что нет Уже давно разобрались, именно поэтому на расте пишут только сами разрабы и те, кому занесли гранты (т.е. полтора землекопа), в то время, как остальные предпочитают выбирать инструмент соответствующий задаче, а не наоборот. >Пруф: Это не пруф, а твои маняфантазии. Пруфай, что: 1. ...из "70% ошибок с памятью" следует "сишка и с++ дырявые"; 2. ..."серьезные компании типа майкрософт заменяют их". Раст делается выходцами из мразиллы, которой владеет гугл, поэтому в качестве примера он не подходит априори. Это всё равно, что написать "сишарпом пользуются такие крупные корпорации как майкрософт, значит это классный инструмент"; 3. ...тут есть какие-то фанатики в принципе, кроме тебя. >Не у меня слава богу все норм Лжёшь ведь, у тебя целая пачка психических отклонений, следствием чего являются обильные проекции и фантазёрство в твоей писанине.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255

273. Сообщение от Аноним (273), 03-Янв-24, 01:55	+/–
Ну если тебе квалификации не хватает, тогда компилируй с -O2
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

275. Сообщение от Янис (?), 03-Янв-24, 20:06	+/–
Каким еще таким развитым синтаксисом обладает растишка?! У чистого Си все куда яснее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

277. Сообщение от Аноним (278), 05-Янв-24, 20:54	+/–
> Синтаксис это на 90% вкусовщина ДАЛЕКО НЕ. Именно в силу синтаксиса ЛИСП (или какой-нть Брэйнфак с Перлом) канули в лету, а ПОЧТИ похожий на Си Паскакаль не выдержал битвы и... тоже забыт большинством. Синтаксис - это не следование капризам очередного з@дp0та (как ты себе представляешь), это выверяемый годами удобный способ представления программы, ибо их не только пишут, но и ЧИТАЮТ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

278. Сообщение от Аноним (278), 05-Янв-24, 21:03	+/–
Смотря откуда взглянуть. Если с позиции Васяна - то да, плодишь себе стотыщпицотный нотепад и думаешь, что сейчас-то ты точно плюнул в вечность. А с позиции камьюнити это УЖАСНО - вместо выбора пакетов для инсталляции, надо погружаться в 3-часовую медитацию "зачем нужен пакет S, чем он отличается от Q, что такое Q-next и превосходит ли он S++". Мириады пакетов непонятной степени отлаженности, готовности в целом и конечно же категорически не нужное РАСПЫЛЕНИЕ СИЛ. Я бы рад помочь *одному* редактору, плагинов там понаписать, но как я его выберу? Этот умеет в синтаксис Perl, а вот этот мультитабный, а тот вообще в консоли работает! Ты теряешься в этом месиве DIY программ, потому что ни одна (нехорошая редиска) не скажет, что его пакет - г0внŏ. Хотя прекрасно знает, что там внутри чёрт ногу сломит. Таковы дилетанты FOSS - сс-ык-уны и посредственности, никто не научен брать на себя ответственность. А нет ответственности - НИКОГДА не будет нормальных фаворитов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229

280. Сообщение от Аноним (280), 08-Янв-24, 23:37	+/–
А тем временем российские физики написали эмулятор 34 кубитного квантового компьютера именно на Rust... "Гуру" тем временем в чатиках важными холиварами были заняты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #281

281. Сообщение от Аноним (-), 09-Янв-24, 00:31	+/–
> А тем временем российские физики написали эмулятор 34 кубитного квантового компьютера именно > на Rust... "Гуру" тем временем в чатиках важными холиварами были заняты Он так же работает как аппарат на луне, робот федор и модуль наука? Или даже лучше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280

282. Сообщение от Пряник (?), 09-Янв-24, 10:10	+/–
Генераторы бы... с ними параллелизм в hello world будет по феншую.
Ответить | Правка | Наверх | Cообщить модератору

283. Сообщение от Пряник (?), 09-Янв-24, 10:16	+/–
Конкуренция-с. Как было с VHS, дискетами, дисками, хардами, интерфейсами...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

284. Сообщение от Пряник (?), 09-Янв-24, 10:26	+/–
Синтаксис намного удобнее и понятнее, чем в С/С++, а больше и не нужно. Хотя немного более многословный. Преобразование через as_, макросы без прострела ноги (когда узнал про косяки макросов в Си, это фейспалм, обязательно всё в скобки, сразу вспомнил баш с кавычками).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

285. Сообщение от wyry (?), 11-Янв-24, 05:07	+/–
Штааа? xD. Всего лишь почти все ПО по производству 3D графики написано на C++. В Blender есть и более низкоуровневый Сишный код. Unreal Engine 5 (давно не пишут xD...) написан на C++. Почти все видеоредакторы написаны на C++. Почти весь САПР - это C++. MATLAB - это C (чистый) + Java морда. Или для вас "прикладное ПО" - это для секретарей и кассиров? Так и там, особенно при отказе от винды можно запросто увидеть C++, помимо Java.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232

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

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