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

"NVIDIA представила CUDA Rust для разработки GPU-ядер на языке Rust"	+/–
Сообщение от opennews (??), 17-Сен-26, 11:52
Компания NVIDIA объявила о развитии инструментария  CUDA Rust, позволяющего использовать язык Rust для разработки ядер, выполняемых на стороне GPU. В следующем году  CUDA Rust планируют довести до уровня, пригодного для разработки рабочих проектов, аналогичного инструментариям  CUDA C++ и CUDA Python... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66295
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 17-Сен-26, 11:52	+3 +/–
И ты, Брут.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14

2. Сообщение от Аноним (2), 17-Сен-26, 11:52	–1 +/–
Ну вот, теперь и у видеокарт память будет исчезать в неизвестном направлении. Да и блокировки непонятные им на пользу пойдут.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #5

4. Сообщение от Аноним (4), 17-Сен-26, 11:58	+/–
Только если полной утечкой видеопамяти в никуда, механизм сброса видеопамяти в оперативную они уже очень много лет в своём блобе реализовать не могут (и вряд-ли соберутся).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

5. Сообщение от Алексей (??), 17-Сен-26, 11:59	+2 +/–
Добрый, а можете, пожалуйста, прислать пояснительную бригаду? В чем конкретно Вы видите проблемы в Rust, как так память теряется?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

9. Сообщение от Аноним (9), 17-Сен-26, 12:13	–3 +/–
Зловреды на расте пишутся только в путь - из-за того, что в "ассемблере каша", это я цитирую. Дизассемблирование неосуществимо.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

10. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 12:13	–1 +/–
Даже великолепная nVIDIA добавляет поддержку блистательного Rust. Тем не менее, ещё находятся на Опеннете критики, что мол никто серьезный не использует сияющий Rust, и что мол надо просто умело писать на Си. А меж тем идея безопасной памяти живёт, и за нее реально голосуют долларом корпорации
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #19, #24, #25, #44

11. Сообщение от Смузихеб забывший пароль (?), 17-Сен-26, 12:15	–1 +/–
> и предотвращает возникновение состояний гонки Это тот самый ЯП, по которому в одной из предыдущих новостей аккурат состояние гонки и было одной из осн. возникших проблем ?)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #53

12. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 12:18	+4 +/–
Дизассемблирование всегда осуществимо, это просто показ ассемблерных команд для бинарного кода. А что касается "каши" - она и в любых других языках каша, особенно с оптимизациями. Просто сияющий Rust ещё относительно молод, и реверсеры ещё к нему не помучились. По старым языкам просто уже компиляторы популярные все знают как облупленные, как они код генерируют Да и не дизассемблированием единым код исследуют
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #15, #27, #46, #73

14. Сообщение от Аноним (14), 17-Сен-26, 12:26	–5 +/–
Корпы пропихивают, им это выгоДНО...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #23, #49

15. Сообщение от Аноним (15), 17-Сен-26, 12:29    Скрыто ботом-модератором	+/–
Зияющий потому, что безопасТный?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

17. Сообщение от Аноним (17), 17-Сен-26, 12:35	+/–
>Для разработки на языке Rust с использованием модели SIMT развивается компилятор cuda-oxide, позволяющий компилировать код на языке Rust, использующий штатную систему типов и модель владения Rust, напрямую в инструкции для выполнения в виртуальной машине CUDA PTX (Parallel Thread Execution). В макросню для компиляции внутри раста в куду нишмагли
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Аноним (18), 17-Сен-26, 12:36	–2 +/–
голосуют за содержимое блоков unsafe
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #34

19. Сообщение от Аноним (-), 17-Сен-26, 12:37	+/–
Корпорации тоже гонятся за хайпом. В них тожу живые люди работают. Или ты наивно полагаешь, что с Растом у них увеличистя капитализация и продажи? В соседней ветке обсуждают Жабу. Ты видимо опоздал родится и не застал времена хайпы Жабы. И где сейчас эта Жаба?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #32, #42, #80

22. Сообщение от VVVVVV (?), 17-Сен-26, 12:43	–1 +/–
Это в какой новости?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #38, #40

23. Сообщение от лул (?), 17-Сен-26, 12:43	+/–
Удивительно, почему эти негодяи хотят меньше проблем, вместо постоянных CVE...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #29, #31

