История изменений

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: 1) https://blog.janestreet.com/oxidizing-ocaml-ownership/ 2) https://blog.janestreet.com/oxidizing-ocaml-parallelism/

Там и опциональные линейные типы, которые не заставляют программиста изворачиваться, когда его логика не вписывается в них.

Настоятельно рекомендую почитать, там очень доступно описаны проблемы Rust, и то как нормальный язык их решает. В том же цикле есть обсуждение инструментов для написания кода который не вызывает GC вообще.

Заключение: Фанаты Rust это луддиты которые застряли в модели Fortran 66, и боятся одной только мысли, что возможна какая то автоматизация в инструментах программирования.

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: 1) https://blog.janestreet.com/oxidizing-ocaml-ownership/ 2) https://blog.janestreet.com/oxidizing-ocaml-parallelism/

Там и опциональные линейные типы, которые не заставляют программиста изворачиваться, когда его логика не вписывается в них.

Настоятельно рекомендую почитать, там очень доступно описаны проблемы Rust, и то как нормальный язык их решает. В том же цикле есть обсуждение инструментов для написания кода который не вызывает GC вообще.

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: 1) https://blog.janestreet.com/oxidizing-ocaml-ownership/ 2) https://blog.janestreet.com/oxidizing-ocaml-parallelism/

Там и опциональные линейные типы, которые не заставляют программиста изворачиваться, когда его логика не вписывается в них.

Настоятельно рекомендую почитать, там очень доступно описаны проблемы Rust, и то как нормальный язык их решает.

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: 1) https://blog.janestreet.com/oxidizing-ocaml-ownership/ 2) https://blog.janestreet.com/oxidizing-ocaml-parallelism/

Там и опциональные линейные типы, которые не заставляют программиста изворачиваться, когда его логика не вписывается в них.

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: https://blog.janestreet.com/oxidizing-ocaml-ownership/

Там и опциональные линейные типы, которые не заставляют программиста изворачиваться, когда его логика не вписывается в них.

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: https://blog.janestreet.com/oxidizing-ocaml-ownership/

Вот опциональные линейные типы, которые не заставляют программиста изворачиваться, когда его логика не вписывается в них.

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust, там начинают применять счетчики, а в языке более высокого уровня, может быть решение лучше.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: https://blog.janestreet.com/oxidizing-ocaml-ownership/

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где совсем невозможно статически определить время жизни переменной, но в таких случаях обычно руками уже ничего не сделаешь и в C/Rust.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: https://blog.janestreet.com/oxidizing-ocaml-ownership/

Про GC конечно смешно написал, я сначала подумал ты про Rust, где RC-GC рантаймовый, самый худший из GC.

Причем в Rust сам программист еще подрабатывает за GC, без получение преимуществ из С где программист может использовать недоказуемое, но рабочее и быстрое решение по управлению памятью.

А есть подход с автоматизацией, как в ML Kit, когда компилятор не просто помещает все в GC, если он видит что переменная не используется за пределами функции то он выделит ее в стеке. А если они перемещаются, он выводит область в которой переменная может находится, и сам строит арены для объектов на разных уровнях кода, которые обеспечивают быструю аллокацию и очищение. В такой модели GC существует лишь там, где невозможно статически определить время жизни переменной.

И все это без мучения программиста как в Rust. Вот еще если кажется что я говорю только про какие то академические, несуществующие вещи: https://blog.janestreet.com/oxidizing-ocaml-ownership/