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

Удобно.

Сегодня ты берешь необстрелянного студента, а через месяц он даже способен что-то сделать.

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

Причем с учетом того что в Go совершенно уродский GC, пропустивший, как и все остальное в Go, последние 50 лет развития технологий…

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

И где это там продемонстрировано?

Это не важно. Оно по смыслу некорректно.

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

А это уже как повезёт.

Оно по смыслу некорректно.

Байты не байты?

А это уже как повезёт.

Чего? То есть он читает байты в строку (это же всё ещё последовательность байт?) и не хранит их в тех же самых байтах?

Давай вместе разбираться.

Смотри. Есть путь к файлу, представляемый некоторой последовательностью байт. Есть utf-8. Есть Rust и Go, оба используют utf-8 строки. Путь к файлу не является корректной строкой с точки зрения utf-8 в общем случае.

Что делает Rust? Rust вводит специальный тип OsString, корректно хранящий такие последовательности байт. Далее вводится тип Path, оперирующий OsStr и реализующий функционал работы с путями в файловой системе. Таким образом, даже если мы решили создать (читать, открыть, удалить, …) файл с именем подобно тому, что предложено по ссылке в оппосте, то все пройдет корректно.

Что делает Go? А Go ничего не делает. Стандартная библиотека Go оперирует исключительно utf-8 строками, и потому ничего ты с таким файлом сделать средствами стандартной библиотеки не сможешь, так как string не сможет хранить путь к нему. Придется подтягивать сторонние библиотеки (а есть ли они?), возможно мучаться с байтовыми слайсами и ffi с сишкой.

Байты не байты

Именно. Байты не байты. Байты там должны были быть одни, но эти байты не удовлетворяют utf-8. Так как string оперирует лишь utf-8, некорректные байты будут заменены на соотв. спецсимвол или попросту обрезаны. Таким образом, в строке байты окажутся другие.

Ну почитай ты про кодировки, ну не позорься ты так.

Rust разработали в компании, которая делает десктопный софт

Фиговому браузеру фиговый язык. А плюсы уже были изобретены до них. Всё сходится.

сервисные службы

хранение всех данных в дропбоксе

рендеринг вебстраниц

http/3

Лел

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

пруфлинк? можно прямо в сырец на строку где это происходит

Это не глупость, это гипербола - порог вхождения-то никто не отменял.

Фиговому браузеру фиговый язык

Отлично подходит под описание C++ и Chromium

C++ за 21 день, ага

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

пруфлинк? можно прямо в сырец на строку где это происходит

https://blog.golang.org/strings

It’s important to state right up front that a string holds arbitrary bytes. It is not required to hold Unicode text, UTF-8 text, or any other predefined format. As far as the content of a string is concerned, it is exactly equivalent to a slice of bytes.

Here is a string literal (more about those soon) that uses the \xNN notation to define a string constant holding some peculiar byte values. (Of course, bytes range from hexadecimal values 00 through FF, inclusive.)

const sample = "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98"

чё та это как-то не вяжется с твоим обрезанием, да?

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

Таким образом, если человек настолько тупой, что только Go и сможет осилить, ему вообще противопоказана работа программистом.

При этом всем, специально для дебилов спроектированные инструменты - и качественно и количественно снижают продуктивность нормальных разработчиков.

Т.е. пользы от таких языков не просто ноль целых хер десятых, а она даже отрицательная, т.е. это вред.

если человек настолько тупой

Show Me the Code

некорректные байты будут заменены на соотв. спецсимвол или попросту обрезаны. Таким образом, в строке байты окажутся другие.

Это никак не продемонстрировано. Последовательность байт не имеет отношения к кодировке. Используемая кодировка лишь определяет как эту последовательность мы хотим дальше интерпретировать.

эти байты не удовлетворяют utf-8. Так как string оперирует лишь utf-8

Вот неплохо бы продемонстрировать, что что-то меняется и в переменной хранится иная последовательность.

http/3

HTTP/3 is still a baby but

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

хранение всех данных в дропбоксе

Вчера было на одном языка, завтра сделают на другом, внутренняя кухня в каждой компании. Поменять имплементацию при очередном обновлении API не проблема, если это не легаси и на развите проекта выделяют деньги. И rust там скорее всего только один из кирпичиков.

