use std::fs::File;
fn main() {
let f = File::create("foo.txt")?;
}
rustc 1.13.0 (2c6933acc 2016-11-07)
error[E0277]: the trait bound `(): std::ops::Carrier` is not satisfied
--> <anon>:4:13
|
4 | let f = File::create("foo.txt")?;
| ^^^^^^^^^^^^^^^^^^^^^^^^ trait `(): std::ops::Carrier` not satisfied
|
= note: required by `std::ops::Carrier::from_error`
error: aborting due to previous error
Хм, я ожидал что благодаря введению специального оператора очень частая ошибка новичков — попытка пробросить ошибку из функции, которая не возвращает Result — получит внятное сообщение об ошибке :(
Во, это уже интереснее. Хотя это тоже уже очень много раз разобранные со всех сторон вопросы, про которые есть много статей. Про String/&str вообще только ленивый не писал еще)
два типа почти одинаковых строк конкатенируются несколько по-разному
Они не по-разному соединяются, сам по себе &str вообще не имеет операции соединения (это одолженная строка, она не владеет своими данными и не может ничего в них дописывать). .to_string() это как раз приведение &str к String.
без «жутко», которое я не говорил
Так и не цитата же была :) Я "жутко" добавил потому, что в любом инженерном решении, если достаточно пристально прикопаться, можно найти нестыковки и кривости разные, но внимания обычно заслуживает только какая-то их часть. Так же, многие кривости определяются врожденной кривостью самой предметной области и тут тоже не всегда что-то можно сделать, что бы совсем их убрать.
И причина в обоих случаях написана почему так сделано, но недостаток системности для меня неприемлем.
И то, и другое объясняется как раз тем что это системный язык и ему нельзя абстрагироваться от этих деталей, иначе ржавчина как язык вообще смысла бы не имела.
Да и строки это вообще отдельный разговор, абсолютное большинство языков отвратительно работает с текстом и скрывает от программиста кучу потенциальных ошибок.
Недостаток скорости в системном языке (если бы все строчки были неизменяемыми и всегда создавались в куче) или провокация языком ошибок (если бы все строки были массивами charов) были бы приемлимы?
Прошу только поменьше мне ставить минусы за высказывание своего мнения, как за начальный комментарий.
Как я понимаю, минусы или за странную форму изложения мысли, или за очень поверхностные наблюдения, поданные в категоричном тоне.
Я несколько раз прочитал, но сомневаюсь четко что понял мысль.
Не нравится что из:
1) ключевое слово fn перед объявлением функции?
2) стрелка перед возвращаемым значением функции?
3) использование пустого кортежа () в качестве замены void/none/nil?
В любом случае, эта вкусовщина точно так важна? Далеко не самая интересная особенность языка же.
Можно и так, но моя логика в том что кривая обучения более плавной будет, если сначала свой малюсенький проектик написать и на нем постепенно познакомиться и понять зачем нужны всякие clippy, rustfmt, cargo, travis, appveyor и т.п., чем если все это сразу на тебя обрушится комом.
Я попробовал несколько подходов к изучению этого языка
Пока мне самым правильным подходом кажется:
1) Бегло пролистать Книгу — http://rurust.github.io/rust_book_ru — что бы получить общее представление о языке;
2) Пробежаться по http://rustbyexample.com и пощупать там примеры;
3) Начать писать какую-то небольшую программу:
3.1) Одновременно внимательно читать главы Книги о тех кусках языка, которые прям сейчас используешь в своем коде;
3.2) Спрашивать в https://gitter.im/ruRust/general, если чего-то все равно остается непонятным;
4) Послать парочку PR в открытые проекты, что бы как следует разобраться в том, как другие люди на языке пишут.
О чем думают авторы — об экономии символов кода вместо простоты и понятности?
pub fn foo(n: &mut u32) {...}
public function foo(n: reference mutable unsigned integer32bit) {...}
Пытаются найти баланс между краткостью и понятность, что бы язык не стал ни Джавой, ни APL. Ну и да, это прям сферическая вкусовищина, где объективных критериев не может быть.
Так разве они лишние? Вообще не продвигать язык нельзя — тогда пользователям-первопроходцам неоткуда будет взяться, а без них язык постепенно загнется.
Эм, с мирным населением? Это преступный приказ.
https://rustycrate.ru/adopters.html
https://www.rust-lang.org/en-US/friends.html
После выхода версии 1.0 (15 мая 2015) все изменения обратно совместимы. Не считая исправлений ошибок, конечно, но обычный код такое не ломает.
Хм, я ожидал что благодаря введению специального оператора очень частая ошибка новичков — попытка пробросить ошибку из функции, которая не возвращает
Result— получит внятное сообщение об ошибке :(До версии 1.0 semver позволяет вносить ломающие изменения в 0.* выпуски
Во, это уже интереснее. Хотя это тоже уже очень много раз разобранные со всех сторон вопросы, про которые есть много статей. Про
String/&strвообще только ленивый не писал еще)Они не по-разному соединяются, сам по себе
&strвообще не имеет операции соединения (это одолженная строка, она не владеет своими данными и не может ничего в них дописывать)..to_string()это как раз приведение&strкString.Так и не цитата же была :) Я "жутко" добавил потому, что в любом инженерном решении, если достаточно пристально прикопаться, можно найти нестыковки и кривости разные, но внимания обычно заслуживает только какая-то их часть. Так же, многие кривости определяются врожденной кривостью самой предметной области и тут тоже не всегда что-то можно сделать, что бы совсем их убрать.
И то, и другое объясняется как раз тем что это системный язык и ему нельзя абстрагироваться от этих деталей, иначе ржавчина как язык вообще смысла бы не имела.
Да и строки это вообще отдельный разговор, абсолютное большинство языков отвратительно работает с текстом и скрывает от программиста кучу потенциальных ошибок.
Недостаток скорости в системном языке (если бы все строчки были неизменяемыми и всегда создавались в куче) или провокация языком ошибок (если бы все строки были массивами
charов) были бы приемлимы?Как я понимаю, минусы или за странную форму изложения мысли, или за очень поверхностные наблюдения, поданные в категоричном тоне.
Ну а там, допустим, безопасная работа с памятью и многопоточность в императивном языке без сборщика мусора — это ерунда и обсуждать тут нечего даже?
Я несколько раз прочитал, но сомневаюсь четко что понял мысль.
Не нравится что из:
1) ключевое слово
fnперед объявлением функции?2) стрелка перед возвращаемым значением функции?
3) использование пустого кортежа
()в качестве заменыvoid/none/nil?В любом случае, эта вкусовщина точно так важна? Далеко не самая интересная особенность языка же.
грамматику делает вменяемой
пишут ") {", просто стрелка ошибку выдаст :)
Можно и так, но моя логика в том что кривая обучения более плавной будет, если сначала свой малюсенький проектик написать и на нем постепенно познакомиться и понять зачем нужны всякие clippy, rustfmt, cargo, travis, appveyor и т.п., чем если все это сразу на тебя обрушится комом.
А что конкретно в ржавчине жутко асимметрично без причины?
Что пользовательские конструкторы типов как часть языка вообще являются хорошей идеей согласны далеко не все.
Пока мне самым правильным подходом кажется:
1) Бегло пролистать Книгу — http://rurust.github.io/rust_book_ru — что бы получить общее представление о языке;
2) Пробежаться по http://rustbyexample.com и пощупать там примеры;
3) Начать писать какую-то небольшую программу:
3.1) Одновременно внимательно читать главы Книги о тех кусках языка, которые прям сейчас используешь в своем коде;
3.2) Спрашивать в https://gitter.im/ruRust/general, если чего-то все равно остается непонятным;
4) Послать парочку PR в открытые проекты, что бы как следует разобраться в том, как другие люди на языке пишут.
Да я так, для полноты картины)
Он тоже "уже": https://github.com/rust-lang/rust/issues/8122 :)
Из ключевых слов еще вот сокращения:
pub fn foo(n: &mut u32) {...}public function foo(n: reference mutable unsigned integer32bit) {...}Пытаются найти баланс между краткостью и понятность, что бы язык не стал ни Джавой, ни APL. Ну и да, это прям сферическая вкусовищина, где объективных критериев не может быть.
Так разве они лишние? Вообще не продвигать язык нельзя — тогда пользователям-первопроходцам неоткуда будет взяться, а без них язык постепенно загнется.
Кто-нибудь workspace'ы пощупал уже, как оно на деле? :)
Зато, если поисковый пузырь не слишком хорошо подогнан, выдача по запросам типа "c strings" бывает неожиданной.