Вышел Rust 1.0

И это плюс. Просто таскать везде to_string() копируя(!) байты из дата секции как-то глупо для системного языка.

Я тебя не понял. Если тебе достаточно слайсов, то зачем копировать?

Причем тут trait-object? Это все на уровне системы типов, примерный аналог type families из Haskell: https://wiki.haskell.org/GHC/Type_families#An_associated_data_type_example .

Если просто, то String это std::string, а &str это char*

Хрена лысого. str не может в индексацию.

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

str не может в индексацию.

String тоже.

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

Смущает String и str что ли? Вообще, типы с большой буквы, но для «примитивных» типов сделано исключение: i32, i8, str и т.д.

То есть это просто сахар для того, что бы везде не писать <A, B, C<A, B>>, никакая рефлексия о типах в сам объект не кладётся, верно?

Если тебе достаточно слайсов, то зачем копировать?

Везде в примерах используют String. И «my string».to_string()

Это всё понятно. Меня интересует конкретно что меняется на уровне байтов в случае внесения Associated Types.

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

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

Как ты собираешься индексировать символы в utf8-строке? Операция индекса подразумевает константную сложность, символы же могут быть разного размера. Если очень хочется, можешь делать chars().nth() и терпеть линейную сложность. Если же надо индексирования, делай collect в vec<char> и индексируй.

Смущает String и str что ли?

Смущает почему не сделали str как String просто со ссылкой на данные и пустым drop. Естественно String тогда нужен немутабельным. Кстати, в свете того что отдельными чарами все равно не поиграешь, то от мутабельности пользы практически никакой.

Везде в примерах используют String. И «my string».to_string()

Ну так это для примера, наверное. Нужно оно точно не везде. Собственно, всё как ты и сказал - если не собираешься менять, то тебе достаточно слайсов. Если пишешь функцию, которая только «читает» строку, то тоже принимать должен именно слайс. И передать можно будет и String и слайс без всякого to_string.

Ну а если строка будет меняться, то понятное дело, что слайс не подойдёт.

Неявного приведения типов в Расте нет, поэтому так написать тоже нельзя:

let a: String = "eee"; // fail

Как ты собираешься индексировать символы в utf8-строке?

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

Нет конечно, все в компайлтайме проверяется, в рантайме никаких типов нет, рефлексии тоже.

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

Поэтому, живя в мире победившего utf8, нормальные языки при каждом вводе-выводе активно конвертят свои особенные внутренние сроки туда-обратно. Сомнительная радость.

Это не аналог.

Ну да, ну да. Для множества случаев это не аналог, а намного лучше.

Да, конечно, ведь нам только и надо, что редакторы встраивать.

Не только. Поэтому если в слабой экосистеме Qt опенсорцный встраиваемый текстовый редактор есть, пусть и кривой, то что-то более редкое может вообще отсутствовать напрочь.

Смущает почему не сделали str как String просто со ссылкой на данные и пустым drop.

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

Естественно String тогда нужен немутабельным.

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

А что если написать общую библиотеку для голубых на Rust и назвать её Pede.rust? :-) На C++ такое не напишешь уже :-)

Ну да, ну да. Для множества случаев это не аналог, а намного лучше.

А для других хуже. Но ты опять о чём-то своём.

Для Qt есть как минимум еще:

И тащить с собой KDE. Отличная идея.

И уровня kate встраиваемых редакторов на JS нет. А всякие codemirror и пр. - как раз прямые аналоги scintilla.

Смешно.

Смущает почему не сделали str как String просто со ссылкой на данные и пустым drop.

Потому что это принципиально разные вещи.

более редкое может вообще отсутствовать напрочь,

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

Смущает String и str что ли? Вообще, типы с большой буквы, но для «примитивных» типов сделано исключение: i32, i8, str и т.д.

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

Понимаю, претензия дурацкая, но меня это момент раздражает.

Выходи из криокамеры

Не раньше, чем софт на JS перестанет тормозить и жрать память/гигагерцы.

JS повсюду

