Rust for Clojurists • Hacker News Board

Re: Rust for Clojurists

#21

Post by MichaelGG » Sat, Apr 29, 2017, 3:41 PM UTC

hacker_9 wrote: post #13

MichaelGG wrote: post #10

Earlier quoted context omitted.

In which scenarios do you use hot swapping?

Just about every scenario? Any algorithm I am working on, any function, any config variable I want to tweak in real time, any GUI I am developing, and so on.

So for interactive work? Versus updating long running server jobs?

I'm used to using the REPL in F#, but you can't redefine data types and have old code pick up on it - only new code. Such an approach is theoretically possible in Rust. Debuggers can do this for C++ to some extent.

Re: Rust for Clojurists

#22

Post by rcarmo » Sat, Apr 29, 2017, 3:57 PM UTC

madez wrote: post #9

rcarmo wrote: post #3

Aside from the emphasis on mutability, I got nothing from this except bias. .jar files are an _advantage_, and the author comes across as a card-carrying member of the Rust Evangelism Strikeforce aiming to bring into the fold a small (but opinionated, and borderline influential) community :)

Why are you so negative about Rust and people who advertise it?

Because they _advertise_ it. The piece would be a lot better if it did positive comparisons.

Re: Rust for Clojurists

#23

Post by coldtea » Sat, Apr 29, 2017, 4:03 PM UTC

While I understand this kind of guide (showing how things are done in one language/ecosystem vs another), is there such a thing as a Clojurist that would have benefited from it?

I'm not asking whether there are Clojurists. Of course there are.

I'm asking whether there are people that primarily and only know Clojure, and thus would benefit from a translation guide between Clojure and Rust, instead of say between C or Java or Python or Ruby etc and Rust.

I'd think that anybody who uses Clojure was already familiar and/or proficient in some other language before, much more major than Clojure.

Re: Rust for Clojurists

#24

Post by erickt » Sat, Apr 29, 2017, 4:28 PM UTC

StreamBright wrote: post #19

Nice. My biggest problem with Rust is the poor performance and lack of complete & sane libraries, especially for HTTP. I was running into serious issues with the following code: https://gist.github.com/l1x/5678c0fdfc2c1a6034b8bcc3800de93c Its performance is saturated around 60K req/s on a 32 core box with 10G networking while wrk was more than happy to do 3M req/s. I was trying to dig further into why it is slow and…

Hello! It's been a bit since I dug into hyper, but that's surprisingly low. Just to check, did you compile this with optimizations enabled, like `cargo build --release`?

Re: Rust for Clojurists

#25

Post by nbardy » Sat, Apr 29, 2017, 4:34 PM UTC

coldtea wrote: post #23

While I understand this kind of guide (showing how things are done in one language/ecosystem vs another), is there such a thing as a Clojurist that would have benefited from it? I'm not asking whether there are Clojurists. Of course there are. I'm asking whether there are people that primarily and only know Clojure, and thus would benefit from a translation guide between Clojure and Rust, instead of say between C or…

Yes. Me. I've been programming for about ten years, but mostly jumped from language to language until I found clojure. Clojure is the only language I really "know".

Re: Rust for Clojurists

#26

Post by kaoD » Sat, Apr 29, 2017, 4:35 PM UTC

StreamBright wrote: post #19

Nice. My biggest problem with Rust is the poor performance and lack of complete & sane libraries, especially for HTTP. I was running into serious issues with the following code: https://gist.github.com/l1x/5678c0fdfc2c1a6034b8bcc3800de93c Its performance is saturated around 60K req/s on a 32 core box with 10G networking while wrk was more than happy to do 3M req/s. I was trying to dig further into why it is slow and…

I'm not sure about performance vs wrk (don't kwow wrk), but just to give an idea: I noticed you're not using Tokio Hyper. Try Hyper's master branch, which fully embraces Tokio's async.

EDIT: From wrk's README:

> wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue.

Your example is multithreaded but IIRC release Hyper isn't using event notification async, which Tokio Hyper does. It might help.

Re: Rust for Clojurists

#27

Post by valarauca1 » Sat, Apr 29, 2017, 4:38 PM UTC

StreamBright wrote: post #19

Nice. My biggest problem with Rust is the poor performance and lack of complete & sane libraries, especially for HTTP. I was running into serious issues with the following code: https://gist.github.com/l1x/5678c0fdfc2c1a6034b8bcc3800de93c Its performance is saturated around 60K req/s on a 32 core box with 10G networking while wrk was more than happy to do 3M req/s. I was trying to dig further into why it is slow and…

- Spawning a new thread for every request isn't good, you can reuse threads this causes a non-trivial Kernel load

- The standard channel library isn't bad but it's a far cry from great. You end up allocating every SEND. Which has its trade offs.

- You are doing a print in every thread which requires acquiring a global lock, and at least 2 system calls, and a global allocation.

- You aren't keeping your client/connection alive. So every new thread has to do a new 3 way handshake every request. 5 way if your is HTTPS.

Re: Rust for Clojurists

#28

Post by boargod » Sat, Apr 29, 2017, 4:42 PM UTC

StreamBright wrote: post #19

Nice. My biggest problem with Rust is the poor performance and lack of complete & sane libraries, especially for HTTP. I was running into serious issues with the following code: https://gist.github.com/l1x/5678c0fdfc2c1a6034b8bcc3800de93c Its performance is saturated around 60K req/s on a 32 core box with 10G networking while wrk was more than happy to do 3M req/s. I was trying to dig further into why it is slow and…

I could be doing something wrong, but I tried your code using hyper master here and got similar results: https://gist.github.com/anonymous/d5fa7a62ae1d3927878a976228...

Re: Rust for Clojurists

#29

Post by actuallyalys » Sat, Apr 29, 2017, 4:46 PM UTC

coldtea wrote: post #23

While I understand this kind of guide (showing how things are done in one language/ecosystem vs another), is there such a thing as a Clojurist that would have benefited from it? I'm not asking whether there are Clojurists. Of course there are. I'm asking whether there are people that primarily and only know Clojure, and thus would benefit from a translation guide between Clojure and Rust, instead of say between C or…

I'm better at Python than Clojure, but I appreciated this article anyway. Clojure and Python take different approaches, so a comparison of Python and Rust and one of Python and Clojure highlight different parts of Rust.

Re: Rust for Clojurists

#30

Post by kaoD » Sat, Apr 29, 2017, 4:51 PM UTC

boargod wrote: post #28

StreamBright wrote: post #19

Nice. My biggest problem with Rust is the poor performance and lack of complete & sane libraries, especially for HTTP. I was running into serious issues with the following code: https://gist.github.com/l1x/5678c0fdfc2c1a6034b8bcc3800de93c Its performance is saturated around 60K req/s on a 32 core box with 10G networking while wrk was more than happy to do 3M req/s. I was trying to dig further into why it is slow and…

I could be doing something wrong, but I tried your code using hyper master here and got similar results: https://gist.github.com/anonymous/d5fa7a62ae1d3927878a976228...

Again I'm talking out of my ass here (very new to Rust's async) but AFAICT running core.run(work).unwrap() inside the loop is the same as just running it synchronously (unwrap is waiting for work to end, i.e. there's only a single concurrent connection ever per thread.)

It'd probably be better to continously run a core per thread and .spawn many tasks for it so that there are several concurrent connections per thread. Or maybe just .run a future which is the .join of multiple .get futures?