Куча вредных советов на самом деле. Если бы можно было увеличить производительность просто увеличивая все буферы подряд, они были бы большими по дефолту. Беспорядочное отключение фич ломает совместимость. "Меньше сервисов - меньше проблем" это не бенчмарк, а домыслы. Скорее всего ошибочные.
Не только в отделениях. Попробуйте уменьшить лимиты он-лайн, в приложении. Это сработает. Хотите увеличить обратно? Не получится без сдачи голосовой биометрии в приложении или при звонке в банк.
Так а вы думаете что в расте у автора меньше ошибок или что он на нем лучше написал?
Я думаю, что автор не в позиции оценивать Go, который он не знает (за это ручаюсь). Он некомпетентен, непрофессионален, но при этом предвзят. Об этом большинство моих комментариев.
Получилось достаточно эквивалентно, тем более что автор изначально написал, что ни тот ни другой особо не знает.
Значит автор не может адекватно судить об обоих языках сразу, а не только об одном, как я писал.
Я видимо некорректно выразился. Надеюсь, никто не будет спорить, что ЯП — это такой инструмент решения тех или иных задач. Когда ЯП проектируют, имеют в виду определенный круг таких задач. Этот круг влияет на дизайн и несет кучу последствий. Простой пример: Go не проектировался писать на нём десктопные GUI приложения. Разумеется, это можно сделать, но это — одна сплошная боль. Фанатики возьмут его и здесь, и будут отстаивать, что он хорош (ну для фанатиков их объект поклонения хорош вообще всегда).
Так вот, на Rust можно писать прикладные штуки, я не спорю. Но придётся думать о памяти. Можно писать тоже самое на Python и не думать о памяти. Или думать. Но в случае с Rust мы не можем выбрать, нам придётся о ней думать, это дизайн такой. Очень полезный в системном прогаммировании. Но совершенно бесполезный в большинстве случаев современного прикладного ПО на современных ПК. Во это я имел в виду.
За сообщество не могу сказать, но я лично спокойно отношусь к критике. Чуть выше я аргументировано разобрал почему этот пост не критика, а по большей части неправда и спекуляция.
Как по-вашему относиться к клевете? Почему новичок должен выбирать Rust начитавшись таких статей?
Неплохое оно было бы если бы автор осилил хоть азы Go, но он некомпетентный профан:
Автор пишет, что у Go хуже с кросплатформой, но это не так (и коллеги уже выше это заметили, ведь они компетентны). У Rust только Tier1 платформы поддерживаются полноценно, а их гораздо меньше, чем то, что поддерживает Go (+ у Go есть другие реализации (TinyGo например), у Rust реализация (полнофункциональныя) одна).
Автор называет обработку ошибок Go негибкой, но это спекуляция. Ошибка в Go — это интерфейс, который может быть реализован чем угодно, куда гибче? Автор просто не умеет этим пользоваться.
Автор называет Rust мультипарадигмальным, но это спекуляция. В моём учебнике по Rust написано, что он системный. И я на 100% с этим согласен. Для прикладной разработки всегда возьму что-то другое.
Автор называет Rust более безопасным. Это конечно не так. Отличный пример релиза в котором исправлена ошибка в Borrow Checker: blog.rust-lang.org/2020/02/27/Rust-1.41.1.html — он просто не работал в оперделенных случаях. Но он — истина в послдней инстанции, и если он работает неверно, с этим ничего не поделать практически.
Автор много пишет (в т.ч. в выводах про GOROOT и GOPATH). Тут без комментариев.
Я могу на Rust написать так, что памяти в 10000 раз больше потребует, чем в случае с Go. И во столько же раз медленнее, но не буду, ведь у меня нет цели доказать превосходство Go. Правда в том, что прикладной Go удобнее и эффективнее в прикладной разработке чем системный Rust и приходится жульничать как автор чтобы доказать обратное.
Очередной скучный наброс в духе «Rust лучше Go, используйте Rust. Ну пожалуйста...». Автор совершенно не может в Go, так что ему действительно лучше с ним не связываться. Аргументы как обычно: «Go плох т.к. в нём что-то (нпр. обработка ошибок) сделано не так как в Rust», а ещё «Rust безопаснее».
Если смотреть объективно: для Go есть Cobra и Viper (советую глянуть всем кто разрабатывает CLI программы), которые выводят Go на совсем другой уровень.
вы простите, я опять не понял…
я был немного удивлён критикой линковки в Go ("время линковки ужасно"), но даже в вашем примере видно, что Go собирает бинарь в 2 раза быстрее чем Rust (и кстати меньше секунды, т.е. мгновенно), линковка входит в сборку
что до размера в 88мб: по дефолту Go собирает статический full debug бинарь, кому не нравится, надо как раз линкеру желаемые флаги передавать. upx кстати хорошо помогает и официально поддерживается, а вот strip делать нельзя, можно потом странные сегфолты поймать.
время выполнения вполне типичное (ну +-), я где не тестировал, Go примерно вдвое и отставал от Rust (что вполне логично: авторы Go считают производительность результирующего кода делом десятым, ведь компьютеры становятся быстрее с каждым годом, а стоимость вычислений наоборот падает. на первом месте для них производительность программиста — чистый прагматизм, в развитых экономиках человекочасы программистов гораздо дороже обходятся чем железо, отсюда и многие дизайн-решения, например GC, который в большинстве случаев позволяет вообще о памяти не думать). да и Rust чертовски быстр, если сравнить со скриптотой, то Go будет быстрее в 5-10 раз (зависит от задачи)
Спасибо за статью.
Может, я невнимательно читал, но не увидел обоснования именно такого решения. Можно как-то прорезюмировать коротко? Я бы сервер скорее писал на C#, который предоставит весь функционал с помощью открытого и документированного протокола. А на Java потом только клиент. Что-то на подобие баз данных SQL. Немного громоздко, но по-моему менее громоздко чем портирование миллионов строк кода на плюсы и кодогенерация.
Спасибо за статью.
Стек, на мой взгляд, должен идти выше и выделяться: не имеет значение какая там команда, если для участия в ней надо 2000 часов какую-то скукотищу учить.
Гоферам-новичкам: fan-in, fan-out в статье реализованы неправильно, так делать не надо! В идеоматичной реализации мьютексов быть не должно. Автора мы конечно не виним, это сложный паттерн и не все его понимают.
Это не стрипание, стрипание - отрезание debug инфы утилитой strip, если сделать go build -ldflags '-s -w' она вообще не добавляется.
Попробуйте сделать обычный билд, стрипнуть его и сравнить с nodebug build который сделает go build, они скорее всего будут отличаться.
Стрипать Go бинари нельзя, это не поддерживается, работа с heap может сломаться. Вместо этого надо делать no debug build
go build -ldflags '-s -w'Куча вредных советов на самом деле. Если бы можно было увеличить производительность просто увеличивая все буферы подряд, они были бы большими по дефолту. Беспорядочное отключение фич ломает совместимость. "Меньше сервисов - меньше проблем" это не бенчмарк, а домыслы. Скорее всего ошибочные.
Не только в отделениях. Попробуйте уменьшить лимиты он-лайн, в приложении. Это сработает. Хотите увеличить обратно? Не получится без сдачи голосовой биометрии в приложении или при звонке в банк.
ещё
vm.watermark_scale_factor = 500
попробуйте, для zram актуально
Я думаю, что автор не в позиции оценивать Go, который он не знает (за это ручаюсь). Он некомпетентен, непрофессионален, но при этом предвзят. Об этом большинство моих комментариев.
Значит автор не может адекватно судить об обоих языках сразу, а не только об одном, как я писал.
Так вот, на Rust можно писать прикладные штуки, я не спорю. Но придётся думать о памяти. Можно писать тоже самое на Python и не думать о памяти. Или думать. Но в случае с Rust мы не можем выбрать, нам придётся о ней думать, это дизайн такой. Очень полезный в системном прогаммировании. Но совершенно бесполезный в большинстве случаев современного прикладного ПО на современных ПК. Во это я имел в виду.
Возможно. Тут кому как.
Согласен.
Тут кому как. Знаю нескольких людей, не самых глупых, которые Go не осилили.
Возможно. Наверное, от человека зависит, от учебников что он читал.
Всё верно (ну если мы оба имеем в виду производительность конечного машинного кода, а не производительность нового в проекте программиста например).
Спасибо, гляну как-нибудь. В среднем Go будет вдвое медленнее и в несколько раз больше памяти съест. И это ожидаемо, таков дизайн.
Если бы вы писали эту статью, она точно была бы адекватной и возможно справедливой. Но автору до вас далеко.
Как по-вашему относиться к клевете? Почему новичок должен выбирать Rust начитавшись таких статей?
Автор пишет, что у Go хуже с кросплатформой, но это не так (и коллеги уже выше это заметили, ведь они компетентны). У Rust только Tier1 платформы поддерживаются полноценно, а их гораздо меньше, чем то, что поддерживает Go (+ у Go есть другие реализации (TinyGo например), у Rust реализация (полнофункциональныя) одна).
Автор называет обработку ошибок Go негибкой, но это спекуляция. Ошибка в Go — это интерфейс, который может быть реализован чем угодно, куда гибче? Автор просто не умеет этим пользоваться.
Автор называет Rust мультипарадигмальным, но это спекуляция. В моём учебнике по Rust написано, что он системный. И я на 100% с этим согласен. Для прикладной разработки всегда возьму что-то другое.
Автор называет Rust более безопасным. Это конечно не так. Отличный пример релиза в котором исправлена ошибка в Borrow Checker: blog.rust-lang.org/2020/02/27/Rust-1.41.1.html — он просто не работал в оперделенных случаях. Но он — истина в послдней инстанции, и если он работает неверно, с этим ничего не поделать практически.
Автор много пишет (в т.ч. в выводах про GOROOT и GOPATH). Тут без комментариев.
Я могу на Rust написать так, что памяти в 10000 раз больше потребует, чем в случае с Go. И во столько же раз медленнее, но не буду, ведь у меня нет цели доказать превосходство Go. Правда в том, что прикладной Go удобнее и эффективнее в прикладной разработке чем системный Rust и приходится жульничать как автор чтобы доказать обратное.
Если смотреть объективно: для Go есть Cobra и Viper (советую глянуть всем кто разрабатывает CLI программы), которые выводят Go на совсем другой уровень.
Статья вредная конечно. Были бы бенчмарки, статьи бы не было. Давным-давно noatime действительно имел смысл, но не сейчас.
Звучит как баг по мне, наверное даже зарепортил бы. Я не помню даже больших проектов которые не уложились бы в 10с итого (вся сборка).
я был немного удивлён критикой линковки в Go ("время линковки ужасно"), но даже в вашем примере видно, что Go собирает бинарь в 2 раза быстрее чем Rust (и кстати меньше секунды, т.е. мгновенно), линковка входит в сборку
что до размера в 88мб: по дефолту Go собирает статический full debug бинарь, кому не нравится, надо как раз линкеру желаемые флаги передавать. upx кстати хорошо помогает и официально поддерживается, а вот strip делать нельзя, можно потом странные сегфолты поймать.
время выполнения вполне типичное (ну +-), я где не тестировал, Go примерно вдвое и отставал от Rust (что вполне логично: авторы Go считают производительность результирующего кода делом десятым, ведь компьютеры становятся быстрее с каждым годом, а стоимость вычислений наоборот падает. на первом месте для них производительность программиста — чистый прагматизм, в развитых экономиках человекочасы программистов гораздо дороже обходятся чем железо, отсюда и многие дизайн-решения, например GC, который в большинстве случаев позволяет вообще о памяти не думать). да и Rust чертовски быстр, если сравнить со скриптотой, то Go будет быстрее в 5-10 раз (зависит от задачи)
а можно поподробнее пожалуйста? в статье не могу найти про гигабайты ничего
в чятах плюсовиков разве что, ну или тех, кто полностью игнорирует облака в 2020
Может, я невнимательно читал, но не увидел обоснования именно такого решения. Можно как-то прорезюмировать коротко? Я бы сервер скорее писал на C#, который предоставит весь функционал с помощью открытого и документированного протокола. А на Java потом только клиент. Что-то на подобие баз данных SQL. Немного громоздко, но по-моему менее громоздко чем портирование миллионов строк кода на плюсы и кодогенерация.
[sarcasm]
итересный факт: все утвердительные предложения из абзаца «Будем честны» — ложь
[/sarcasm]
[/offtop]
Стек, на мой взгляд, должен идти выше и выделяться: не имеет значение какая там команда, если для участия в ней надо 2000 часов какую-то скукотищу учить.