24. Сообщение от Sm0ke85 (ok), 17-Сен-26, 12:43	–1 +/–
>идея безопасной памяти живёт, она "живет" только в голове у леммингов >и за нее реально голосуют долларом корпорации не за нее голосуют, совсем не за нее... ЗЫ ищи где прибыль может быть и буратиной не помрешь может быть, ахахахах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

25. Сообщение от Ivan_S (?), 17-Сен-26, 12:44	+1 +/–
Производитель железа от этого имеет финансовую выгоду в виде продажи своей продукции. Сей "чудесный" язык память и дисковое пространство кушает лопатами. Им такой Си со своими миниатюрными бинарниками, простой системой сборки не даёт заработать столько, сколько хочется. Вот и всё. Никакой магии, никакой безопасности в работе с памятью итд. Бизнес. Лишь бизнес. Мани
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #33

27. Сообщение от Аноним (27), 17-Сен-26, 12:51	–1 +/–
> относительно молод А молод - это до скольких лет, до 40 или до 50?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #35

29. Сообщение от Аноним (29), 17-Сен-26, 12:52	–1 +/–
Странно, но в раст-утилзах всё наоборот получилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #36, #61

30. Сообщение от Аноним (29), 17-Сен-26, 12:55	+/–
> обеспечивает безопасность работы ... предотвращает возникновение состояний гонки Недавняя новость: "...из-за проблем с безопасностью, выявленных в ходе аудита кодовой базы Rust Coreutils. Большая часть уязвимостей в Rust Coreutils вызвано наличием состояния гонки".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #57

31. Сообщение от aname (ok), 17-Сен-26, 12:58	+1 +/–
Чтоб зашить возможность делать те же руты на телефонах, например. Очень полезная корпоратам вещь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

32. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 12:59	+1 +/–
Остаточный хайп Джавы я помню - и что же, Джава оставила огромное наследие, инфраструктуру JVM, на ней написано тонна кода, она заработала много денег самым разным людям. Чем не успех? Разве я говорю, что сияющий Rust будет вечен? Когда-то и его чем-то заменят
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

33. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 13:02	–1 +/–
Я думаю, что жор памяти многославным Rust сильно преувеличен. На Си или голом ассемблере вообще можно сделать бинарь, конечно, сильно мельче. Но стоит ли оно того, если так легко накосячить с памятью?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #39, #47, #105

34. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 13:03	+2 +/–
Раньше был один сплошной unsafe, и это никого не волновало. Теперь же дали возможность писать safe, так все кричат "а как же unsafe блоки?!!11". При том, что unsafe даже не все гарантии отключает, а лишь ограниченный их список
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #77

35. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 13:08	+1 +/–
Тут молодость/зрелость скорее не в конкретных годах будет исчисляться, а в объеме кода, который пишется и реверсится. Если язык малопопулярный, то будь ему хоть 30 лет, под него не будет заточки. Хотя у старых непопулярных языков редко сильно продвинутые оптимизирующие компиляторы. В общем, отвечая на вопрос - когда напишут и отреверсят достаточно много кода, чтобы наработать инструменты реверсинга для великолепного Rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

36. Сообщение от Аноним (36), 17-Сен-26, 13:12	+6 +/–
Потому что язык принесли. А уметь программировать не принесли. Одни pronounce engineers и прочие сотнегендерные
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

38. Сообщение от аморим (?), 17-Сен-26, 13:18	+/–
про uutils видимо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

39. Сообщение от Аноним (36), 17-Сен-26, 13:19	+1 +/–
ну посмотри сколько растовых лефтпадов приезжаетна диск с этой новой кудой, которая даже не в паритете по фичам и сколько на сях/питонах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #56

40. Сообщение от Смузихеб забывший пароль (?), 17-Сен-26, 13:39	+/–
Да, анон ниже был прав > Ubuntu 26.10 полностью переведён на Rust Coreutils https://www.opennet.ru/opennews/art.shtml?num=66274 > в LTS-ветке Ubuntu 26.04 был совершён откат > на поставку утилит cp, mv и rm из набора GNU Coreutils > Варианты[из uutils] cp, mv и rm были возвращены из-за проблем с > безопасностью, выявленных в ходе аудита кодовой базы > Rust Coreutils. Большая часть уязвимостей > в Rust Coreutils вызвано наличием состояния гонки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #58

