FreeBSD install update upgrade [ основной тред по FreeBSD ]

там автоматическая аллокация памяти? смысл ведь исключить человеческую ошибку в сложном коде, поручив управление памятью программе. и вот написали memory-safe алгоритм. он непротиворечивый и решает проблему выделения/освобождения памяти в стеке и в куче. чем ты недоволен?

почему алгоритм в java runtime тебя устраивает, а алгоритм, основанный на четкой логике в момент компиляции, нет. компилятор содержит счетчик аллокаций, отслеживает выделение памяти, сам следит, в какой момент ее безопасно освободить. находит твои попытки use-after-free и заставляет переписывать код безопасно.

компилятор c/c++ дает тебе свободу использования malloc/free, rust-компилятор берет это на себя и накладывает ограничения на использование переменных. в чем проблема???

С++ делает для всех

Ага, щаз… никогда не видел сегфолтов в программах проекта КДЕ?

Чем он не устроил?

Самая большая претензия к языкам С/С++ это «Undefined behavior».

там автоматическая аллокация памяти?

Да.

почему алгоритм в java runtime тебя устраивает

Потому что он работает в рантайме, и следовательно, он может решать эту задачу.

В компайлтайме это нормально не решается (иначе бы никто джавы с виртуальными машинами не делал). А ограниченно, в той же степени что и в расте - решено уже в C++ двадцать лет назад.

и накладывает ограничения

Чтобы написать программу, придется попросить его снять ограничения. И дальше все то же самое как в C++, только через зад.

А ты никогда не видел учебника по C++, как и разрабы KDE?

А почему у меня в джава сегфолты, например?

А ты никогда не видел учебника по C++

Как учебник может избавить от сегфолтов в КДЕ?

А почему у меня в джава сегфолты, например?

Потому что виртуальная машина жабы написана на С++ 😏

Да.

C++ позволяет dangling pointers или null pointers, а rust нет. таким образом C++ всеравно не является memory safe языком. у Rust приоритет на безопасности. чтобы точно было. rust более продвинут в этом отношении.

В компайлтайме это нормально не решается (иначе бы никто джавы с виртуальными машинами не делал).

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

Чтобы написать программу, придется попросить его снять ограничения.

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

Как учебник может избавить от сегфолтов в КДЕ?

Если знать язык, можно писать сильно лучший код чем тот, кто его не знает.

Потому что виртуальная машина жабы написана на С++

А почему не на жабе?

C++ позволяет dangling pointers или null pointers, а rust нет.

И раст позволяет. Иначе на нем нельзя было бы писать программы. Просто в расте это спрятано в «опасные» блоки, а в C++ на совести программиста не использовать указатели в прикладном коде (компилятор не запрещает, запрещает учебн к который никто не открывал).

Разница только в этом. В расте сделали, чтобы программист-обезьяна явно получал по рукам за то что обезьяна. В С++ программисту предлагается просто не быть обезьяной.

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

ищи способы не снимать ограничение

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

В своей докторской диссертации Ральф Юнг (англ. Ralph Jung) формально доказал потокобезопасность и безопасность управления памятью, использовав логику разделения в созданной им модели RustBelt и инструменте Iris
https://publikationen.sulb.uni-saarland.de/bitstream/20.500.11880/29647/2/thesis-screen.pdf

Для С++ таких доказательств нет.

И раст позволяет. Иначе на нем нельзя было бы писать программы. Просто в расте это спрятано в «опасные» блоки

у нас какой-то глупый разговор получается.

я говорю: тебе дали memory-safe инструмент.
ты: а я всеравно буду его использовать unsafe, потому что я так привык с с++!

знаешь, это не проблема языка сейчас…

@cocucka программист и он за rust.

Собственно тут написано именно то о чем я говорю. В C++ надо знать букварь. В расте тебе, якобы, не так надо потому что компилятор не даст сделать опасное. Но на практике, тебе надо знать как бороться с ограничениями компилятора чтобы все-таки написать программу, вопреки ему. И для этого придется намного больше читать растовый букварь.

Что выигрывает программист - не понятно.

читать растовый букварь.

читать вообще полезно. читай и пиши safe код.

Что выигрывает программист - не понятно.

выигрывает пользователь, когда программы перестают падать.

