Посмотрел я этот ваш Rust

Ой, это пройденный паскалем этап, который твой язык почему-то не прошел.

Паскаль не безопасен и там легко испортить память. Также там ручное управление памятью, а значит dangling pointers & memory leaks, первое может привести к порче памяти.

Тут три варианта, либо разрешить адресную арифметику и забыть про безопасность (C++), либо как в Обероне/Go со сборщиком мусора, либо мудрить хитроумную систему типов и владений как в Rust.

достаточно сделать довольно простой двухуровневый запрос по таблицам

…который легко делается для UTF-8 (prefix tree).

Неудивительно, что на этом фоне UTF-8 «просто работает» — нет локалей, нет и проблем.

Это его преимущество.

Спасибо хоть число графем умеют считать.

Вы так и не привели пример зачем это надо.

у приложения должна быть библиотека смайлов специально для отрисовки этих символов — иначе вместо них будут квадратики или вопросики.

Приложение просто передаёт строку в GUI тулкит, который сам всё делает. Нет необходимости писать свой рендеринг текста, всё уже сделано в FreeType/HarfBuzz.

работающем с семантикой текста.

Примеры в студию.

Но для UTF-16 это делать сильно проще.

Не сказал бы что сильно проще, там тоже переменное число байт.

А теперь прикинь, что у тебя в ОС-и системные идентификаторы записаны кириллицей.

Так и есть и УМВР (Linux KDE, Haiku). Юникодные имена символов в C++ и ELF модулях работают, специальной поддержки для этого не требуется.

А для ASCII-only идентификаторов можно брать не просто UTF-8, а даже тупо ASCII.

Нельзя потому что в любой момент могут понадобится символы за пределами ASCII.

Паскаль не безопасен и там легко испортить память. Также там ручное управление памятью, а значит dangling pointers & memory leaks, первое может привести к порче памяти

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

Тут три варианта, либо разрешить адресную арифметику и забыть про безопасность (C++), либо как в Обероне/Go со сборщиком мусора, либо мудрить хитроумную систему типов и владений как в Rust

Я несколькими сообщениями ранее описал четвертый вариант:

Посмотрел я этот ваш Rust (комментарий)

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

К слову, вариант такой защиты уже есть — это виртуальные машинки.

Модель организации динамической памяти, которую ты описал — это один в один ранний паскаль.

В Паскале разве был сборщик мусора? Там вроде всегда был dispose, который может привести к порче памяти.

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

Переизобретаете сегментную память? Её аппаратную поддержку уже почти везде выпилили. А без сегментной памяти нельзя без дополнительных накладных расходов и проверок защитить небезопасный код от записи по произвольному адресу.

достаточно сделать довольно простой двухуровневый запрос по таблицам

…который легко делается для UTF-8 (prefix tree)

Графему UTF-8 надо сначала найти в строке, а потом уже делать запрос к дереву. Ну или примерно половину запросов делать холостыми (для не-ASCII строк).

Неудивительно, что на этом фоне UTF-8 «просто работает» — нет локалей, нет и проблем

Это его преимущество

Ну и зачем такие регулярки человеку, которые работает с кириллическим текстом?

Спасибо хоть число графем умеют считать

Вы так и не привели пример зачем это надо

Графемы нужно считать, например, для того, чтобы выполнить условие «предудущий/следующий символ символ».

работающем с семантикой текста.

Примеры в студию

Приводил: Посмотрел я этот ваш Rust (комментарий)

Числа, даты, URL/email, взять слово из строки, валидировать последний введенный символ

Или даже банально кто-то напишет простые текстовые конфиги — но на родном для пользователя языке.

Приложение просто передаёт строку в GUI тулкит, который сам всё делает. Нет необходимости писать свой рендеринг текста, всё уже сделано в FreeType/HarfBuzz

Которые, внезапно, работают на базе UCS-4. Как и ICU.

Не сказал бы что сильно проще, там тоже переменное число байт

