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

141–150 of 811 posts

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

#141

Post by d3nj4l »

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.

I cannot, for the life of me, recommend Elixir enough! You write your code without every thinking of words like "async" or "await" and the VM handles it for you!

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

#142

Post by 0des »

bobbylarrybobby wrote: post #111
0des wrote: post #24

Earlier quoted context omitted.

Perl did nothing wrong, but I echo the sentiment you have about Rust. Last year I ported a mid size internal project to it as part of a resolution to learn a new language and the experience left me feeling like it was just me who "didnt get it". Building things took a lot longer, not just in the amount of code, but also the compile time. Ultimately compile time was the dealbreaker. On more than one ocassion I'd have…

Rust pro tip: don't compile til you're really done. Use something like cargo check or rust-analyzer to quickly spot errors without wasting time on the rest of compilation.

Thanks for the tip

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

#143

Post by 0des »

rfiat wrote: post #101
0des wrote: post #23

Earlier quoted context omitted.

Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC

It's interesting that you find Go to be Rust-adjacent. Setting aside the USPs of each language (goroutines and borrow checker respectively) and just speaking about the general experience of writing code, I find Go painful for all the reasons that I find Rust pleasant. The best summary I can give of Rust is that it was designed by people who learned from the mistakes of the programming languages that came before it. T…

It's like my favorite John Quincy Adams quote, "It is what it is, and it ain't what it ain't" Different strokes for different folks you know? At the end of the day if folks code at all, and it makes them happy, that's a good thing.

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

#144

Post by giraffe_lady »

crabbygrabby wrote: post #96
eternalban wrote: post #82

Earlier quoted context omitted.

Rust and Python sit at almost extreme opposite ends of programming paradigms. The question on the table remains if the excessive complexity of the Rust language is factually worth the pain.

If you need performance, compiled binaries, etc then yea it sure can be worth it. In some cases you don't have a product if you can't get the performance to reach a certain level. In other cases you spend a lot more money tracking bugs in production that rust just doesn't allow to happen in the first place. Every project has different priorities, some projects don't need rust at all, some greatly benefit from it. The…

ocaml though? it's got plenty of gnarly symbols bc obviously we love that shit plus is safe enough and only a modest pain in the ass to write.

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

#145

Post by Hirrolot »

cmrdporcupine wrote: post #69

I've been doing a lot of Rust the last two weeks. Like others have said, if you stay away from async, it's not that bad. But I also have plenty of experience in OCaml and Standard ML and Scala, and also C++. Still, I'm finding my C++ experience is more hindrance than help most times. Async & Tokio is pure hell if you have any kind of shared mutable state. And also it's tough to fight 20-30 years of programming experi…

> Rust can work this way, but mostly doesn't by default. It's like you were programming in C++ but instead of normal copies and references, almost every single variable use was a std::move. Profoundly unintuitive. I just used this variable, why can't I use it again?!

You just need to get used to it, really. As you've noted, it's about our habits. The ownership model makes perfect sense after some experience in Rust, unlike that stuff with asynchronous programming.

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

#146

Post by SuperQue »

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.

Go is the prime example.

For example, in your typical web application a Goroutine is spawned for every incoming connection. This basically gives you a dedicated runtime for each simultaneous connection. In Node or Python, this would be the equivalent of starting a whole new process for every request. But in Go, there's very little cost to doing it this way.

The advantage is that each connection basically never blocks waiting for another user.

In Node and Python, we talk about handling tens to hundreds of requests per second per server.

In Go, we talk about handling thousands to tens of thousands per second. It's just orders of magnitude more throughput.

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

#147

Post by Hirrolot »

throwaway23342 wrote: post #67

Async rust isn't pretty. If you are using async rust, and want to borrow data, use an Arc . In fact, if you ever use tokio::spawn, you will have to use Arc anyway because it requires 'static lifetime.

True about 'static. Sometimes I think I need an IDE shortcut for `Send + Sync + 'static`.

Like `if err != nil`, you know :))

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

#148

Post by tialaramex »

koyote wrote: post #47

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?

For me the notable difference is that the Rust compile errors are almost always about the problem I actually have.

They can be quite verbose, but that's largely from showing me what the problem is exactly. e.g. Rustc will show you where you borrowed X and then where you tried to modify it after forgetting it was borrowed, not just go "You can't do that, it's already borrowed" and expect you to figure out where and how or fly into a rage because you're sure you didn't borrow it.

The error[E0308] mismatched type message with a type whose name repeats itself several times is a bad sign, yeah, you probably should not make a type like that. But most of the rest look like helpful Rust errors to me.

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

#150

Post by rascul »

eternalban wrote: post #123
crabbygrabby wrote: post #96

Earlier quoted context omitted.

If you need performance, compiled binaries, etc then yea it sure can be worth it. In some cases you don't have a product if you can't get the performance to reach a certain level. In other cases you spend a lot more money tracking bugs in production that rust just doesn't allow to happen in the first place. Every project has different priorities, some projects don't need rust at all, some greatly benefit from it. The…

You are basically asserting that performance & correctness are beyond the reach of developers who build systems in other languages. So based on this I suppose all systems developed in other languages are either performing subpar and/or are incorrect? "Is the pain worth it" is the question. My 42 years of professional development tells me the answer is no. (I lean towards programming pleasure and not pain). YMMV.

I think the idea is that performance and correctness are easier to achieve with rust. Once you get over the initial mountain of learning. The mountain is a different height for each person.
Post reply on HN