• Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    0
    (grammar-nazi-mode компонуются), но по сути согласен
  • Краткая история Rust: от хобби до самого популярного ЯП по данным StackOverflow
    +1
    Когда есть опыт в OCaml и Haskell, высокоуровневые части не кажутся приятными. Слишком громоздко.
  • Реализация «Тетриса» в игре «Жизнь»
    +6
    Оно, конечно, очень круто всё. И мне всегда было крайне интересно, откуда у людей берутся ресурсы времени и деньги на разработку подобных проектов?
  • Google планирует представить облачный сервис для квантовых вычислений
    +1
    Программа — это граф из унитарных операторов и измерений. Можно примерно представлять это себе, как последовательность умножений вектора огромной размерности (2^{число кубитов}) на соответствующей же размерности матрицы. Квантовый алгоритм — это алгоритм, который по входным данным строит такой вот граф из операторов.
  • Google планирует представить облачный сервис для квантовых вычислений
    0
    Я тоже это имею в виду. Там смысл очень простой: сумели поймать в ловушку много атомов (это давно умеют делать), чуть-чуть покрутили некоторые параметры взаимодействия (это новизна) и проинтерпретировали результаты, как симуляцию системы из нескольких спинов специального вида (чтобы грант дали). Сама работа, как физический эксперимент, интересная, но шагом к большим квантовым вычислениям её можно считать с большой натяжкой кота за одно место в ящик.
  • Google планирует представить облачный сервис для квантовых вычислений
    0

    Ну, про 51 кубит старая технология. Ошибок там очень много и, опять же, это не большое произвольное когерентное состояние.

  • Google планирует представить облачный сервис для квантовых вычислений
    +1

    Да можно сделать хоть миллион. Проблема в том, что надо создать 128 запутанных кубитов и оперировать ими как одним целым. В этом проблема. D-Wave так не умеет

  • Google планирует представить облачный сервис для квантовых вычислений
    0
    А какие текущие идеи есть о масштабировании и увеличении числа кубитов? Чё-то как-то ни о каких технологических прорывах давно не слышно. За счёт чего будет 50 кубитов-то?
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    0
    Ну, насколько я знаю, если нужно вычислить дискретный логарифм на эллиптической кривой над полем с 384-порядком, требуется проанализировать 2^192 вариантов. Которые, собственно, и надо все «упихать» в когерентное состояние.
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    0
    В кубиты ничего не записывается. Кубиты, в некотором смысле, «поворачиваются» в нужное положение при помощи унитарных преобразований. А эти преобразования абсолютно точные, потому что работают на уровне физических симметрий (можно вспомнить спектры). Проблема в другом, сложно поддерживать большое когерентное состояние.
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    +1
    Китаев А., Шень А., Вялый М. «Классические и квантовые вычисления» — хорошее введение.
  • Постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?
    +1

    Сможет, если построят достаточно большой КК (нужно 192 когерентных кубита, а пока IBM говорит, что у них есть 16; и не факт, что есть на самом деле). Но для этого могут быть существенные физические ограничения.

  • Система синтеза асинхронных схем Petrify: проблемы и их решение
    0
    Дело не в публикациях, но изложенно совсем не понятно. Вроде, кажется, что-то полезное, но сложно понять, что именно.
  • Почему стоит полностью переходить на Ceylon или Kotlin (часть 1)
    –1
    Сейчас учат Python
  • Почему стоит полностью переходить на Ceylon или Kotlin (часть 1)
    0
    Либо ему просто стало скучно 90% рабочего времени тратить на ковыряние в памяти, указателях и интерфейсах, и он решил выйти на 80-ый уровень искусства программирования.
  • О том, как в Instagram отключили сборщик мусора Python и начали жить
    +1
    Ну, наверное, они достаточно хорошо знают о своих зависимостях, чтобы не рисковать.
  • О том, как в Instagram отключили сборщик мусора Python и начали жить
    0
    Дело не в самой сборке мусора, а в том, насколько она эффективна. В Python за эффективностью никто никогда не гонялся. Ну и, обычно, когда действительно важна скорость, то, скорее всего, Вы просто непишете некий custom-вариант сборки мусора. Размазывать malloc/free по коду тоже не самая лучшая практика для повышения произвоидтельности.
  • О том, как в Instagram отключили сборщик мусора Python и начали жить
    0
    Неясна реальная логика вызова GC в finalize(). Зачем собирать мусор, если все равно всю память при выходе отдавать? Молодцы, что поймали.


    Python же рассчитан на работу не только в операционках с поддержкой виртуальной памяти. Его ещё и просто встраивать можно.
  • Современный подход к сборке мусора
    0
    Пытался, согласен с тем, что неочевидно, как писать производительный код. Но тут акцент был таким: Haskell — язык не самый удобный, но алгоритмы со сложной логикой на нём проще писать, чем на Си++, благодаря сборке мусора.

    Сборка же мусора сама по себе не мешает добиваться высокой производительности и спускаться на уровень ассемблера. Примером может служить GOAL (вообще Lisp), которым до сих пор пользуются в Naughty Dog для программирования игр.
  • ВВС США используют нейроморфный чип IBM для обнаружения танков и наземных систем ПВО
    +1
    Существует эмулятор Compass и MATLAB-библиотека Corelet Library, позволяющи собирать образы из готовых блоков. Было бы интересно узнать и про внутренности самих процессоров, но таких сведений нет. Пока всё описывается уж в чрезчур общих словах для готового работающего изделия. Причастность современных ВВС США только добавляет сомнений
  • Современный подход к сборке мусора
    0
    Так в том-то и дело, что нет безопасных языков в природе почти. Просто… нет. История про Java — описана выше. Вот вам про python.

    То есть сдалать-то безопасный язык можно… а потом добавляются фичи, ещё фичи, примочки, хотелочки… и оп-па: язык у вас, оказывается — небезопасный. Его, оказывается, нужно на уровне операционной системы ограничивать. А тогда, извините, за что мы, собственно, платим?


    Безопасные языки есть. И есть безопасные системы. Я уже приводил пример MirageOS. Unsafe-режимы нужны, в основном, именно для того, чтобы вписываться в существующие native-экосистемы или использовать native-библиотеки, потому что родных нет. Если такой необходимости нет, то можно написать операционку типа House, и жить целиком на Haskell, на одной дискете и не испытывать проблем с производительностью.

    Native — это не технологическая необходимость, а экономическая. Я уже говорил, что да, действительно, это важный фактор. И моя точка зрения заключается в том, что именно он самый важный фактор в устойчивости текущих основанных на Си/Си++ программных экосистем. Просто кода понаписано столько, что его уже не перенести никуда за разумные деньги. Не в скорости тут дело совсем. Уже довольно долго существуют безопасные системы, которые по скорости исполняемого кода уделывают Си/Си++. ATS, например.

    А вот тут — в точку. Программа — это газ. И её сложность — тоже. Вася не сможет реализовать менее эффективную схему управления/ ресурсами на языке без GC. Просто не сможет. Его программа — будет падать и всё.


    Да ладно!? Такое ощущение, что Вы никогда не сталкивались с говнокодом. У меня был случай, когда нам пришлось искать баг в программе, в которой каждый день утекал один мегабайт данных. Мы нашли места утечек при помощи Valgrind. Мы даже поняли, почему так происходит. Но исправить ничего у нас не получилось, потому что мы не смогли переписать код, там сотни тысяч строк кода и наивные попытки просто его роняли. Можно было бы зарефакторить всё, но никто бы нам этого не оплатил. В итоге, заказчик просто каждый день стал перезапускать приложение. Вот Вам и эффективность.

    При этом, программа вполне себе работала два месяца подряд, потом падала, потом снова работала.

    И я сомневаюсь, что это нетипичная ситуация.

    Действительно: а чёб нам не ввести подсистему, которая должна нам всё «улучшить», а потом начать её героически преодолевать? И всё равно GC нет-нет да отжирает свои ресурсы, так как отключить его полностью в Java нельзя.


    Да никто и никогда не считал GC «улучшением». GC — это необходимое зло в безопасных системах. И с ним точно так же, как скажем, с количеством системных вызовов в Си-программах, или с количеством синхронизаций в параллельных программах яростно сражаются, пытаясь всячески развить и компиляторы, чтобы точно вычислять регионы использования ресурсов, и придумать способы эффективного программирования.

    Борьба идёт именно за безопасность, а не за сборку мусора. Сможете предложить, как делать безопасный код с ручным управлением памятью — сообщество возрадуется. Но, к сожалению, это принципиально невозможно.

    А это уж «кто на что учился», извините. Грамотно написанная программа никакой особой боли не вызывает, не больше чем программа на Java. А неграмотно — тут да. Программа на Java, написанная кривыми руками обеспечит целое пополение «условных индусов» работой на годы вперёд. Подобная же программа на C++ — просто не заработает. Но является ли это недостатоком Java и проблемой C++? Зависит от ваших задач…


    Ещё как заработает! Нет, ну в самом деле. Вон в соседней статье обсуждают косяки в коде MySQL.

    Кстати. Вы сужаете тему принудительно к Java против C++. Java, действительно, не является идеальным языком с точки зрения надёжности, безопасности и технологической продвинутости. Тут бы со Scala надо сравнивать.

    Но есть и другие языки, в которых всё намного лучше. А сама технология безопасных языков и language-level os развивается. Пока в академическом сообществе. Может быть, она там останется навсегда. А, может быть, и не останется. Уж слишком хорошо иногда получается. Снова упомяну ATS и Arrp.
  • Современный подход к сборке мусора
    0
    Да, идея была красивой. Но… не работает. Без аппаратной поддержки — не работает. Вот, собственно, официальная капитуляция.


    А в чём Вы видите факт капитуляции? Ну да, на поддержку Applet-ов забивают постепенно, потому что есть JavaScript. Вполне естественно, об этому говорили ещё тогда, когда V8 только появился.

    Java вообще и сборка мусора в частности — это прекрасная иллюстрация известного принципа: на всякий сложный вопрос имеется ответ – ясный, простой и ошибочный.


    Сборка мусора никогда не была ясным и простым ответом на проблему. Ясный и простой ответ — это просто запретить свободную динамическую память, как в Fortran. Всегда было понятно, что сборка мусора — штука сложная и требует много усилий для реализации. Но так же было понятно, что во многих сценариях она необходима.

    Тут же дело какое. Сборка мусора — это не просто способ управления памятью, это, действительно, техника которая влияет на всю систему конкретного языка. Если сборки мусора нет, то библиотеки надо писать одним способом, а если есть, то можно писать другим. И со сборкой мусора библиотеки могут быть гораздо более гибкими. А это тоже важно, если программист может не тратить 50% своего времени на продумывание схемы управления ресурсами, а сразу реализовывать алгоритм.

    На Си++ тоже, наверное, можно сразу сесть за реализацию, ничего не продумывая в плане потока ресурсов. Но лично мой опыт показывает, что потом 10 раз придётся всё переписывать.

    Скорость разработки тоже штука важная. И это было понятно ещё во времена Алгол-68.

    Ну да. А сколько они тратят на обслуживание двух видов виртуальной памяти друг над другом??


    В смысле? В безопасных языках нет виртуальной памяти. На том и стоят. А когда они работают с виртуальной памятью, то продвинутые системы типа .Net или Java пытаются её задействовать в свою пользу. Например, используют cow-отображения страниц при копировании больших объектов. Можно так сделать на Си++? Можно. Но кто же так будет делать? На Си++ скорее всего, человек просто наплодит адову схему из перекрёстных ссылок.

    И тут возникает вопрос, а что считать стоимостью? Ведь, код пишут люди. Люди пишут через пень-колоду. И не факт, что та схема управления ресурсами, которую написал Василий, будет эффективнее, чем сборка мусора. Программы-то сложные.

    Кроме того, никто не отменял техники оптимизации. Можно оптимизировать код со знанием того, что он будет работать со сборкой мусора. Пишут же люди довольно быстрые игры на Java. Просто выделяют несколько больших массивов для хранения всего необходимого и сборка мусора их почти не касается.

    Просто потому что проигрывает в скорости другим подходам.


    Нет объективных данных, что проигрывает. Проблема со сборкой мусора не в проигрыше вообще по скорости, а в том, что есть проблема непредсказуемых задержек. В среднем, в пакетных режимах, сборка мусора забирает до 5% времени (в равнении с виртуальной памятью — копейки), в зависимости от задачи.

    Проблема именно с непредсказуемыми задержками. Но опять же. Когда всё живёт поверх виртуальной памяти, то никаких гарантий на задержки тоже нет. TLB будет вносить неопределённости, операционка будет дефрагментацией заниматься, cow-процессы будут происходить.

    Автоматически от использования Си++ проблема не исчезнет. Для гарантии задержек нужно будет специальным образом писать код и специальным образом резервировать ресурсы. Но в точности такое же можно делать и в системах со сборкой мусора. Там есть технологии realtime-пулов памяти и всего такого прочего.

    Гарантированных времён реакции системы можно добится и с одной техникой, и с другой. В конце концов всё упирается в умения и навыки программиста. И это очень важный экономический фактор.

    Ну, а здесь, как ни крути, Си++ Java совсем не конкурент. Даже на Haskell писать проще, чем на Си++. Потому что на Си++ элементарно отстреливаешь себе все конечности, и даже не знаешь, что именно оказывается отстреленным. Отладка больших Си++ программ — вот истинный источник боли и унижения в современном мире.
  • Современный подход к сборке мусора
    0
    Но почему нерациональное? Основной мотивацией порыва SUN в сторону Java была же простое желание: даль сложному софту работать на более простых процессорах. И дело даже не в чайниках, а в том, что они посчитали: их сервра под нагрузкой тратят 30% времени на обслуживание виртуальной памяти. Это без подкачки, просто на управление TLB, создание областей разделяемой памяти, fork-и и прочие такие вещи. У меня где-то статья даже эта завалялась в коллекции. Мотивация у Java — это более рациональное использование ресурсов: зачем проверять каждый доступ в память, если можно гарантировать, что они всегда будут верными?
  • Современный подход к сборке мусора
    0
    Они просто наиболее известны. А так — да, попыток было много.


    Так в том-то и дело, что Lisp-машины не были «попыткой». Это было развитое направление в индустрии. И развивались они быстрее, чем UNIX и Си. И успехов там было много. Люди вот об этом помнят. Поэтому и стремятся повторить успех. Тем более, на новом уровне производительности и технологий можно более интересные вещи делать.

    Ага. И продемонстрировала proof-of-concept с поддержкой scheme и tcl в 1995 году. На календарь давно смотрели?


    И что? Non-profit же. Хотят — делают, хотят — не делают. Guile вообще долго не развивался, но пару лет назад за него снова взялись.

    И да — побочные эффекты часто двигают индустрию вперёд. А вот «философский камень» всё как-то не вырисоывается… Такая «современная алхимия»…


    Да никто там не ищет «философского камня». Просто есть проблемы, есть подходы к их решениям, есть люди, которые верят в эти подходы и работают над ними. Си/Си++ же тоже не идеальны. Да, код быстрый, но работать с динамическими данными тяжело. Если на Java можно написать WebSphere, а на Erlang ту же Riak, то можно ли это сделать на Си++? Ну, не знаю. Никто почему-то не сделал. Почему?

    Чего хорошего в том, что люди пишут 100 парсеров JSON'а и 500 http-серверов? Хорошо хоть TCP/IP стек системный используют.

    Лучше бы вместо того, чтобы разрабатывать 100500 изолированных миров подумали бы о том как делать систему в которой можно программировать на разных языках — но почему-то все попытки так сделать приводят только к ещё одному монстру, который пытается в себя втянуть весь мир…


    А люди и так напишут 100 парсеров JSON-а, даже если у них будет один язык программирования. А потом напишут ещё парсеры для других языков программирования. И так далее. Ну, и, люди любят вообще-то искать свою идентичность в каких-нибудь малых группах. Мы вообще не приспособлены ощущать себя хорошо в многомиллионных однообразных коллективах. Поэтому вот так вот.

    Но я не понимаю, а чего Вы так переживаете? Вряд ли экосистема UNIX/Си в ближайшее время куда-нибудь пропадёт. Работы в ней для всех хватит. Маловероятно, что Intel, Apple или Google накроются медным тазом и GCC или LLVM останутся без финансирования и остановятся в развитии.
  • Современный подход к сборке мусора
    0
    А чем Вам так не нравятся Lisp-машины? Исторически, именно на Lisp-машинах было воплощено впервые всё то многообразие идей, с которыми мы сейчас имеем дело. Там были GUI, векторная вёрстка, сетевые протоколы, мультимедия и CAD-ы. Вообще, что было на Lisp-машинах в конце 80-ых на PC появилось только в конце 90-ых, и не в полном объёме. Да что там говорить, даже TCP/IP впервые на Lisp-машине появился. Проблема Lisp-машин даже не в технологиях была, а в том, что Symbolic (основной драйвер Lisp-индустрии) втянулась в какую-то аферу с недвижимостью и прогорела. Но осколки Symbolic живы, и часто являются лидерами в своих направлениях. Например, именно благодаря Lisp-машине NaughtyDog умеет делать огромные бесшовные миры для Uncharted (это к вопросу о производительности; они вообще только из-за давления Sony переписали движок на C++, Lisp их вполне устраивал и по скорости, и по возможностям писать низкоуровневый код).

    И это только экосистема Lisp. А есть ещё экосистема ML. Тоже с довольно интересной историей и своими текущими успехами, в том числе, в высокопроизводительных системах. Вот Вы когда заходите на https://mirage.io/, почему, как Вам кажется, оно тормозит? А вот и нет. Потому что они стартуют виртуальную машину с runtime ML внутри под конкретно Вашу сессию.

    И есть ещё экосистема Haskell. Там тоже интересно.

    Это я всё к чему? К тому, что идея языковой операционной среды жизнеспособна. Тем более, в наше время. Никому не интересно, C++ в приложении поверх Linux, или же Lisp на голом железе, главное, чтобы на JSON и HTTP умел общаться с окружающим миром.

    Ну, то есть, скорее всего, ждёт нас эпоха мультикультурализма в плане языков программирования. Будут экосистемы с разными базовыми языками (тут вот, например, GNU решила Guile Sheme допилить до VM и реализовать поверх неё Python, JS, Ruby и Lua), ну, а программист уже будет просто выбирать в какой экосистеме ему комфортнее.

    Экосистема С/С++ вряд ли куда-то пропадёт с этого праздника жизни и разнообразия, но возвращение Lisp-машин, или появление униядер ML, или мощных runtime-ов Go вполне, мне кажется, имеет смысл приветствовать.

    Повторюсь, людям это интересно, и это не давление сверху со стороны SUN или Microsoft, просто людям так эффективнее работается. Хорошо же.
  • Современный подход к сборке мусора
    0
    Эта идея вечна и постепенно воплотится в жизни. Это интересный challenge и люди не сдадутся. Да, может быть, пока это обратно всё ушло в НИР, но там прогресс довольно существенный.

    Советую вам ради интереса посмотреть на ICFP-2015 и ICFP-2016. Там довольно большая движуха именно на эту тему. Очень много объективно крутых проектов.

    Они пока ещё не вписаны в общую экосистему, но по отдельности впечатляют. Arrp какой-нибудь с глобальной оптимизацией и вращениями вычислений над многомерными массивами, и автоматическим параллелизмом (TensorFlow тихонько завидует в сторонке). Или тот же Ur/Web.

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

    Не очевидно, кстати, что SUN погорела именно из-за Java. У них много косяков в стратегии было.
  • Современный подход к сборке мусора
    +1
    У Эльбруса другая идея. И тоже не особо аппаратно экономная: нужно память тратить на тэги. Если нужна надёжность, то это отлично. Но скорость снижает и сложность архитектуры увеличивает.

    Но, я думаю, тут надо учитывать какие-нибудь экономические факторы. Singularity была бы настоящий disrupt-технологией. То есть, рынок железа существенно бы трансформировался. Может быть, поэтому решили не выпускать. А, может быть, просто Z3 был сырой, и не умел считать всё, что нужно.

    Но сейчас всякая такая техника то там, то здесь вылазит. Например: Ur/Web. Штука умеет целиком про клиент-серверное приложение с базами данных доказывать, что оно корректное, вычислять регионы жизни ресурсов и обходится без сборки мусора. Скорость на уровне C++, а кода раз в 10 меньше. Плюс GADT и всё такое прочее. Минус в том, что не для каждой программы она способна построить вывод всего того, что нужно, иногда вывод отрезается по глубине рекурсии. Но автор пишет, что, для обычных программ, а не специальных контрпримеров, всё нормально.
  • Современный подход к сборке мусора
    +1
    Крутые IDE, написанная на Си (я думаю, что нам тут не важно, на Objective или Plus Plus) — это, например, Microsoft Visual Studio, XCode или Open Watcom. ViM и Emacs, конечно, системы с другим подходом к организации проесса написания кода, но я бы не сказал, что они менее эффективны, чем IDE. А почему? А потому что, сюрприз: ViM и Emacs не на Си написаны, на Си написаны только их ядра, а основной функционал прописывается в скриптах (со сборкой мусора), которые дают намного-намного больше возможностей, чем типичная IDE. То есть, как бы, Вы мимо злорадствуете
  • Современный подход к сборке мусора
    0
    Это если объекты большие. А у серверных ребят наоборот всё. У них там куча мелких записей и сложные графы зависимостей между ними. Ну, вот да, стиль программирования такой. То есть, вполне бывает так, что одна запись о ФИО держит в памяти страницу целиком.
  • Современный подход к сборке мусора
    0
    Haskell ghc генерирует нативный код, конечно, но рантайм там жирноват, мягко скажем, не сишечный и даже не плюсовый, поэтому называть это нативным языком несколько странно. А так и JIT в итоге нативный код генерирует, но это же не повод.


    Среда для Си, как минимум, включает в себя операционку и некоторое количество защитного и отладочного железа в процессоре. Если мы хотим нечто минимально надёжное, то хотя бы регионы памяти надо поддерживать. А если мы хотим программу хотя бы на 1000 строк кода, то, как минимум, нужен JTAG. То есть, даже в low end микроконтроллерах не всё так просто.

    Runtime для Haskell тоже штука такая. Не исследованная. Никто же не пытался его максимально облегчить и оставить минимум необходимого. Насколько мне известно. О! Вспомнил. На самом деле, было такое. Проект House. Они запили полноценную операционку на 1.44 дискету. Микроядро там, конечно, L4 на Си. Но всё же.

    Я не говорю, что лучше, а что хуже. Но на картину надо смотреть в целом, с учётом аппаратуры и операционной системы.

    На самом деле, с Си ситуация довольно тяжёлая. Например, процессор вынужден постонно обеспечивать видимость строгого порядка доступа к памяти, потому что указатели. И если не обеспечивает, то приходится постоянно вставлять барьеры. А для Haskell такого не надо. И, значит, если у нас Haskell-экосистема, то мы можем позволить себе 16-ти ядерный процессор по цене 4-ёх ядерного, потому что можем транзисторы на ALU потратить, а не на MOB.

    И вот, как бы, сиди и думай над tradeoff-ами. Тут можно 10N диссертаций точно влёгкую написать.

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

    С другой стороны, вот приду я в условную новую компанию, пусть даже очень большую, а там на какие-нибудь 10к разработчиков хаскель знают хорошо если 50 человек. Тимлиду моему хаскель внедрять будет рискованно, непосредственным коллегам он тоже не сдался, им не пло́тют за изучение, дома семья-дети, какой хаскель ещё, да и вообще на плюсах неплохо кормят. И что делать?


    Так я и не утверждаю, что Си++ плохой. Я говорю, что он жизнеспособный, а это даже важнее, чем хороший. Но вопрос в том, чем поддерживается жизнеспособность? Обычно утверждается, что причина в скорости получаемого кода. Я же просто осторожно и, надеюсь, обоснованно сомневаюсь в этом утверждении.

    Вот в том же сценарии, когда у нас 10k программистов пишут на Си++, очень даже может быть, что на каком-нибудь Stalin Scheme они бы получали более эффективный код. Scheme — это динамический язык вообще; но картинка такая вот, тем не менее, в которой нужно учитывать, что GCC пишет 100 человек, а Stalin был написан одним профессором.

    Почему бы Stalin мог для них быть лучше? Потому что, все же понимают, что 10k программистов пишут, в основном, г-код. А особенность Stalin-а в том, что он процессе компиляции абстрактно исполняет программу, и процентов 50 г-кода посто выкидывает, заменяя константами.

    Но Scheme или Haskell вряд ли в такую компанию можно будет внедрить, у ней слишком большая масса, инерция и объёмы legacy-кода. Тем более, что Haskell может и не давать никаких profit-ов именно тем приложениям, которые в этой компании пишут, а осваивать его тяжело. Си++ же не такой уж и плохой язык, и он работает.

    Но а зачем в такую компанию внедрять Haskell? Я думаю, такие компании сами отвалятся. Если рядом будет компания, в которой 5k разработчиков, которые на Haskell делают то же самое, но в 2 раза дешевле, в 8 раз безглючнее, и работать оно будет в 64 раза быстрее, потому что на GPU хорошо уложится, то экономика сделает своё дело.

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

    Или вот ещё. Физики всегда любили Fortran. И до сих пор его нежно любят. Но постепенно все переходят на Python. Потому что profit: можно писать программы в 16 раза быстрее, чем на Fortran, а работают они примерно с той же скоростью, или даже в 100 раз быстрее, если попадают на GPU. И, кстати, так получается не только, потому что можно лего использовать библиотеки, которые уже были написаны на Fortran, но и потому что у Python хорошо подходящая для оптимизаций арифметическая семантика, и PyPy способен на чудеса (есть проект Pixie, который отдаёт PyPy абсолютно адский г-код, но JIT его вытягивает на отличную скорость).

    Как-то вот так вот оно сейчас неоднозначно. Вот 15 лет назад было хорошо. Хочешь скорости — пиши на Си или Фортран, и не заморачивайся. А сейчас нельзя не заморачиваться. Потому что слева сидит Василий, который ту же программу напишет на Python, в скорости проиграет процентов 15, но на рынок выйдет в 5 раз быстрее. А справа сидит Пётр, который ту же программу будет писать на Haskell, времени затратит, наверное, столько же, сколько и я, но он её ещё проверит при помощи Liquid, и ему не придётся потом полгода исправлять баги в production. И да, коды Васи и Пети тоже будут отлично работать на микроконтроллерах.

    И что вот с этим делать?
  • Современный подход к сборке мусора
    –1
    Апологеты GC не обещают надёжность и безглючность. Правильная формула такая: если нам необходимы надёжность, выразительность, и безглючность, то GC — это необходимый компонент системы. А дальше уже вопрос реализации и дизайна самого языка.

    Java вот совершенно не разрабатывалась для вычислительных задач. Но тем не менее, прогресс в скорости исполнения кода в Java-экосистеме впечатляющий.

    Но есть языки, которые специально затачивают пот вычисления. Вот, например, сравнение от IBM.

    Go, OCaml и Haskell, кстати, генерируют native-код и вполне способны работать с BLAS.

    А то, что у нас куча legacy-библиотек, учебников, дао в рабочих коллективах и прочего, что приводит к жизнеспособности языков, подобных Си++. Ну, да. Есть такое. Но это не техническая проблема. Культурная, скорее. Это тоже важно, конечно.
  • Современный подход к сборке мусора
    0
    Ключевое слово «можно». Идея живёт, вроде как. Не отпускает людей память о lisp-машинах.
  • Современный подход к сборке мусора
    0
    Я бы посмотрел на систему типов с такими аннотациями.


    Datafun
  • Современный подход к сборке мусора
    0
    Умеет. ХМ — это схема для вычисления типов по правилам типизации. Какие правила будут заданы, то он и выведет. Главное, чтобы правила были непротиворечивыми. Времена жизни в Rust тоже ХМ выводит.

    Не знаю. У меня такой опыт: я легко читаю библиотеки на Си (где, в общем-то тоже не шибко круто с типами) или Scheme, но мне очень тяжело читать Haskell или шаблоны в Си++. Типовые переменные увеличивают сложность и объём внимания, который надо уделять коду.
  • Современный подход к сборке мусора
    0
    Информации, на самом деле, очень много. Вопрос в том, как программист может зафиксировать интерфейсы и что он должен в этих интерфейсах фиксировать. Ну, и да, я не особый фанат динамических языков. Но и прописывать везде типы тоже не особо хочется. Даже если они абстрактные.

    Тут дело не в том, что тяжело кнопки давить. А в том, что хочется как можно быстрее переписывать программы. То есть, схема типов важна где-то на уровне интерфейса, а то, как я внутри это всё фигачу должно просто сойтись к этому интерфейсу. Но я хочу свободу в процессе «фигак-фигак и в продакшн» внутри модуля.

    Я бы в этом смысле Haskell бы считал идеальным, если бы мог читать его код спокойно.
  • Современный подход к сборке мусора
    0
    Так низкоуровневый системный код и на языках с GC вроде не особо пишется.


    Это интересный вопрос, на самом деле. Была, например, jNode. Там управление памятью прописано на Java, и пользователь мог даже свои писать сборщики. Конечно, в регистры процессора всё писалось при помощи ассемблера.

    Как-то вот так оно. Не очевидно.
  • Современный подход к сборке мусора
    0
    А я и не говорю, что написать код проблема. Я говорю, что изменить код проблема. И проблема даже не в том, чтобы аннотации написать, проблема в том, чтобы изменить их схему, придумать новую, которая бы вписалась в старый код, и в новый. Собственно, набор буковок — не проблема.

    IDE или REPL-ы вполне помогают разобраться с автоматическими типами функций.
  • Современный подход к сборке мусора
    0
    Ничем не лучше. Да и Java не настолько уж статичен. Загрузка классов же. Но я к тому, что прогресс ощутимый и в Java тоже. Опять же, с базами данных тоже не понятно. Люди вон вообще базы используют на Erlang, потому что иначе проблему просто не решить. Си++ не позволяет так масштабироваться. Я думаю, там в прямом смысле дилемма: либо писать на Си++ 30 лет, либо писать на Erlang лет 5. И не потому что программисты плохие, а потому что вот так вот оно просто потому что объективно сложно.
  • Современный подход к сборке мусора
    0
    Ссылка: мужики зарубились на задаче по обработке Англо-Китайского словаря.

    По производительности у них одинаково получилось. Но код со сборкой мусора сожрал на 5.5Mb больше.
  • Современный подход к сборке мусора
    0
    Ну зачем же каждый раз с нуля писать? Есть же готовые библиотеки.


    Ага. Только я боюсь библиотек, в которых есть управление памятью. Собственно, отсюда Rust и начался, потому что Mozilla задолбалась бороться с утечками. Это серьёзная проблема, к сожалению. Тут надо как-то аккуратно совместно разрабатывать и семантику языка, и методы управления памятью, и методы управления управлением памятью. Потому что realtime и сборка мусора не совместимы по определению на уровне современных технологий.

    А хотелось бы. IMHO, было бы прекрасно, если бы на уровень языка получилось бы как-то аккуратно вынести то, что делает UNIX, управляя процессами.