Вышел Rust 1.3

Единственное решение которое сейчас приходит в голову

Хреновое. У тебя тогда строки от Char отличаться не будут. Это в питоне нет специального типа для символов, ибо он всё равно динамический и типы не проверяет, поэтому строки можно писать так и так.

которые не считали бы Такой_Стиль_Наименования красивым

s/не//g

Что за проблема, как решить?

Допилить документацию малость нужно.

но тем не менее to_string() здесь выглядит очень костыльным решением

В to_string() нет ничего костыльного. String владеет данными в куче, так что ты не можешь просто иметь его на момент запуска программы, тебе нужно его из чего-то создать.

Хорошие плюсисты в раст должны въезжать легко. Я так думал.

Я по прежнему так думаю.

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

Придётся, но на Rust гораздо больше времени и нервов потратится.

Нет.

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

Да, языки с GC, пожалуй, проще. Но так у раста ниша другая. И жертвовать преимуществами просто чтобы тебе удобнее (а скорее даже «привычнее») было никто не будет. И правильно.

Это всё имеет отношение к работе со строками

К «работе со строками» отношения имеет гораздо большее количество сущностей. Ты же свалил в кучу совершенно разнородный набор.

Визуально это всё очень уродливо выглядит.

Нет. Непривычно и непонятно без знания матчасти - возможно.

Вероятно, раст не лучший язык в качестве первого, особенно если человек не желает терпение проявить. Хотя в твоём случае, мне кажется, больше проявляется «синдром утёнка» - все жалобы на то, что сделано не так как ты привык. У меня после С++ (в основном) вопросов было куда меньше и они были совершенно другие. Что в общем-то логично, учитывая нишу на которую претендует язык.

В любом случае, я сомневаюсь, что раст нужен всем. Устраивает питон/шарп/джава/пхп - пожалуйста.

И мне кажется проблема слишком преувеличена.

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

Два года назад работал со строками в С++, вообще в программировании не разбирался но было проще и приятнее с ними работать

Можешь конкретно перечислить проблемы которые есть в расте и которых нет в С++? Форматирование там такое же. Да есть стримы, но каждый второй предпочитает что-то типа boost::format.

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

Логика из разряда «докупить ещё несколько планок оперативной памяти»...

Вообще мимо.

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

Да, не получилось! Решил я «Hello World» модифицировать и не получилось. Нужно to_string() вызывать.

Покажи пример.

println!("{}, {}", "hello", "world!");

Просто в таком виде он на язык общего назначения не тянет

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

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

Так что то, что раст не является универсальным инструментом - совершенно нормально.

Вот тут никаких to_string, например.

Он упертый) Один в один это же с ним уже обсуждал - Что вы хотели бы увидеть в идеальном языке программирования? (комментарий) и выше по ветке.

Писать серпантины из лайфтаймов удобно

Передёргивание. Во первых, в большинстве случаев это не требуется. Во вторых, то что оно удобно я и не заявлял. Другое дело, что варианта лучше пока не видел.

а поднять одну букву в верхний регистр — нет. Ну и почему это неудобно?

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

Функция плохо себя описывает, такую простую вещь и искать в документации — ну смешно же

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

А ты терпеливый) Уверен, что есть смысл ему отвечать?

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

Единственное решение которое сейчас приходит в голову:

Различие не бросается в глаза. Особенно, без подсветки ИДЕ против которой ты выступал.

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

Так 80% программистов скажут

Нет, 80% «новичков» или «программистов с ограниченным» (и не сишным) опытом.

//// struct Test { // лайфтайм 'z' такой как у 'x'
////     @x: &i32,
////     @y: &i32,
////    x@z: &i32
//// }
////
////// struct Test { // 'x' и 'z' имеют одинаковый лайфтайм 'a'
//////    a@x: &i32,
//////     @y: &i32,
//////    a@z: &i32
////// }

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

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

