I mean if you have to write that match construct around every function call the code quickly gets bloated, doesn't it? And that is not good.

> I mean if you have to write that match construct around every function call

Not quite.

1. you're supposed to handle errors around function calls which can fail, which is a strict subset of "every function call"

2. rust has a number of higher-order constructs to facilitate that handling[0][1][2], not just raw `match` statements or expressions.

That aside, for rust explicit error handling is considered a feature both at the language level (allows for less runtime requirements and much stronger guarantees — check out exception-safe C++ for what happens when low-level meets exceptions) and at the user level (by forcing a conscious and explicit decision, whether it's crashing the system, handling the error or passing the ball upwards)

> the code quickly gets bloated, doesn't it?

Does C code quickly get bloated? Because you're also supposed to check for error codes after each function call which can fail, and C doesn't provide much abstractive power to mitigate that.

[0] http://doc.rust-lang.org/std/result/enum.Result.html

[1] http://doc.rust-lang.org/core/macro.try!.html

[2] https://github.com/rust-lang/rfcs/pull/243

Rust has macros, so boilerplate can be swept up pretty tidily. In the case of propagating up errors, there is the try! macro that encapsulates a match that returns early with the error

try! macro results in code that looks pretty similar to exceptions: https://doc.rust-lang.org/std/macro.try!.html

Yeah Error handling bloat is a problem.

You can use convenience functions: expression.expect("panic with this message if expression evaluates to an Err")

You can also use macros: try!(expression) makes it so if expression evaluates to an error it returns the error immediately, otherwise it does nothing.

This approach is still more verbose than using exceptions but on the flip side dealing with errors up front can make it easier to write reliable code.

Comment OP's stance is valid. "Magic" in this context are keywords or symbols that are not immediately clear to programmers that don't work in rust. One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword).

FWIW I also share their opinion that rust is unapproachable.

> One of the reasons golang is so successful is that there is very little magic in the syntax, and even when there is it's fairly easy to grok (an example would be the `go` keyword).

Do you have a specific symbol you would like to change in Rust, and what would you like to change it to?

The only example I've seen (in a child comment to yours) is effectively a complaint that Rust has lifetimes and Go doesn't, which is effectively saying "you should have a garbage collector like Go does", which is an argument against a fundamental design decision of Rust. If you want to argue that you should always use a garbage collector, argue that directly instead of making vague negative comparisons between Rust's and Go's syntax.

I'm definitely a Rust fanboy, but the single-quote syntax for lifetime annotations can be irritating. Several editors I've used automatically insert a second quote to match, and I am frequently unable to disable that behavior without losing all paired delimiter insertion (like for parentheses or braces).

It's a minor quibble to be sure, but it's the only language symbol that bothers me when writing Rust. Not sure what I'd suggest replacing it with...backtick, maybe? Pipe? @? ~?

There aren't many other special characters on a QWERTY board that aren't already used in Rust. Which I think gets at one of the stumbling blocks that I see in the various Rust syntax bikesheds among those who haven't worked in the language. It's just alien until you've used it a bit, especially if you're writing a lot in pseudocode-y dynamic languages.

Rust used to have @ and ~ sigils* but they were removed for legibility reasons and difficulty typing on European keyboards.

* For heap and owner pointers respectively.

We had a big debate about it back in the day, and ' won as it's about as visually lightweight as you can get. I think the other characters you suggested would invite even more Perl comparisons.

> keywords or symbols that are not immediately clear to programmers that don't work in rust

That's an argument against introducing new notation for anything. That can't be right.

Golang has some magic too - for example magic with capital letters in exported symbols. But generally golang is easier to read than line like this:

> static NAME: &'static str = "du";

Because Rust has lifetimes and Go doesn't, so Go doesn't need syntax for them. If you want to argue that Rust should use a garbage collector like Golang does (which entails arguing that everybody who is using Rust is wrong for not wanting an always-on GC) I'm happy to have that argument, but say so explicitly.