Hacker News Reader

Comment by chriskrycho | Hacker News Reader

I mostly hear it from folks who are explaining why they use Zig or Odin instead, or aren't why they are not interested in switching from C or C++.

Re: overhead—I think the compiler helps a ton here, but I do think that it makes a lot of memory-related concerns explicit where they are usually implicit, and dealing with lifetimes can be quite burdensome. Now: I also think that those concerns still exist when you're using other systems-level languages, and that the tradeoff therefore often ends up looking like "Deal with it up front, or deal with it on hard mode later."

View on HN

I’ve spent a fair bit of time in rust and written more than my fair share of unsafe code. Unsafe is super necessary sometimes. But there are definitely reasons I’d consider using Zig or C or something if I needed a lot of unsafe in my project.

- From a language point of view, the syntax for dereferencing pointers in rust is awful. I don’t mind the unsafe keyword. But in rust you can’t do a->b. You need to write (*a).b. And that gets increasingly awful as you have more complex pointer expressions. Unsafe code in rust looks significantly uglier than the equivalent C.

- The Rust community - particularly on Reddit - seems to get very snide annd condescending about programmers using any amount of unsafe in their rust code. Even when it’s totally necessary. I’m not convinced the community will is there to fix rust’s bad pointer syntax, or other missteps with unsafe. Apparently having unreadable unsafe code is my atonement for wanting high performance code. Never mind that the harder my code is to read, the more likely I am to make mistakes. And in exactly the part of my codebase where bugs would be the most damaging to safety! Argh.

I love rust. I love the fresh ideas it’s brought to programming as a whole. But I can’t wait for some other, newer languages to iterate on these features & the language syntax some more. It’s not the top of the mountain.

> But in rust you can’t do a->b. You need to write (*a).b.

For what is worth, I think that we'll add that at some point.

I think some of the snideness is probably due to different senses of what amount of unsafe is actually needed. There’s so much premature optimization in many cases that wouldn’t even come up if the language were Java, Go or whatever. It’s totally fine to initially accept some known overhead from cloning or Rc if you don’t know yet it it’s going to significantly impact performance.

I think the tricky thing here is that unsafe blocks pit safety and performance against each other at the limit. There’s essentially two languages both called rust: one which prioritises performance over safety. (“Make it safe - but only when safety doesn’t negatively impact performance”) And another which prioritises safety over performance (“Raw pointers and unsafe code should only be used as a last resort”).

Cargo stores packages from both sub-communities and we fight over the heart of rust. - And sometimes to our collective detriment, like what happened to actix.

I definitely know what you mean re: snideness about `unsafe`, and I wish that were quite different. I think it's (a) good to have a default of "avoid unsafe, you probably need it less than you think" and (b) good to remember that the tool is there for a reason!

Also: agreed re: syntax.

> But I can’t wait for some other, newer languages to iterate on these features & the language syntax some more. It’s not the top of the mountain.

YEP. That's exactly what I was getting at in my callout at the top of the piece. First word, not the last.

Pointer dereferencing is a missed opportunity to use a postfix operator. If a* was the way to dereference, then a*.foo() could have been the way to call a function on a pointer.

I wonder how much they would be interested, when we finally catch up with the other industries, and liability becomes a real thing.

Reply on news.ycombinator.com