но есть dumb-ass программисты, которые всеравно будут считать себя невмеру крутыми, не совершающими ошибки и использующими unsafe язык:(((

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

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

Зачем? Пиши тогда на С++.

А что он написал, доктор этот? Ядро линукса? Или просто докторскую?

В C++ надо знать букварь.

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

Просто в расте это спрятано в «опасные» блоки

даже на расте.:(

ты собственно программист, который не готов писать memory-safe код, потому что считаешь свое знание букваря важнее.

Я тебе в десятый раз повторяю. Мне не могли дать мемори сейф инструмент, потому что на нем нельзя было бы написать программы.

Вот же я гад, правда? Хочу чтобы на языке еще и программы писать можно было, а не только дрочить на баззворды!

да я на 100% уверен, что ты тоже не пишешь ядро ОС. поэтому твое отрицание Rust какое-то чисто религиозное: мне он не нравится, значит, он плохой.

на нем нельзя было бы написать программы.

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

Ну вот пусть сосиска придет и пояснит, как написать стандартную библиотеку раста без использования unsafe. Я с интересом послушаю

@cocucka!

Никто не пишет. Там unsafe везде в стандартной библиотеке, о чем мы говорим вообще.

На чистом safe rust ничего написать нельзя кроме 2+2

Мне не могли дать мемори сейф инструмент, потому что на нем нельзя было бы написать программы.

А вот там в докторской написано что дали.
И на нём пишут программы.

А на заборе написано одно, а за ним дрова. На safe rust целиком программ в природе нету. Ну или покажи их, посмотрим. Может в диссерах академические примеры есть.

На чистом safe rust ничего написать нельзя кроме 2+2

fine by me

UNIX way rule number 2:

2. small programs that do only one thing, but do it well

Вот ты и сможешь делать one thing. Одну - 2 плюс 2. А другую one thing уже не сможешь.

https://github.com/uutils/coreutils

Спасибо, хорошее подтверждение тому что я пишу.

Чё? Джим и прав, и не прав насчёт unsafe.

Прав в том, что в расте в стандартной библиотеке полно unsafe. Да, много чего без этого не написать. Работа с памятью, вся хуйня.

Не прав в том, что в прикладных программах без unsafe не обойтись.

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

Я говорил что на чистом safe нельзя целиком сделать.

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

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

Я говорил что на чистом safe нельзя целиком сделать.

ну это то же что @cocucka и говорит

Не прав в том, что в прикладных программах без unsafe не обойтись.

что в расте в стандартной библиотеке полно unsafe

она статически включается при компиляции в программу или как? когда эти куски участвуют?

Це ли ком

Ты понимаешь что это слово значит?

зачем целый новый язык ваять с кучей ограничений

ограничения делают его safe, в отличие от с++, на котором ты «якобы можешь» писать безопасный код.

нет не понимаю. прикладная программа в rust статически включает библиотеки, емнип. что здесь целиком, а что не целиком, мне не понятно.

Статический анализатор делает из C++ safe. Зачем новый язык?

В библиотеках unsafe, в твоем личном коде safe. Через библиотеки ты работаешь с ОС, с памятью, с внешними данными. То есть unsafe из них используется у тебя всегда, постоянно.

Но - ты его не писал, это стандартный код из библиотек. Твой прикладной код может быть safe.

видимо, не делает, раз постоянно программы падают. rust тебя принуждает писать safe, а на c++ ты ковбой.

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

Да, именно. В с++ есть средства для написания безопасного кода, std::unique_ptr, RAII и т.д. Проблема только в том, что они опциональны. Семантика языка не поощряет их использование.

Раст же в этом плане более строг, ибо тебе придётся писать обёртки для любого небезопасного кода.

В библиотеках unsafe, в твоем личном коде safe.

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

Кстати, в яве тоже есть своего рода unsafe, но никто по этому поводу не возбуждается. А реализация JVM вообще на с++.

зачем целый новый язык ваять с кучей ограничений

чтобы избавиться от легаси, которое добавляет человеческих ошибок

Ты не избавишься от легаси. Ты не можешь переписать весь мир с нуля на расте.

А взаимодействие любой safe песочницы с unsafe легаси средой сводит на нет всю безопасность.

Поэтому, как выше заметил @cocucka, и в джаве есть «unsafe» для работы с внешним миром. И как следствие, джава проекты точно так же сегфолтятся. Просто сегфолт будет локализован в unsafe блоке.

Проблема только в том, что они опциональны. Семантика языка не поощряет их использование.

Еще раз. Примени статический анализатор сделай их обязательными.

Что мешает это сделать?

Статический анализатор вещь хорошая, но это не панацея. Его всегда можно отключить/проигнорировать/неправильно настроить.

Вчера, вот, обсуждали с коллегами баг с NPE, который должен был выловить статический анализатор, но не выловил, собака. А если бы это был код на котлине (который заставляет тебя писать null-безопасный код), а не на чистой яве, то этого бага бы не было. Вот так же и с с++ vs rust.

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

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

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

@Minona

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

Те же байки писали 25 лет назад про Java, что все будет безопасно, вы не можете переполнить буфер, не можете освободить дважды и далее по списку. Через 25 лет сосиска пишет, что они в чистой джаве статическим анализатором NPE ловят. Вот это теория/реальность.

Так же и с растом будет. Как невозможно все на свете переписать на чистой Java, так и на расте не перепишут.