41. Сообщение от Аноним (17), 17-Сен-26, 14:36	+/–
>Большая часть уязвимостей в Rust Coreutils вызвано наличием состояния гонки". зачем там многопоток и почему не переписать уутилс на хаскель, в котором есть исключатор гонки как основной примитив itc?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

42. Сообщение от eugener (ok), 17-Сен-26, 14:41	+1 +/–
> И где сейчас эта Жаба? да везде практически.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

44. Сообщение от Сладкая булочка (?), 17-Сен-26, 14:59	+1 +/–
> Даже великолепная nVIDIA добавляет поддержку блистательного Rust. Почему нвидия "великолепная"? Почему раст "блистательный"? Ну и самое главное, вы под куду что-то пишите/писали? Какая разница от добавления вам?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #51

46. Сообщение от опеншлёпивпродакшн (?), 17-Сен-26, 15:28	–1 +/–
Rust - результат всех наших прошлых страданий. В этом смысле он зрелый и своевременный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #48

47. Сообщение от Аноним (47), 17-Сен-26, 15:30	+1 +/–
У меня программа на 20мб для компиляции тянет зависимости на 5гб.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #54, #63, #79

48. Сообщение от Аноним (48), 17-Сен-26, 15:50	+1 +/–
"наших" это про тех, кто неосилил си?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #62

49. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 15:52	–2 +/–
скорее смешно, как на Опеннете раньше отторгали блистательный Rust с криком "да никто на этом не пишет, ни одна крупная компания в это не ввяжется". Сейчас же, когда это очевидно не так, сменили пластинку, теперь наоборот "да его только корпорации и пропихивают, надо писать на народном, не крупном".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

51. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 16:01	–1 +/–
> Какая разница от добавления вам? Мне греет душу, что небезопасные языки заменяются более безопасными. Ещё в 2000-х в своих книгах Брюс Шнайер писал, что обилие переполнений буффера и прочих подобных проблем - позор индустрии, и во многом он вызван использованием ручного контроля памяти. Но в 2000-х из этого не было элегантного выхода - из крупных языков с автоматическим управлением памяти была только Java со своим специфическим набором проблем (медленнее натива, слабо управляемый GC). Java, конечно, эволюционировала и продолжает жить. Но в целом было разделение: или пишешь на относительно низкоуровневых Си/C++ ради скорости или низкоуровневых фишек и уповаешь не накосячить с UB, либо пишешь на тяжеловесной Java. Но появление лучезарного Rust совершило прорыв - появился язык, который может одновременно и быть низкоуровневым, и при этом дать zero-cost гарантии памяти. И потому я не могу не радоваться, наблюдая его развитие P.S. да, я знаю, что ошибки идут не только из-за памяти и что в Java тоже умели делать RCE, однако так или иначе - чем меньше программисту нужно заниматься мелким bookkeeping'ом, тем более концентрации на логической корректности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #60, #87, #88

52. Сообщение от Человек из СССР (?), 17-Сен-26, 16:03	–1 +/–
Кто-то объяснит мне причину хейта в сторону раст?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67, #68, #74, #78, #85, #104

53. Сообщение от Человек из СССР (?), 17-Сен-26, 16:04	+/–
> состояние гонки и было одной из осн. возникших проблем Если не быть программистом, а лишь вайбкодером, и не такое становится возможным даже на раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

54. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 16:13	+/–
Так не тяни столько зависимостей, причем здесь сверкающий Rust? Это и на C++ можно притащить библиотек, что он будет весить гигабайты, качать полИнтернета для сборки и тормозить из-за Тьюринг-полных шаблонов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

56. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 16:15	+/–
А причем тут лефтпад? Грех лефтпада был не в том, что он тяжёлый, а в том что тривиальную функцию все бесконтрольно вынесли в библиотеку и вообще все бездумно используют абы чьи библиотеки, что открывает огромные возможности атак на цепочки поставки. Это дурное поветрие, к сожалению, не обошло стороной коммьюнити пышноблещущего Rust, но по крайней мере ты сам можешь принять решение, какие либы и сколько тащить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

