Recently started introducing Rust in my team and here are my notes on some of the issues we have run into so far. We are primarily a Scala/JVM shop with a little bit of Python.
- `Error Handling` is a bit of a dumpster fire right now. Rust has something called a `Result` enum which is similar to `Either[Error,T]` monad in Scala however every single Rust crate I have used so far its creating its own `Error` enum which makes it really hard to compose `Result`. Ideally I would like to chain `Results` as `e1.and_then(e2).and_then(e3)` but its not possible due to incompatible error enums. Ended up using `https://docs.rs/crate/custom_error/1.3.0` to align the types.
- A lot of basic things are still influx and community wide standards have not been established. For example: I needed to externalize some environment specific settings in a Config but couldnt figure out where to put non-code assets in a cargo project and then how to reliable read them. In JVM world `src/main/resources` acts like a standard place for stuff like this but that patterns has not been established yet.
- Distributing code inside the company is hard because there is no integration with Artifactory or similar tools. We are directly referring git sha in Cargo right now and waiting for better solutions.
- Rust comes with a default unit test framework but it pretty bare bones. I havent seen examples of test fixture, setup/teardown support and loading test configs etc.
- I really like Rust compiler because of really good error messages it produces but its really slow and you start to notice it as you add more code/external crates
-IDE support is good but not great. I am using IntelliJ with Rust plugin as we use IntelliJ for Scala/JVM and it is nowhere as good as even Scala plugin which is pretty mediocre in itself.
Overall I am pretty happy with the language (except for Error issue) and most of my gripes are around the ecosystem and tooling around the language. Hopefully these will be resolved as language gains more momentum
> Rust comes with a default unit test framework but it pretty bare bones. I havent seen examples of test fixture, setup/teardown support and loading test configs etc.
This is one of the things that I really love about Rust - it has a testing framework that is so simple that it subtly pushes you to write better tests and better code.
What I mean by that is - it really wants you to write simple tests with no mocking and no convoluted state using simple asserts, and it really wants you to write code which is trivially testable. In other languages this might be problematic, but in Rust this synergises really well with other language features such as #[derive(...)], sum types and pattern matching. If you write good, idiomatic Rust code then all of those extra features of other testing frameworks are usually totally unnecessary.
> every single Rust crate I have used so far its creating its own `Error` enum which makes it really hard to compose `Result`.
Is there a reason why `map_err()` doesn't achieve what you need - i.e. to get everything into your error type no matter where it came from?
For example: OtherLibResult.map_err(|e| MyError::from(e))
Unless I'm mistaken - you ultimately are doing something like this in one form or another, because if you never match on the different Error variants that happened somewhere along the pipeline- then those details are being swallowed.
Implementing a From trait at least forces you to make that choice (all in one place too)- and then you can keep composing the results as needed since it's all in your MyError type
> - Rust comes with a default unit test framework but it pretty bare bones. I havent seen examples of test fixture, setup/teardown support and loading test configs etc.
There is an eRFC for better integration of custom test frameworks.
What I would like to see is something where people could submit a small working program in one language and a Rust expert would make a program that does the same thing in idiomatic Rust. This doesn't need to be anything too complex. A wiki would be fine, the work would be in having volunteers to make the demos.
If you don't know the idioms you end up doing a sort of transliteration of the source language where the concepts may work against the nature of Rust. A developer can spend a long time barking up the wrong tree with few indicators as to which is the right tree.
As an example of what I mean. Here is a program that I wrote in JavaScript specifically because I could not find a way to write it in Rust that felt like I was doing it the right way.
I could come up with Rust versions that were basically emulating pointers with array indexes(and a mess when something is deleted), or map versions that incurred lots of run-time lookup. The crux of the problem, I think is either how to do a mutable graph of mutable nodes, or how to do map on a immutable graph of immutable nodes to a new immutable graph of immutable nodes in the next state along.
I'm sure others have this issue of "I know how to do it in X, doing it that way in Rust is a mess, what's the right way?"
I agree about the need for an Idioms Cookbook or something to show different practices. We have one for how libraries can help you solve problems but not code patterns..
Almost everything major (and lots of non-major stuff, like minor release announcements) regarding Rust ends up on HN, so it only made sense that this would too...
Great article. I’m excited for the future of Rust.
A bit of really nit-picky grammatical feedback: you use it’s vs its wrong multiple times in the article. It was surprising given your solid command of technical prose displayed in the post. Try to bone up on the correct usage of the two. It makes a big difference. Thank you!!
One of my 2019 goals is to try and be more involved with Rust in some way or shape. Hoping to go to meetups or the like. Rust as a language is really special to me, and I'd love to be able to give more back.
>The embededded working group could probably use a page listing all the platforms
I haven’t looked into which micros are supported by Rust in actuality because I checked their main site and saw an old Nordic, a few old STMs, an old NXP, and some old MSPs, then left the page.
If I was a hobbiest this might be ok and I might research it more. As a professional, I pretty much noped out of there assuming that it’s just nowhere near ready for me.
I’d like to see it work! But until there is an IDE with debugging using code overlay and breakpoints... Rust is just not for me. I wonder what year they get there?
Edit: apparently there is a gap between what hobbiests consider acceptable and what my company would need that the Rust fans can’t imagine - this somehow means my opinion isn’t valid. Let me know when Keil or IAR or anyone sells a supported and professional IDE with a Rust compiler.
You do get all that today already. The various Cortex'es are supported rather well + gdb in combination with a JLink gives you the debugging interfaces you need.
[+] [-] scaleout1|7 years ago|reply
- `Error Handling` is a bit of a dumpster fire right now. Rust has something called a `Result` enum which is similar to `Either[Error,T]` monad in Scala however every single Rust crate I have used so far its creating its own `Error` enum which makes it really hard to compose `Result`. Ideally I would like to chain `Results` as `e1.and_then(e2).and_then(e3)` but its not possible due to incompatible error enums. Ended up using `https://docs.rs/crate/custom_error/1.3.0` to align the types.
- A lot of basic things are still influx and community wide standards have not been established. For example: I needed to externalize some environment specific settings in a Config but couldnt figure out where to put non-code assets in a cargo project and then how to reliable read them. In JVM world `src/main/resources` acts like a standard place for stuff like this but that patterns has not been established yet.
- Distributing code inside the company is hard because there is no integration with Artifactory or similar tools. We are directly referring git sha in Cargo right now and waiting for better solutions.
- Rust comes with a default unit test framework but it pretty bare bones. I havent seen examples of test fixture, setup/teardown support and loading test configs etc.
- I really like Rust compiler because of really good error messages it produces but its really slow and you start to notice it as you add more code/external crates
-IDE support is good but not great. I am using IntelliJ with Rust plugin as we use IntelliJ for Scala/JVM and it is nowhere as good as even Scala plugin which is pretty mediocre in itself.
Overall I am pretty happy with the language (except for Error issue) and most of my gripes are around the ecosystem and tooling around the language. Hopefully these will be resolved as language gains more momentum
[+] [-] smaddox|7 years ago|reply
[+] [-] jgrowl|7 years ago|reply
[+] [-] kouteiheika|7 years ago|reply
This is one of the things that I really love about Rust - it has a testing framework that is so simple that it subtly pushes you to write better tests and better code.
What I mean by that is - it really wants you to write simple tests with no mocking and no convoluted state using simple asserts, and it really wants you to write code which is trivially testable. In other languages this might be problematic, but in Rust this synergises really well with other language features such as #[derive(...)], sum types and pattern matching. If you write good, idiomatic Rust code then all of those extra features of other testing frameworks are usually totally unnecessary.
[+] [-] dakom|7 years ago|reply
Is there a reason why `map_err()` doesn't achieve what you need - i.e. to get everything into your error type no matter where it came from?
For example: OtherLibResult.map_err(|e| MyError::from(e))
Unless I'm mistaken - you ultimately are doing something like this in one form or another, because if you never match on the different Error variants that happened somewhere along the pipeline- then those details are being swallowed.
Implementing a From trait at least forces you to make that choice (all in one place too)- and then you can keep composing the results as needed since it's all in your MyError type
[+] [-] epage|7 years ago|reply
There is an eRFC for better integration of custom test frameworks.
https://github.com/rust-lang/rfcs/pull/2318
[+] [-] joelg236|7 years ago|reply
[+] [-] YorkshireSeason|7 years ago|reply
That would be an ideal combination for me: do performance critical stuff in Rust, use Scala everywhere else.
[+] [-] Lerc|7 years ago|reply
If you don't know the idioms you end up doing a sort of transliteration of the source language where the concepts may work against the nature of Rust. A developer can spend a long time barking up the wrong tree with few indicators as to which is the right tree.
As an example of what I mean. Here is a program that I wrote in JavaScript specifically because I could not find a way to write it in Rust that felt like I was doing it the right way.
https://codepen.io/Lerc/pen/yQxmob?editors=0010
I could come up with Rust versions that were basically emulating pointers with array indexes(and a mess when something is deleted), or map versions that incurred lots of run-time lookup. The crux of the problem, I think is either how to do a mutable graph of mutable nodes, or how to do map on a immutable graph of immutable nodes to a new immutable graph of immutable nodes in the next state along.
I'm sure others have this issue of "I know how to do it in X, doing it that way in Rust is a mess, what's the right way?"
[+] [-] epage|7 years ago|reply
[+] [-] steveklabnik|7 years ago|reply
I think this idea is pretty good!
[+] [-] em-bee|7 years ago|reply
[+] [-] wwright|7 years ago|reply
There is so much genuine compassion, diligence, and attention in the community, and it shows everywhere.
[+] [-] cjohansson|7 years ago|reply
[+] [-] qznc|7 years ago|reply
Other language communities, take note.
[+] [-] swsieber|7 years ago|reply
[+] [-] coldtea|7 years ago|reply
[+] [-] shijie|7 years ago|reply
A bit of really nit-picky grammatical feedback: you use it’s vs its wrong multiple times in the article. It was surprising given your solid command of technical prose displayed in the post. Try to bone up on the correct usage of the two. It makes a big difference. Thank you!!
[+] [-] nixpulvis|7 years ago|reply
[+] [-] jhack|7 years ago|reply
[+] [-] steveklabnik|7 years ago|reply
[+] [-] afandian|7 years ago|reply
[+] [-] SlowRobotAhead|7 years ago|reply
I haven’t looked into which micros are supported by Rust in actuality because I checked their main site and saw an old Nordic, a few old STMs, an old NXP, and some old MSPs, then left the page.
If I was a hobbiest this might be ok and I might research it more. As a professional, I pretty much noped out of there assuming that it’s just nowhere near ready for me.
I’d like to see it work! But until there is an IDE with debugging using code overlay and breakpoints... Rust is just not for me. I wonder what year they get there?
Edit: apparently there is a gap between what hobbiests consider acceptable and what my company would need that the Rust fans can’t imagine - this somehow means my opinion isn’t valid. Let me know when Keil or IAR or anyone sells a supported and professional IDE with a Rust compiler.
[+] [-] woah|7 years ago|reply
[+] [-] th0br0|7 years ago|reply