Смайлы, редкие математические операторы, к которым также прилагаются горизонтальные знаки дроби и знаки суммы с подстрочным и надстрочным указанием интервало, а также очень редкие иероглифы. Простой текст с семантикой в UTF-16 имеет строго фиксированное число байт, даже для китайского языка. Для сложного текста тебе не хватит и UCS-4, потому придумали составные символы из нескольких графем — но это уже издевательство, когда текст размазывается по соседним строчкам.

Ограничь системные идентификаторы UCS-2 — и ты сильно упростишь работу всей системы. Что и сделал MS. Туда попадут все примитивные символы всех языков мира. А приложуха внутри себя пусть хоть UCS-8 использует.

Так и есть и УМВР (Linux KDE, Haiku). Юникодные имена символов в C++ и ELF модулях работают, специальной поддержки для этого не требуется

Не всё так просто, например: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

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

А для ASCII-only идентификаторов можно брать не просто UTF-8, а даже тупо ASCII.

Нельзя потому что в любой момент могут понадобится символы за пределами ASCII

И тогда можно будет использовать UTF-8. А нагибать программистов раком, заставляя итерировать UTF-8, просто потому, что кому-то когда-то может быть наверное вполне возможно — это сомнительный ход. Чисто объективно, а не коньюктурно в рамках ASCII-only вечно совместимой экономики США, где на реактивных самолетах расстояния меряют шагами, ступнями, и пальцами.

В Паскале разве был сборщик мусора? Там вроде всегда был dispose, который может привести к порче памяти

Пардон, да, я затупил. Сборщика мусора, действительно, не было, но язык, тем не менее, разрабатывался именно под виртуальную машину.

Переизобретаете сегментную память? Её аппаратную поддержку уже почти везде выпилили. А без сегментной памяти нельзя без дополнительных накладных расходов и проверок защитить небезопасный код от записи по произвольному адресу

А разве сегментная память сама по себе не была этим накладным расходом? Так-то в x86_64 можно вполне себе выполняться в двух режимах виртуальной памяти — 32 и 64 бит.

но язык, тем не менее, разрабатывался именно под виртуальную машину

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

сегментная память
защитить адрес возврата

Можно, но для этого надо сделать call/ret привилегированными.
На эльбрусе АФАИК так и сделано.

Ну или примерно половину запросов делать холостыми (для не-ASCII строк).

Просто запрос к дереву в текущей позиции, если не найдено, то продвигаться на один char. Холостых запросов не будет, части символов будут отсеиваться на первом ноде дерева (которое Node *nodes[256];).

Ну и зачем такие регулярки человеку, которые работает с кириллическим текстом?

Регулярные выражения с байтами работают, а не с кириллицей (у меня вообще подозрения к тем кто упоминает слово кириллица, обычно это какие-нибудь фанаты КОИ-8 или cp1251). Что вы напишете, такие выражения и будут, хоть с иероглифами или смайлами.

выполнить условие «предудущий/следующий символ символ»

Зачем? Свой велосипед текстового редактора пишете?

Приводил: Посмотрел я этот ваш Rust (комментарий)

Сферический конь в вакууме, приводите конкретные примеры желательно со ссылками на софт, а не абстрактное непонятно зачем нужное «последние 20 символов».

Или даже банально кто-то напишет простые текстовые конфиги — но на родном для пользователя языке.

Никакой специальной поддержки UTF-8 не требуется, код для ASCII будет работать без изменений, максимум дописать что ch >= 128 это часть идентификатора.

Которые, внезапно, работают на базе UCS-4. Как и ICU.

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

Простой текст с семантикой в UTF-16 имеет строго фиксированное число байт, даже для китайского языка.

В китайском/японском языке регулярно попадаются редкие иероглифы. Одно время из-за этого был холивар сторонников Юникода и местных кодировок (Shift-JIS) когда в Юникоде ещё не было всех необходимых символов.

Не всё так просто, например: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

Status: RESOLVED FIXED

Видимо решились заморочиться с делением на буквы/пробельные знаки/спецсимволы для идентификаторов. Могли бы просто считать ch >= 128 частью идентификатора.

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

Какой раз повторяю что не нужная никакая специальная поддержка в большинстве случаев. Статическому/динамическому линковщику ELF нет дела какие ноль-терминируемые последовательности байт сравнивать и хешировать.

