Trying Rust for web services
blog.wearewizards.io
blog.wearewizards.io
One thing this blog post points out is Rust ecosystem docs. I've been trying to find a good way to evaluate this: https://users.rust-lang.org/t/lets-talk-about-ecosystem-docu...
Other thoughts:
Crates.io, our package server, uses Rust + Ember. One thing that is really interesting about Rust in this space is memory usage: last I heard, crates.io uses a flat ~30 MB of RAM, resident. I'm used to Rails where that is... very different.
On that note, I think "Rust serving JSON + Javascript for the frontend" is a really interesting stack. I've been trying to find the time (and hopefully roping another person or two in) to build a http://jsonapi.org/ library for this purpose. I have a project where I've been using it, but I went down the "why use a library, I can generate the JSON by hand" and it's.... ugly. Serde is so much nicer.
As always with a young ecosystem, we need more libraries. For everything. It's gotten a lot better, and much of the basics are there, but sometimes, you're still going to have to write things yourself, which slows things down.
mio is gaining preliminary Windows support, and once it does, hyper will roll it in, which should significantly improve performance in many web contexts, as well.
I largely come from Ruby, where Rails was such a leap forward that people learned Ruby just to use it. I expect that if you know Rust, writing application-tier Rust will be fine, but I'm not sure it will ever see the same kind of pattern.
Plus, there are other serialization libraries as well, and having the official Rust docs play favorites in the ecosystem is something we try to avoid.
I don't have a login on rust-lang yet, but I wanted to add this comment regarding the documentation:
The rust-doc auto generated pages are really confusing. The sidebar generally fails to show where in the hierarchy of the API docs you are (ideally it would highlight the current page you're looking at in the hierarchy and provide the full hierarchy to give you context), the breadcrumbs don't indicate that they are links, the breadcrumbs indicate the type of the entry to the left rather than the right adding semantic confusion, and long pages tend to not have a TOC meaning you have to either search in the page or know the page structure ahead of time (probably mostly an issue for new users).
I feel like those are all simple mechanical issues that could make the auto-generated rust-docs a lot more useful.
It'd also be nice to tie non-auto generated docs into a crate's documentation, but I haven't looked into how rustdoc works so I'd guess that's possible but a lot of people don't do it.
As for non-API docs, https://github.com/rust-lang/cargo/issues/739 is the tracking issue. Also great to have, also just needs someone to come along and do it.
I am looking for example code where I can pass in the server certificate prior to listening. Something similar in functionality to Go's http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil)
Edit: typo
Also, the Iron docs that another commenter pointed you at looks vaguely like that call. I'm not familiar with Go's API.
And if you want to patch other frameworks or build your own: I have personally used Hyper (http-crate) with the OpenSSL crate to do Https before and I found it very easy.
As the ecosystem grows I only expect it to get better.
We're in the middle of a big refactoring of the compiler that will eventually enable even more gains. I'm confident rustc will only get faster in the future.
sudo apt-get install inotify-tools
That's too categorical a statement. It depends on a lot of things. Sure, there's a place in the world for PHP pages that take two or three full seconds to render, but it doesn't matter because they're doing something useful and don't get hit a thousand times per second. There's also a place for things that render in under a millisecond because they're getting hit at an incredible rate, and if they also have some sort of interdependencies then Rust can make a lot of sense.
Plus as I've said before, the whole "you're stuck in IO anyhow so who cares how fast the render code runs" dogma has sometimes gone too far. (I know you didn't say anything about that, but I'm guessing based on experience it's what lies behind your point.) My experience in switching from slow languages to fast languages, even doing the same IO, is that you do tend to see real performance gains unless your page was absolutely trivial. Slow languages really are slow in practice.
I don't use php personally, but most of my rails apps render full pages in under 100ms. I'd imagine php performance to be at least on-par with a full rails app.
Rails, for that matter, is known for being easy to produce multi-second pages too.
Slow languages are slow in practice, too.
If you haven't tried it, consider trying it before becoming offended at the idea that your tool may not be appropriate for all use cases. Yes, it can matter when your language is 50 times slower than another.
There are plenty of non-interpreted languages that don't require GC though. When you pick Rust you are picking manual memory management. Does even Google opt for non-GCed languages for their web servers?
{
let x = Box::new(5); // malloc
} // free
Maybe "deterministic"?
What's this non-lexical borrowing idea you mentioned in your other comment? (I can't reply there for some reason.) Is there an RFC for that?
There hasn't been an RFC yet, because we're in the middle of a large amount of compiler internals work (HIR/MIR), which will make overall analysis easier, including these two features.
> (I can't reply there for some reason.)
HN limits responses based on the depth of the comment tree and the length of time since the comment was posted, to discourage flamewars, you can always click on a comment link directly to kind of bypass that though.
Rust: "statically memory managed" Java, Go: "dynamically memory managed"
Similar to: "statically typed" or "dynamically typed"
I didn't mean it to be. Of course there are extreme cases where GC pauses are unacceptable on a web server, but those are relatively rare. Even Google mostly uses Java (although they are heavy C++ users, is it for their web servers?).
There are always extreme cases, which is why I asked the question.
> My experience in switching from slow languages to fast languages, even doing the same IO, is that you do tend to see real performance gains unless your page was absolutely trivial. Slow languages really are slow in practice.
Slow vs. fast is not black and white. Is Go slow? Is Lua slow? I Java (on a warmed up JVM) slow?
We're talking about GC vs. non-GC languages here. Do you really see a difference in performance gains?
I'm not so sure about that. The core services (e.g. Search, Maps, Earth, Big table, Map reduce) seem to be C++. Ads is possibly an exception.
I don't think it's any secret that Java is huge Java users. If not web servers, then for what?
At Google's scale, the performance difference between Java and C++ can means millions of dollars in electricity alone.
This is an unnecessary tangent though, as I've said throughout this discussions, there's extreme cases and no doubt Google is likely one of them. But we're talking about common use case, to which I still haven't seen any evidences that GC pauses are a deliberating factor.
Other languages give you that ( namely Go ), but I found the correctness checking from rust is _way_ better and I am forced to have much better designs in my programs.
Another Tangential benefit is that I can do lots of great system level things ( High performance data collection, Clustering, Math), and then have a thread pull in a web server and serve out things like statistics and control interfaces.
Also its just nice to program in and the tooling is much nicer then C++
One of the big areas where people choose Go is for cli utilities and static linking is a big reason for that choice. I can see Rust becoming a competitor in this space for the same reason. But for a web server that you control I don't see a huge advantage to static linking.
Many organizations have yet to adopt devops and templated system deployment methodologies, so it's a legit concern.
That's true of dynamic linking as well. Static linking just saves you the trouble of having to install the library dependencies on the server. But for ops that's a pretty tiny, if not non-existent gain. So I don't buy it.
When deploying to users it's a huge gain, so I do get that that for things like cli utils.
I know there's been several articles lately about broader applications of rust, and then "is it worth it?" type responses, concerns about "manual memory management", with the implication being there's some heavy tax on not using a GC.
I would certainly agree with the presence of this tax while writing C/C++. (Less with C++, RAII, and especially c++11, but still there.)
With rust, once you're up the learning curve (which, granted, can take a few months), your productivity is not substantially worse than GC'd languages. You pretty much master the borrow checker's semantics, and the best practices to structure things in ways that play nicely with its expectations. And lifetime-related errors don't occupy all that much of your development time.
Source: my team has been re-writing some components of Dropbox's multi-exabyte storage system in rust (from go) over the last 9 months.
Can you point me to a list of libraries written in ObjC that work without Apple specific code? (E.g. without using anything starting with 'NS')
I'm using Iron instead of Nickel. Not sure who will become more popular over time...
Because of the language (no null, bounds checking, option/result types, etc.) and borrow checker I find I rarely have to 'hot reload' or even test my code. I realize that sounds surprising. I'm not doing any HTML templating in Rust - that's better done in JavaScript on the client - so I don't have the edit/compile/test cycle for every tweak to the UI.
Either way, I hope Rust skips the callbacks.
Dynamic typed language frameworks are also around 70k requests per second[1], something must be going wrong outside postgres too.
[1] https://www.techempower.com/benchmarks/#section=data-r10&hw=...
EDIT: Agh! Armin isn't the author of Requests. :) I'm mad at myself because I even went to the Requests home page to attempt to verify that before posting this comment, and mistook his name under "Testimonials" as an indication of authorship. :P Sorry Kenneth!
minor correction, Requests is written by Kenneth Reitz
The performance is better and I reckon it's much nicer to write. Unfortunately, the ecosystem isn't there yet.
In my preliminary tinkerings, I'm a bit faster writing Go than Rust. I'm not super comfortable with either language. Rust's compiler is a lot more picky, and there's a learning curve to understand how ownership works. Go is a comparatively simple language (which can be a positive or a negative depending on your ideals and usage cases).
I think Go will probably always be "faster" to write, but Rust will keep you from making certain mistakes that you may have sunk debugging time into later. Hard to say where the time break-even is. I am keeping a close eye on both camps so that I'm equipped to make the call as soon as some of our components at work need something faster than Python.
* Flow from Facebook
* TypeScript
* Elm
* PureScript
I've never heard of Elm or PureScript being used for backends, users would prefer Haskell I presume. With elm it would require using ports for almost everything, I haven't used PureScript so I can't comment on that.
And as far as ecosystems go, I would prefer using the Python one rather than the Node one.
So far, TypeScript's type system isn't perfect, but it is strict enough to help me catch errors before runtime. Also, there's the (huge) added benefit of making code more readable and self-documenting.
I think I've only had one instance where I violated a type at runtime, but keeping the type system in mind as you're writing your code, you know exactly where those things can or can't happen.
I am really enjoying using Visual Studio's excellent IntelliSense and debugging features, which are on-par with any other web language I've used. Generally speaking, the typing makes hints and autocompletion far better.
Overall, I'd give the whole experience a 7 out of 10. I don't really know of a more productive way to write asynchronous code at the moment.
In addition, if you intend to use static typing on generated JS, I suspect that you are going to lose plenty of information.