Rust Is Hard, Or: The Misery of Mainstream Programming • Hacker News Board

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

#181

Post by galangalalgol » Fri, Jun 03, 2022, 4:28 AM UTC

xyzzy_plugh wrote: post #161

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…

You hit the nail on the head, at least for me. I've found Go to be the right sweet spot between efficiency and productivity. I can't get anything done in Rust. My worst enemy is myself.

I like the thick stdlib in go, but it feels a lot slower even than java. The thin stdlib and giant dependency trees is my primary complaint with rust. I like most of the syntax, but async is not my threading style, I mostly use fine grained threads like rayon provides. I'm currently more excited about julia though. Same dependency hell, but super fast and flexible, and the code looks good.

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

#182

Post by jandrewrogers » Fri, Jun 03, 2022, 4:30 AM UTC

bombela wrote: post #93

megous wrote: post #79

Earlier quoted context omitted.

Re: fearless concurrency... Would Rust prevent you in general from writing code that could deadlock, btw? Thread1: takes lock A, ..., tries to take lock B Thread2: takes lock B, ..., tries to take lock A Looks like you should be able to pass Mutex and Mutex to both threads otherwise what's the point of mutex if there's no way to share data protected by it, so it doesn't look like it prevents you from hitting this sce…

Rust doesn't protect you against deadlock. I wonder if it is similar to the halting problem. Can deadlocks even be prevented in theory?

Yes, deadlock-free lock systems are an ordinary part of OLTP database engines. They don't prevent deadlocks per se so much as detect them and dynamically resolve them.

The mechanism is costly but elegant. If a lock you are trying to acquire is owned by another thread, you inspect the locks you own to determine if that thread is waiting on one of your locks. When a deadlock is detected, there are several strategies to automatically resolve it e.g. rolling back one of the threads to a point where forward progress can be safely serialized.

No one wants to use these mechanics for ordinary code, due to their cost. For the fashionable thread-per-core software architectures, deadlocks aren't something you commonly have to worry about.

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

#183

Post by bpye » Fri, Jun 03, 2022, 4:36 AM UTC

anonymoushn wrote: post #168

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…

never allocating memory can be and should be simple.

What language actually makes it simple?

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

#184

Post by rdedev » Fri, Jun 03, 2022, 4:40 AM UTC

jmprspret wrote: post #51

nullcipher wrote: post #7

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.

I completely agree. I think the syntax looks awful, for one. This has put me off learning it completely.

I had that same issue but got over it once I started diving into rust. What really helped me are the compiler error messages. Without that i would have given up learning it

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

#185

Post by jnash » Fri, Jun 03, 2022, 4:47 AM UTC

aphexairlines wrote: post #17

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

Yep ocaml seems to be a perfect balance of all the best of other languages.

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

#186

Post by rob74 » Fri, Jun 03, 2022, 4:48 AM UTC

jen20 wrote: post #180

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.

I’d agree they’re at opposite ends of the complexity spectrum: it’s very difficult to write a moderately complex python program which uses even a single dependency and is bug free, then deploy it to the machine of a non-technical user. Rust meanwhile excels at this task. Oh wait, that’s not what you meant?

In Python, "it’s very difficult to write a moderately complex program which uses even a single dependency and is bug free" - whereas in Rust, it's very difficult to write pretty much anything, but if you manage to do it, it has less bugs, (and being a single binary, is easier to install - but you don't need Rust for that)?

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

#187

Post by jnash » Fri, Jun 03, 2022, 4:48 AM UTC

birdfood wrote: post #35

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've bounced around a few languages this year, looking for a language to use in my spare time for fun / enjoyment / skills growth (I have a similar set of criteria to you). I've looked at rust, swift, haxe, zig, and now nim, and I think I'll be sticking with nim. I like that it's seemingly simple, and takes care of memory management for you, but you still have access to pointers if you want them and can extend the la…

Try ocaml or F#. I did the same as you and was surprised how well balanced ocaml/F# are compared with everything else.

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

#188

Post by jjtheblunt » Fri, Jun 03, 2022, 4:52 AM UTC

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…

> There are almost no active / popular libraries related to network IO that haven't switched over.

wouldn't Go afficianados say Go is a counterexample right under every Rust programmer's nose?

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

#189

Post by noisy_boy » Fri, Jun 03, 2022, 4:56 AM UTC

api wrote: post #140

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…

Rust is like C++ in the following way: it has many features and a complex type system, but that doesn't mean you should use all its features all the time! Dancing around with lifetimes can be premature optimization. Yes you can write very efficient code that way but if you find yourself spending tons of time fighting the borrow checker you might be overdoing it. I tend to use Arc a lot in async code. It makes things…

> Rust is like C++ in the following way: it has many features and a complex type system, but that doesn't mean you should use all its features all the time!

I have come to the same opinion about Scala. Stick to the basics (i.e. the Scala Book[0] and doesn't even have to be all of it) and it is a joy to use.

[0]: https://docs.scala-lang.org/scala3/book/introduction.html

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

#190

Post by jandrewrogers » Fri, Jun 03, 2022, 4:57 AM UTC

jeroenhd wrote: post #53

PragmaticPulp wrote: post #9

Earlier quoted context omitted.

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…

Rust isn't hard for the things you try to solve in Rust. The author compares Rust code with Go code. Those two languages serve entirely different purposes, with entirely different mechanisms behind it. Go does what the author does with ease because the runtime fixes all the complicated parts for you. You tell Go what you want and it'll try to solve all the memory management/threading/memory safety issues for you, usu…

In fairness, for the kind of software that C++ is particularly suited, the idiomatic software architecture is thread-per-core, which has the distinction of being almost entirely single-threaded at the code level. Race conditions aren't a meaningful concern because data virtually never crosses thread boundaries. The bigger issue, particularly and mostly for C code, is object lifetime management.

If maximum performance, whence thread-per-core architectures originate, is not the objective, then GC languages start to become more attractive and C++ may not be the right tool for the job. And in those cases, Rust may not be either.