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

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

Post reply on HN
Print view View original

41–50 of 811 posts

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#41

Post by epage »

the_duke wrote: post #12

Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…

> This isn't because no one cares, but because Rusts async implementation (which is very cool due to it's low overhead) and it's interactions with the other language features require complicated extensions to the type system. It does seem to me like there might be a lack of resources/coordination/vision ever since the Mozilla layoffs, but that's a different topic.

I wonder how much technical debt is slowing things down. It seems like we keep hitting a breaking point where we'll finally be forced onto polonius and chalk but people keep finding ways to extend the existing implementation to make things work, kicking the can down the road.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#42

Post by dhosek »

the_duke wrote: post #12

Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…

I might be (probably am) missing something, but for the use case described, it seemed odd to me to have borrowing come into play at all. I would think that rather than a borrowed reference with a lifetime, the dispatcher could just consume the object coming in. The term “moving” is a bit misleading in that it carries with it an implied heavyweight operation that likely doesn't come into play at all.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#43

Post by azemetre »

the_duke wrote: post #12

Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…

In your experience what languages would you say handle async well? Genuinely curious. I’ve only ever done JS professionally for a decade but started branching out into python, rust, and kotlin due to personal projects.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#44

Post by lumost »

PragmaticPulp wrote: post #28
the_duke wrote: post #12

Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…

> To be clear: using async is fine if you know what you are doing, and it can provide incredible performance. But if you do, keep it simple: avoid lifetimes and most importantly: don't attempt advanced trait shenanigans - if you do need traits, just returned BoxFutures without lifetimes, throw in lots of Arc >, clone() and call it a day. It seems like everyone doing async Rust goes through a long journey before arriv…

Anecdotally, this is the pain felt most across the entire rust language. There are more ways not to do something than to do something. This makes it hard for beginners to pickup, and difficult for projects to scale on.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#45

Post by mynameisash »

I started picking up Rust a bit over two years ago, and it was HARD. I didn't have teammates who knew it to help me out, so I used community resources (/r/rust, exercism.io, etc.) I'm still not great with the language, but I'd say I'm about as proficient in it as anything else. The progress is slow enough that you find many more opportunities to quit, but once you do become productive, I think the hard work really pays off.

I've written before about some of my woes in taking a service to prod with mostly Python code. It was easy to write and get running, but then it had all sorts of errors that were basically impossible to detect until runtime. Kind of a nightmare to maintain. Transitioning it to Rust was a lot of work, but I've literally only had one error that I had to fix, which was caused by my faulty assumption about incoming data that I simply `.unwrap()`ped.

I initially was interested in Rust for the promises of higher-performance, lower memory footprint compute, and that is a great aspect of it. But the correctness guarantees that I've experienced make all the hard work I went through absolutely worth it.

Sure, it would be great if the learning curve was less steep. But that doesn't mean the hard work isn't worth it.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#46

Post by jacksnipe »

Waterluvian wrote: post #38
ericbarrett wrote: post #34

Earlier quoted context omitted.

Completely agree. I wrote a multithreaded compute-heavy program in Rust, semi-ported from a C++ version, and sidestepped async completely—just used old school thread primitives. It was delightful! Once I sorted out the data structures and messaging, the borrow checker and Send/Sync traits made implementation nearly trivial, and absolutely no memory corruption or accidental non-atomic clobbering. It took a bunch of ho…

I’m a Rust newbie. Mind if I ask: are you referring to using threads and locks and queues and such? Does Rust give you rope to hang yourself when doing it without async or does it continue to be very specific about forcing you to guarantee that you’re not going to run into races and whatnot?

Oh my god we’ve strayed so far from the light T_T

Once upon a time, the whole promise of Rust was “fearless concurrency”.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#47

Post by koyote »

As someone that has only dabbled in Rust, the post reminds me of C++ and its mind-boggling templating system. Rust even seems to provide you with the multi-page compile errors.

Is it really as bad, or does the post only highlight the misery you get when you're working on the fringes of what the language is capable of doing?

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#48

Post by crabbygrabby »

Patrol8394 wrote: post #30

I am fluent in C/C++, Java, Scala. I really wanted to like Rust, but it is hard. The borrow checker is hard and the language api is not intuitive and/or ergonomic.

In my opinion, easy rust is easy, hard rust is hard. A lot of people take for granted how hard some things are to do correctly until they are asked to do them correctly. Not saying this to put you down, we all struggle with this until we get over the hump.

My best advice for loving errr learning rust is put it aside for a few weeks after being annoyed with it. Survey some other language like idk Haskell, then try it again.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#49

Post by inChargeOfIT »

adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

I really like the idea of something like vlang (https://vlang.io), as I've tried multiple times to find the motivation to learn Rust, but always end up going back to golang for the simplicity.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#50

Post by sprkv5 »

adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

OCaml[1] is what you are looking for. You also might want to look at Roc[2], even though that's not released yet.

1. https://ocaml.org/ 2. https://www.roc-lang.org/

Post reply on HN