• Разработка инструмента командной строки: сравнение Go и Rust
    0
    Так а вы думаете что в расте у автора меньше ошибок или что он на нем лучше написал?

    Я думаю, что автор не в позиции оценивать Go, который он не знает (за это ручаюсь). Он некомпетентен, непрофессионален, но при этом предвзят. Об этом большинство моих комментариев.
    Получилось достаточно эквивалентно, тем более что автор изначально написал, что ни тот ни другой особо не знает.

    Значит автор не может адекватно судить об обоих языках сразу, а не только об одном, как я писал.
  • Разработка инструмента командной строки: сравнение Go и Rust
    –1
    Я видимо некорректно выразился. Надеюсь, никто не будет спорить, что ЯП — это такой инструмент решения тех или иных задач. Когда ЯП проектируют, имеют в виду определенный круг таких задач. Этот круг влияет на дизайн и несет кучу последствий. Простой пример: Go не проектировался писать на нём десктопные GUI приложения. Разумеется, это можно сделать, но это — одна сплошная боль. Фанатики возьмут его и здесь, и будут отстаивать, что он хорош (ну для фанатиков их объект поклонения хорош вообще всегда).
    Так вот, на Rust можно писать прикладные штуки, я не спорю. Но придётся думать о памяти. Можно писать тоже самое на Python и не думать о памяти. Или думать. Но в случае с Rust мы не можем выбрать, нам придётся о ней думать, это дизайн такой. Очень полезный в системном прогаммировании. Но совершенно бесполезный в большинстве случаев современного прикладного ПО на современных ПК. Во это я имел в виду.
  • Разработка инструмента командной строки: сравнение Go и Rust
    0
    Они втроём смогу «скаффолдинг»? (не могу найти в доках). Это когда утилита генерит вам весь скелет, а вы просто пишите бизнес-логику.
  • Разработка инструмента командной строки: сравнение Go и Rust
    –1
    Почему Раст — на нем интересно писать

    Возможно. Тут кому как.
    он делает вас лучшим программистом

    Согласен.
    В Го новичку для развития делать вообще нечего — бери здесь, кидай сюда

    Тут кому как. Знаю нескольких людей, не самых глупых, которые Go не осилили.
    Новичок после Го будет думать что это абсолютно нормальный подход сделать кодогенерацию итератора вместо понимания абстракций.

    Возможно. Наверное, от человека зависит, от учебников что он читал.
    Так же он эффективней Го.

    Всё верно (ну если мы оба имеем в виду производительность конечного машинного кода, а не производительность нового в проекте программиста например).
    Вот попробуйте реализовать на Го например эту задачу
    У меня на Расте получилось 4 мс по ЦПУ и 778Кб по памяти.

    Спасибо, гляну как-нибудь. В среднем Go будет вдвое медленнее и в несколько раз больше памяти съест. И это ожидаемо, таков дизайн.

    Если бы вы писали эту статью, она точно была бы адекватной и возможно справедливой. Но автору до вас далеко.
  • Разработка инструмента командной строки: сравнение Go и Rust
    –1
    За сообщество не могу сказать, но я лично спокойно отношусь к критике. Чуть выше я аргументировано разобрал почему этот пост не критика, а по большей части неправда и спекуляция.
    Как по-вашему относиться к клевете? Почему новичок должен выбирать Rust начитавшись таких статей?
  • Разработка инструмента командной строки: сравнение Go и Rust
    –6
    Неплохое оно было бы если бы автор осилил хоть азы 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 и приходится жульничать как автор чтобы доказать обратное.
  • Разработка инструмента командной строки: сравнение Go и Rust
    –8
    Очередной скучный наброс в духе «Rust лучше Go, используйте Rust. Ну пожалуйста...». Автор совершенно не может в Go, так что ему действительно лучше с ним не связываться. Аргументы как обычно: «Go плох т.к. в нём что-то (нпр. обработка ошибок) сделано не так как в Rust», а ещё «Rust безопаснее».
    Если смотреть объективно: для Go есть Cobra и Viper (советую глянуть всем кто разрабатывает CLI программы), которые выводят Go на совсем другой уровень.
  • Как и почему опция noatime повышает производительность Linux-систем
    +2
    Спасибо за перевод.

    Статья вредная конечно. Были бы бенчмарки, статьи бы не было. Давным-давно noatime действительно имел смысл, но не сейчас.
  • Go глазами Rust-программиста: первые впечатления
    0
    Я например наблюдал 40с линковку для небольшой задачки.

    Звучит как баг по мне, наверное даже зарепортил бы. Я не помню даже больших проектов которые не уложились бы в 10с итого (вся сборка).
  • Go глазами Rust-программиста: первые впечатления
    –1
    вы простите, я опять не понял…
    я был немного удивлён критикой линковки в Go ("время линковки ужасно"), но даже в вашем примере видно, что Go собирает бинарь в 2 раза быстрее чем Rust (и кстати меньше секунды, т.е. мгновенно), линковка входит в сборку

    что до размера в 88мб: по дефолту Go собирает статический full debug бинарь, кому не нравится, надо как раз линкеру желаемые флаги передавать. upx кстати хорошо помогает и официально поддерживается, а вот strip делать нельзя, можно потом странные сегфолты поймать.

    время выполнения вполне типичное (ну +-), я где не тестировал, Go примерно вдвое и отставал от Rust (что вполне логично: авторы Go считают производительность результирующего кода делом десятым, ведь компьютеры становятся быстрее с каждым годом, а стоимость вычислений наоборот падает. на первом месте для них производительность программиста — чистый прагматизм, в развитых экономиках человекочасы программистов гораздо дороже обходятся чем железо, отсюда и многие дизайн-решения, например GC, который в большинстве случаев позволяет вообще о памяти не думать). да и Rust чертовски быстр, если сравнить со скриптотой, то Go будет быстрее в 5-10 раз (зависит от задачи)
  • Go глазами Rust-программиста: первые впечатления
    0
    В современном Go (1.2-1.4 уж простите не застал) полная сборка (с линковкой) большинства проектов мгновенна.

    многогигабайтный результирующий бинарник — это про Го

    а можно поподробнее пожалуйста? в статье не могу найти про гигабайты ничего

    позиционируется исключительно для Веб-прикладных

    в чятах плюсовиков разве что, ну или тех, кто полностью игнорирует облака в 2020
  • Как мы автоматизировали портирование продуктов с C# на C++
    +4
    Спасибо за статью.
    Может, я невнимательно читал, но не увидел обоснования именно такого решения. Можно как-то прорезюмировать коротко? Я бы сервер скорее писал на C#, который предоставит весь функционал с помощью открытого и документированного протокола. А на Java потом только клиент. Что-то на подобие баз данных SQL. Немного громоздко, но по-моему менее громоздко чем портирование миллионов строк кода на плюсы и кодогенерация.
  • Как сделать терминал вашим помощником, а не врагом?
    +1
    [offtop]
    [sarcasm]
    итересный факт: все утвердительные предложения из абзаца «Будем честны» — ложь
    [/sarcasm]
    [/offtop]
  • Правильное письмо о вакансии IT-специалисту
    +1
    Спасибо за статью.
    Стек, на мой взгляд, должен идти выше и выделяться: не имеет значение какая там команда, если для участия в ней надо 2000 часов какую-то скукотищу учить.
  • Михаил Салосин. Golang Meetup. Использование Go в бэкенде приложения «Смотри+»
    0
    Гоферам-новичкам: fan-in, fan-out в статье реализованы неправильно, так делать не надо! В идеоматичной реализации мьютексов быть не должно. Автора мы конечно не виним, это сложный паттерн и не все его понимают.
  • Golang + Phaser3 = MMORPG — Клиент и Сервер
    +1
    спасибо за статью

    Map_Handler стоило бы переписать, в Go принято обрабатывать ошибки явно, вот здесь:
    js, e :=json.Marshal( c )
    if e != nil {
    fmt.Println(e.Error())
    // прямо здесь!
    }

    нужно вернуть клиенту HTTP ошибку или JSON с описанием этой ошибки (иначе можно долго потом дебажить странное на клиенте)

    ну и коллегу выше поддержку — нейминг надо починить (снейк-кейс, константы)
  • Делаем так, чтобы терминал летал (часть 1)
    +8
    эмм… я всё правильно понял, что Gnome Terminal обвиняется в монструозности и жоре памяти (20 мегабайт), а альтернативой ему предлагается Hyper на базе Electron?
    чем скорость мерили, time с format?
  • Как выбрать редактор, и почему нужно выбрать NeoVim?
    –1
    Аргументация подкачала конечно…
    Даже на ноуте <2 секунд vscode стартует. Тестировал с 9 плагинами и 4 вкладками. На десктопе ещё быстрее.
    Как и другие ждал аргументы в пользу того почему neovim > vim (пользуюсь последним для Си и конфигов)
  • Так ли хорош PocketBook?
    +2
    ИМХО разрабы-сишники glib и glibc не перепутают, для них это не просто похожие названия, а очень разные либы
  • Так ли хорош PocketBook?
    0
    glibc 2.50.3

    хм…
    такая версия точно существует? у меня в самой новой убунте 2.30
  • О структуре параллельных вычислений или доводы против оператора «Go»
    +3
    Спасибо за перевод.

    Автор — клоун, я даже дочитать этот опус не смог. Коллеги выше уже отметили нулевые знания в области (непонимание concurrency, parallelism, CSP), так ещё и полное профанство в языке Go (15-минутный go tour очевидно не пройден).

    Даже лень комментировать этот бред: «go похож на goto (нет), поэтому они одинаковые (нет)», "'go' ломает исключения, а без них ошибки не обработать" (исключений в Go нет), «каналы ещё не придуманы и не существуют», «мифические абстракции ломаются (автор не знает какие абстракции есть в Go, но уверен что они ломаются)», «go ломает автоотчистку ресурсов» (её в Go тоже нет, но автор и этого не знает).

    Немного питонирую и могу понять, какую проблему автор «героически» решает. Но это проблема именно языка Python (и многих других к сожалению), а Go с его «go» спроектирован на базе решения этой проблемы и просто иммунен к ней (но не ко многим другим к сожалению).
  • Девелопишь на .NET Core? Го в Ubuntu, я создал
    +1
    А Ansible и не требует 10+ хостов. Зато иногда надо рабочую машину переустановить (новое железо например).
    Установка чего-либо скриптом не гарантирует идемпотентности, а Ansible'ом гарантирует, поэтому имеет смысл предпочесть его.
  • Девелопишь на .NET Core? Го в Ubuntu, я создал
    +6
    Спасибо за статью. По-моему одного маленького шажка не хватило — Ansible. Скрипты делают своё дело, но это инструмент прошлого тысячелетия (тогда софт был заметно проще, его было меньше, open source и коллаборация были на совершенно ином уровне), поддерживать чужой плейбук проще простого, а вот скрипт уже кому как.
  • Пишем USB-драйверы для заброшенных устройств
    +1
    Ну если вчитаться в доки этого F-Stack, то оно базируется на DPDK. Так что оно не в userspace работает, а прямо на железе (и только на поддерживаемом). В userspace только управление этим делом. Видимо нужно отдать специально обученную железку специально обученному софту (я как понял даже open source надо патчить) и только так оно будет быстрее. Чудес не бывает, и практически любой userspace использует те же самые возможности ядра только в режиме конкурентности и в порядке живой очереди.
  • Убил ли Linux коммерческий Unix?
    +3
    Нет только компаний, которые бы вкладывали деньги и труд своих сотрудников.

    Есть мнение, что они есть, но не возвращают большую часть своих наработок в upstream по той или иной причине. Лицензия же позволяет. Потому и имеем то, что имеем.
  • Веб сервер на CentOS 8 с php7, node.js и redis
    0
    негативный опыт: старое здание с протекающей крышей, частые отключения света при дожде (обычное дело — отключение на 6+ часов ночью и на выходных, бесперебойники столько не держали), бывали отключения подряд (т.е. ФС восстанавливается после отключения и в этот самый момент происходит следующее отключение).
    EXT4: многочасовые fsck, с которыми непонятно что делать, многократные поломки самой ФС, которые не лечатся fsck вообще (иногда второе следовало за первым т.е. я сидел, ждал, а в итоге ОС не может даже загрузиться)
    XFS: любая проверка меньше 15 секунд, нулевое количество разрушений ОС за примерно аналогичный период (2 года против 2.5)
    справедливости ради несохраненные данные лучше «выживали» на ext4 (если сама ФС не дохла), но кого это волнует? — у нормального админа все важные данные забэкаплены в любом случае

    BTRFS хороша для системного раздела (если использовали атомарные обновления, понимаете), но не для данных (производительность может быть ниже в разы)
  • Веб сервер на CentOS 8 с php7, node.js и redis
    0
    для установки CentOS 7 нужно минимум 1 GB памяти (я ставил и на 750 MB), просто нужно освоить kickstart и текстовую установку
    отключать SELinux нельзя. просто нельзя и всё.
    использовать ext4 нельзя. RH не рекомендует этого по очевидным причинам (ну ext4 — это экскременты (простите за французский)) а в storage продуктах даже не поддерживает(!). SUSE тоже не рекомендует. только XFS.
    зачем нужны Development tools (make, strace, gdb вот это всё) на боевом сервере (чтобы проще было руткиты и бэкдоры конпелять?) не оч понятно
    Поэтому одна volume group используется для системы и обязательно другая исползуется для данных! Это логическое разделение сильно помогает в жизни!

    можно пожалуйста поподробнее, кому помогает, как? бэкап PV — одна простая команда, аналогично и с восстановлением бэкапа, вы всю VG бэкапите? как если не секрет? много лет одной VG обходился…
  • Семейный бюджет в Telegram
    0
    Спасибо за статью. Тема бюджета не оч интересна, а вот исходник бота бы с удовольствием посмотрел (сам гофер + хочу бота одного написать), но ссылку не нашел, ткнёт кто-нибудь?
  • Гибридные телефонные системы
    0

    Как там у Снома с OPUS и SRTP в локализованных прошивках у бюджетных моделей?

  • Продуктовая разработка на Go: история одного проекта
    +2
    Людям надо было продукт запускать, главное что одумались.
  • Продуктовая разработка на Go: история одного проекта
    +3
    Сегодня мы уже ушли от Beego и Gorm

    <Шумно выдохнул...>
    Ну раз ушли, следующая статья обещает быть интересной. Ждём.
  • Разбираемся с интерфейсами в Go
    0
    «Увы и Ах», многие беженцы с других языков используют пустые интерфейсы по сути для отмены типизации. Это неидеоматично, уродливо, небезопасно и медленно.
    Пару раз пытался увещевать: «мол, не делайте так, сделайте лучше нормальный интерфес». В ответ лишь непонимание…
  • Самодокументируемый код – это (как правило) чушь
    +14
    золотой коммент, ++

    статья бредовая:

    1. автор пишет/использует несамодокументируемый код
    2. указывает очевидную несамодокументированность кода
    3. делает нелепые выводы

    Роба Пайка бы лучше почитал/посмотрел
  • Каркас API на Golang
    +2

    Дайте угадаю, Go не первый язык, а до него был C#? DI — это антипаттерн, ORM — тоже. GORM — два антипаттерна.

  • Самые редкие и самые дорогие языки программирования
    +2
    Принято считать, что языки программирования, такие как Rust, Erlang, Dart, а также некоторые другие являются самыми редкими в мире IT

    кем принято? они даже в топ-20 самых редких не попадут, никак
    Rust занял первую позицию(третий год подряд) в списке самых любимых языков

    как этот опрос коррелирует с редкостью из заголовка? очень слабо. как этот опрос коррелирует с «дороговизной» из заголовка? вообще никак. зачем оно здесь?
    Несмотря на то, что язык достаточно популярен в мире (… это про Rust ...)

    false
    не-pet проектов на Rust с значительной пользовательской базой крайне мало. проектов целиком на Rust без unsafe и unstable фич, но с пользаками ещё в принципе не существует! на популярном языке уже написали бы что-нибудь
    Предлагают работу Rust разработчикам 32 компании на Headhunter

    нет там такого, максиму что я видел 9
    и да, «требуется React-разработчик, знание любого языка из списка следующих 6 (среди них есть Rust)» не значит что там ждут Rust-разработчика
    Go не вытеснит Erlang, потому что для действительно высоконагруженных и сложных проектов Erlang является незаменимым языком.

    киллер-фичи erlang — горячая замена кода и realtime (и около-realtime), в них может и не вытеснит, но в «высоконагруженных» и «сложных» вытеснит
    “топовыми” языками для освоения являются: Rust, Erlang, Dart — есть спрос, высокая зарплата

    надеюсь, это исследование увидит как можно меньше людей…
    топовыми языками для освоения являются JavaScript и Python. там и спрос есть, а при наличии опредленных навыков и опыта ещё и зряплаты клёвые
  • Изменение настроек программ с сохранением персональных параметров
    +2
    Сейчас все 2 перловика Хабра проснутся и закидают вас тапками за отсутствие strict, warnings, ООП подхода в работе с файлами и другие сомнительные практики…

    А вообще здорово, что Perl продолжает get shit done вне зависимости от того жив он или нет.
  • Microsoft Edge на Chromium официально доступен для открытого тестирования
    +7

    Оно легче, если я правильно понял. Msft выпилили кучу всего, что нужно только для Chrome OS, но зачем-то тащится во все платформы.
    Я бы попользовался. Жаль, что Майкрософт <сердечко> Linux только в рекламных проспектах.

  • Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind
    +4
    Все люди разные. Некоторым нужны безопасность, стабильность, надёжность и производительность, которых Docker с его тысячами открытых issues предоставить не может. А ещё некторые понимают, что Docker — средство доставки приложений. Если ваш стартап выкатывает новую версию сервиса 2 раза в неделю, Docker незаменим. Если вы поднимаете почтовый сервак, который будет работать годами Docker вообще ни к чему.
  • Мой путь от Python к Go — делюсь советами и ресурсами
    0
    Вот прямо +++, хочется подписаться под каждым словом. Не хватает только рекомендации Chi: github.com/go-chi/chi
  • Условия в Go и их странности
    +1
    Кто-то из основных разрабов Go писал: приоритет скорости компиляции, а не оптимизациям. Т.е. оптимизации тоже запиливаются, но не ценой скорости компиляции.