LINUX.ORG.RU

Там опять Go ругают

 , ,


4

9

сабж

Статья вызвала бурю эмоций на HN.

Сама статья мне очень понравилась. Очень красочно описывает моё отношение к Go.

This fake “simplicity” runs deep in the Go ecosystem. Rust has the opposite problem - things look scary at first, but it’s for a good reason. The problems tackled have inherent complexity, and it takes some effort to model them appropriately.

Ну или как я люблю говорить: Go примитивный, а не простой.

PS: Работа со строками в Go напомнила недавний холивар (C рулит и педалит.). @grem’у понравится. Путь к файлу содержит недопустимые символы? Та забей!

@WitcherGeralt

Ответ на: комментарий от cherry_boy

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

Если вам кажется, что COBOL мертв, то неудивительно, что вам кажется, что чистый Си жив.

https://www.i-programmer.info/news/99-professional/13484-survey-says-cobol-still-going-strong.html

eao197 ★★★★★ ()
Ответ на: комментарий от red75prim

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

cherry_boy ()
Ответ на: комментарий от Siborgium

На нем можно писать хороший, эффективный, надежный код, но не благодаря, а вопреки.

«Не благодаря, а вопреки»… Вот и выросло поколение ЕГЭ.

eao197 ★★★★★ ()
Ответ на: комментарий от WatchCat

Кому-то нужные, кому-то нет.

Напомнило мой вопрос в чате гоферов добавили ли try в 1.14. На что ответили нет и не будет, потому что так решило сообщество :)

dnb ★★★ ()
Ответ на: комментарий от RazrFalcon

что же делать!? это что, я файл с кириллицей в названии открыть не смогу?

grem ★★★★★ ()

вкусовщина. таким текстом ты показываешь, что, вероятно, ты ещё не вышел из подросткового состояния.

anonymous ()
Ответ на: комментарий от cherry_boy

Суть в том, что вы делаете выводы не имея достаточного количества информации. Отсюда можно предположить, насколько вашим выводам можно доверять. Будь то вывод о нежизнеспособности COBOL-а или жизнеспособности чистого Си.

eao197 ★★★★★ ()
Ответ на: комментарий от grem

Ты статью читал? С точки зрения ФС там всё норм, просто недопустимые символы там с точки зрения юникода.

theNamelessOne ★★★★★ ()
Ответ на: комментарий от WatchCat

Просто надо ещё вспомнить, когда там в Го появился нормальный пакетный менеджер?

theNamelessOne ★★★★★ ()
Ответ на: комментарий от eao197

а мейнстрим - всегда был падок на моду (или наоборот). выпендриться и сказать что что-то умерло - может каждый. другое дело - иметь аргументы.

вот я, со 100% могу сказать, что c/c++ - это ходячий труп, потому что есть более хорошие инструменты. если делать софт, от которого зависят жизни, то лучше я выберу Go.

теперь что касается rust

rust, это ошибочная технология, не имеющая под собой достаточного смыслового основания: Mozilla просто не хотела кодить на C++, и не хотела смотреть на Go (она же гордая), и не знала про существование D.

в подтверждение не очень умной политике Mozilla, можно привести пример со слитой технологией XUL - это вообще эпик :|

anonymous ()

Мне язык go не понравился (я кодю на java, kotlin, typescript), но наверное это таки не плохой инструмент раз на нем написано много чего полезного, например docker, syncthing, gitea. А что из широко известного написано на rust?

Aber ★★★★ ()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

не дочитал

просто недопустимые символы там с точки зрения юникода.

Где там? Имеешь ввиду случай когда вместо допустимого значения в hex запихнуть недопустимый и его обратно нельзя декодировать в u+ значение?

grem ★★★★★ ()
Ответ на: комментарий от eao197

Про Си объяснил, что касается COBOL - это больше опыт общения с человеком, который на нем долго писал.
Если сравнивать, то по C вакансий банально больше, так что более мертвым он быть точно не может.

cherry_boy ()
Ответ на: комментарий от anonymous

вот я, со 100% могу сказать, что c/c++ - это ходячий труп, потому что есть более хорошие инструменты. если делать софт, от которого зависят жизни, то лучше я выберу Go.

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

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от dave

нужно ооочень сильно постараться, чтобы сборка мусора Go стала сколько либо заметна.

anonymous ()
Ответ на: комментарий от cherry_boy

да видел я эту статью:

  1. вероятно они неправильно заархитектили
  2. вероятно они специально и упорно неправильно заархитектили

короче, этот опыт - не показателен.

anonymous ()
Ответ на: комментарий от cherry_boy

Про Си объяснил

Это вам так кажется (собственно, есть впечатление, что вы здесь высказываете только то, что вам кажется). Упомянутые вами копролиты на С является лишь небольшой долей того, что существует в софтостроении.

eao197 ★★★★★ ()
Ответ на: комментарий от anonymous

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

cherry_boy ()
Ответ на: комментарий от cherry_boy

как говорится Show Me the Code. - это не про Дискач

anonymous ()
Ответ на: комментарий от eao197