А нагибать программистов раком, заставляя итерировать UTF-8

Программисты, которым всё время надо посимвольно итерировать строки профнепригодны.

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

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

А разве сегментная память сама по себе не была этим накладным расходом?

Не была, по сравнению с таблицей страниц виртуальной памяти, расходы там околонулевые. Надо просто взять смещение и размер сегмента, прибавить смещение к адресу и проверить размер. O(1).

За счет чего короче?

Короче за счёт возможности вводить на С++ более высокоуровневые абстракции (шаблоны, коллекции, и т.п.), чем на Go, и за счёт обработки ошибок через исключения (а в Go ошибки надо обрабатывать явно после вызова каждой функции).

простой сервис

Простой сервис ничего не показывает. Тут ни Go, ни C++ не нужны. Надо рассматривать системы среднего и большого размера, когда все нужные библиотеки и абстракции уже есть в кодовой базе.

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

Например, вот такую библиотеку хрен напишешь на Go.

boost

Сверхжирное переусложнённое ненужно. Могли бы на чистом C++ написать.

Конечный автомат легко делается безо всяких библиотек через обычный switch.

Конечный автомат легко делается безо всяких библиотек через обычный switch.

Библиотека переносит формирование конечного автомата на уровень типов. Конечный автомат можно сделать через switch, а темплейты через копипасту и поиск с заменой – но зачем, если есть типобезопасная, удобная и, что важно, легко читаемая альтернатива?

Можно, но для этого надо сделать call/ret привилегированными.

Или отдельный стек для адресов возврата.

Короче за счёт возможности вводить на С++ более высокоуровневые абстракции (шаблоны, коллекции, и т.п.), чем на Go, и за счёт обработки ошибок через исключения (а в Go ошибки надо обрабатывать явно после вызова каждой функции).

Согласен, в теории оно все звучит так. Вот интересно было бы реальные исследования увидеть.

Я вот потому и немного удивился, когда ожидал увидеть разницу даже на простом сервисе, так как в Расте обработка ошибок ну сильно короче чем на Го. Но так то я тоже согласен, что мелкий сервис еще не показатель.

а в Go ошибки надо обрабатывать явно после вызова каждой функции

Редко можно встретить обработку исключения где знают что делают. В абсолютном большинстве случаев просто констатируют кодом - «что-то поломалось, а где и что…».
Эта отягощённость контролем ошибок есть признак того что всегда писали обработку исключения как подпорку. «Повалится, ну и пусть лежит».
Обработка ошибок в месте их возникновения есть часть логики алгоритма, программы.

Python язык где exceptions выглядят наиболее удобными и полезным инструментом.

Обработка в Go некоторыми считается автоматически плохой потому что им кажется что возвращение ошибок такое же как в C. Возвращение нескольких значений полностью меняет картину. Как в Lua.
В Rust добавили типы для этого, и подкрепили это статьёй про «ошибка на миллиард долларов», для значимости.

Просто запрос к дереву в текущей позиции, если не найдено, то продвигаться на один char. Холостых запросов не будет, части символов будут отсеиваться на первом ноде дерева (которое Node *nodes[256];).

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

Регулярные выражения с байтами работают, а не с кириллицей (у меня вообще подозрения к тем кто упоминает слово кириллица, обычно это какие-нибудь фанаты КОИ-8 или cp1251). Что вы напишете, такие выражения и будут, хоть с иероглифами или смайлами

Неочевидный факт, но регулярные выражения почти нигде, кроме простого текста, не нужны, поскольку простой текст в роли машинного представления представляет собой весьма неэффективную штуку. Не говоря уже про текст с разметкой, который регулярками не разбирается. А для текста важно найти границы слов, а еще круче было бы уметь игнорить мусорные черточки, наряду с игнорированием регистра — а игнор регистра поддерживается во всех движках регулярок, хотя бы на уровне ASCII. Ну и пользователя мало волнует, что регулярка задана в виде CP1251, а строка, по которой идет поиск, закодирована в UTF-8 .Так что по факту людям нужно анализировать регулярками именно видимый текст, а не байты.