57. Сообщение от Аноним (58), 17-Сен-26, 16:37	+1 +/–
> Большая часть уязвимостей в Rust Coreutils вызвано наличием состояния гонки". Состояния гонки в Rust Coreutils были на уровне файловой системы, а не внутри программы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #70, #86

58. Сообщение от Аноним (58), 17-Сен-26, 16:44	+1 +/–
> в Rust Coreutils вызвано наличием состояния гонки И ты правда не соображаешь, что состояния гонки там были на уровне файловой системы? В тексте новости же об этом черным по белому написано, с примерами. 🤦
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #90

60. Сообщение от Malinovsky (?), 17-Сен-26, 16:55	–1 +/–
Да, библиотеки на расте можно и в джавовский байт код запихать, но вот этот щенячий восторг выглядит странно. Библиотеки годятся - меньше парить мозг. А вайб кодинг скоро и так убьет программирование. Так что высокоуровневые языки это как раз норма, а подобные неудобные языки применительны только в форме библиотек. Тратить излишне много усилий на освоение "безопасных" методов бессмысленно когда нужны все методы. Проще сразу переходить на джавовский байт код. Он уже давно работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #64, #71

61. Сообщение от Бжежко (ok), 17-Сен-26, 17:02	+2 +/–
В раст программах больше CVE чем в сишках? Это какое-то отрицание реальности, на уровне религиозности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

62. Сообщение от Бжежко (ok), 17-Сен-26, 17:06	–1 +/–
Никто не осилил Си, программисты топового уровня не могут писать на нем без ошибок. Собственно такими программистами и создавался раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #76

63. Сообщение от Бжежко (ok), 17-Сен-26, 17:18	+/–
Не используй зависимости, пиши всё сам, компактно будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

64. Сообщение от Бжежко (ok), 17-Сен-26, 17:20	+/–
> Проще сразу переходить на джавовский байт код. Он уже давно работает. Переходи, тебе кто-то мешает это сделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

67. Сообщение от Бжежко (ok), 17-Сен-26, 17:27	+/–
Непрофессионализм и религиозная приверженность к уже освоенным инструментам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

68. Сообщение от анон (?), 17-Сен-26, 17:33    Скрыто ботом-модератором	+1 +/–
причина хейта - его сообщество, неотличимое без микроскопа от классических фанбоев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

70. Сообщение от Аноним (15), 17-Сен-26, 17:45    Скрыто ботом-модератором	+/–
Это же другое. Раст, как вседа, невиноват!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #92

71. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 17:46	+/–
Так а смысл компилировать блистательный Rust в Java-байткод? Для интеропа с JVM-системами что ли? А так сам по себе сияющий Rust в нативный код компилируется, при этом со своими гарантиями
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #81

73. Сообщение от Смузихеб забывший пароль (?), 17-Сен-26, 17:50	+/–
Он ведь вроде через LLVM идёт Т.е это м.б отреверсить лишь до многоэтапно-оптимизированного IR( или как он там называется ) Ну а далее - до чего угодно, что преобразуется в IR( хоть сишка хоть раст ). Но это скорее будет не реверс, а просто генерация исходного кода на выбранном ЯП на основе промежуточного представления. В остальном, веселее бывало, когда в проге под капотом была своя мини-виртуальная машина, в рамках которой исполнялся уже наваленный код, который даже не дизассемблировать Причём, из-за особенности выбора опкодов для конкретных команд или их наборов, порой даже достигалась экономия места
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #75

74. Сообщение от Аноним (15), 17-Сен-26, 17:55	+/–
А кто объяснит причину хайпа?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #102

75. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 18:03	+/–
Генерация исходника по байткоду или машинному коду редко бывает идеальной для сколько-нибудь сложной программы. Она худо бедно может быть близка к идеалу в Java, особенно если поленились включать обфускатор. Но такова уж JVM,. много инфы сохраняет. Из нативного же кода, особенно при подрубленных оптимизациях, очень навряд ли. Максимум верхнеуровневая структура Ну а что касается ВМки внутри программы - это да, в теории можно какую угодно ВМ с какой угодно архитектурой хоть самому с нуля придумать и в нее компилироваться. И программа твоя будет выглядеть как просто исполнялка каких-то байткодов, лежащих просто как данные и которые ты в начале расшифруй что значат
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

