let lumen_host = env::var("LUMEN_HOST").unwrap_or(String::from("luajit"));
let lua_path = env::var("LUA_PATH").unwrap_or(String::new());
let node_path = env::var("NODE_PATH").unwrap_or(String::new());Out of curiosity, did you spot any other antipatterns? I'm sure there are a bunch: https://gist.github.com/shawwn/4d7a89188cac72f3e591f47c84d3c...
I poo poo the language a lot, but it's satisfying to get the hang of it.
fn realpath(path: &str) -> &str {
unsafe {
return CStr::from_ptr(
libc::realpath(
path.as_ptr() as *const i8,
0 as *mut i8
)).to_str().unwrap();
}
}
That being said.. A lot of this stuff is things that already exist that you don't need to write yourself. dirname, basename, join, even s is .to_string. It's also the same as str. getenv is env().unwrap_or().
> Curious about that block in particular.
I would call https://doc.rust-lang.org/std/fs/fn.canonicalize.html and be done with it, instead of importing libc and going through all of this.
In the end, this should be like 40LOC, 50 tops, if you made use of the standard library rather than trying to re-implement it all :)
The question is why. The relevant examples are everywhere:
https://doc.rust-lang.org/std/env/fn.var.html
https://doc.rust-lang.org/std/env/fn.vars.html
https://doc.rust-lang.org/book/second-edition/ch12-05-workin...
The reason it's difficult is that it simultaneously introduces the concepts of optionals, unwrapping, string processing, variable assignment, and lifetime management. It's not like it's impossible to figure out. I was only saying the workload was similar to "baby's first vi session".
That would be like criticizing vi based on "baby's first vi session", because "couldn't even exit the editor!".
On the other hand, you're absolutely right: the hypothesis is, given two equally-experienced programmers, one of them a Rust aficionado and the other a LuaJIT maniac, the LuaJIT dev will deliver reliable and maintainable software with an order of magnitude less effort. So you're right, that remains to be seen (to put it mildly).
Looking forward to seeing how close I can get to XSV's performance. It's a great benchmark.
You have a couple of helper functions, like `s` and `str` which you might consider using `to_str` and `to_string` in their place, as it's more idiomatic to use them directly rather than save characters.
And obviously you can replace `getenv` with `env::var`.
1: https://doc.rust-lang.org/std/path/struct.Path.html#method.c...
Criticizing a language by how easy it is to write the "first 20 lines" doesn't sound really fare...
It took hours to figure out how to implement this in rust: https://github.com/sctb/lumen/blob/master/bin/lumen
If you want to see an "expert" programmer's attempt at making sense of the language, here you go: https://gist.github.com/shawwn/4d7a89188cac72f3e591f47c84d3c...
Now that it's done though, I see why people fall in love with Rust. It's really satisfying seeing Lumen's startup time drop from 200ms to 100ms.
But yes, like -- dude, at one point I just wanted to write a for loop like this, to grab some environment vars:
Good luck with that! I'm sure there's a way to coax Rust into please-allow-me-to-just-compile-this, but the borrow checker is a cruel taskmaster. Whatever the syntax is, that's not it, and spending literally an hour trying to figure out how to store an environment variable into a separate variable doesn't feel very productive.That said, Cargo is amazing. It's truly a wonderful, delightful piece of software. Cargo crates plus a dynamic language seems like a recipe for success.