Hacker News Reader

Comment by khc | Hacker News Reader

This is my attempt at learning rust and also build something that I can potentially use. I'd have to say that the feeling of being reasonably sure that my code is free of many classes of bugs is a very nice feeling indeed, but I am still not entirely sure if the effort to fight against the compiler was worth it.

Two shortcomings that I noticed building my first rust project:

* many lifetimes that are easy for humans to reason about are difficult/impossible to express to the compiler, so I had to use unsafe hacks.

* the std library does not feel complete or well thought out. For example too many string types with different sets of functions. Also many IO functions are too abstracted away.

Happy to elaborate more and hear what others think about catfs or rust!

View on HN

The more experience you gain with Rust, the less you fight against the compiler, and the less you'll opt for the unsafe keyword. Fighting the compiler is just something that happens the first few weeks.

Can you show me some examples of 1?

2 is necessary, unfortunately, in a systems language. Well, regarding strings anyway. Most people complain that IO isn't abstracted enough; could you give some specifics? Thanks!

For 1: https://users.rust-lang.org/t/conflicting-lifetime/11887

Or any time you want to use thread and closure. I know I am joining the threads before the references go away but it's not possible to express that. There's scoped threadpools but sometimes it's at a higher level than scope.

2: Can't get the return value for close(). readdir doesn't return the offset. I ended up wrapping libc myself: https://github.com/kahing/catfs/blob/master/src/catfs/rlibc....

I guess wrt string, it's extra frustrating because on unix, OsStr is really CStr but I get former (from command line) and often need latter for interacting with libc. Also when you learn Rust you first learn about str and String even though in my case I actually want to avoid them. Admittedly that's probably rare. Having every type duplicated (a ref type and a storage type) also increases the complexity.

You should use crossbeam for #1. And as for strings, I wouldn't think of them as duplicate types any more than u32 and &u32 are duplicate types. They are semantically the same. Referencing a boxed type returns the reference type.

What does crossbeam have to do with #1? I already mentioned scoped thread pools.

Thanks! Always interested in learning about pain points.

Reply on news.ycombinator.com