> 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.
Tangentially related, but if any of you work with designers or are yourselves designers, please give Figma a try. It is identical to Sketch in so many ways, better in some others (particularly editing vectors and dealing with nested "symbols" or other components), and only falls behind in a few areas. If any of you have had to deal with the nightmare of keeping your design files in sync between designers forgetting to push changes to dropbox or InVision, or multiple designers working together and having their changes fall out of sync, the ability to edit and view the same document together cannot be overstated.
> We chose Rust for this rewrite because it combines best-in-class speed with low resource usage while still offering the safety of standard server languages. Low resource usage was particularly important to us because some of the performance issues with the old server were caused by the garbage collector.
Reading between the lines here, they didn't go with a more mature language like Java because they were worried GC tuning would be a problem?
Given all the other issues they noted with using a less mature language like Rust in production, that's a pretty heavy load to take on in exchange for not having to tune GC. Isn't GC tuning a fairly well understood problem? Is there something about encoding large documents that makes it a significantly greater obstacle?
Or are there other unstated considerations at play here? For example, I mean this completely earnestly and not cynically, but there is a lot more PR and recruitment value in blogging about a hot new cutting-edge language than "how we rewrote our TypeScript server in Java".
Language maturity is not a one-dimensional problem and it's also not equal to the age of the language.
To name just two ways in which I consider Rust more mature than Java:
* It has a lot of fundamentals that are based on more academic languages which have explored some specific PLT space for a long time and let it mature. The fruits of that are now in Rust (many aspects of its type system for example).
* Rust's community has an almost absurd ability (contrasted with most other languages) to focus on specific core libraries and tooling. For example serde[1], the Rust serialization library, is well-understood, simple, mature and supported in basically every Rust library out there.
The second point is extremely impressive when contrasted with the state of things in Java-land, where you often have many different solutions for the same problems. Sometimes even the well-known and used ones are of very questionable quality[2].
One thing that we've been hearing for a while is that even if you can tune a GC, it still takes up significantly more memory than the equivalent Rust program. GCs can be memory hungry. Sometimes, you care a lot about RSS. It just depends.
GC still brings its own set of problems like Finalizers and the like.
GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear.
Rust might immature, but it's rock solid. I don't think lack of maturity of the core language is a reason not to use it in production anymore. Lack of available libraries may be an issue, but if it's not then Rust seems like a pretty goos choice to me.
"Instead of going all-in on Rust, we decided to keep the network handling in node.js for now. The node.js process creates a separate Rust child process per document and communicates with it using a message-based protocol over stdin and stdout. All network traffic is passed between processes using these messages."
This is not entirely surprising, Rust's async I/O story isn't settled yet. tokio and futures exist, but there's some churn there that means it's a bit difficult to deal with at the moment. An RFC for async/await in Rust has been proposed and it's likely that that will be implemented this year, and then tokio should be reworked atop that, which should provide a good basis for things moving forward. It'll take some time for the crates ecosystem to settle around that, though.
I’m curious to know if they ever looked at https://github.com/Microsoft/napajs from Microsoft or any other in-nodejs solutions to deal with the need for multithreading vs launching multiple processes...
Honestly, it's pretty encouraging. All of the problems they listed are things I see as being very nearly solved.
For example, I ran into the futures issues. Now I use nightly's async/await, and it's a massive improvement while still being early days.
I also use the Non Lexical Lifetimes feature, and see a lot of ergonomic wins there.
The other stuff is being worked through as well - Failure is coming along, and I hear good things. Libraries are always improving.
I would be a lot more terrified if these issues were surprising, or not being dealt with, or were extremely hard to fix without breaking the language, etc. Instead, it's a list of things I've run into and can even solve today with a few features.
It depends on perspective, I guess. After all, they say
> While we hit some speed bumps, I want to emphasize that our experience with Rust was very positive overall. It’s an incredibly promising project with a solid core and a healthy community. I’m confident these issues will end up being solved over time.
Rust is still a relatively new language, and most of the cons list fits in with that. They also talked about how they worked around these issues, and what we're doing to address them, which is pretty wonderful.
I'm also happy to talk more about any of the specific points here to add more context; for example, the comment about error-chain and failure is spot on. error-chain is the older, more battle tested library, failure is the newer one that's try to address some issues with it. The ecosystem is still shaking out. (I personally love failure.)
It does match expectations for a language of Rust's maturity and complexity though.
One needs to have a robust instinct for separating the excited statements of early adopters and fans from the more mundane reality: developing a language ecosystem takes a long time and other languages have had decades to iterate.
" each document lives exclusively on one specific worker"
Would decoupling the workers and the documents they work on not solve this problem? Granted this might be non trivial, but it might have solved the fundamental issue thats arguably more interesting.
[+] [-] kibwen|7 years ago|reply
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.
[+] [-] vvanders|7 years ago|reply
[1] https://crates.io/crates/rlua
[+] [-] nickpsecurity|7 years ago|reply
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.
[+] [-] jrhurst|7 years ago|reply
[+] [-] shmerl|7 years ago|reply
[+] [-] tytytytytytytyt|7 years ago|reply
[+] [-] ralusek|7 years ago|reply
[+] [-] Dowwie|7 years ago|reply
[+] [-] blub|7 years ago|reply
Affinity is pay once, use as long as you want.
It looks like Figma is a SaaS. Might as well pay for Adobe if one wants to give up even the meagre amount of ownership they had over their software.
[+] [-] Scarbutt|7 years ago|reply
Is there anything you miss from sketch? what do you think sketch does better?
[+] [-] danenania|7 years ago|reply
[+] [-] abalone|7 years ago|reply
Reading between the lines here, they didn't go with a more mature language like Java because they were worried GC tuning would be a problem?
Given all the other issues they noted with using a less mature language like Rust in production, that's a pretty heavy load to take on in exchange for not having to tune GC. Isn't GC tuning a fairly well understood problem? Is there something about encoding large documents that makes it a significantly greater obstacle?
Or are there other unstated considerations at play here? For example, I mean this completely earnestly and not cynically, but there is a lot more PR and recruitment value in blogging about a hot new cutting-edge language than "how we rewrote our TypeScript server in Java".
[+] [-] tazjin|7 years ago|reply
To name just two ways in which I consider Rust more mature than Java:
* It has a lot of fundamentals that are based on more academic languages which have explored some specific PLT space for a long time and let it mature. The fruits of that are now in Rust (many aspects of its type system for example).
* Rust's community has an almost absurd ability (contrasted with most other languages) to focus on specific core libraries and tooling. For example serde[1], the Rust serialization library, is well-understood, simple, mature and supported in basically every Rust library out there.
The second point is extremely impressive when contrasted with the state of things in Java-land, where you often have many different solutions for the same problems. Sometimes even the well-known and used ones are of very questionable quality[2].
[1]: https://serde.rs/ [2]: https://github.com/FasterXML/jackson-databind/pull/1423
[+] [-] steveklabnik|7 years ago|reply
[+] [-] vvanders|7 years ago|reply
GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear.
[+] [-] nicoburns|7 years ago|reply
[+] [-] observer12|7 years ago|reply
The post says GC was already a problem in their old system.
[+] [-] Thaxll|7 years ago|reply
[+] [-] fulafel|7 years ago|reply
"Instead of going all-in on Rust, we decided to keep the network handling in node.js for now. The node.js process creates a separate Rust child process per document and communicates with it using a message-based protocol over stdin and stdout. All network traffic is passed between processes using these messages."
[+] [-] tedmielczarek|7 years ago|reply
[+] [-] cakoose|7 years ago|reply
[+] [-] rationalthug|7 years ago|reply
[+] [-] slezyr|7 years ago|reply
[+] [-] chocolatkey|7 years ago|reply
[+] [-] pkulak|7 years ago|reply
[+] [-] staticassertion|7 years ago|reply
For example, I ran into the futures issues. Now I use nightly's async/await, and it's a massive improvement while still being early days.
I also use the Non Lexical Lifetimes feature, and see a lot of ergonomic wins there.
The other stuff is being worked through as well - Failure is coming along, and I hear good things. Libraries are always improving.
I would be a lot more terrified if these issues were surprising, or not being dealt with, or were extremely hard to fix without breaking the language, etc. Instead, it's a list of things I've run into and can even solve today with a few features.
[+] [-] steveklabnik|7 years ago|reply
> While we hit some speed bumps, I want to emphasize that our experience with Rust was very positive overall. It’s an incredibly promising project with a solid core and a healthy community. I’m confident these issues will end up being solved over time.
Rust is still a relatively new language, and most of the cons list fits in with that. They also talked about how they worked around these issues, and what we're doing to address them, which is pretty wonderful.
I'm also happy to talk more about any of the specific points here to add more context; for example, the comment about error-chain and failure is spot on. error-chain is the older, more battle tested library, failure is the newer one that's try to address some issues with it. The ecosystem is still shaking out. (I personally love failure.)
[+] [-] vvanders|7 years ago|reply
[+] [-] blub|7 years ago|reply
One needs to have a robust instinct for separating the excited statements of early adopters and fans from the more mundane reality: developing a language ecosystem takes a long time and other languages have had decades to iterate.
[+] [-] vkjv|7 years ago|reply
[+] [-] hsaliak|7 years ago|reply
Would decoupling the workers and the documents they work on not solve this problem? Granted this might be non trivial, but it might have solved the fundamental issue thats arguably more interesting.
[+] [-] unknown|7 years ago|reply
[deleted]