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

Tell HN: Rust Is Complex

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 102 posts

Re: Tell HN: Rust Is Complex

#51

Post by csande17 »

xiaodai wrote: post #23
Matthias247 wrote: post #22

Yes - Rust can be complicated. However it doesn't have to be. There's nobody forcing you to use Pin. Even async code doesn't do, if you just stick to using library functions, don't write any Future implementation manually and just stick to async-trait. There's even nobody forcing you to use async code. In fact it might be the wrong choice for > 99% of use-cases, since it adds complexity and limits on which functions…

Yes - C++ can be complicated. However it doesn't have to be. There's nobody forcing you to use templates......

C++ can be unsafe. However it doesn't have to be. There's nobody forcing you to use pointers...

Re: Tell HN: Rust Is Complex

#53

Post by csomar »

Last time I remember fighting with Pin was when working with async in Wasm (a single threaded environment). It seemed to me that the complexity justified the cost. Go, for example, is a no-go for Wasm. As a result, I don't think the two languages are comparable.

Re: Tell HN: Rust Is Complex

#54

Post by legerdemain »

2fast4you wrote: post #4
throwawaymaths wrote: post #3

The problem with go is not it's simplicity, it's it's inconsistency . As a small-minded programmer my hobgoblin is tripping over having to remember that X works this way but not Y, which looks vaguely like x. It feels like the designers of go tripped over themselves to make things simple for some definition of simple and then ran into some feature they wanted and then just bolted the feature on without thinking about…

Do you have more examples? I’ll admit that Go is full of weird quirks, but nothing feels bolted on. Generics were agonized over for so long because they had to fit it within the existing language

Rust is full of weird quirks that defenders explain by saying that "the compiler isn't smart enough yet." They often seem like consequences of a "compiler-defined" implementation. One random example -- this compiles and runs:

   #![allow(unused)]
   pub fn main() {
     let mut x = vec![1, 2, 3];
     let y = &mut x;
     let z: &mut _ = y;
     println!("{:?}", y)
   }
This does not:

   #![allow(unused)]
   pub fn main() {
     let mut x = vec![1, 2, 3];
     let y = &mut x;
     let z = y;
     println!("{:?}", y)
   }

Re: Tell HN: Rust Is Complex

#55

Post by samsquire »

I think I need someone to explain Rust async to me.

I think I understand that await causes the half of function to be rewritten into a state machine that returns immediately to caller and the promise object implements the rest of the control flow.

I don't understand waiters, pollers.

Re: Tell HN: Rust Is Complex

#56

Post by afdbcreid »

legerdemain wrote: post #54
2fast4you wrote: post #4

Earlier quoted context omitted.

Do you have more examples? I’ll admit that Go is full of weird quirks, but nothing feels bolted on. Generics were agonized over for so long because they had to fit it within the existing language

Rust is full of weird quirks that defenders explain by saying that "the compiler isn't smart enough yet." They often seem like consequences of a "compiler-defined" implementation. One random example -- this compiles and runs: #![allow(unused)] pub fn main() { let mut x = vec![1, 2, 3]; let y = &mut x; let z: &mut _ = y; println!("{:?}", y) } This does not: #![allow(unused)] pub fn main() { let mut x = vec![1, 2, 3];…

In my experience, this quirks don't appear in real life (at least unless you do bunch of trait metaprogramming). One exception is async code, since it stretches the type system you are far more likely to enter some obfuscated lifetime or trait error.

That being said, I was quite surprised this doesn't compile... (I understand why, but I expected the compiler to have all required information to perform reborrowing).

Re: Tell HN: Rust Is Complex

#57

Post by afdbcreid »

2fast4you wrote: post #5
RcouF1uZ4gsC wrote: post #2

Question: How much of Rust’s type system complexity is due to async? It seems Pin is mostly related to async and the official examples for GAT are for async. Given the complexities of async and how other alternatives such a Java Loom’s virtual threads, in about 10 years I am not sure that we won’t see Rust going all in on async as a mistake.

Since we’re comparing Go and Rust, I think Go really nailed it with goroutines and channels. It’s much easier to get your head around than async.

I don't think this is right. To me at least JS's promises and C#'s async/await are as easy as Go's goroutines. The problem with Rust is the effort to make everything static and without heap allocations, which is understandable but enforce really hard-to-grasp design. On the other hand, you can get rid of most issues of async even in Rust by boxing.

Re: Tell HN: Rust Is Complex

#59

Post by scoutt »

Cloudef wrote: post #39
allisdust wrote: post #38

Earlier quoted context omitted.

It's a RWLock. Not a mutex. As long as no one is writing to it, readers are not blocked.

I know, but the RWLock itself also did not work. Complaining about safety and the only solution seemed to wrap the value itself into mutex inside rwlock. If I still had to go back to this, I would just write the function in C and go from there. Rust is productive when you can work with the highest level of abstraction and when it can copy values freely. When you want to work with copy-free or shared memory, is when r…

I feel your pain as I started to learn Rust recently (again) and found the same problem, coming from C.

In my case, after fighting for literally days, the crate OnceCell did the job (kind of), but I felt awkward retorting to an external crate to deal with a simple static-global-initialize-once-never-touch-again piece of data.

Re: Tell HN: Rust Is Complex

#60

Post by cyber_kinetist »

atoav wrote: post #47

I get the sentiment, but one thing that probably needs to be underlined here is that one only needs to face that complexity if you really want to, however. Otherwise you can just wrap everything in Arc, Cow and similar helpers and call it a day. Even lazy Rust code can still be incredibly performant, testable and fault tolerant. The lower level you go, the more you need to know about Rust and how what it does maps to…

> Otherwise you can just wrap everything in Arc, Cow and similar helpers and call it a day.

… which is how we got slow, bloated legacy C++ codebases today, should we make the same mistake with Rust? If you are wrapping everything in ref-counted smart pointers it might probably be better to just use a garbage-collected language like Java or C# instead…

Post reply on HN