Разумеется, но это, опять же, известные, широко используемые и развиваемые копролиты, для парочки из которых нет альтернатив. Так в чем заключается претензия?

cherry_boy ()
Ответ на: комментарий от cherry_boy

Так в чем заключается претензия?

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

Тогда как, на мой взгляд, ситуация с чистым С достаточно непростая:

  • чистый C не умрет, т.к. ничего лучшего для организации FFI пока не придумано. И вряд ли будет придумано в ближайшие десятилетия;

  • чистый С никуда в ближайшие годы просто так не уйдет из завязанной на Unix-ы системщины (в частности Linux-овщины);

  • чистый С никуда не уйдет из-за большого количества недопрограммистов, не могущих ни во что сложнее чистого С. Кто-то из-за своей тупости (таких немало, к сожалению), кто-то из-за того, что разработка на C для них – это вообще побочный вид деятельности;

  • чистый С убог настолько, что разрабатывать на нем что-то вне Unix-овой системщины могут либо мазохисты, либо не имеющие достаточной квалификации люди.

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

Ну и надеюсь, что даже в тех узких нишах, где адепты чистой С-шки все еще с удовольствием его применяют, со временем присутствие более адекватных альтернатив (будь то C++, Rust или Ada) будет только усиливаться.

eao197 ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Речь идёт про случай, когда путь валидный, но go этого не понимает.

Посмотрел статью. Что я там вижу:

  • создаём файл с произвольной последовательностью байт заведомо не декодирующуюся в utf8 символ (ls его уже не отображает)
  • пытаемся обработать такой «путь» в go как с строку и удивляемся кракозябрам в выводе
  • используя класс path в rust выводим информацию с конвертирование в символ того, что можно (что такое {:?} кстати?)
  • не делаем никаких действий с файлом в обоих случаях - не пытаемся оттуда читать или писать в него
  • забиваем на то, что непонятно как интерпретировать вывод примера пути на rust «./\xBD\xB2=\xBC ⌘», то есть так же будет отображаться имя в файловых менеджерах или нет? откроет ли rust такой файл, если передать ему в path снаружи «./\xBD\xB2=\xBC ⌘»?

Ээээ, чего показать то хотели в итоге? Что мешало добавить проверку строки в golang с помощью utf8.valid, чтобы тоже сообщать, что строка некорректная?

Почему вывод rust считается корректным, если в исходной последовательности байт не была закодирована строка «\xBD\xB2=\xBC»?

grem ★★★★★ ()
Ответ на: комментарий от eao197

чистый C не умрет, т.к. ничего лучшего для организации FFI пока не придумано.

Лучше-то придумано. Но С используется только по причине легаси. При этом как клей для разных языков он убог чуть менее чем полностью. Начиная от отсутствия слайсов и заканчивая переусложнённым синтаксисом. Радует что хоть stdbool.h и stdint.h завезли.

Самая перспективная альтернатива - это web idl.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от grem

Что мешало добавить проверку строки в golang с помощью utf8.valid, чтобы тоже сообщать, что строка некорректная?

Вы так ничего и не поняли. Пути в винде имеют свою кодировку. Это не обязательно валидный unicode/utf-8. Поэтому в Rust есть String и OsString.

В Go тупо интерпретируют путь как utf-8, что в корне неверно.

Подробности: https://simonsapin.github.io/wtf-8/

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

пример не для винды был; да для путей в винде utf-16 - данная последовательность является корректной с точки зрения utf-16 или она всё ещё произвольная?

В Go тупо интерпретируют путь как utf-8

операции с файлом при этом будут работать или нет при обработке пути как последовательности байт?

и да: https://golang.org/pkg/path/filepath/

то есть автор статьи тот ещё «говнокодер»?

Ты так и не ответил что дальше то с этим «путём делать», о выводе инфы в несоответствующем действительности виде тоже.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 3)
Ответ на: комментарий от dnb

Если тебе нужно пол года на раст, то не представляю сколько понадобится на плюсы.

Kuzy ★★★ ()
Ответ на: комментарий от grem

используя класс path в rust выводим информацию с конвертирование в символ того, что можно (что такое {:?} кстати?)

Это debug вывод. impl std::fmt::Debug

Ээээ, чего показать то хотели в итоге?

То что строки в rust являются валидными utf-8 строками, а путь может быть невалидным, с т.з. utf-8, набором байт. В гошечке, как я понял, решили автоматически конвертировать путь в строку с потерями.

WatchCat ★★★★★ ()
Последнее исправление: WatchCat (всего исправлений: 1)
Ответ на: комментарий от WatchCat

Но в выводе примера на «rust» неверно отображается информация о пути: «\xBD\xB2=\xBC ⌘» не соответствует изначальной последовательности байт (по понятным причинам).

Лучше бы они привели примеры работы с такими путями, а то продемонстрировали, что в обоих случаях неверный вывод имени файла, имя которого нельзя интерпретировать как utf8 строку.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от anonymous

А когда внезапно станет заметена у проекта наступят очень интересные времена с ручными пулами объектов.

Kuzy ★★★ ()
Ответ на: комментарий от Kuzy