рендеринг вебстраниц

Это уже ближе к пользователю, годится.

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

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

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

Согласен, но оно уже в проде, хоть и для особо бесстрашных.

Вчера было на одном языка, завтра сделают на другом

Бизнес немного не так работает. А если бы и так работал, то не долго.

Есть ещё два AWS (лямбда и чето про контейнеры). Если и это не подходит, то я даже не знаю.

Ну почитай ты про кодировки, ну не позорься ты так

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

Бизнес немного не так работает. А если бы и так работал, то не долго.

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

Самое главное что из твоего перечня opensource, т.к. подумаешь если где-то внутрях компании есть сервис реализованый на rust, где все глубоко под NDA, и вместо кода только слайды с очередной IT конфы об истории успеха руста.

Это никак не продемонстрировано. Последовательность байт не имеет отношения к кодировке. Используемая кодировка лишь определяет как эту последовательность мы хотим дальше интерпретировать.

Кажется, я распарсил о чем у вас сыр-бор. UTF-8 определен не для всех байтовых массивов. Не любой массив байт порождает валидный UTF-8. Здесь нет прямого отображения из массива в UTF-8. Отображается на UTF-8 лишь подмножество множества массивов байт.

Тебе пытаются донести, что растишка учитывает этот момент.

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

Это абсолютно неверное мнение, хотя бы потому, что порог вхождения в любой язык - по сравнению со средненьким проектом - абсолютно незначителен. Чтобы начать понимать код, и даже писать - достаточно понимать самые базовые конструкции языка. А далее любой язык учится «по ходу дела», и довольно быстро. Любой, даже хаскель. В таких криво и косо спроектированных языках, как С++, отдельные грабли потом изучаются годами, но это уже не порог вхождения совершенно. В 2020 году, при обилии документации, Stackoverflow-подобных форумов, и прочего - никакие шаблоны плюсов никакой абсолютно сложности не представляют. Даже для студентов. Это не значит что на C++ надо писать, это тоже дерьмовый язык, это просто пример.

порог вхождения в проект напрямую коррелирует с порогом вхождения в язык,

Нет, более того я часто наблюдал даже обратную ситуацию. Потому что чем «проще» язык, тем больший говнокод на нем можно написать (а если какое-то дерьмо может случиться, то оно обычно обязательно и происходит). PHP, Python, Go, JavaScript - эти языки провоцируют невероятное количество говнокода, об который даже у опытных разработчиков ломается мозг.

Даже если сишечка мертва, то как зомби она будет существовать ещё сотни лет

В точку! Это раковая опухоль, которая стала больше больного и переживет его. Не имеет никакого значения удобство, надежность, производительность, поддерживамость - это всё второстепенные свойства. Главное свойство - это готовые решения. То есть, не писать новый код, а просто дергать уже имеющиеся функции. А поскольку уже имеющиеся функции написаны на Си, то и дергать ты их будешь на Си.

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

а вот мне сдаётся, что ты более хорошо можешь трепаться. где много трепотни - там мало дела..

Есть только один хороший я.п. Это Си++

Есть только одно хорошее говно - то, которое кушаю я.

А при том, что на C++ как писали, так и продолжают писать крупные проекты

Ты бы щее вспомнил о том, что в гугле на питоне пишут, а значит это замечательный инструмент.

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

Да, и именно поэтому навык хорошего крестовика заключается в том, чтобы знать, какие фичи языка не нужно использовать, и как правильно использовать оставшиеся фичи. А худшее, что можно сделать с крестами - это использовать все доступные фичи языка.

залогинься

Юниксовые ядра написаны на C, драйвера написаны на C, системная обвязка в виде клиентов, демонов и прочих systemd написана на С, nginx написан на С, redis написан на C, openssl написан на C, curl, который тут светили, тоже написан на C. Слишком много активных и известных проектов для умирающего языка, не находишь?

Умирающесть определяется тенденцией, а не точечным состоянием. А тенденция такая - Си умирает.

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

проблема притянута за уши по следующим причинам:

1. если Go не может корректно распарсить юникод (sic!) то это решается багрепортом
2. следовательно, это проблема реализации, а не концепции.

