As a part of a learning exercise, I have been trying my hand at writing a parser for a local data format in Rust. It’s been interesting and enlightening. I do wish Rust had a more robust standard library (I don’t want to adjudicate third-party crates for batteries included functionality).
No #LanguageWars; thank you!
(I am familiar with the format like the back of my hand, and could recite an efficient implementation in Go using the standard library alone.)
The allowance of algebraic data types for the enum values (which represent individual data nodes) is one of the things that made this Rust exercise interesting.
To contrast, I mentioned how in Go I had employed enums similarly. There, each enum value implemented a lowercase-i interface (namely: function value signature) that could be processed incrementally with a method value. The Go code wasn't super concise, but it was clear and explicit.
Ecosystems have their idioms. That's something that anybody making a foray into a foreign land must understand and accept.
The one that's caused the most mental agony for me in Rust is that traits can back formal language features found in the grammar (specifically operators like slice indexing). This reminds me of the bad parts of C++ with operator overloading. The code might be concise, but I find it hard to reason with.
On balance, Rust's ? operator's ability to integrate with std::convert::From is slick (runs the risk of being too implicit) to enable error space conversion.
I do really wish that the Go ecosystem was more mature with error space conversions: if err != nil { return err } is nice and convenient, but it has dulled developers' brains into ignoring how different domains interact. I feel like the same could be said for Java exceptions as well as the oft-abused https://grpc.github.io/grpc/core/md_doc_statuscodes.html.
@gsora The morphological simplicity of Go has made it rather easy to understand data's lifetime and design accordingly, Were this Java, it would be a lot more of a struggle.
As for this code I am writing here, the idiomatic Go solution (simple hand-written enum with a switch statement as a driver) has a near 1:1 mapping in Rust that in principle should be idiomatic. That is one of the reasons this learning exercise is tractable.
@matt I share that experience of Rust. Go and Python's standard libraries both have deep imperfections that are hard to fix because of backwards compatibility policies, but coming from those ecosystems I'm hesitant to just add a dozen deps to my Rust (or JS) projects.
The best trick I've found is to only pick deps that large mature projects (eg: rustc, android, fuchsia) depend on. But there's no cargo command for that.
@ian I pretty rarely use external libraries, barring small, well-built abstractions that serve narrow purposes.
It's hard for a beginner to adjudicate what's good and what would be good to learn from. I suspect this is largely true for any language ecosystem. Go has no silver bullets here (outside of standard library batteries).
mtp
JP Sugarbroad
Gianguido
Ian McKellar
Tony Finch