выполнить условие «предудущий/следующий символ символ»

Зачем? Свой велосипед текстового редактора пишете?

Автоматическое распознавание семантики текста. Любое. В том числе:

Или даже банально кто-то напишет простые текстовые конфиги — но на родном для пользователя языке.

Никакой специальной поддержки UTF-8 не требуется, код для ASCII будет работать без изменений, максимум дописать что ch >= 128 это часть идентификатора.

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

Которые, внезапно, работают на базе UCS-4. Как и ICU.

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

Мне нравится такая позиция. Теперь логичное продолжение: почему где-то вообще временное внутреннее представление небольших буферов должно быть в UTF-8? Имен файлов и просто объектов IPC, печатаемый на экране монитора текст, будь то консоль или заголовочек в GUI. Если в конечном итоге продвинутые рендерилки шрифтов применяют int32_t. Хочешь хранить текст в файлах или передавать по сети? Пожал lz4 — это эффективнее, чем UTF-8. Более того, ты можешь жать свои байты lz4 даже в оперативной памяти — у него производительность распаковки 4-5 Гб/с, что немногим меньше тупого копирования байтов. Примерно так делает SAP HANA, к слову, с очевидным результатом — обращаться с запакованными данными значительно сложнее, чем с распакованными.

В китайском/японском языке регулярно попадаются редкие иероглифы. Одно время из-за этого был холивар сторонников Юникода и местных кодировок (Shift-JIS) когда в Юникоде ещё не было всех необходимых символов

Shift-JIS еще более упорота, чем UTF-8, поскольку даже не позволяет найти границу символа, потому рассматривать ее в качестве конкурента несерьезно, особенно если учесть, что Shift-JIS стандартизирован на год позже, чем Unicode 2.0. Ну типа если ты мне скажешь «выбирай, будет ли наша система на Shift-JIS или на UTF-8», то я скажу «конечно же UTF-8». Но для представления японского и китайского текстов UTF-16 тупо эффективнее, поскольку требует в среднем меньше байт. Много кто посчитал так же, как и я, и выбрал UTF-16. Но реалии экономики показали, что обратная совместимость с сишкой первешивает любой здравый смысл. И особенно здравым смыслом я вижу необходимость полного отказа от Си — не только из-за кодировок.

Да-да, еще раз, чтобы убрать двусмысленность: UTF-8 получил распространение именно как костыль под никсами, который со временем перетек в интернет (поскольку много серверов на никсах), а потом его уже внезапно стало не извести, даже несмотря на то, что никакой канал UTF-8 сам по себе не экономит — его применяют просто из соображений безопасности, потому что весь клиентский и серверный софт заточен под UTF-8. В этом смысле я полностью соглашусь, что очень рисковано заниматься самодеятельностью и пытаться лепить на сайт UTF-16. Но если никто тебя не заставляет пользоваться UTF-8 — зачем оно нужно?

Status: RESOLVED FIXED

Видимо решились заморочиться с делением на буквы/пробельные знаки/спецсимволы для идентификаторов. Могли бы просто считать ch >= 128 частью идентификатора

Так год зацени — это свежак. Компилятору таки приходится разбирать семантику: ему важно, что там находится внутри «идентификаторав», есть ли там какой-то служебный символ с ch < 128, который должен подлежать специальной интерпретации, является ли он частью юникодной графемы или же стоит отдельно.

Статическому/динамическому линковщику ELF нет дела какие ноль-терминируемые последовательности байт сравнивать и хешировать

Это правда. А теперь попробуй сделать линковщик регистронезависимым. Ты перепутал причину со следствием: линковщик ELF ограничили в возможностях, поскольку в рамках никсов не получается анализировать семантику символов, ведь у нас сплошь и рядом в либах сишное убожество, которое умеет только в байты и ничего кроме байтов. Нужно отсортировать список по алфавиту? Да вам это было не нужно — сортируйте по байтам. И с твоей позиции это самое «нет выбора» каким-то образом становится фичей. А если я хочу, чтобы удобно было мне, а не моему компьютеру?

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

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

В Обероне нет виртуальной машины, всё компилируется в машинный код и может напрямую взаимодействовать с SO/DLL библиотеками в обе стороны

