Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

21–30 of 811 posts

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

#21

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…

> If you can avoid async I would recommend doing so. The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO that haven't switched over.

Yes. I've been complaining about async contamination for some time. I'm writing heavily threaded code, with threads running at different priorities, and libraries which want async get in the way.

If you look at the poster's example, the "Arc" version is very close to the Go version. And if it didn't use "async", it would be even closer.

Go's green threads simplify things. It's real concurrency; you can block. But there are times when you have to lock.

As I've said before, if you're writing webcrap, use Go. The libraries for web-related stuff are stable and well-exercised, since Google uses them internally.

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

#22
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…

What about a transpiler that added a ^ operator that made a variable actually an Arc and inserted unwraps, clones, etc as necessary?

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

#23
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…

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

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

#24

Unpopular opinion: I find rust code unreadable. And I consider myself a polyglot. I am sure all those symbols have a special meaning but it's like perl to me. Just throw some random special characters and they all mean something.

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 to go back to the git history to remember what it was I had planned to do next.

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

#25
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 think that's ocaml. Higher level, with GC, nice type system, no traits but signatures and higher order modules might be enough for you, and a compiler that produces fast native binaries.

I think you are pretty spot on here. I write Rust and Haskell most of the time, where the choice depends on the kind of project I'm working on. Also I've written Rust professionally but Haskell has been confined to random hobby projects.

I love Haskell but it has its own flavor of problems. I've meant to brush up a bit on OCaml; I've heard it has interesting features in its module system that Haskell does not have (maybe what you call "higher order modules").

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

#26
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 think some aspects of ownership are useful, e.g. move semantics and mutable/immutable references. withoutboats had a good post about a Rust-with-ownership-and-GC language a while back: https://without.boats/blog/revisiting-a-smaller-rust/

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

#27
post #3

Rust isn't hard. Programming is hard. Rust just points out failure states before you encounter them in production.

I enjoy Rust, but it's not that simple. It really is more work to accomplish certain tasks in Rust than many other languages even when what you're doing is safe. The narrative that "Rust isn't hard" is getting tiresome, and I say this as someone who writes a lot of Rust. Let's be honest that Rust can be harder than many other programming languages in many ways, but those of us who use it believe the upsides and trade…

I'm in the same boat, I spend a bit of my working day writing in Rust .. it's a great language but it's very cumbersome and I find it suffers form poor ergonomics, like it's annoying to type

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

#28

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 arriving at this conclusion. Once you know the pitfalls you can navigate around them, but I hit a lot of dead ends along the way.

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

#29
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…

Try D it has most features that you just described. It feels Phytonic and it's GC by default[1].

There is an ongoing work for borrow checker for D language, and pardon the pun but I believe D is borrowing just the right amount features from Cyclon and Rust for safer compiled software without overly complex programming syntax.

[1]Origins of the D programming language:

https://dl.acm.org/doi/abs/10.1145/3386323

Post reply on HN