4 ms·

> That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher le

> That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, … I am not convinced that there's so more to Rust than there is to GHC Haskell to justify so much dense syntax. There's many syntax choices made in Rust based, I assume, on its aim to appeal to C/C++ developers that add a lot of syntactic noise - parentheses and angle brackets for function and type application, double colons for namespace separation, curly braces for block delineation, etc. There are more syntax choices made to avoid being too strange, like the tons of syntax added to avoid higher kinded types in general and monads in particular (Result<> and ()?, async, "builder" APIs, etc). Rewriting the example with more haskell-like syntax: Trying::to_read::<&'a heavy>(syntax, |like| { this. can_be( maddening ) }).map(|_| ())?; Trying.to_read @('a heavy) syntax (\like -> can_be this maddening) >> pure () It's a tortuous example in either language, but it still serves to show how Rust has made explicit choices that lead to denser syntax. Making a more Haskell-like syntax perhaps would have hampered adoption of Rust by the C/C++ crowd, though, so maybe not much could have been done about it without costing Rust a lot of adoption by people used to throwing symbols throughout their code. (And I find it a funny place to be saying _Haskell_ is less dense than another language given how Haskell rapidly turns into operator soup, particularly when using optics).

skavi 4y ago
> In more plain terms, the line above does something like invoke a method called “to_read” on the object (actually `struct`) “Trying”... In fact, this invokes an associated function, `to_read`, implemented for the `Trying` type. If `Trying` was an instance `Trying.to_read...` would be correct (though instances are typically snake_cased in Rust). I'll rewrite the line, assuming `syntax` is the self parameter: syntax .to_read::<&'a heavy>(|like| this.can_be(maddening)) .map(|_| ())?; In my opinion, this is honestly not bad.
zozbot234 4y ago
> like the tons of syntax added to avoid higher kinded types in general and monads in particular (Result<> and ()?, async, "builder" APIs, etc). Rust is not "avoiding" HKT in any real sense. The feature is being worked on, but there are interactions with lifetime checking that might make, e.g. a monad abstraction less generally useful compared to Haskell.

skavi 4y ago

> In more plain terms, the line above does something like invoke a method called “to_read” on the object (actually `struct`) “Trying”... In fact, this invokes an associated function, `to_read`, implemented for the `Trying` type. If `Trying` was an instance `Trying.to_read...` would be correct (though instances are typically snake_cased in Rust). I'll rewrite the line, assuming `syntax` is the self parameter: syntax .to_read::<&'a heavy>(|like| this.can_be(maddening)) .map(|_| ())?; In my opinion, this is honestly not bad.

zozbot234 4y ago

> like the tons of syntax added to avoid higher kinded types in general and monads in particular (Result<> and ()?, async, "builder" APIs, etc). Rust is not "avoiding" HKT in any real sense. The feature is being worked on, but there are interactions with lifetime checking that might make, e.g. a monad abstraction less generally useful compared to Haskell.