Как будто в этом есть что-то хорошее.

И тащить с собой KDE. Отличная идея.

Для тех, кто в заморозке:

http://en.wikipedia.org/wiki/KDE_Frameworks_5

Тащить придется уж точно не больше чем для JS.

Смешно.

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

Да, и, разумеется, любой ORM/FRM/DSL враппер для SQL-запросов про эти различия знает.

То-то куча народу жалуется на производительность Hibernate. А те, кто умеют выжимать из Hibernate максимум скорости, признаются, что достичь такого уровня мастерства оказалось совсем не просто.

Естественно String тогда нужен немутабельным.

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

А ты представь, что в качестве языка для браузера использовался бы C++. Я могу представить Lisp в качестве такого языка, но не C++. Вот взять Node.js. Ну согласись ты, что приятнее работать с JavaScript и получать отличный результат в производительности, чем пыхтеть ради принципа на C++.

Вот взять Node.js. Ну согласись ты, что приятнее работать с JavaScript и получать отличный результат в производительности

Уж лучше Java, чем это.

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

Батхёрт засчитан :-) Наконец-то :-)

Ага, всяко лучше, чем C++. :-)

А где можно почитать про str и String? Чтение доков вызвало недоумение и неуловимый бугурт. Язык сам по себе вроде неплох, но вот это разделение как-то пованивает. Есть такое ощущение что если бы строки были немутабельными, как в питончике или жабке, то двух типов не надо было бы изобретать.

&str из Rust это String из Java. String из Rust это StringBuilder из Java.

А ты представь, что в качестве языка для браузера использовался бы C++.

Я так понимаю, что речь идет о Web-приложении, которое крутится внутри браузера, правильно?

Вообще-то говоря, были такие вещи как CINT (это интерпретатор C++) и Ch (это такой скриптовый язык по мотивам C и C++). Их наличие демонстрирует, что C++ не обязательно должен транслироваться в нативный код. Собственно, emscripten лишнее тому свидетельство.

Однако, не думаю, что написание клиентских приложений для браузера на C++ было бы хорошей идеей. Но даже использование Python или Ruby вместо JS было бы, на мой взгляд, намного лучше. Не говоря уже про статически типизированные языки, вроде Java.

Ага, всяко лучше, чем C++. :-)

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

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

Как хорошо, что такие решения принимаешь не ты :-)

Пока он еще ничего не уничтожил. А кресты пытались «уничтожить» много раз=) Посмотрим, что будет дальше.

Хрена лысого. str не может в индексацию.

А зачем тебе индексация строк? Ты в KOI8R живёшь? В юникоде индексация бесполезна.

Нет, для замены Си он тяжеловат. Скорее все таки С++.

Обычно, в нормальных языках, есть юникодные строки, которые состоят из широких чаров.

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

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

Rust это один из немногих языков с адекватной реализацией строк.

Для подгоревших пуканов специально сообщаю, на с++ можно все от микроконтролеров до амазона и гугла.

Ну синтаксис все таки не самая сильная черта Rust, мягко скажем.

Я наверно какую то другую документашку читал, но String большинство методов тянет из str через Deref. То есть там inplace методов с гулькин хрен, обычный жабский StringBuilder. О какой эффективности может идти речь если надо постоянно аллоцировать память в куче?

аха, тоже всплакнул с этого клоуна. каждый день сталкиваюсь с этим «надежным» кодом

String это строка с произвольной длиной. Естественно она будет в куче. Какую задачу ты пытаешься решить эффективно?

Жабский StringBuilder не суется в примерах как основное хранилище для строк.

Все остальное - ненужный оврерхед. Не можешь на C++ - иди на рынок директором.

Я не знаю, о каких примерах ты говоришь, но в жаве даже «a» + «b» это StringBuilder под капотом. Он там везде.

Я не про задачу, а семантику. По моему немутабельные строки (без разницы где их байтики, на стеке или в куче) можно было бы смоделировать одним типом. А там где нужно дрочево уже бы работали с капасити и буфером.