В жаве тогда, получается, тоже нет виртуальной машины? Она тоже умеет компилироваться в натив, и с нативным кодом перекидываться вызовами. Да. в паскале не было сборщика мусора. Более того, в ранних предках JVM не было сборщика мусора — слишком уж они дорогие, падлы, были по меркам тех времен. Так что работали с памятью ручками. Но машинка была виртуальная — с настоящими файлами программа работать не умела, и системных вызовов не знала, трансляцию в онные производил промежуточный слой, который и можно назвать виртуальной машиной. А можно и не назвать — как поставишь определение.

Не была, по сравнению с таблицей страниц виртуальной памяти, расходы там околонулевые. Надо просто взять смещение и размер сегмента, прибавить смещение к адресу и проверить размер. O(1)

ну там была и кооперативная многозадачность-с. То есть, один процесс честно-честно обещает не лезть в память другого. Если система начинает контролировать доступ, то внезапно начинают вылазить логарифмы сложности.

и за счёт обработки ошибок через исключения (а в Go ошибки надо обрабатывать явно после вызова каждой функции)

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

Я вот потому и немного удивился, когда ожидал увидеть разницу даже на простом сервисе, так как в Расте обработка ошибок ну сильно короче чем на Го

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

Просто не обращай внимания.

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

Твою позицию насчёт «усложнений» уже понял ещё в теме про хаскель. Не согласен, моя производительность при переходе на раст выросла, но не думаю, что смогу переубедить. Да и объективно это замерить сложновато. Впрочем, с некоторыми тезисами всё-таки постараюсь поспорить.

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

Внимание, важный тезис: индустрии нужно было просто ПОВЫСИТЬ НАДЕЖНОСТЬ работы программ. Не сделать их безупречно безопасными, потому что это практически невозможно, а просто повысить их надежность.

Так ведь именно это и сделали! Никакая технология не даст магическую «безупречную безопасность», особенно если мы начнём расширять список ошибок, от которых надо защищаться. Я бы ещё поверил, что тебе действительно не нравится именно как в расте к этому подошли, но ты «просто» хочешь «немного более безопасный» С++. Вот только это тоже не будет бесплатным: придётся или какие-нибудь атрибуты расставлять или специальные типы использовать и прибивать гвоздями статический анализатор. Будет ли это лучше? Я вот не уверен. С одной стороны, преимуществом выступает больший объём кода (который правда никто переписывать не побежит) и специалистов. С другой стороны язык тяготит легаси, а станет он ещё сложнее.

Как по мне, у раста довольно неплохой баланс предоставляемых гарантий с практичностью. Всё-таки ATS не особо взлетел, да и Agda тоже. Да, где-то используются, но о вытеснении С/С++ речи не идёт даже в самых смелых фантазиях. О полноценном взлёте раста тоже говорить пока рано, но пока тенденции положительные. Опять же, раст даёт ещё и множество «мелочей», которые в современных языках идут из коробки, а в С++ до сих пор договориться не могут. Можно, конечно, сказать, что популярность исключительно из-за хайпа и рекламы, но если смотреть объективно, то мозилла совсем бледно выглядит на фоне айти гигантов. Которые начали язык пробовать уже позже, хотя вполне могли бы выкатить что-то своё.

Как говорит народная поговорка «за ёлками леса не видно»:

На динамически типизированном языке функция выглядела бы ещё проще. Думаю, что у тебя просто нет практики чтения такого кода, вон он и вызывает удивление. Как по мне, более конкретные ограничения понятные по сигнатуре - это плюс, а не минус. Опять же, не согласен, что тут есть прям качественная разница с С++, где шаблоны тоже могут выглядеть очень перегружено. Я к тому, что хуже не стало.

Ну и наконец в «среднем» коде всяких «ужасов» и не будет. Я работал над С++ проектами, где и бустом обмазываться любили и свою шаблоны активно писали. Верю, что где-то может и весь проект из такого целиком состоит, но в моём опыте это всё было аккуратно завёрнуто и большая часть кода была вполне обычной. В расте такая же ситуация: да, где-то будут сложные дженерики, но далеко не везде.