76. Сообщение от Аноним (76), 17-Сен-26, 18:09	+/–
Ошибки были, есть и всегда будут. Нельзя писать абсолютно без ошибок и это не проблема языка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #84

77. Сообщение от SanityEclipse (ok), 17-Сен-26, 18:10	–1 +/–
Unsafe ничего не отключает, а дает доступ к четко прописанному списку: The only things that are different in Unsafe Rust are that you can:     Dereference raw pointers     Call unsafe functions (including C functions, compiler intrinsics, and the raw allocator)     Implement unsafe traits     Access or modify mutable statics     Access fields of unions
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

78. Сообщение от Аноним (76), 17-Сен-26, 18:13	+1 +/–
Он очень сложен, некрасив и долго компилируется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

79. Сообщение от Смузихеб забывший пароль (?), 17-Сен-26, 18:21	+/–
это ты образ линя не собирал той же йоктой образ 40-60Мб - собирается сутки, тянет зависимостей и генерит промежуточных файлов на 40-60 Гб
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

80. Сообщение от Аноним324 (ok), 17-Сен-26, 18:25	+/–
> И где сейчас эта Жаба? Буквально везде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

81. Сообщение от Malinovsky (?), 17-Сен-26, 18:26	–1 +/–
Что? Я думал я понятно написал. Библиотеки Scala могут бить написаны на C, C++ и Rust запросто. Язык настраиваемый. Scala Native тоже как проект есть для ускорения. Тут все зависит от способности освоить высокий язык программирования. Многие думают высокоуровневый язык это просто, а на деле страниц так 700 например нужно прочитать, чтобы просто начать, помимо практических примеров конечно же. Маленькие кирпичики тоже неплохо иметь, но на мой взгляд лютая жесть со сложными инструментами слишком часто уделывает низкоуровневые языки программирования. Из-за кривой организации мультипоточности они такой ужас выдают на деле, из-за чего и приходится заморачиваться с разными аппаратными конфигурациями для игр. Слишком много неосиляторов моделей конкурентного подхода. Просто ради интереса сравните. А в Java можно хоть ассемблерные вставки пихать. Многие Java программисты, которые не догоняют как работает процессор часто по граблям прыгают. Было как-то видео про ассемблер на конференции несколько лет назад на английском. Можете поискать. Просто ненужно так выслуживаться. Это убивает критический взгляд и не может считаться здоровым подходом. Не знаешь в итоге как это немного снизить по градусу, ведь мозги в восхвалении не то чтобы участвуют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #89

84. Сообщение от Бжежко (ok), 17-Сен-26, 18:36	+/–
Нет смысла спорить, проблема это языка или проблема программистов, если на выходе все равно нерабочий код с UB. Раст всего лишь инструмент, позволяющий как минимум снизить количество ошибок с памятью, а если не выходить из safe подмножеста то вообще исключить их. Откуда столько хейта и истерики, как-будто кто-то заставляет писать программы на расте. Продолжайте писать на Си, если вам нравится, никто же не запрещает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

85. Сообщение от Аноним (85), 17-Сен-26, 18:36	+4 +/–
1. язык хороший, мощный, но сложный: те кто не осилили - хейтят, потому что они не смогли 2. раст претендует на ту же поляну что и C/C++: диды не любят конкуренции - хейтят как новое и угрожающее их уютному мирку 3. у языка много "фан-боев" которые топят за "святой раст" похлеще проповедников (часто не понимая даже самого языка): тут хейтят самих "боев", ну и расту достаётся заодно 4. прямой перевод "safe" раста почти всегда трактуется неверно: от языка ожидают чуда и решения всех проблем сразу - хейтят за обломанные завышенные ожидания
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #99

86. Сообщение от Аноним (29), 17-Сен-26, 18:37    Скрыто ботом-модератором	+/–
Раст даже с ФС работать не умеет без ошибок?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

87. Сообщение от Сладкая булочка (?), 17-Сен-26, 18:43	+/–
>> Какая разница от добавления вам? > Мне греет душу, что небезопасные языки заменяются более безопасными. Ещё в 2000-х > в своих книгах Брюс Шнайер писал, что обилие переполнений буффера и > прочих подобных проблем - позор индустрии, и во многом он вызван > использованием ручного контроля памяти. С того времени кучу всего поменялось, как в самих яп (тот же современный с++), так и в инструментарии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

