There are working zeromq bindings: so you can use mongrel2 to handle websockets (with or without TLS) and then service those requests with a handler written in Rust!
You have to write the handshake & protocol framing yourself; but there's a reference implementation in Python[1] that's only ~200 lines long and supposedly passed the Autobahn test suite.
Rust's model of concurrency also jives really well with mongrel2's architecture.
---
There's one gotcha: receiving on a zeromq socket through the C bindings blocks the OS thread. This will cause your program to deadlock if you're using Rust's green threading. (Native "1:1" threading is the default however.)
[1]: https://github.com/zedshaw/mongrel2/tree/master/examples/ws
In Rust, from what I've seen, you basically have the option to avoid heap allocations almost entirely which is fantastic for performance. The only other languages that come close to giving you that ability in a very explicit and deterministic way that I know of are C and C++.
Not really. Any time you using a `Vec<T>` or a `String` type, you'll be heap allocating.
I suspect what you meant to say is that Rust does not force programmers to use some sort of garbage collection (whether it be reference counting or otherwise). That is indeed the case. I've written a fair amount of Rust code and haven't needed to use a GC at all.
Well, we have the SmallVec type to avoid this if you can bound the size of your vectors. I would also like to introduce scratchpad allocators at some point, which should allow you to avoid heap allocations even for those.
Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all.
> Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all.
Definitely. Executing searches from `regex!` expressions won't heap allocate either. :-) (Sans the return value, but maybe that can be avoided too.)
This is also the key to programming performant Go. However, you can't really entirely avoid heap allocations, just minimize them.
Modern generational GCs are reasonably nice on caches in most cases.
I am a big fan of Rust, but as it aims to be a better C++, it is probably a better fit for OS development, game engines,
If there was an easy way of using Rust as a websocket server, I would be using that for my project instead of Go. The option to use reference counting is a Big Win when it comes to high degrees of parallelism on multicore processors. When you have GC, the GC thread comes along and causes cache misses for all of the other threads running on different processor sockets. With reference counting, garbage is "collected" locally.