Нет никакого мусора в данных.

Мусор не в «данных», а «на входе». Кривые индексы - это вполне себе входные параметры для функции. Всю необходимую информацию по работе с UTF-8 в расте я уже привёл, только ты это проигнорировал.

Или не знают что такое UTF-8, или не используют Rust.

Ага, конечно. Только ты и Роб Пайк знаете как работать с юникодом.

На расте пишу четыре года, если что.

Тема-то старая, но внезапно снова всплыла. (:

Расскажите это пользователям iPhone, у которых телефон бесконечно перезагружался от неправильного UTF-8 в сообщениях. Пусть лучше ерунду на экран выводит, но не падает.

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

Но вообще кроме «падать» и «выдавать мусор» есть и другие варианты.

В Go range понимает utf8:

const c = "çé"
for index, runeValue := range c {
    fmt.Printf("%#U starts at byte position %d\n", runeValue, index)
}

Выведет:

U+0063 'c' starts at byte position 0
U+0327 '̧' starts at byte position 1
U+0065 'e' starts at byte position 3
U+0301 '́' starts at byte position 4

Это совсем не то, что ожидал бы человек, который хочет получить «символы». Тут надо не только чтобы «Go range понимал utf8», а и самому соображать, что происходит.

К слову, точно так же можно и на расте:

let nihongo = "日本語";
for char in nihongo.char_indices() {
    println!("{:?}", char);
}

Недавно в Windows 10 сделали поддержку UTF-8 в ANSI функциях, UTF-16 можно закапывать.

Справедливости ради, они сделали это довольно костыльно. И я уверен, что внутри они сначала в UTF-16 преобразуют, а потом передают в уже существующие функции.

Это уже выяснили в других комментах.

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

На расте пишу четыре года, если что.

Хочу на него перейти.
Пару лет назад были проблемы с инструментарием как «go to definition», в Emacs что-то перестало функционировать, и казалось что язык заглох.
Единственный компилятор. Но всё же если есть стабильный синтаксис то перенести можно, главное что не нужно GC свой реализовывать.

Языки которые не предоставляют полный IDE в Emacs - по моему мнению ущербны за редким исключением. A Rust сейчас вроде бы работает отлично.
Надо вспомнить ту либу… Racer! https://github.com/racer-rust/racer
Автор как-то терял интерес, или что-то не получалось реализовать.
А сейчас LSP аботает, даже нет необходимости смотреть на чём сделано.

Румынские «ț»(c), «ă»(э), «î»(ы). Не руны.
Й не руна.

UTF-8 надо запретить и сажать за посты в твиттерах с UTF-8.

Дебаг в Java гамно, неюзабельное, неработающее.
Про operator overloading не ко мне, это кажется к byko3y который осилил Java, с перегрузкой операторов наверное. Или в уме был Python.

В Обероне это уже давно сделано. Компилятор генерирует код так, чтобы ошибка обращения к памяти (NULL dereference, переполнение стека и т.д.) не приводила ни к чему плохому

«Ничего плохого» - это не падение/UB, а исключение?

«Ничего плохого» - это не падение/UB, а исключение?

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

Кто, я?

Ненужнисты

Дебаг в Java гамно, неюзабельное, неработающее.

В чем это выражается?

Дебаг в C++ гамно, неюзабельное, неработающее.

Починил. В Java намного лучше с дебагом ввиду безопасного языка и наличия метаинформации. В C++ не поймёшь длину массива и что в void* лежит.

В чем это выражается?

Это было полтора-два года назад. Я ожидал идеала, эталон индустрии, пример для других языков.
И в Eclipse, и в JIdea дебаг какой-то бесполезный.
Я пытался читать проект с помощью дебаггера, как с GDB.
Забросил эту идею работать с Java, оно не стоит перехода с Emacs.

Я не тот кто работает с Java и при этом критикует. Нет. При этом все нормальные вакансии на Java для тех кто с ней лет 10 работает и с мощным корпоративным опытом. Иногда висят месяцами.

При этом SBCL удивлял. Серьёзный инструмент.

Go это улучшенный Oberon на синтаксисе C.

Скорее поломанный Оберон. В Go насколько я понимаю нет нормальной динамической загрузки модулей и исключений (HALT(n), ASSERT(cond, n)). Непонятно как дела с метаинформацией и рефлексией.

Почему ты меня к ним приписал?

В Go насколько я понимаю нет нормальной динамической загрузки модулей и исключений (HALT(n), ASSERT(cond, n)). Непонятно как дела с метаинформацией и рефлексией.

HALT это как во Free Pascal? os.Exit() в Go?
ASSERT… Есть panic(), recover() и defer statement в комплексе.
Или в OBERON это совсем что-то волшебное?

Runtime reflection в Go в stdlib, import "reflect".

HALT это как во Free Pascal?

Это генерация исключения с выводом окна с описанием ошибки. Можно обработать и работать дальше, что делает GUI среда по умолчанию, например если в процедуре отрисовки будет вызов HALT(), то покажется сообщение об ошибке и отрисовка конкретного визуального объекта, вызвавшего ошибку, будет отключена, на других визуальных объектах ошибка не скажется.

HALT() реализована как сигнал SIGILL, в Обероне исключения работают через сигналы.

ASSERT…

ASSERT(cond, n) — это сокращение для IF ~cond THEN HALT(n) END. Используется для проверки параметров процедур и корректности внутреннего состояния.

Есть panic(), recover() и defer statement в комплексе.

Если есть, то почему тогда всё ещё жалуются на отсутствие исключений?

Если есть, то почему тогда всё ещё жалуются на отсутствие исключений?

Если не жаловаться, то будет скучно :)