intelfx, за тобой, поциент, я наблюдаю давно, и знаю что бы любишь газифицировать.

Не любой массив байт порождает валидный UTF-8.

Не любой массив байт порождает валидный UTF-8.

Именно. Это мне известно.

Тебе пытаются донести, что растишка учитывает этот момент.

Вызовом дополнительной проверки при «конвертации» одно типа в другой.

Я пытаюсь им донести, что go её можно тоже можно вызвать. И то, что переменная хранящая имя файла типа path в rust и типа string в go хранят одинаковую последовательность байтов. Ну да, в rust данная последовательность не преобразуется в строку даже частично (поэтому, видимо, и возвращается none); в go при выводе на экран преобразует то, что может, остальное отображает не даже знаю в виде чего.

Но в обоих случаях отображаемое на экране имя некорректно - корректное отображение невозможно. Какой подход лучше и реализация - дело вкуса.

Несомненно надо сообщать пользователю, что имя файла не может быть отображено корректно. И это можно сделать в обоих подходах.

Что лучше при чтении из файла байтов: отображать некорректно или вообще не отображать? Зависит от желаемой реализации.

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

Если бы не Go, я бы решил, что ты про динамическую типизацию.

залогинься

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

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

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

Повторишь это, когда наберешь написанную на Си команду гита, чтобы запушить новые строчки на Расте.
Читайте весь разговор целиком, что ли.

и вообще.. D лучше их обоих! =D

Если бы не неразбериха с D2 в свое время, то неизвестно как повернуло бы время. Я и сам когда-то увлекался D, который потом внезапно стал D1

написанную на Си команду гита

так git реализации не только на C есть.. погуглить за тебя?)

если Go не может корректно распарсить юникод (sic!) то это решается багрепортом

Если бы ты утрудил себя прочтением треда или поста по ссылке в ОП, ты бы понял, что речь идёт о строках, которые не являются корректным юникодом.

intelfx, за тобой, поциент, я наблюдаю давно, и знаю что бы любишь газифицировать.

Сначала залогинься, «поциент», потом поговорим.

я хз что там было раньше, но сейчас мне кажется что D шикарен.. никак руки не дойдут до него ((

Первый день на ЛОРе, прямиком из детсада?

На самом деле никто ничего не конвертирует до тех пор, пока не требуется это куда-то записать в нужном виде, в данном случае в виде текста.

После этого примера мне теперь непонятно, можно ли при чтении из файла повреждённой строки (теперь некорректной) показать её корректный фрагмент. Или чтение в переменную невозможно из-за встроенной проверки?

Этот подход — программирование методом задавания вопросов гуглу, поиска ответов в стэковерфлоу и т.п. — как раз и приводит к созданию ужасного кода. Хороший код возможно написать, только если хорошо знаешь синтаксис языка. Другого способа нет, поэтому порог вхождения не бывает маленьким. А для того чтобы грамотно использовать ООП, шаблоны, и прочие изощрения, вообще нужно знать принципы разработки архитектуры кода. Их 90% программистов не знают, поэтому пишут «чтоб работало». Значительная доля программистов даже процедурное программирование используют довольно криво, что уж говорить про ООП и т.п.

Первый день на ЛОРе, прямиком из детсада?

аа.. всё ясно

Понимаю. Из идейных соображений каждый поцыент устанавливает ту реализацию git, что написана на языке, привычном для больного.

Хороший код возможно написать, только если хорошо знаешь синтаксис языка.

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

Т.е. человек с широким кругозором и 10-летним опытом и на JS будет писать хорошо, разве что постоянно плеваться. А студент и на хаскеле наговнокодит(правда, на хаскеле еще терпимо, а вот дай ему в руки пых, бидон или вон то сабжевое поделие, там говнокод будет просто мама не горюй, просто потому что язык «изи», и можно херачить отсюда и до обеда).

Их 90% программистов не знают, поэтому пишут «чтоб работало». Значительная доля программистов даже процедурное программирование используют довольно криво, что уж говорить про ООП и т.п.

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

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

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

Повторишь это, когда наберешь написанную на Си команду гита, чтобы запушить новые строчки на Расте

Гит - редкостный кусок дерьма, слепленный на коленке по мотивам проприетарного софта. Лично я предпочитаю Hg.