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

Several core problems with Rust

bykozy.me

Post reply on HN
Print view View original

271–280 of 341 posts

Re: Several core problems with Rust

#271

Post by drannex »

Measter wrote: post #244
dana321 wrote: post #233

Earlier quoted context omitted.

It was bad coding. .unwrap() is not required to be used. use: if let Some(value)=something_to_unwrap{ }else{ // log an error and exit!! }

Fun fact: that's what an unwrap does. It panics, which causes the error to be logged and the thread ended.

And one of the fun things about how unwrap() does that automatically, is that if you are working with an orchestrator with retry logic, you won't need to (re-re-re-re-re-)write your own for the entire program - the orchestrator will see the error, log its output, and try again in high volume workloads, or move on to the next request - this is incredible and nice to use especially when a failure in one request doesn't need to fail the entire application for all requests.

I shy away from unwrap() in almost all cases (as should anyone!) but if you are running a modular system, then unwrap when placed strategically can be incredibly useful.

Re: Several core problems with Rust

#272

Post by Capricorn2481 »

vacuity wrote: post #162
Capricorn2481 wrote: post #156

Earlier quoted context omitted.

> Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB. Doesn't mean I think it's…

Internal use of unsafe requires securing the safe code at the module boundary. However, the design of unsafe still greatly reduces the burden of memory safety, both when it is and isn't used directly. The specific semantics of Rust aside, unsafe is more or less the ideal way for a language to express unsafe escape hatch constructs.

> Internal use of unsafe requires securing the safe code at the module boundary

Not even that, because you can pass data structures from unsafe code at arbitrary depth.

Re: Several core problems with Rust

#273

Post by Capricorn2481 »

Dylan16807 wrote: post #184
Capricorn2481 wrote: post #156

Earlier quoted context omitted.

> Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB. Doesn't mean I think it's…

If changing the safe code causes UB, the actual bug is in the unsafe code.

Nope. I would encourage you to actually read what unsafe does, because nowhere in the Rust docs does it say "scopes bugs to the unsafe block"

See the below code. The unsafe code is doing exactly what it's supposed to. The safe code frees a value while it's being used. This compiles. There's nothing to change here in the unsafe code.

```rust

  use std::slice;
  
  // Unsafe block that creates a slice from raw parts
  fn make_slice(ptr: *const i32, len: usize) -> &'static [i32] {
      unsafe {
          slice::from_raw_parts(ptr, len)
      }
  }
  
  fn main() {
      let vec = vec![1, 2, 3, 4, 5];
      let ptr = vec.as_ptr();
      let len = vec.len();
      
      // Unsafe block creates the slice - this operation itself is fine
      let slice_ref = make_slice(ptr, len);
      
      // Safe code: drop the vec
      drop(vec);
      
      // Safe code: use the slice - CRASH/UB
      println!("{:?}", slice_ref);
  }
```

Re: Several core problems with Rust

#274

Post by adastra22 »

bryanlarsen wrote: post #263
adastra22 wrote: post #250

Earlier quoted context omitted.

It is hard to use because you can’t just access the shared state. You have to annoyingly lock it, handle the guard object, etc. Each one of those layers has protocols.

Of course you have to lock a mutex. You'd have to do that no matter the language, right? And that's what I meant by verbose/ugly. Each of those steps is usually an if let / else error. None of those steps are hard, but you have to do them every time.

Oh, plenty of people access shared state without proper locks all the time. Even experienced developers.

Re: Several core problems with Rust

#275

Post by adastra22 »

saghm wrote: post #262
adastra22 wrote: post #212

Earlier quoted context omitted.

Also the argument with `Arc >>>` boils down to "Rust makes it hard to work with automatic reference-counted shared mutable heap-allocated state." In which case... mission accomplished? Rust just made explicit all the problems that you still have to deal with in any other language, except dealing correctly with all that complexity is such a pain that you will do anything you can to avoid it. Again, mission f#*@ing acc…

> So many times I've tried to do something in Rust the old fashioned way, the way I have always done things, and been stopped by the compiler. I then investigate why the compiler/language is being so anal about this trivial thing I want to do.. and yup, there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time. This is also my experience.…

That’s a very good quote.

There’s a handful of pain points that the Rust model does impart which are not fundamental. For example, unsafe code is required to get a mutable borrow to two different fields of a struct at the same time.

But really that’s the only example I can think of offhandedly, and I expect there are not many in total. Nearly all of the pain is merely the trouble of thinking through these issue upfront instead of kicking the can down the road.

Re: Several core problems with Rust

#276

Post by bryanlarsen »

adastra22 wrote: post #274
bryanlarsen wrote: post #263

Earlier quoted context omitted.

Of course you have to lock a mutex. You'd have to do that no matter the language, right? And that's what I meant by verbose/ugly. Each of those steps is usually an if let / else error. None of those steps are hard, but you have to do them every time.

Oh, plenty of people access shared state without proper locks all the time. Even experienced developers.

Heh. You're pedantically correct, the best kind. I meant "have to" in terms of "for correct operation you must" not "the compiler forces you to" since the latter isn't a thing in some languages.

Re: Several core problems with Rust

#277

Post by a022311 »

lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

> - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow?

Even if you know you're code compiles, it's often easier and faster to validate the logic or complex interactions by running the code. In large (and even not so large actually) projects, debug builds can be painfully slow, even on good hardware. It's important to have a tight feedback loop so that you can interate quickly.

Re: Several core problems with Rust

#278

Post by leoh »

vacuity wrote: post #178
leoh wrote: post #114

>Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. Refactor your build. >It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc >> on every single step directly impacts the quality of the logic bei…

> Refactor your build. People do this, and at best it works for some people. This kind of messaging towards people who bring up a valid criticism of Rust does not help.

Although naively factored builds can be slow on rust, I firmly believe that most folks complaining about this problem have not taken the time to learn how to do this and their builds could be perhaps 10x faster. Bringing this up an important counter-point that all too frequently is ignored or met with hostility, as this replier has done.

Re: Several core problems with Rust

#279

Post by leoh »

Measter wrote: post #244
dana321 wrote: post #233

Earlier quoted context omitted.

It was bad coding. .unwrap() is not required to be used. use: if let Some(value)=something_to_unwrap{ }else{ // log an error and exit!! }

Fun fact: that's what an unwrap does. It panics, which causes the error to be logged and the thread ended.

I think the commenter meant "return a Result" instead of exit. Your snark is perhaps amusing, but not particularly charitable.

Re: Several core problems with Rust

#280

Post by josephg »

tialaramex wrote: post #231
josephg wrote: post #141

Earlier quoted context omitted.

> Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover. I guess its equivalent to Go code like this: value, err := stuff() if err != nil { panic(err) } Or in C: int result = stuff(); assert(result >= 0); If someone wro…

I see what you mean for -> although personally I haven't missed it (I spent many years writing C) I don't write much pointer twiddling in Rust so I'm the wrong person to have an opinion. However surely the aliasing is actually a problem and so MIRI is annoyed because what you wrote might be wrong? If we hang on to (*node).first_next() but somehow node changes, we're no longer talking about the same thing, it's exactl…

> I think my instinct is sympathy for the "Don't write aliases" approach.

Yes, requiring that nothing alias it’s much more conceptually elegant. But as I said, in practice it makes programming extremely treacherous. There are no warnings when you alias. No errors. 99% of the time you’ll get a working program with no bugs every time you build. You’re just - quietly - at the whim of llvm. Maybe it won’t compile correctly on some other architecture. Maybe a minor compiler bump, or different flags, will make your program totally broken. The only way to discover there’s even a potential problem is by running the code through MIRI.

I get why it’s like this but I think it’s a mistake. I think unsafe rust should be at least as expressive and pleasant to work with as C. Having quiet foot guns here seems antithetical to rust’s philosophy of safe ergonomic programming.

Post reply on HN