fn test(@a: &i32, @b: &i32) -> Test {

Тут, кстати, @ смысла и не имеют. Ведь лайфтаймы у ссылок есть просто по определению.

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

Нет. Встретил в «References and Borrowing» и там ни слова о том что это dereferencing.

Действительно. Впрочем, в предыдущих главах оно слегка объясняется. Есть даже пару слов в Introduction. На мой взгляд, книга структурирована не лучшим образом, может со временем это изменится.

В одних случаях удобна, в других нет.

А давай на конкретных примерах.

Что-бы я не говорил, ты всёравно станешь на другую сторону и будешь твердить обратное ))

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

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

Один в один это же с ним уже обсуждал - Что вы хотели бы увидеть в идеальном языке программирования? (комментарий) и выше по ветке.

Пропустил тему, почитаю...

Я даже, в своё время, выписал список из десяти пунктов о вещах которые меня бесят в расте.

Можно ссылку?

Можно ссылку?

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

1. Нет перегрузки функций. Ну тут без шансов, а жаль.

2. Нет опциональных параметров. Второе бы несколько сгладило отсутствие первого и убрало дурацкие «билдеры», которые сейчас рекомендуют использовать. Ну и апи было бы менее замусоренным. Хотя после стабилизации мусор в виде кучи «конструкторов» похоже будет с нами всегда. Например, у HashMap: new, with_capacity, with_hash_state, with_capacity_and_hash_state - уродливо ведь. А добавление ещё одного параметра сделает всё ещё «веселее».

3. Нет переменного количества аргументов (хотя бы для одного типа) - стали бы не нужны макросы типа vec!, которые ещё и не совместимы с конструкторами из предыдущего пункта.

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

5. Не помешал бы nothrow атрибут для функций. Ведь паника разматывает стек и вызывает деструкторы, как и исключения, так что это помогало бы компилятору с оптимизациями. Ну и «явности» стало бы больше, а ведь именно это многие считают преимуществом языка. Есть ведь специальное обозначение для функций которые никогда не завершаются (нормально).

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

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

8. Макросы. Не нравится, что они сделаны как совсем отдельный язык, пусть и «простой». Плюс много корявых моментов - на них не действуют неймспейсы, импорт дурацкий и т.д. Мне кажется, что у многих есть опасения того, что макросами легко «всё запутать» и только из-за этого опасения «тормозиться прогресс».

9. Хочется сахара для CTFE. Сейчас ради этого приходится писать плагины к компилятору.

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

Тут надо сказать, что некоторые пункты точно будут фиксится/улучшаться, так что всё не так плохо. Правда некоторые моменты всё-таки вызывают опасения. Скажем, макросы уже стабилизировали, значит переделывать их вряд ли будут. К 2.0, вроде, хотят много изменений разных вносить, но совместимость-то обещали. Значит, в «лучшем случае» будут ещё одни макросы, а так и до С++ недалеко.

Ну и некоторые вещи (исключения, например) принципиально не хотят делать, что меня не радует.

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

Ты про 1..10 vs 1...10? "..." вроде же не добавили, или я пропустил?

Всё, понял, о чём ты.

Ну и некоторые вещи (исключения, например) принципиально не хотят делать, что меня не радует.

Ну так зачем они будут нужны, когда завезут HKT?

Ты про 1..10 vs 1...10? "..." вроде же не добавили, или я пропустил?

При паттерн матчинге можно использовать и ".." и "...".

Ну так зачем они будут нужны, когда завезут HKT?

Может я чего-то не понимаю, но как одно заменяет другое?

Вместо исключений будут монады :)

Вместо исключений будут монады :)

Но паника-то останется?

Собственно, чтобы паника была «полноценными исключениями» надо просто сделать немного более удобную обработку. Всё остальное и так есть.

Но паника-то останется?

Конечно.

чтобы паника была «полноценными исключениями»

Ну, лично я не уверен, что паника должна быть «настоящим исключением».

