Comment by pmontra | Hacker News Reader

Comment by pmontra | Hacker News Reader

If one needs speed one does everything it takes. That said, I read the code of the example. It's short and even if I don't know Rust I've been paid to write C in the 90s. They look similar enough.

I see we're back to stuff like

    let ptr = path.as_ptr();

    let c = unsafe { *ptr.offset(i) };

    if c == SEP {
      return &path[(i + 1) as usize..end];
    };

It's as low level as it can get. I remember that I wrote a small web app in C in 1994 but I wrote the next one in Perl and never looked back. It was some hundreds lines, countless core dumps and many hours vs much less code and pain and time.

Again, Ruby and Python are all about connecting those small pieces of C code that implement their builtin and library methods / functions. Writing them in C or Rust makes no difference. I personally won't write code in those kind of languages again unless I find myself in a scenario where CPU time is worth more than my time. Maybe we'll be back to that with functions in the cloud billed by the millisecond. Programming is going to be a pain again. At least modern languages like Rust don't crash like C and have a better concurrency story. Meanwhile I'll keep using Ruby and Python with C or Rust extensions from GitHub written by somebody else (a big thank you!), and Elixir where concurrency matters.

    let mut bytes = path.bytes();
    if let Some(end) = bytes.rposition(|&x| x != SEP) {
        if let Some(idx) = bytes.rposition(|&x| x == SEP) { &path[idx..end] } else { &path[..end] }
    } else { "" }

There are other ways to do this, like using a single iterator where we scan manually, but I just threw this together to demonstrate that this code needn't use unsafe, & by extension needn't use pointers. All that unsafe stuff is more so that if you need to drop down to C from safe-Rust you can instead use unsafe-Rust

The real Rust basename implementation is not so low-level:

https://doc.rust-lang.org/src/std/path.rs.html#1801-1808

I don't see how Rust vs C makes no difference. Both languages have trade-offs and I'm pretty sure that Rust advocates would claim the increased safety of the Rust part as a big advantage, and it will certainly reduce those core dumps. Probably the reason there are so many of those advocates is because they don't have to write such error-prone low-level code. Expressive code is more fun, in my experience.

> I personally won't write code in those kind of languages again unless I find myself in a scenario where CPU time is worth more than my time

It is very much possible, that if you run code on a big enough number of CPUs , it'll worth more than an average developer time.

For what it's worth, I don't think that line needs to be unsafe. I think you can just do this:

    let c = s.as_bytes()[i];

In unoptimized/debug mode that's going to do array bounds checks that the unsafe code doesn't, but I think the compiler is smart enough here to see that you're doing the exact same checks in the loop condition too, and it can optimize them out in release mode?

Of course it looks like C, it's using a C interface to interface with Ruby. Normal Rust does not look like that. Your comment is quite frankly entirely pointless.

Your comment is misleading. The code in question is inside a function of the signature

    extract_last_path_segment(&str, &str)

This is pure Rust, no C interface involved.

Per my comment above linking the real implementation: the comment is perhaps misleading about the cause but its claim is largely true. Rust code tends not to look like this.

Well, unsafe Rust does tend to look like this. You were claiming that it is only for interfacing with C code, but unsafe is also used for performance, as in the snippet above. You were IMHO incorrectly dismissing the parent comment based on that. (On the other hand, the code in question could probably rewritten in safe Rust while still avoiding the bound checks. It would be less straight forward though.)

Reply on news.ycombinator.com