Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My negative views on Rust (2023)

chrisdone.com

Post reply on HN
Print view View original

151–160 of 308 posts

Re: My negative views on Rust (2023)

#151

Post by refulgentis »

Const-me wrote: post #118
pcwalton wrote: post #95

Earlier quoted context omitted.

> When you need efficient trees or graphs (I doubt any non-trivial software doesn’t need at least one of them), unsafe code is the only reasonable choice. To name one example, the AnimationGraph in Bevy is implemented with petgraph, which is built using adjacency lists, and doesn't use any unsafe code in any of the parts that we use. It is very high-performance, as animation evaluation has to be.

> It is very high-performance, as animation evaluation has to be Are you sure evaluating these animations is performance critical? I doubt games have enough data to saturate a CPU core doing that. Screens only have 2-8 megapixels; animated objects need to be much larger than 1 pixel. If you animate bones for skeletal animation that’s still not much data to compute because real life people have less than 256 bones. Yo…

> Are you sure evaluating these animations is performance critical?

Isn't this obviously true? A key part of UI work is avoiding "jank", which commonly refers to skipped frames.

> I doubt games have enough data to saturate a CPU core doing that.

Got a bit lost here: games?

> Screens only have 2-8 megapixels.

4 bytes per pixel, 32 MB/frame. 120 frames / sec = 8 ms/frame. 3.84 GB/second.

> animated objects need to be much larger than 1 pixel.

Got lost again here.

In general, I'm lost.

First, there's a weak claim that all performant data structures in Rust must use unsafe code.

I don't think the author meant all performant data structures must use unsafe code.

I assume they meant "a Rust data structure with unsafe code will outperform an equivalent Rust data structure with only safe code"

Then, someone mentions a 3D renderer, written in Rust, is using a data structure with only safe code.

I don't understand how questioning if its truly performant, then arguing rendering 3D isn't that hard, is relevant.

Re: My negative views on Rust (2023)

#152

Post by nneonneo »

fiedzia wrote: post #58
ritcgab wrote: post #49

Earlier quoted context omitted.

It's ugly but it's inevitable in some sense. The author should know what they are doing, and `// SAFETY:` comment is a must.

