Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust for Clojurists

gist.github.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Rust for Clojurists

#31

Post by actuallyalys »

charlieflowers wrote: post #14

+1 for this gem right here. Well done! "Many people try to compare Rust to Go, but this is flawed. Go is an ancient board game that emphasizes strategy. Rust is more appropriately compared to Chess, a board game focused on low-level tactics. Clojure, with its high-level purview, is a better analogy to the enduring game of stones."

Yeah, the wry humor throughout is great. Another good bit: "While the Rust project doesn't start off with any equivalent to Clojure's namespace declaration, once you move beyond a single source file you'll need to use it. This isn't C or C++, where you just include files like a caveman. Rust separates code into modules, and each source file is automatically given one based on the file name."

Re: Rust for Clojurists

#32

Post by sanderjd »

rcarmo wrote: post #22
madez wrote: post #9

Earlier quoted context omitted.

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.

I think you may have missed the sense of humor. For instance the thing about jars is absolutely a joke. I thought it came across very much as someone very reasonably discussing tradeoffs and cracking some pretty good jokes along the way.

As an aside, you have to be kind of careful when saying things appear to be advertisements - if it doesn't seem to be true (as in this case it doesn't), then you come away looking like the one with an agenda.

Re: Rust for Clojurists

#33

Post by AlexCoventry »

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 think it's satire?

Re: Rust for Clojurists

#34

Post by coldtea »

AlexCoventry wrote: post #33
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 think it's satire?

No, it's written in a funny way, but it's a legit guide.

Re: Rust for Clojurists

#36

Post by kibwen »

kibwen wrote: post #20
1_player wrote: post #7

> Rust chose to call its [package] format "crates". This reflects the language's industrial roots and the humble, blue collar town of its sponsor: Mountain View, California. Nice :)

The terminology there was actually inspired by the fact that Grayson Hoare would walk to work along the docks in Vancouver, passing the shipping crates as he went.

s/Grayson/Graydon. I blame autocorrect. :P

Re: Rust for Clojurists

#37

Post by elcritch »

nonsince wrote: post #11
hacker_9 wrote: post #4

Good article. He missed out the main pro though (and literally the only reason I ever use any Lisp): hot swapping. The ability to change code on the fly as the program is running. For this to actually work you need 2 things: 1. No explicit types: Everything in Clojure is just a list or hash map, so I can add extra members to anything at runtime no problem. The amount of static checks Rust does at compile time makes t…

You don't need dynamic types to allow hot reloading, as long as a function has the same absolute path and type signature it can be done. I'm pretty sure miri[0] plus some compiler hooks would allow this, although it would need to reach nearly speed-parity with debug code if not release code. Hot reloading and/or repl-driven development is my number one programming desire right now, and Rust is my most-used language,…

Following on this, it should be possible to use something like CLASP [1] to do hot loading on C++ code objects.

https://github.com/drmeister/clasp

Re: Rust for Clojurists

#38

Post by StreamBright »

kaoD wrote: post #26
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…

Thanks, I will look into this.

Re: Rust for Clojurists

#39

Post by StreamBright »

erickt wrote: post #24
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`?

Yes I did compile like that, even had optimization on.

[package]

name = "hammer"

version = "0.1.0"

authors = ["me"]

[dependencies]

hyper = "0.10"

[profile.release]

opt-level = 3

debug = false

rpath = false

lto = false

debug-assertions = false

codegen-units = 1

panic = 'unwind'

Re: Rust for Clojurists

#40

Post by StreamBright »

valarauca1 wrote: post #27
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/connect…

Thank you, it would be useful to show how to this properly.

Answers:

- we are not spawning a thread for each request

The following means we are creating N threads and execute a loop in every one of them, unless I misunderstand Rust entirely.

  for id in 0..NTHREADS {
    let thread_tx = tx.clone();
    thread::spawn(move || { } ....
- I am not sure what coould I do about the standard channel library

- Doing a print at the very end once, the impact on performance is negligible

- keep alive used to be broken with hyper and I am not only looking for keepalive but pipelinening as well. Let me know if you are aware of a HTTP client in Rust that can do both

Post reply on HN