Unfortunately failure and errorchain appear to not be cool anymore (ie I've noticed quite a few people are migrating away from failure just like they did from errorchain) and there doesn't appear to be any push from the Rust team as of yet.
I think it's a serious problem as your code base grows and I wish we had some more work on the RFC front.
quite smart approach of having a nodejs frontend doing what it's good at (async) calling the backend via simple subprocess/stdio communication. they could almost say they invented CGI :)
It seems like the speedup they gained was probably as much from the architecture change as it was rust. (That often seems to be the case when people say they saw a significant speedup due to switching to rust, go, or similar.)
I did this recently, where I compared going through FFI from Java to Rust, vs through gRPC. gRPC wasn't that much slower than FFI, and its benefit would be that I could have 2 services in the network.
FFI had overhead, but its performance profile was consistent, very little fluctuation in runtime.
They're forking a new process for each request. Passing the request data to that process on stdin when you create it is much simpler than spawning a process, waiting for it to be ready, and then communicating with it via http.
Hm, I don't think they are. I think they one persistent process managing the state of each document, and many requests might interact with that document, via stdin/stdout channels on that document's process.
Makes the case for the rest of what you said all the stronger, though.
I would say it has improved quite a bit, but they are still there. It varies quite a bit on what you are doing. At work we have a modest sized project, converted from C, being used and updated for about a year. I don't think it has had any significant lifetime battles; I don't think there are even explicit lifetimes in the source.
Data structures exercises will be a different story.
I'm not the author, but from my perspective: Yes. Dramatically. Non-lexical lifetimes eliminated the most common cases where the compiler was just wrong.
Of course you still need to think about lifetimes, and sometimes warp your program around them. However, it is now much less common for that thinking to arrive at "The compiler is wrong; how can I convince it of that?"
I've been writing servers in Rust and I don't really agree. Granted, these may not be traditional HTTP servers - they're AWS lambdas, which puts them closer to the "some function" than "some server" depending on how you look at it.
They work great, I've been able to iterate extremely quickly on a system that has had its requirements changed quite a lot over time.
I haven't spent much time optimizing my code at this point but they execute extremely quickly, much faster than my Python lambdas.
Regarding the author's complaints:
I haven't needed any async. I use threads and it's fine. When async/await is a thing I'll use it, maybe - I really don't think it's going to make a difference but it might free up some memory that I can throw at caching.
Error handing in Rust is still a bit uncomfortable. The failure crate has been working for me but it doesn't always feel 'right'.
those are not servers! In fact the branding of AWS lambda is exactly "serverless". You don't have to have process restart logic, they're very transient, if a process error causes a crash (yes that happens even in rust) the entire thing is taken down. They're less of a server than a kubernetes-orchestrated container.
Sure, sorry, I meant services where I wrote "servers" and it's likely the person I responded to did as well.
I don't think it changes anything about what I said - process restarts aren't something I'd care about the language for anyways, I'd have a sidecar for that.
Hey there, yes. I guess I meant "services" / servers.
I suppose from my point of view - small fish in the ocean - I suppose Rust services running on lambda would be a-ok.
I'd love to learn more about how you build and deploy. Do you have any favorite articles / resources that I should look at?
It's pretty nice, it even feels a bit like Node.js' express. It's pretty easy if you can answer requests quickly/synchronously.
When you need to use Futures, it's a bit more fiddly (you can't wing it, you really need to understand lifetimes and how the Future types are composed). I'm hoping the upcoming async/await syntax sugar will lower the barrier to entry here.
Lines of code is not the only metric. I'm actually really curious about Erlang and Elixir but to be honest I do like type systems a lot. I also like the idea of idk...having one language for my os, db, front-end.
Unfortunately I can't show you my code since it's closed. Just looking at the two codebases, about half of the erlang implementation is static typechecking hints, and I don't know if GitHub counts the documentation HTML as LOC.
As an example of convenient concurrency, in Erlang vm gives you process node id translation. What that means is that if you're sending a message between threads in two instances in a cluster of VMs, you can send your the mailbox address of your local thread and have it converted on transmit to the equivalent remote thread address on the remote machine. Literally one less thing you don't have to worry about, and clustering is a first class citizen in the language, no libraries necessary.
Basically, the dev process was, I wrote my raft implementation, tested it locally and extensively (including property tests) using multiple local threads, and did almost nothing (three lines of code to provide a mailbox Oracle) and had a solution that worked across the network.
If you're curious about BEAM languages, I wouldn't worry about type systems. If anything I think hypercorrectness in the languages leads to a false sense of comfort about the quality of your code that can get in the way of building resilient, designed to fail gracefully systems. Typechecking can catch errors early and save you dev and debug time, but static typechecking is probably enough for about 80% of those concerns.
Erlang languages come with static typechecking. It's kind of a pain in the butt out of the box. I don't know about erlang, but if you code in vscode, the elixir_ls plugin engages the static typechecking in such a transparent fashion that I've forgotten to install the makes-static-typechecker-easier library and it's caught code problems for my junior dev (who I haven't taught typechecking yet). Despite it being optional in the language, the vscode plugin makes it ever so ugly to not annotate types that my very minor obsessive tendencies lead me to annotate everything.
I'm just learning Rust right now and my initial thoughts are exactly your sentiment. Writing a backend for Websockets is so easy in Erlang/Elixir, seems a lot more difficult in Rust.
Now, the performance of Rust is aspect that Erlang/Elixir will never close to reaching.
- NLL (non lexical lifetimes) are now in stable, so working with lifetimes and references is a bit easier
- stack traces: failure is still around, it's got a fairly large group using it, it seems. I prefer the std error handling route most times.
- async is hard: it's still pretty hard