Мне кажется, мы говорим о разном. Настолько я понимаю понятие контекстно-свободной грамматики - это грамматика, в описании которой в левой части правил всегда один нетерминальный символ. И грамматика го этому вполне соответствует. Есть например случаи типа вызов функции vs приведение типа. На уровне грамматики отличить одно от другого не выйдет, поэтому в процессе построения AST понадобится таблица символов. Но можно в принципе обойтись и без неё на этапе парсинга и отдать дальнейшие проблемы на уровень семантического анализа, где проверяются типы и всё такое.
Было бы интересно почитать продолжение. Управление памятью, мне кажется, вообще мастхев. Классы, имхо, чуток оверкил. Можно, например, структуры с методами + интерфейсы. В этом случае будет охвачена довольно интересная тема про инкапсуляцию и таблицы виртуальных функций, но при этом вполне можно обойтись без наследования, полиморфизма и ограничений доступа (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, которые компилятся очень быстро. А компиляция крупных проектов на плюсах может занимать длительное время даже с выключенной оптимизацией. А с учётом тьюринг-полных шаблонов она вообще может длиться вечно. :)
Ещё из недостатков: низкая скорость компиляции и высокие требования к железу (какой-нибудь хромиум, боюсь, на среднем ноуте невозможно собрать в принципе).
Мне кажется, мы говорим о разном. Настолько я понимаю понятие контекстно-свободной грамматики - это грамматика, в описании которой в левой части правил всегда один нетерминальный символ. И грамматика го этому вполне соответствует. Есть например случаи типа вызов функции vs приведение типа. На уровне грамматики отличить одно от другого не выйдет, поэтому в процессе построения AST понадобится таблица символов. Но можно в принципе обойтись и без неё на этапе парсинга и отдать дальнейшие проблемы на уровень семантического анализа, где проверяются типы и всё такое.
Golang такой: ну да, ну да, пошёл я нафиг... (Ну ладно, он совсем чуточку не дотянул, но максимально близок к context free).
Было бы интересно почитать продолжение. Управление памятью, мне кажется, вообще мастхев. Классы, имхо, чуток оверкил. Можно, например, структуры с методами + интерфейсы. В этом случае будет охвачена довольно интересная тема про инкапсуляцию и таблицы виртуальных функций, но при этом вполне можно обойтись без наследования, полиморфизма и ограничений доступа (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, которые компилятся очень быстро. А компиляция крупных проектов на плюсах может занимать длительное время даже с выключенной оптимизацией. А с учётом тьюринг-полных шаблонов она вообще может длиться вечно. :)
Ещё из недостатков: низкая скорость компиляции и высокие требования к железу (какой-нибудь хромиум, боюсь, на среднем ноуте невозможно собрать в принципе).
Продажа данных о пользователях тем, у кого с показом рекламы ситуация получше. :)