3 ms·

Thank you. I spent ... more time than I'm comfortable admitting trying to figure out how to do that. Out of curiosity, did you spot any other antipatterns? I'm

by shawn 8y ago

Thank you. I spent ... more time than I'm comfortable admitting trying to figure out how to do that. Out of curiosity, did you spot any other antipatterns? I'm sure there are a bunch: https://gist.github.com/shawwn/4d7a89188cac72f3e591f47c84d3ca49 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(); } } Curious about that block in particular. I have no idea what I'm doing, so it'd be somewhat shocking if that were idiomatic.

coldtea 8y ago
>Thank you. I spent ... more time than I'm comfortable admitting trying to figure out how to do that. 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.var.html https://doc.rust-lang.org/std/env/fn.vars.html https://doc.rust-lang.org/std/env/fn.vars.html https://doc.rust-lang.org/book/second-edition/ch12-05-working-with-environment-variables.html https://doc.rust-lang.org/book/second-edition/ch12-05-workin... http://siciarz.net/24-days-rust-environment-variables/ http://siciarz.net/24-days-rust-environment-variables/
- shawn 8y ago
  FWIW, those four links are already purple for me. 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".
  - coldtea 8y ago
    That's understandable, but isn't it premature to judge Rust based on such a session? That would be like criticizing vi based on "baby's first vi session", because "couldn't even exit the editor!".
    - shawn 8y ago
      I... am not sure. On one hand, it's instructive for language designers to know what turns out to be a barrier to entry. They're often unexpected things. And what's worse, users usually run into them and then quietly disappear; you almost never get the chance to see what trips newbies up in practice. It wasn't meant as a solid criticism, but more of a cathartic "yes, this language can be really counterintuitive at times." (Rust is in good company. It's the same reason Lisp is unpopular.) 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.
steveklabnik 8y ago
You're welcome! I have had a lot more time to familiarize myself with the standard library than you probably have. 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 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 :)
pitaj 8y ago
Does `canonicalize` [1] not work in place of `realpath`? 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.canonicalize https://doc.rust-lang.org/std/path/struct.Path.html#method.c...
- shawn 8y ago
  Just wanted to say thanks for taking the time to give feedback. Swinging through the jungles of a new ecosystem is always fun, and guideposts like this are quite helpful.

by shawn 8y ago

coldtea 8y ago

>Thank you. I spent ... more time than I'm comfortable admitting trying to figure out how to do that. 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.var.html https://doc.rust-lang.org/std/env/fn.vars.html https://doc.rust-lang.org/std/env/fn.vars.html https://doc.rust-lang.org/book/second-edition/ch12-05-working-with-environment-variables.html https://doc.rust-lang.org/book/second-edition/ch12-05-workin... http://siciarz.net/24-days-rust-environment-variables/ http://siciarz.net/24-days-rust-environment-variables/

shawn 8y ago
FWIW, those four links are already purple for me. 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".
- coldtea 8y ago
  That's understandable, but isn't it premature to judge Rust based on such a session? That would be like criticizing vi based on "baby's first vi session", because "couldn't even exit the editor!".
  - shawn 8y ago
    I... am not sure. On one hand, it's instructive for language designers to know what turns out to be a barrier to entry. They're often unexpected things. And what's worse, users usually run into them and then quietly disappear; you almost never get the chance to see what trips newbies up in practice. It wasn't meant as a solid criticism, but more of a cathartic "yes, this language can be really counterintuitive at times." (Rust is in good company. It's the same reason Lisp is unpopular.) 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.

steveklabnik 8y ago

You're welcome! I have had a lot more time to familiarize myself with the standard library than you probably have. 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 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 :)

pitaj 8y ago

Does `canonicalize` [1] not work in place of `realpath`? 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.canonicalize https://doc.rust-lang.org/std/path/struct.Path.html#method.c...

shawn 8y ago
Just wanted to say thanks for taking the time to give feedback. Swinging through the jungles of a new ecosystem is always fun, and guideposts like this are quite helpful.