Было бы интересно почитать продолжение. Управление памятью, мне кажется, вообще мастхев. Классы, имхо, чуток оверкил. Можно, например, структуры с методами + интерфейсы. В этом случае будет охвачена довольно интересная тема про инкапсуляцию и таблицы виртуальных функций, но при этом вполне можно обойтись без наследования, полиморфизма и ограничений доступа (private/protected).
Было бы круто добавить поддержку ARM64, чтобы можно было на бесплатных виртуалках в Oracle Cloud поставить. Сейчас оно при попытке установить амнезию на такую виртуалку пишет, что всё успешно, но при попытке подключиться зависает. Если зайти на сервер, то в journald видно, что контейнер стартануть не может.
Нет удобного универсального способа скачать и начать использовать зависимости. Для каждой либы приходится искать индивидуальный подход.
В Go, например, это делается одной командой: go get. К сожалению, есть и обратная сторона - Go очень плохо дружит с либами, которые написаны на не-Go. Настолько плохо, что есть и реально используются тулзы, которые транслируют код из C на Go. Например, для того же SQLite.
По бенчмаркам видно, что сбор стека занимает ~1 мс в среднем при глубине вызова в 100. Цифра приличная, если рядышком у вас нет вызовов базы данных по 100-200 мс.
По таблице кажется, что худший случай это 0.5мс для наивной реализации. В случае эффективной реализации получается ~4мкс (BenchmarkStackTraceErrorxError100), что уже сложнее сравнивать с IO, мне кажется.
Спасибо за статью! Давно хотел разобраться в SSA хотя бы немного, но всё руки не доходили. Понял (надеюсь, что правильно) наконец как работают Ф-функции. На самом деле, оказалось даже проще, чем мне казалось. В этом примере, где Ф-ноды зависят от других Ф-нод, сразу понял что дело в том, что значения из предыдущего блока берутся и нет никакой разницы в порядке вычислений внутри блока.
Ну в го в большинство аллокаций происходят на стеке/регистрах за счёт escape анализа на этапе компиляции. По этому принципу в го есть много zero-allocation либ оптимизировнных таким образом, чтобы в процессе их работы память на куче вообще не выделялась, а значит и для сборщика мусора меньше работы. Но в целом согласен, что языки накладывают свои ограничения на возможности оптимизации компилятором. В го вообще разработчики компилятора осознанно не добавляют оптимизации, которые могут сильно замедлить скорость компиляции.
Ну под рандомными сайтами я имел в виду те, где не жалко потерять аккаунт. В моём случае Пикабу именно такой. Раньше я для таких сайтов юзал е-мейл/простой пароль, который тоже не особо жалко потерять, но всё же неприятно.
После прочтения новости побежал проверять свой аккаунт, которым я давно не пользовался. Оказалось, что у меня там нет ни телефона, ни емейла, ни пароля. А всё благодаря oauth через гугл. Теперь вот думаю, что буду его чаще юзать для рандомных сайтов. :)
Ну то, что это заняло меньше суток, это весьма обнадёживающе.))
Я ради интереса собирал kubernetes на raspberry pi 4 с 4гб памяти — чистая сборка занимает 25 минут. Наверняка у него кодовая база гораздо меньше. Допустим, судя по быстромугуглению оценок cloc, в 25 раз меньше. В этом случае, сборка бы сопоставимого с хромиумом проекта на го заняла бы на малинке 10 часов. :)
На счёт паскаля не знаю, в го, вроде, нет LTO. Но опять же, плюсы и без оптимизаций дольше компилятся, чем го с оптимизациями. Даже с precompiled headers. Так или иначе, долгая компиляция си++ это недостаток, достойный упоминания.
На моей работе есть крупный плюсовый проект, для сборки которого отдельные девелоперские сервера юзаются, т.к. даже на мощных ноутах это занимает неприлично много времени. Но даже на этих серверах, после пары правок в код приходится ждать минуту-две, чтобы собрать проект. Вроде бы это немного, но достаточно, чтобы отвлечься на браузер и потом обратно вспоминать, что я там проверить хотел.)
P.S. И не дай бог поменять бранч… Иначе проект будет пересобираться заново, что займёт уже не 1-2 минуты, а все 20.
Не согласен на счёт всех. Как минимум, есть pascal/delphi и golang, которые компилятся очень быстро. А компиляция крупных проектов на плюсах может занимать длительное время даже с выключенной оптимизацией. А с учётом тьюринг-полных шаблонов она вообще может длиться вечно. :)
Ещё из недостатков: низкая скорость компиляции и высокие требования к железу (какой-нибудь хромиум, боюсь, на среднем ноуте невозможно собрать в принципе).
Go хорош не только для примитивных сервисов, но и в целом для бекенда, девопса, системных утилит и сервисов независимо от размера проекта. Но из-за примитивности синтаксиса он плохо подходит для геймдева, датасаенс и всего такого. В общем, на серебренную пулю он разумеется не тянет, но и совсем уж узким инструментом его не назовешь, мне кажется.
А вот срачей в комментах на счёт го как-то маловато, даже специально прошёлся по go-шному хабу. В этом плане, rust больше срачей триггерит, хотя это ничего не говорит про сам язык. :)
Ну в процитированном абзаце, всё на самом деле упирается в то, как понять reallocated. Я вижу два способа: 1) фактическая реаллокация, т.е. память была перемещена на новое место, 2) тупо факт вызова функции realloc. И UB тут можно натянуть только при второй трактовке, что ну очень натянуто. А если учесть ещё, что в первом подчёркнутом предложении речь идёт именно о памяти (in the space allocated), а не о значении указателя, то первая трактовка кажется единственно верной.
Было бы интересно почитать продолжение. Управление памятью, мне кажется, вообще мастхев. Классы, имхо, чуток оверкил. Можно, например, структуры с методами + интерфейсы. В этом случае будет охвачена довольно интересная тема про инкапсуляцию и таблицы виртуальных функций, но при этом вполне можно обойтись без наследования, полиморфизма и ограничений доступа (private/protected).
Было бы круто добавить поддержку ARM64, чтобы можно было на бесплатных виртуалках в Oracle Cloud поставить. Сейчас оно при попытке установить амнезию на такую виртуалку пишет, что всё успешно, но при попытке подключиться зависает. Если зайти на сервер, то в journald видно, что контейнер стартануть не может.
Вроде, даже без уточнения может
Нет удобного универсального способа скачать и начать использовать зависимости. Для каждой либы приходится искать индивидуальный подход.
В Go, например, это делается одной командой: go get. К сожалению, есть и обратная сторона - Go очень плохо дружит с либами, которые написаны на не-Go. Настолько плохо, что есть и реально используются тулзы, которые транслируют код из C на Go. Например, для того же SQLite.
Тут из-за двоеточия ссылка получается невалидной.
По таблице кажется, что худший случай это 0.5мс для наивной реализации. В случае эффективной реализации получается ~4мкс (BenchmarkStackTraceErrorxError100), что уже сложнее сравнивать с IO, мне кажется.
Спасибо за статью! Давно хотел разобраться в SSA хотя бы немного, но всё руки не доходили. Понял (надеюсь, что правильно) наконец как работают Ф-функции. На самом деле, оказалось даже проще, чем мне казалось. В этом примере, где Ф-ноды зависят от других Ф-нод, сразу понял что дело в том, что значения из предыдущего блока берутся и нет никакой разницы в порядке вычислений внутри блока.
Ну раз питон-питон, то тогда так :)
Ну в го в большинство аллокаций происходят на стеке/регистрах за счёт escape анализа на этапе компиляции. По этому принципу в го есть много zero-allocation либ оптимизировнных таким образом, чтобы в процессе их работы память на куче вообще не выделялась, а значит и для сборщика мусора меньше работы. Но в целом согласен, что языки накладывают свои ограничения на возможности оптимизации компилятором. В го вообще разработчики компилятора осознанно не добавляют оптимизации, которые могут сильно замедлить скорость компиляции.
Прям каждая компания под свои нужды придумала свой uid. Вероятно, UUIDv7 тут вряд ли что-то изменит, как минимум из-за длины.
По свойствам похоже на xid
Ну под рандомными сайтами я имел в виду те, где не жалко потерять аккаунт. В моём случае Пикабу именно такой. Раньше я для таких сайтов юзал е-мейл/простой пароль, который тоже не особо жалко потерять, но всё же неприятно.
После прочтения новости побежал проверять свой аккаунт, которым я давно не пользовался. Оказалось, что у меня там нет ни телефона, ни емейла, ни пароля. А всё благодаря oauth через гугл. Теперь вот думаю, что буду его чаще юзать для рандомных сайтов. :)
Да понятное дело. Такие вещи сравнивать вообще дело неблагодарное, просто интересно было хотя бы грубо прикинуть.
Ну то, что это заняло меньше суток, это весьма обнадёживающе.))
Я ради интереса собирал kubernetes на raspberry pi 4 с 4гб памяти — чистая сборка занимает 25 минут. Наверняка у него кодовая база гораздо меньше. Допустим, судя по быстрому гуглению оценок cloc, в 25 раз меньше. В этом случае, сборка бы сопоставимого с хромиумом проекта на го заняла бы на малинке 10 часов. :)
На счёт паскаля не знаю, в го, вроде, нет LTO. Но опять же, плюсы и без оптимизаций дольше компилятся, чем го с оптимизациями. Даже с precompiled headers. Так или иначе, долгая компиляция си++ это недостаток, достойный упоминания.
На моей работе есть крупный плюсовый проект, для сборки которого отдельные девелоперские сервера юзаются, т.к. даже на мощных ноутах это занимает неприлично много времени. Но даже на этих серверах, после пары правок в код приходится ждать минуту-две, чтобы собрать проект. Вроде бы это немного, но достаточно, чтобы отвлечься на браузер и потом обратно вспоминать, что я там проверить хотел.)
P.S. И не дай бог поменять бранч… Иначе проект будет пересобираться заново, что займёт уже не 1-2 минуты, а все 20.
Не согласен на счёт всех. Как минимум, есть pascal/delphi и golang, которые компилятся очень быстро. А компиляция крупных проектов на плюсах может занимать длительное время даже с выключенной оптимизацией. А с учётом тьюринг-полных шаблонов она вообще может длиться вечно. :)
Ещё из недостатков: низкая скорость компиляции и высокие требования к железу (какой-нибудь хромиум, боюсь, на среднем ноуте невозможно собрать в принципе).
Продажа данных о пользователях тем, у кого с показом рекламы ситуация получше. :)
Go хорош не только для примитивных сервисов, но и в целом для бекенда, девопса, системных утилит и сервисов независимо от размера проекта. Но из-за примитивности синтаксиса он плохо подходит для геймдева, датасаенс и всего такого. В общем, на серебренную пулю он разумеется не тянет, но и совсем уж узким инструментом его не назовешь, мне кажется.
А вот срачей в комментах на счёт го как-то маловато, даже специально прошёлся по go-шному хабу. В этом плане, rust больше срачей триггерит, хотя это ничего не говорит про сам язык. :)
Ну в процитированном абзаце, всё на самом деле упирается в то, как понять reallocated. Я вижу два способа: 1) фактическая реаллокация, т.е. память была перемещена на новое место, 2) тупо факт вызова функции realloc. И UB тут можно натянуть только при второй трактовке, что ну очень натянуто. А если учесть ещё, что в первом подчёркнутом предложении речь идёт именно о памяти (in the space allocated), а не о значении указателя, то первая трактовка кажется единственно верной.