> One of them is called `error-chain` and another one is called `failure`. We didn’t realize these existed and we aren’t sure if there’s a standard approach.
`error-chain` is in maintenance mode these days; `failure` is its spiritual successor and seems that it's on the path to becoming a community standard eventually.
I'll add that bindings Chucklefish did for Lua via rlua[1] are some of the best I've seen. I had Lua up and running from scratch in a project within 5 minutes which is pretty darn awesome.
Given other comment dismissing it, I'll do a quick review of that Chucklefish paper. Here's what I noticed:
1. A case study of Rust used in something performance-critical. People pushing or just assessing it like to see those.
2. They say they're all in on modern C++ but still trigger undefined behavior and crashes a lot in practice. Member's of Rust team regularly claim that happens despite C++'s safety improvements over time. In this case, it was happening in C++ but not in Rust with C++ developers using both. Far as learning complexity, they're both complex enough that C++ coders should be able to learn Rust. So, the main drawback is in both languages. Looking at complexity vs reliable iterations, Rust provided an advantage in knocking out problems that were slowing the C++ coders down sometimes by "hours" of debugging.
3. On parallelism and concurrency, their prior method was getting a single-core implementation working first that they transformed into something for multi-core. This was giving them a lot of trouble. That there's lots of ways to implement concurrency in C++ means I can't be sure if it was due to the language, what library/framework they were using, their own techniques, or some combo. Also, I'm not going to guess since I don't use C++. :) Regardless of what they were doing, the alternative approach in Rust let them get a lot of stuff right on the first try. So, it was easier for those C++ coders to do multicore in Rust than in C++. It's evidence in favor of Rust teams claim that Rust makes concurrency easier with less debugging given they were newcomers immediately getting good results. However, I don't think it's evidence of anything comparative between Rust and C++ concurrency without knowing what they were doing in C++. As in, some C++ coders might be getting better results with different methods where gap between them and Rust might be anywhere from zero to smaller than this case.
4. Finally, handling platform differences was so much easier as newcomers using Rust's tooling than it was for them as C++ veterans that they still saved time overall in Rust despite having to implement Rust support for game platforms themselves. That's strong evidence that Rust's package manager or platform tooling is excellent with some anecdotal evidence it's better than C++ at this cross-platform, use case.
So, there's a summary of what I got out of the case study for anyone that might find it useful.
EDIT: That Reddit thread has some great comments about floats, too. Problems, solutions, Rust vs C++ handling, and so on.
How did it break? If it was just a matter of syntax then error-chain does have support for attributes on the enum variants, or you can look at derive-error-chain for a more regular syntax instead.
I'm not sure what you mean - this looks like a very conventional whitepaper to me.
Wikipedia says
> In business, a white paper is closer [than the government meaning of a policy document] to a form of marketing presentation, a tool meant to persuade customers and partners and promote a product or viewpoint.
If you have more specific feedback about what you'd expect a whitepaper to look like, we'd love to hear it. We surveyed some stuff and didn't really find much commonality, but would prefer to follow conventions if there are any!
I do think that some data would be good, but at the same time, the kind of data that's relevant here is really hard to get in any concrete terms, so might actually be harmful.
> a "paper" of any sort
Remember that this isn't a paper of just any sort: it's a whitepaper. So it has a specific audience: CTOs, VPs, and other technical management types. Audience is important for what you have to include in any work.
Oh! Actually, I'm paging through "Rust in production at Figma" (https://blog.figma.com/rust-in-production-at-figma-e10a0ec31...) and I think this is closer to what I would expect in a "paper" - while acknowledging that am predisposed toward thinking "graphs and data" when I think of a paper, I do think these kinds of blog posts have more of an impact (and seem more true to the idea of a "paper") on me than the current Rust whitepapers.
That said, I will happily concede that I have no idea who the target audience is for the whitepapers and probably don't know the accepted industry definition of a whitepaper. However, I'm very happy to see Rust flourish either way.
It's not supposed to be a scientific paper - it's narrative a report on their experience doing something. Obviously not all papers have data in them - not even all computer science research papers have data in them!
EDIT: Quote from the OP:
> One of them is called `error-chain` and another one is called `failure`. We didn’t realize these existed and we aren’t sure if there’s a standard approach.
`error-chain` is in maintenance mode these days; `failure` is its spiritual successor and seems that it's on the path to becoming a community standard eventually.