Комментарии 11
Как и зачем ТС умудрился к 3 компилируемым языкам добавить js непонятно.
Так же по концепции уместнее было бы добавить сюда zig и C4, а там зачем то 3 языка с GC и один без GC а в сравнении C++ и Rust обнюхаються нейронок и совсем думать перестают лишь бы контента фармануть.
Срамота...
Затем, что благодаря JIT долгоиграющий JS на дистанции может уделать всех, особенно если программист небрежен и оставляет ненужные вычисления.
Как и зачем ТС умудрился к 3 компилируемым языкам добавить js непонятно.
Сравниваются же модели управления памятью, а не способ компиляции, скорость компилятора или скорость вычислений. JavaScript runtime тоже выделяет, отслеживает и освобождает память, поэтому его подход вполне можно сопоставлять с подходами других runtime.
C++ и Rust в разделе с бенчмарками тоже выбраны не мной: реализации на этих языках входят в исходный набор тестов автора Goose.
Rust управляет через Ownership и borrow cheker и возможностью руками, C++ это полностью ручная система, JS это язык с GC который в принципе не имеет механизма влияния сравнивать его некорректно поскольку есть огромный пласт задач которые можно легко сделать с помощью Rust, C++, Zig и любым языком без GC и которые даже технически невозможно сделать любым языком который использует GC.
Я понимаю еще если бы это было в статье например про REST API то окей т.к эту задачу можно сделать и на язке с GC и без, т.к он тут никакой роли не играет но добавлять это в статью где 80% времени идет речь об управлении памятью это все равно что сравнивать скорость воздушного шара с моторной лодкой.
сравнивать его в принципе некорректно
Сравнивать можно что угодно, яблоки с апельсинами, воздушный шар с лодкой и так далее. Сравнение даёт возможность понять, например, когда нужно использовать воздушный шар, а когда - лодку.
А уже сравнение GC vs non-GC… Вот, например, сравнивают Quantifying the Performance of Garbage Collection vs. Explicit Memory Management.
Нет фундаментальных запретов на сравнение. Можно аргументировать, что методика сравнения некорректна, там, игнорирует ключевые свойства объектов. Статья сравнивает качественные характеристики подсистем управления памятью - скорость работы (с памятью), простоту использования и безопасность. Всё это вполне можно идентифицировать для javascript. Что-то важное для последующего анализа пропущено?
Сравнивать можно что угодно, яблоки с апельсинами, воздушный шар с лодкой и так далее.
так вам никто не запрещает, просто вопрос какой в этом смысл? Сравнения подобного рода всегда будут иметь слишком много "Но" и "Если", а также некоторые люди могут сделать заключения о тех уровне сравнивающего не в его пользу.
Условно пойдете вы на собес, а там спросят ( в команде ) знает его кто то? И человек скажет "ну да видел этого посты, этот чудак на хабре в сравнии с компилируемыми языками JS указывал" и вот вроде хотели сделать хорошее дело а получилось не очень.
P.S C++ и прочие разработчики особенно старой закалки в принципе нелюбят когда где-то рядом по любой из причин появляется JS или те кто пишут на нем, т.к искренне считают что JS превратил весь имеющийся итенрнет в забагованное нечно весом в теробайты и пожирающее тонны оперативной памяти.
Как будто на C или Go нельзя сделать то же самое.
Правило Goose: на одном стеке может находиться только один “живой” resizable-массив. Если одновременно живут три таких массива, компилятор использует три стека
Похоже даже java позавидует потреблению памяти.
На C или Go это действительно можно реализовать. Но придётся пожертвовать хотя бы одним из трёх качеств: либо усложнится код, либо в управлении памятью останется GC, либо ослабнут гарантии безопасности.
Похоже даже java позавидует потреблению памяти.
Не очень понял, что имеется ввиду. На всякий случай. Три датастека по 2 GB это не 6 ГБ занятой RAM. Резервируется виртуальное адресное пространство, а физическая память подключается по мере использования. В табличке приведено, сколько именно физической памяти используется для некоторых кейсов.
Я просто оставлю это здесь:

Ты не бойся, это Goose