No. Nobody is going read those (because most people won't even know that some unsafe is buried 5 layers of dependencies below what they work with). The author should make reasonable effort to prove the code is working correctly (and cannot be abused) by other means if possible. It might be a domain issue, so far all my apps are 100% safe (not counting libraries).

You put those safety comments in two places: when you declare an API as being unsafe, and when you use an unsafe API. Not coincidentally, those are the two places in the language that force you to use the “unsafe” keyword. If you declare a safe API that uses unsafe under the hood, it’s on you to ensure that it’s safe to call under any situation, so that callers can call it without worrying that their program is suddenly unsafe. If you can’t guarantee that your API is safe under all circumstances, you need to declare it unsafe and make it the caller’s job to use it safely.

Re: My negative views on Rust (2023)

#153

Post by alfiedotwtf »

Animats wrote: post #11

My big problem with Rust is too much "unsafe" code. Every time I've had to debug a hard problem, it's been in unsafe code in someone else's crate. Or in something that was C underneath. I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people see…

I’ve been using Rust almost daily since 2015 and I’ve used unsafe twice - both when interoping with C.

I don’t know what fancy things you’re doing with unsafe that you’re seeing it on a daily basis… maybe it’s a you problem

Re: My negative views on Rust (2023)

#154

Post by jcranmer »

sophacles wrote: post #142
tptacek wrote: post #104

Earlier quoted context omitted.

Again, the subtext here is GC versus direct control of memory lifecycles, and it is probably not reasonable to argue that there isn't a tradeoff here --- that every application is as gracefully expressible in one as the other, so long as you "git gud" at it. Both sides of this debate are guilty of deploying that trope.

I'm not arguing that there isn't a tradeoff, or about "git gud". I'm literally and genuinely baffled about how one can magically elide knowing if a file is open or closed (or the equivalent) when using a resource. Like I can't think of a single language that doesn't make you explicitly obtain resources, and most of the GC languages do the same thing as rust for casual closing - just let the handle go out of scope. Ev…

> I still don't know what people mean when they talk about "having to think about memory layout"

The best example I'd give is the degree to which you have to ask yourself if you want to use String or if you want to use &str--is this struct, or this function, going to own the string or borrow it from somebody else? If you're borrowing it, who is owning it? Can you actually make that work (this is really salient for parser designs)?

Essentially in Rust, before you can really start on a large project, you have to sit down and plan out how the memory ownership is going to go, and this design work doesn't really exist in most other languages. Note that it's not inherently a good thing or a bad thing, but it is a potential source of friction (especially for small projects or exploratory tools where memory ownership might want to evolve as you figure out what needs to happen).

Re: My negative views on Rust (2023)

#155

Post by faitswulff »

hyperbrainer wrote: post #48
jkelleyrtp wrote: post #38

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". --- Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :) --- The points, addressed, I guess? - Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling - Rust inserts…

> Rust is as complex as C++: ...no, it's not. Maybe not yet, but it is heading in that direction; and I only say this because of the absolutely giant pile of features in unstable that seem to be stuck there, but I hope will eventually make its way to stable at some point. > Async Rust really is fine I dunno. Always thought it was too complicated, but as another person pointed out avoiding Tokyo::spawn solves many iss…

> Maybe not yet, but it is heading in that direction

When people say that Rust is complex, they often neglect to differentiate between implementation complexity and developer facing complexity. The implementation complexity is growing in part to support the end user simplicity. I also don't understand why anyone feels the need to know every feature of the language. You can just learn about and use the features that you need.

Re: My negative views on Rust (2023)

#156

Post by ryandrake »

jltsiren wrote: post #120
Const-me wrote: post #109

Earlier quoted context omitted.

> Non-trivial data structures are often just a bunch of arrays/maps with additional semantics This might be fine for code which consumes data structures implemented by other people. The approach is not good when you actually need to implement data structures in your program. In modern world this is especially bad for a low-level language (marketed as high performance, BTW) because the gap between memory latency and c…

I used to think like that. Then C++11 arrived, and I realized I could get effectively the same performance with containers and move semantics, while spending less effort on writing and debugging the code. If you need an array for your custom data structure, a standard library vector is almost always good enough. Associative arrays are a bit more tricky, but you should be able to find a handful of map implementations…

The C++ Standard Library containers are very good and generic, and almost always the right tool to reach for. People are finally giving up on that notion that their own custom linked list is so much better than . My estimate is that out of all the C++ programmers, 1% of them think that the C++ standard containers are not appropriate for their application, and only 1% of that 1% is right, due to their extremely specialized application needs.

Re: My negative views on Rust (2023)

#157

Post by cmrdporcupine »

tptacek wrote: post #107
cmrdporcupine wrote: post #78

Earlier quoted context omitted.

A tree of Rc/Arc is a tree of references, and is really no different than a Java or Python reference value, except that you'll have to do explicit .clone()s Is it mutability that's tripping you up? Because that's the only gotcha I can think of. Yes, you won't get mutability of the content of those references unless you stick a RefCell or a Mutex inside them.

Yes! Mutability is what's tripping me up! That is not a minor detail!

You can get something like what you're used to a "traditional" language without compiler safeguards by using RefCell and .borrow_mut() on it. That will let you get past the compile-time borrow checks but will do runtime borrow checking and throw panic if more than one borrow happens at runtime.

It's verbose, but it's explicit, at least.

So:

  struct Node {
    parent: Rc>,
    left: Option>>,
    right Option>>,
  }
and just off the top of my head it'd be something like

  {
    let my_parent = my_node.parent.borrow_mut();
    ... do stuff with my_parent ...
  }
  ... my_parent drops out of scope here, now others can borrow ...
etc.

Haven't tried this in compiler my memory might not be right here.

Re: My negative views on Rust (2023)

#158

Post by christianqchung »

sebastos wrote: post #140

"X is as complex as C++" is a preposterous statement for all values of X. A lot of people seem to assume that "C++ is complex" is referring to how the committee adds new language features every 3 years. The conventional wisdom that C++ is wickedly difficult to learn is NOT about "oh man, now I need to learn about the spaceship operator?" C++ is an almost unfathomably bottomless pit. From the arcane template metaprogr…

Yeah, but in 12 years when reflection is in the language and is widely used, people will probably have to deal with a significantly increased amount of weirdness as a result of that feature. Though all that's to say the complexity gap between rust and C++ is only going to go up.

Re: My negative views on Rust (2023)

#159

Post by jyafffyasdfs »

api wrote: post #89
jkelleyrtp wrote: post #38

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". --- Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :) --- The points, addressed, I guess? - Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling - Rust inserts…

IMHO the biggest Rust async annoyance is exactly this: > Tokio's default choice of making `spawn` take Send/Sync futures ... combined with lack of structured concurrency. This means async tasks look like threads in every respect, causing you to end up using Arc and other concurrency constructs all over the place where they ought not be necessary. This harms efficiency and adds verbosity.

I use Box::leak without shame.
Post reply on HN