88. Сообщение от Сладкая булочка (?), 17-Сен-26, 18:45	+/–
>> Какая разница от добавления вам? > Но появление лучезарного Rust совершило прорыв - появился язык, который может одновременно и быть низкоуровневым, и при этом дать zero-cost гарантии памяти. Они есть и в с++. Плюс в расте они не такие уж и zero-cost, например, та же проверка на границы ни разу не такая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #91

89. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 18:48	–1 +/–
> Я думал я понятно написал. Честно говоря, нет, мне довольно сложно вас понимать, вы пишете довольно сумбурно Я даже не могу понять, что вас конкретно смущает в блистательном Rust, потому что вы как-то всё к не то Java, не то Scala свели. И каким-то рассуждениям про 700 страниц. >  А в Java можно хоть ассемблерные вставки пихать Это что за новость такая? Писал на Java давно, во времена седьмой, но отродясь такого не помню. Java ж write once run everywhere. Или вы ассемблер JVM имеете в виду? Ну это очень специфическая опция какая-то > Просто ненужно так выслуживаться. Не знаю где вы это в моих сообщениях прочитали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

90. Сообщение от Смузихеб забывший пароль (?), 17-Сен-26, 18:49	–1 +/–
Я просто привёл цитату из статьи ) > выявленных в ходе аудита кодовой базы Rust Coreutils Очень интересно. Дыры в ФС, но выявили их почему-то в ходе аудита кодовой базы растовой корутилс и у сишной подобных проблем не было Очевидно, если всё дело в ФС, то и исправления связаны непосредственно с ФС и никак не касались кода растовых корутилс, не так ли ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #95

91. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 18:53	+/–
В теории - да. На практике в C++ эти инструменты во-первых лишь опция, можно писать по-старому в Сишном стиле и ловить переполнения и прочее. Во-вторых, насколько мне известно, даже в описании этих абстракций в C++ имеются различные UB, да и в целом там есть UB. А моя позиция по UB максимально жесткая - его должно быть минимально. Если компилятор не может гарантировать defined behavior - он должен запретить этот код и выдать ошибку компиляции. В крайнем случае - заставлять программиста явно указывать, что проверку нужно отключить, чтобы в коде явно было видно, где тонкое место Ну и плюс в блистательном Rust есть и некоторые другие концепции, не только лишь RAII
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #100

92. Сообщение от Аноним (58), 17-Сен-26, 19:03	+/–
> Это же другое. Раст, как вседа, невиноват! Да, друг, другое: состояния гонки на уровне асинхронщины/многопоточности внутри адресного пространства одного процесса - это не то же самое, что состояния гонки на уровне ФС. Первое вылавливается на уровне компиляции, а второе происходит в рантайме и вообще за пределами твоего кода. Но чтобы это понимать, нужно шарить в технической части. А у тебя и прочих воинов против ветряных мельниц с этим туго: вы видите совпадение по словам - и сразу бежите слюноотделять. Вот и получается цирк...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #97

95. Сообщение от Аноним (58), 17-Сен-26, 19:56	+1 +/–
> аккурат состояние гонки и было одной из осн. возникших проблем > Я просто привёл цитату из статьи ) Нет, ты буквально утверждал, что "в аккурат состояние гонки". А теперь, когда оказалось, что не в аккурат - прикидываешься валенком "я просто привел цитату". > но выявили их почему-то в ходе аудита кодовой базы растовой корутилс и у сишной подобных проблем не было Ага, не было. Иди посмотри на CVE-2017-18018, сказочник. "In GNU Coreutils through 8.29, chown-core.c in chown and chgrp does not prevent replacement of a plain file with a symlink during use of the POSIX "-R -L" options, which allows local users to modify the ownership of arbitrary files by leveraging a race condition." https://nvd.nist.gov/vuln/detail/cve-2017-18018 > Очевидно, если всё дело в ФС, то и исправления связаны непосредственно с ФС и никак не касались кода растовых корутилс, не так ли ? Очевидно, с логикой у тебя совсем туго, друг. Но это закономерно, когда не шаришь в технической части. Дело не в "непосредственно с ФС", а в том, как с ней работают. И язык на это ни коим боком не влияет. Если бы ты это понимал, то не всплыл бы тут со своим "ыыыы, тот самый ЯП".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

