Как у Rust с рефлекшном?

Продвижения в этом плане есть. https://github.com/dgrunwald/rust-cpython Не копал как оно там внутри. Пока нестабильно и требует nightly версию компилятора.

Безопасность и GC ортогональны.

Ты ведь понял мысль или хочешь поспорить?

А double free, например, имеет

Если ты используешь GC в C, то ты и не такое сможешь сделать=)

GC избавляет кодера от необходимости самостоятельно реализовывать логику управления памятью.

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

GC - это просто один из механизмов управления памятью.

Понял не до конца. rust, как я понимаю, просто предоставляет аналоги unique_ptr/shared_ptr(кстати, аналог weak_ptr есть?) + контроль работы со ссылками на этапе компиляции. Это так же ортогонально GC. Он вполне мог бы быть в Rust, лучше всего опционально.

из треда повалил дым

кстати, аналог weak_ptr есть?

Да.

...GC. Он вполне мог бы быть в Rust, лучше всего опционально.

И будет. Именно опционально.

Тем более непонятно, почему ты тогда противопоставил GC и механизмы Rust

почему ты тогда противопоставил GC и механизмы Rust

Потому что Rust гарантирует memory safety, не прибегая для этого к gc.

Потому что Rust гарантирует memory safety, не прибегая для этого к gc.

Ты выше сообщения читал? GC - это просто (еще один) механизм управления памятью. Memory safity и GC ортогональные вещи.

Они не настолько ортогональны, насколько тебе хочется считать. Давай составим список языков общего назначения, где компилятор формально верифицирует программу на предмет memory safety, и при этом сборка мусора не является обязательной.

Я начну:
1. Rust
2. ??? продолжай

Потому что Rust гарантирует memory safety, не прибегая для этого к gc.

А зачем для memory safety прибегать к GC? Тем более, что он никакой memory safety не гарантирует(если я использую Boehm GC в C, мой код сразу станет memory safety?).

Давай составим список языков общего назначения, где компилятор формально верифицирует программу на предмет memory safety, и при этом сборка мусора не является обязательной.

Для начала, давай составим список языков общего назначения, где компилятор формально верифицирует программу на предмет memory safety.

Я начну:

1. Rust 2. ???продолжай

Далее из этого списка попробуем найти языки с обязательным GC... Хм. В Rust его нет...

он никакой memory safety не гарантирует

Однако он лежит в фундаменте почти всех языков, гарантирующих memory-safety.

А зачем для memory safety прибегать к GC? Тем более, что он никакой memory safety не гарантирует(если я использую Boehm GC в C, мой код сразу станет memory safety?).

Ты хотел сказать, что некоторые GC, например, Boehm GC, не гарантирует memory safety?

Однако он лежит в фундаменте почти всех языков, гарантирующих memory-safety.

Но так же он есть в modula2, где две кучи, он доступен в Си через библиотеки в духе boehm gc. И там нет memory-safety. С другой стороны, GC нет в Rust, который memory-safety гарантирует.

Ты хотел сказать, что некоторые GC, например, Boehm GC, не гарантирует memory safety?

Я хотел сказать, что никакой GC не гарантирует memory safety, т.к. это забота не GC, а языка программирования. GC мусор собирает.

Я хотел сказать, что никакой GC не гарантирует memory safety, т.к. это забота не GC, а языка программирования

Да, Капитан. Но интересно было бы увидеть список языков, гарантирующих memory safety, и при этом не использующих GC. Кроме Rust, конечно.

Для начала, давай составим список языков общего назначения, где компилятор формально верифицирует программу на предмет memory safety.
Я начну:
1. Rust 2. ???продолжай

Продолжаю:
2. java
3. c# / .net
4. go
5. python

Хватит пока?

Хватит пока?

Врать? Действительно хватит. Ни один из тобой перечисленных языков формально не верифицирует программу на предмет memory safety

Кстати, Go не гарантирует memory safety в смысле Rust - возможен несинхронизированный доступ к памяти из разных нитей (думаю, все остальные - тоже).

Это race safety

Нет.

Кроме Rust, конечно.

А почему кроме него? Он вполне иллюстрирует то, что я говорю. Так исторически сложилось, что языки без гарантии memory safety не используют GC. И, наоборот, языки с memory safety используют так же и GC. Да, если мы используем GC(и только его), то у нас задача обеспечения memory safety в языке упрощается, не спорю. Но тут еще требуется обязать использовать GC и не разрешать другие механизмы. Сам же по себе GC ничего не гарантирует.

А почему кроме него?

Потому что он появился в 2015 и о нем мы уже знаем.

Можно подробнее?

https://en.wikipedia.org/wiki/Go_(programming_language)

«Go's internal data structures like interface values, slice headers, and string headers are not immune to race conditions, so type and memory safety can be violated in multithreaded programs that modify shared instances of those types without synchronization»

Битва анонiмуса с анонимусом. Хочу увидеть битву анонiмуса с царем.

Ой, уже забанили.

Принято. Благодарю

Хочу увидеть битву анонiмуса с царем.

Уже было. Победил tailgunner

В смысле как всегда обосрался и потопил топик в говне?

как я понимаю, просто предоставляет аналоги unique_ptr/shared_ptr(кстати, аналог weak_ptr есть?) + контроль работы со ссылками на этапе компиляции.

Да.
Аналог weak тоже есть.

Тем более непонятно, почему ты тогда противопоставил GC и механизмы Rust

Попробую обьяснить: ГЦ позволяет уделять (гораздо) меньше внимания управлением памятью и заодно избавляет от традиционных ошибок ручного управления. Да, ты можешь сказать, что и у ГЦ есть свои проблемы и выстрелить в ногу можно, не спорю. Сказать хотел только то, что раст тоже избавляет от ошибок типа двойного освобождения и т.д. Разумеется, выстрелить в ногу можно и тут.

Но тут еще требуется обязать использовать GC и не разрешать другие механизмы.

Обойти гарантии раста тоже можно, но это не значит, что их нет.

Ололо. Уеб-макака имеет наглость иметь мнение. Цирк!!!