Ну, лично я не уверен, что паника должна быть «настоящим исключением».

Мы об этом уже спорили пару раз. Да и про субъективность я сразу оговорился.

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

всё равно динамический и типы не проверяет

И откуда вы такие лезете?

Проверяет, но только в рантайме, хотел сказать. Кроме придирок слаовам сказать что есть?

http://www.opennet.ru/opennews/art.shtml?num=43017

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

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

А кто-то это обещал?

Это был хороший способ показать нужность.

Это был хороший способ показать нужность.

Не был. ScyllaDB - продолжение OSv, которая на Си++.

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

Проверяет, но только в рантайме, хотел сказать.

И че? Если проверяет только в рантайме, то можно писать, а вот если бы проверял при компиляции, то увы - было бы нельзя? Мусье может вообще объяснить, причем тут динамизм, отсутствие спец-типов и проверка их же?

Кроме придирок слаовам сказать что есть?

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

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

Большинство умеет только в джангу. Какой Go? То есть они не очень представляют как писать код работающий с сетью. Естественно нужны дополнительные люди.

может вообще объяснить?

Может. В любом языке есть ряд функций, принимающих на вход единичный символ. Так вот, в питоне нету символьного типа, и при передаче строки с несколькими символами такие функции тупо кидают исключение типа «В твоей строке слишком много символов, чувак». В статически типизированных языках такое поведение будет выглядеть немного странно, поэтому нужен символьный тип. Я не говорю, что это Design goal при создании символьного типа, но одна из проблем, которую решает его существование. А раз во всяких сишках нужен символьный тип, его нужно как-то синтаксически выделить. Этой целью и заняты ", предложенные тем норкоманом, которому я отвечал, к использованию для владеющих строк. Доступно?

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

Жесть. *рука-лицо*

Так вот, в питоне нету символьного типа,

Потому что он в динамике прекрасно заменяется строкой с одним типом. И потому что, в принципе, не особо нужно.

и при передаче строки с несколькими символами такие функции тупо кидают исключение типа «В твоей строке слишком много символов, чувак».

Угу, только вот при отсутствии стат. проверки типов оно «по барабану». Т.к. все равно могут передать int, dict и так далее — т.е не подходящий для обработки тип.

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

Принимая строку, обрабатывать только первый символ? Нет. Но повелосипедить и покостылять таки да, все же придется (проверка длины, «выковыривание» каждый раз из строки конкретных значений и т.д. — да, легче ввести отдельный тип).

А раз во всяких сишках нужен символьный тип

Угу, особенно в слаботипизированном си. Да, встроенная в старом коде или либах «ascii-арифметика» бывает очень «доставляет».

Этой целью и заняты ", предложенные тем норкоманом, которому я отвечал, к использованию для владеющих строк. Доступно?

Дык это я сразу понял, если что. Что не отменяло (и не отменяет) невменяемого примера с питоном, в котором как раз можно и без этих типов обойтись :)

А раз во всяких сишках нужен символьный тип, его нужно как-то синтаксически выделить. Этой целью и заняты ", предложенные тем норкоманом, которому я отвечал, к использованию для владеющих строк. Доступно?

ЗЫ: казалось бы, причем вообще типы и литералы? Ну делай в случае надобности хоть chr(«f»)... Хотя вообще-то «норкоман» предложил backticks ``, что тоже на мой взгляд не очень оптимально.

ScyllaDB - продолжение OSv

Откуда дровишки? Оно на их собственном фреймворке, которой в той же организации на гитхабе лежит.

ScyllaDB - продолжение OSv

Откуда дровишки?

Его пишут те же люди - было бы странно, если бы одна группа разработчиков использовала разные языки; эти люди пишут свой _стек_, довольно специфичный - опять же, нет смысла использовать 2 языка.

Оно не зависит от гипервизорной прокладки, если я правильно понял.

Просто хотелось бы видеть на расте что-то очевидно полезное для народного хозяйства. Из большого пока только Servo.

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

