(For reference: I know why it is the way it is, the stark difference is just kind of fun to contrast on trivial examples.)
a = input()
print(a)
fn main() {
// make a scope
let a = {
// we'll need a buffer to read into
let mut buf = String::new();
// won't bother with error handling here - just unwrap the Result
std::io::stdin().read_line(&mut buf).unwrap();
// get rid of Unicode whitespaces on ends of input
// and convert &str to String to get proper lifetimes
buf.trim().to_string()
};
println!("{}", &a);
}
a = "abc"
print(a[1])
fn main() {
let a = "abc";
// get nth element of characters iterator
// this might fail at runtime due to index being out of bounds
// therefore we unwrap
let b = a.chars().nth(1).unwrap();
println!("{}", &b);
}
from uniseg import graphemecluster
a = "a̐éö̲\r\n"
b = list(graphemecluster.grapheme_clusters(a))
print(b[1])
extern crate unicode_segmentation;
// UnicodeSegmentation is implemented for str
// therefore, using it gives our strs additional methods
use unicode_segmentation::UnicodeSegmentation;
fn main() {
let a = "a̐éö̲\r\n";
let b = &a.graphemes(true) // returns an iterator
.collect::<Vec<&str>>(); // collect it and specify type to cast to
println!("{}", &b[1]);
}
@Omrigan I just fixed #string-indexing: actually, it's not as easy in Python too.
Rust in fact has good reasons to have things the way they are.
Yes, reading from stdin might be kind of complex, but it leaves any magic out.
read_line
's implementation is literally one line, and we have text_io crate which hides all those buffers - shall you not want them in your way - under pretty macros.String indexing is a more fun topic. The thing is, strings are Complicated. As in there are tons of variants of encoding visibly the same one even within one encoding (yes, UTF-8, I'm looking at you): that is, characters, bytes and graphemes in Unicode are things which don't correspond basically.
So, by default Python indexes by chars, which is fine and all until we get to Unicode. Than everything breaks. Rust, however, makes whatever you're doing explicit: you either take a
.chars()
iterator,.bytes()
iterator, or a.graphemes()
one (also, note how beautifully just importing a library extends our str type).So, that was mostly about explicitness, but Python could do better with internal storage / operations too: details here, I'll quote a bit: