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

201–210 of 811 posts

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

#201

Post by infogulch »

charlieflowers wrote: post #163
infogulch wrote: post #129

Earlier quoted context omitted.

I don't understand. What about this thread would make you fear running rust? Fear of learning a solution to rusts memory model, and 'fighting with the borrow checker' as they say -- sure. But rust never claimed that you wouldn't have to climb a steep learning curve, it claims that if you do make it up then the result can't hurt you due to a memory fault. So "fallen from the light" seems a little overdramatic.

IMO fallen from the light sounds spot on (not gp). I’m shocked to hear the state of async from real practitioners saying to avoid it.

"fallen from light" would mean breaking it's safety promises. No promises have been broken, the async developer experience is just less than a silver bullet and needs a lot of work. If you're so disappointed by that fact that you'd say rust has "fallen from light" then you've not been paying attention at all or your expectations need serious calibration.

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

#202

Post by DeathArrow »

Hirrolot wrote: post #169
mwcampbell wrote: post #156

Earlier quoted context omitted.

> So much of this pain is caused by premature optimization. Part of the problem is that Rust itself has such lofty aspirations to do it all (particularly "abstraction without overhead"), and is largely successful at that. So if I compromise on efficiency, it feels like my code is unworthy of the language it's written in. Also, it's easy to feel that the slightest inefficiency puts us on a slippery slope to the bloat…

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.

>This is why I think we need a high-level, no-BS version of Rust.

F# to the rescue. :)

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

#203

Post by accountofme »

jacksnipe wrote: post #46
Waterluvian wrote: post #38

Earlier quoted context omitted.

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”.

Fearless concurrency in respect to threading .... Not async

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

#204

Post by lmm »

Hirrolot wrote: post #165
duped wrote: post #99

Earlier quoted context omitted.

The last thing I would take away from async/await in Rust is that it's "half baked." It's incredibly deeply thought out with years of RFCs, great contribution work that required both low level implementations in nightly and creating extensions to the memory model, and extensive bike shedding and discussion with the community on surface APIs.

async/.await in Rust is a perfect example of "code duplication" in the language core. Okay, you have a nice syntax for performing do-notation on futures, but what about iterators, streams, etc? We have generators in nightly and some third-party macros for streams, which sucks. A proper algebraic effect system could resolve the problem. You can take a look at Koka to see how elegantly it abstracts common control flow…

Algebraic effects are still a research area - no mainstream language has them fully working - but basic Haskell-style higher-kinded types should not be so much of a stretch, and are a necessity if you want reusable libraries for this kind of stuff.

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

#205

Post by sideeffffect »

azemetre wrote: post #43
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.

Scala. With the functional effect systems, like Cats Effect or ZIO, you get superpowers.

Not only can write programs that are "async", but you also get easy retries (and other tricks), safe refactorability (because of its Pure FP nature), reliable and painless resource management and some other goodies like STM (Software transactional memory).

It's really that good.

https://www.youtube.com/watch?v=qgfCmQ-2tW0

https://zio.dev/

https://typelevel.org/cats-effect/

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

#206

Post by lelanthran »

jen20 wrote: post #176
Hirrolot wrote: post #169

Earlier quoted context omitted.

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.

Which parts of Rust would you give up to make this happen? And how would this be implemented?

> Which parts of Rust would you give up to make this happen? And how would this be implemented?

Traits, maybe? Switch to an OO model more closely aligned to what the majority of developers understand. Dump all of the line-noise-type syntax.

My Own Toy Language (ComingRealSoonNow)^tm that I started designing had exactly one goal - prevent the majority of memory errors, not prevent ALL memory errors. All I wanted was to indicate when/where an object will be destroyed/mutated. That's enough for me.

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

#207

Post by klabb3 »

nemothekid wrote: post #72

I've been doing async Rust since the tokio 0.x combinator days, and I remember being like OP. For some reason `Arc` did not exist in my mind and it was a struggle appeasing the borrow checker. The Go version is similar to the final Rust version; except the Go version is forcing you to use Arc everyone[1]. Seriously, just use Arc (or Arc >), in 70% of cases you are wrestling with the borrow checker trying to do someth…

"If you can't handle me at my BoxFuture, Arc> and #[async_trait], you don't deserve me at my zero cost abstractions and fearless concurrency."

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

#208

Post by kenhwang »

mwcampbell wrote: post #156
ekidd wrote: post #60

Earlier quoted context omitted.

> 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. Even in regular Rust, trying to get too clever with lifetimes can cause serious pain. The usual culprit is complex code that tries to never allocate memory. "Oh, well this closure borrows this parameter from the parent function, and then stores a…

> So much of this pain is caused by premature optimization. Part of the problem is that Rust itself has such lofty aspirations to do it all (particularly "abstraction without overhead"), and is largely successful at that. So if I compromise on efficiency, it feels like my code is unworthy of the language it's written in. Also, it's easy to feel that the slightest inefficiency puts us on a slippery slope to the bloat…

I just tell everyone, just write Rust like you'd write Scala. Don't try to optimize the crap out of anything until you need it, especially if no one else is going to use your code.

Just make the allocations.

Even if you write it that way it's still significantly more performant and lightweight than the alternatives without much loss in productivity.

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

#209

Post by pjmlp »

Hirrolot wrote: post #196
jen20 wrote: post #176

Earlier quoted context omitted.

Which parts of Rust would you give up to make this happen? And how would this be implemented?

Hide memory management under a language runtime. Make a single Fn trait/string type instead of multiple ones. Add effect polymorphism to deal with function colours. Remove async/.await and express it using algebraic effects, do the same for streams and iterators. How it'd be designed and implemented is probably a theme for a separate blog post, not a HN comment.

So basically OCaml.

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

#210

Post by SquibblesRedux »

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 do wish async would go away and never come back -- in every language. Some days I long for the NMI: non-maskable interrupt.

I have been coding since the late 70s -- the latter half of the last century. After all I have seen, async feels wrong.

Post reply on HN