97. Сообщение от Аноним (15), 17-Сен-26, 20:51	–1 +/–
Да понели мы всё. Вот только почему-то разработчикам Standard GNU utilities файловая система не мешает. Может, просто разработчики uutils неправильно сидят? Им нужно сесть по-другому, тогда уж музыка пойдёт не та!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #101

99. Сообщение от Аноним (99), 17-Сен-26, 21:44    Скрыто ботом-модератором	+2 +/–
Ты покормил тролля, молодец чо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

100. Сообщение от Сладкая булочка (?), 17-Сен-26, 22:00	+/–
> В теории - да. На практике в C++ эти инструменты во-первых лишь > опция, можно писать по-старому в Сишном стиле и ловить переполнения и > прочее. Кто мешает писать на расте в unsafe и > ловить переполнения и прочее. ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #103

101. Сообщение от Аноним (58), 17-Сен-26, 22:04	+/–
> Вот только почему-то разработчикам Standard GNU utilities файловая > система не мешает. Да что ты говоришь! Открываем NEWS файл в сорцах GNU Coreutils, а там: * chmod -R now avoids a race where an attacker may replace a traversed file   with a symlink, causing chmod to operate on an unintended file. * cp, mv, and install now use openat-like syscalls when copying to a directory.   This avoids some race conditions * 'cp -n -u' and 'mv -n -u' now consistently ignore the -u option.   Previously, this option combination suffered from race conditions   that caused -u to sometimes override -n. * 'mv -n A B' no longer suffers from a race condition that can   overwrite a simultaneously-created B * When creating numbered backups, cp, install, ln, and mv now avoid   races that could lose backup data * mv no longer supports moving a file to a hardlink, instead issuing an error.   The implementation was susceptible to races * cp S D is no longer subject to a race Не иначе как растовики в штаны подбросили, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

102. Сообщение от чатжпт (?), 17-Сен-26, 22:12	+1 +/–
бесконечные cve в сишном коде
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #106

103. Сообщение от Аноним10084 и 1008465039 (?), 17-Сен-26, 22:15	+/–
Во-первых, unsafe не отключает все гарантии, а во-вторых - явное требование обрамлять такие места unsafe-блоком явно помечает, какой код нужно пристально проверять. Это гораздо более верный подход, чем опциональная безопасность, хотя конечно и понятно, что C++ пошел на это из-за обратной совместимости в числе прочего
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #108

104. Сообщение от Аноним (-), 18-Сен-26, 00:38	+/–
Единственное за что можно поругать, некрасивый многословный синтаксис. Но с другой стороны плюсы с прибамбасами выглядят даже хуже. А так его хейтят люди, верящие в то, что программисты это элитная каста с 200IQ, которая не совершает ошибок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #109

105. Сообщение от Ivan_S (?), 18-Сен-26, 01:22	+/–
Тут можно не думать. Это факт. Он просто ест память.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

106. Сообщение от Ivan_S (?), 18-Сен-26, 01:26	+/–
Найденные ИИ. А тот глупостей сколько хочешь повыдает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

107. Сообщение от Ivan_S (?), 18-Сен-26, 01:32	+/–
Отличный ЯП. Память ест правда. Дисковое пространство сжирает. Надо память и диски докупать. Синтаксис такой, что сложно разобраться. Следовательно не понять, что программа делает кроме заявленного. Багов в программах на нем много как в любом ЯП. А так отличный ЯП. Блистательный. Только дорого очень софт на нем иметь.
Ответить | Правка | Наверх | Cообщить модератору

108. Сообщение от Аноним (18), 18-Сен-26, 08:50	+/–
а остальной код не нужно пристально проверять?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

109. Сообщение от Пыщь (?), 18-Сен-26, 09:04	+/–
А Вы где инженеров-программистов в ширнармассах видели? Одни "кодеры", да погроммисты. Тяп-ляп и в продажу, побольше тестов на чепуху (то что на ум не пришло - не проверяется) с отсутствием изначальной матмодели (а так вообще бывает в ширпотребе?). Таких да, за верёвочку ржавую водить надо, вот они и обожествляют ржавчину. Что-то ada никто не восхваляет, хотя очень многое уже было, есть и будет есть до появления ржавОго. Как обычно, "морально устарел".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

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

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