В общем случае работает. По крайней мере с vimscript, bash, perl, java и С# получалось. Открыл исходник, открыл доки, разобрался с кодом, внёс свои изменения, запустил — работает.

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

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

Просто это редко нужно.

Это нужно, иначе ты язык не поймёшь.

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

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

Ты опять путаешь «нормальность» и «непривычность».

А может вещь, к которой так сложно привыкнуть — ненормальная?
Вот я думаю, что люди которые считают синтаксис Rust нормальным, никогда нормального синтаксиса не видели.

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

По поводу синтаксиса и строк я видел много гнева в сторону Rust.

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

Это не значит, что его нельзя критиковать.

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

И чем раньше тем лучше. Пока не поздно

А какой язык тянет?

Да какая разница? Нужно чтобы Rust тянул

Не соответствует избранному авторами раста кодинг-стайлу.

Кодинг стайл можно дополнить таким «исключением»: названия типов в функциях — с заглавной. Логично же? А то типы с маленькой писать — может быть неоднозначность.
Например, get_data() и get_Data() — в первом случае мы получаем какие-то данные, во втором мы получаем конкретный тип: Data.

получится PHP

Преувеличено. Такой_Стиль_Наименования будет только там, где он уместен.

Строка 'a'
Char__ `a`
Отличаются. Только человек с очень хреновым зрением может ошибиться.
Подсветка кода в данном случае решает.

В общем случае работает.

Нет, не работает. Или ты не понимаешь что такое «в общем случае».

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

Красивой реализации ты так и не показал. Зато отлично показал отсутствие знаний «системных языков».

Это нужно, иначе ты язык не поймёшь.

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

Это не книга-учебник по языку, это как энциклопедия, справочник.

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

Ну и кинь ссылку на «идеальную документация» без этой абстрактной болтовни про «вот майкрософт заботятся обо мне...».

Вот я думаю, что люди которые считают синтаксис Rust нормальным, никогда нормального синтаксиса не видели.

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

По поводу синтаксиса и строк я видел много гнева в сторону Rust.

Ну а я много раз видел, что «<любой_язык> не нужен». И что это значит? Да ничего, по сути.

Это не значит, что его нельзя критиковать.

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

Только человек с очень хреновым зрением может ошибиться.

Про то, что шрифты бывают разные, я так понимаю, ты не слышал?

В to_string() нет ничего костыльного.

Слегка не так выразился: to_string() выглядит слишком громоздко. Когда контент важнее чем логика (например в веб-программировании) тогда такие вещи сильно напрягают. Сложно писать элегантный код.
to_string() это +11 символов.

тебе нужно его из чего-то создать.

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

Освой сишку/плюсы, походи по граблям с утечками памяти и падениями, а у новичка такие проблемы возникнут наверняка

Даже NullPointerException у меня не вызывал таких диссонансов как to_string().

жертвовать преимуществами

Ну не надо так драматизировать.

Ты же свалил в кучу совершенно разнородный набор.

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

Нет. Непривычно и непонятно без знания матчасти - возможно.

Понимаешь, привыкнуть — не проблема. Я отказываюсь к такому привыкать.

все жалобы на то, что сделано не так как ты привык.

Из разряда: «извиняй, но ты живёшь в России и придётся хреначить. И ничего ты нам не докажешь. Привыкай»

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

В реальной жизни с такими проблемами сталкиваешься редко.

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

Давай! System.out.println(«Hello» + " World!");. Только без форматирования, с конкатенацией.

Мы вызываем метод у чего-то. Чтобы знать, что произойдёт надо посмотреть какой тип.

Логика из разряда «напишу криво, и плевать что нужно больше телодвижений чтобы разобраться в коде, зато всё по правилам, всё так как мне привычно )))»

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

В Rust нет перегрузки операторов, да и вообще функция не может вернуть какой-то левый тип — мимо