Плюсы умею немного и мне они даются проще. В раст потыкал и оставил.

dnb ★★★ ()
Ответ на: комментарий от grem

Но в выводе примера на «rust» неверно отображается информация о пути: «\xBD\xB2=\xBC ⌘» не соответствует изначальной последовательности байт (по понятным причинам).

А оно и не обязано правильно отображаться.
`Debug should format the output in a programmer-facing, debugging context.`

WatchCat ★★★★★ ()
Ответ на: комментарий от grem

Так потому что печатается этот пример через Debug, а не через Display.

Siborgium ★★ ()

Oh, here we go again - Rust, Rust, and Rust again.

Why always Rust?

Well, I tried real hard to keep Rust out of all of this.

Орнул. А таки сложно. Когда где-то кривое API, сложно не упомянуть нормальный аналог в Rust

vertexua ★★★★☆ ()
Ответ на: комментарий от Siborgium

Так там ж говорят, что нет Display для path.

grem ★★★★★ ()
Ответ на: комментарий от grem

Так поэтому и печатают через Debug, раз Path не реализует трейт Display.

Siborgium ★★ ()
Ответ на: комментарий от eao197

Все по существу, но есть нюансы.

Во-первых, если я правильно понимаю, то кодовая база COBOL - это в первую очередь системы, созданные десятки лет назад, и существующие только в рамках компаний, где они были разработаны. Я попробовал найти в открытом доступе проект, сравнимый по масштабам с, не знаю, OpenSSL, Node.js, etc, но не смог. Если такие есть, то было бы любопытно взглянуть. Почему это важно? Потому что это формирует комьюнити вокруг языка, которое потом держит такой язык на плаву.

Во-вторых, юниксовая экосистема - это, безусловно, легаси, но это то легаси, которое готовы активно использовать прямо сейчас для новых проектов: будь то сервера в датацентрах, будь то прошивка для какого-то девайса, будь то DPI под закон Яровой в соответствии с требованиями Роскомнадзора. Все это в конечном счете продлевает жизнь как юниксов, так и сишки, на которой они в том числе написаны. А кто сейчас готов использовать COBOL помимо тех, кто уже 30 лет его использует?

В-третьих, есть еще пункт про embedded, где использование С может быть обусловлено аппаратными ограничениями.

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

cherry_boy ()
Ответ на: комментарий от grem

для путей в винде utf-16

Не utf-16, а 2 байта. Путь не обязан содержать валидный utf-16. Ссылка выше.

и да: https://golang.org/pkg/path/filepath/

Что да? Вы статью читали? Там есть ответы на все ваши вопросы.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от WatchCat
  1. Тогда смысл примера? Тут много крика об utf8 строках, когда к ним пример отношения не имеет чуть более чем полностью.

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

  1. Создаём файл с именем «\xBD\xB2=\xBC ⌘» рядом с тем и теперь что мы увидим в выводе? Наблюдаем в списке 2 файла с одинаковыми именами!, но для одного почему-то сообщают, …. ладно правим сообщение об ошибке, чтобы у наблюдателя не было мысли «чё за нах?»

Добавляем в пример на golang проверку последовательности байт с соответствующим сообщением (если это конечно здесь возможно при получении списка файлов - а он скорее получается в виде последовательности байт) и видим в выводе 2 визуально разных имени файла и сообщением, что имя файла с кракозябрами закодировано неверно с точки зрения utf8.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

С используется только по причине легаси

вообще-то С - майнстрим, область использования сужается с появлением всяких DSL.

anonymous ()
Ответ на: комментарий от RazrFalcon

Там слишком много воды.

В обоих случаях имя мы отобразить не можем, но ты про с строки продолжаешь втирать.

Ещё раз: файл на чтение то открывается в каком либо из случаев?

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 2)
Ответ на: комментарий от grem

в выводе примера на «rust» неверно отображается информация о пути: «\xBD\xB2=\xBC ⌘» не соответствует изначальной последовательности байт (по понятным причинам).

Вообще говоря, если ты посмотришь внимательнее (и сравнишь с выводом ls), то увидишь, что соответствует. Три байта непечатаемые, остальные (пять байт, три символа) печатаемые.

Можем ли мы отобразить его имя - вообще неважно при этом, раз уж мы взялись такие файлы создавать.

Алё, гараж, тебе знакома разница между внутренним представлением и выводом?

Debug-распечатка ({:?}) вообще не обязана быть полной или корректной. Вот только у Go некорректно само внутреннее представление, т. е. ты просто не можешь в общем случае передать результат os.Readdir() в os.Open().

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от intelfx

Три байта непечатаемые

Да ты капитан очевидность! Только что с того то, что напечатали значения байтов в строке?

тебе знакома разница между внутренним представлением и выводом?

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

у Go некорректно само внутреннее представление

И где это там продемонстрировано? Строка в go не та же последовательность байт которая соответствует имени? Он её меняет, если она неправильная с точки зрения utf8?

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от rbbtnspc

Возможно, стоило загуглить?

Так это тогда почти любого языка касается. Думаю даже на nim, red или haxe найдется пара сервисных служб.

Aber ★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)