Не согласен, моя производительность при переходе на раст выросла

При переходе с чего и в какой сфере? Тут должна была быть цитата про забивание болтов и закручивание гвоздей.

Я бы ещё поверил, что тебе действительно не нравится именно как в расте к этому подошли, но ты «просто» хочешь «немного более безопасный» С++. Вот только это тоже не будет бесплатным: придётся или какие-нибудь атрибуты расставлять или специальные типы использовать и прибивать гвоздями статический анализатор. Будет ли это лучше?

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

С другой стороны язык тяготит легаси, а станет он ещё сложнее

Я до сих пор не могу однозначно ответить, что же было в голове у людей, которые решили, что переходить с Си на C++ — это хорошая идея. Когда в итоге из-за манглинга ты все равно не можешь писать на C++ так, будто это и есть Си, а дергать сишные функции можно на куче языков, для этого не обязателен Си-подобный язык.

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

Да, стало так же плохо, как в шаблонах C++. Представь на секунду, что ты можешь писать на C++ вообще без типов, только тип контейнера при создании указываешь. А теперь задайся вопросом: зачем нужен питон или Go, если у тебя есть такой язык?

ASSERT(cond, n) — это сокращение для IF ~cond THEN HALT(n) END. Используется для проверки параметров процедур и корректности внутреннего состояния.

То же самое в Go. Только пишут функции для удобства типа ASSERT, но разные варианты.

if condition {
  panic(err)
}

panic("something happened") покажет не окно конечно, но что это panic, текстовое сообщение и traceback.
В traceback будут полные квалифицированные названия функций, полные пути к файлам, номерa строк, и позиции в абстрактном ассемблере.

В Go насколько я понимаю нет нормальной динамической загрузки модулей

Есть, но в виде сборки *.so, shared object потому что несколько лет назад было доступно только на Linux. Может быть появилось на других платформах.
OBERON вещь в себе, там это легко сделать, «для самого себя».

Дебаг в Java гамно, неюзабельное, неработающее.

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

Если есть, то почему тогда всё ещё жалуются на отсутствие исключений?

Потому что с исключениями легко и просто реализуются сценарии вроде «перехватить только конкретное исключение или его наследников», а с паникой - нет. Ограничение не техническое и специально подталкивает к тому чтобы на паниках не строили обработку ошибок.

Потому что с исключениями легко и просто реализуются сценарии вроде «перехватить только конкретное исключение или его наследников»

В Обероне перехватываются все исключения без разбору и ничего… Имеет значение только упало/не упало.