4 ms·
I think you missed the implied wink. This post is not arguing for throwing away all performance and safety, it is showing how “ugly syntax” is actually mostly i
by jrk 4y ago
I think you missed the implied wink. This post is not arguing for throwing away all performance and safety, it is showing how “ugly syntax” is actually mostly inherent complexity from trying to be safe and fast.
- ben0x539 4y agoLike, all the syntax does something that contributes to being safe and fast, but that doesn't mean there couldn't be a completely different notation for all of that. Maybe there is nothing that would make everybody happier, but for any given person unhappy with Rust syntax, there's probably a bunch of tweaks you could do to make it nicer for them. For example, in pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> { for me it's really unpleasant that there is so much stuff between the function name and the names of the parameters. It's a bit nicer with already-a-Rust-feature where-clauses like pub fn read<P>(path: P) -> io::Result<Vec<u8>> where P: AsRef<Path> { but if nothing else I think that makes a mess of the indentation if you linebreak anywhere in that line. C++ avoids this by just yanking all the extra bits at the very start of the declaration, so we could copy that (without going all the way into C++ caricature): for<P: AsRef<Path>> pub fn read(path: P) -> io::Result<Vec<u8>> { This addresses my specific complaint, but is probably worse for other people. Who knows. As another example, the whole business with explicit Result types and the early-return question mark is basically isomorphic to checked exceptions, which may or may not be syntactically lighter/more pleasant. Would Rust enthusiasts prefer that? Probably not. Would it make the language more approachable to people coming from some Java ecosystem? Maybe? Would it be worth it? No idea.
- 29athrowaway 4y agoDo you know what are the plans to do this in Carbon?
- ben0x539 4y agoI haven't really been keeping up, sorry.