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

81–90 of 811 posts

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

#81

Post by 3np »

gregwebs wrote: post #75
azemetre wrote: post #43

Earlier quoted context omitted.

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.

Haskell has always been the best. Go's did the same as Haskell. In either case IO is automatically async. If you want concurrency you create very light weight threads. This approach works very well for most use cases, but when you want the best performance possible the light weight threads can still be too much. Zig is going for a lowest possible overhead approach like Rust but has an interesting take: https://kristo…

Are you sure you are talking about Haskell and not Erlang? I'm not aware of how Haskell IO would be "automatically async".

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

#82

Post by eternalban »

mynameisash wrote: post #45

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 pa…

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.

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

#83

Post by FpUser »

crabbygrabby wrote: post #74
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…

This is good advice. Write simple code first. Another generic thing I've come across is, "if the borrow checker is screaming at me when I hit a patch of code, I probably have a design flaw not a programming problem". I've seen a lot of new people also prematurely over generalizing code. I know it sounds terrible to say, but if you probably aren't going to reuse it, you really don't have to prepare your code base just…

>"if the borrow checker is screaming at me when I hit a patch of code, I probably have a design flaw not a programming problem".

This reminds me: "you are holding it wrong"

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

#84

Post by Starlevel001 »

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 find Rust easier to read in a real IDE with semantic highlighting (although the IntellIJ plugin constantly breaks this) and inlay type hints so that everything doesn't end up blurring together.

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

#85

Post by ericbarrett »

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?

Yes, Arc for structured data passed between threads, atomics for smaller things like counters job queue length. Of course the fastest synchronization primitive is nothing at all :)

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

#86

Post by FpUser »

cmrdporcupine wrote: post #66
Animats wrote: post #21

Earlier quoted context omitted.

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

I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…

>"I don't understand why so many people lately seem to want to use Rust for web domain stuff."

>"Rust is the new C++. Let's just stick with that."

I write "web domain stuff" in C++ and it is incredibly easy (well for me at least). In C++ I could always use my own styles / paradigms / patterns etc. etc. Not forced to any particular way. And modern C++ is incredibly safe if one wishes.

So if it is bad idea to write "web stuff" in Rust it means it is anything but new C++

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

#87

Post by jerf »

crabbygrabby wrote: post #76
cmrdporcupine wrote: post #66

Earlier quoted context omitted.

I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…

Why? Because it's stupid fast, fast means serving an order of magnitude or more clients before requiring scale up. Scale up means $. No stop the world GC time situations, etc. That's basically it. To be fair, I usually prefer to use go as well, lately though rust is more appealing.

Rust does not in general have an order of magnitude advantage over Go. 2 or 3 would be closer, and that's with some nontrivial attention paid to optimization, not "you write Rust and it's automatically always faster".

Super high-end stuff can outclass Go by that much, like if you're seriously using DPDK or something, and in those cases I strongly recommend Rust over Go. There some other noches like that. But in general, it's not a factor of magnitude.

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

#88

Post by estebank »

FpUser wrote: post #83
crabbygrabby wrote: post #74

Earlier quoted context omitted.

This is good advice. Write simple code first. Another generic thing I've come across is, "if the borrow checker is screaming at me when I hit a patch of code, I probably have a design flaw not a programming problem". I've seen a lot of new people also prematurely over generalizing code. I know it sounds terrible to say, but if you probably aren't going to reuse it, you really don't have to prepare your code base just…

>"if the borrow checker is screaming at me when I hit a patch of code, I probably have a design flaw not a programming problem". This reminds me: "you are holding it wrong"

In industrial machines, there's such a thing as holding it wrong. In some cases, that means getting maimed (that old-school table saw doesn't care whether it chews on wood or flesh) or precluded through a clunkier mode of operation (you need to press these two buttons separated at roughly arm length to make sure that they can't be actioned while you have an arm in the way of the heavy arm-eating chunk of metal). The former is C and unsafe Rust, the later is safe Rust and GC languages.

You're trying to draw a comparison with a consumer product with a design flaw.

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

#89

Post by taneq »

yeputons wrote: post #15
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 care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an…

I feel this fact is grossly underappreciated. Caring about speed and correctness but not ownership and lifetimes (and thread safety and race conditions and...) is like caring about road safety but not caring about headlights. You're not avoiding ownership and lifetime problems, you're just avoiding looking at them.

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

#90

Post by crabbygrabby »

cmrdporcupine wrote: post #78
crabbygrabby wrote: post #76

Earlier quoted context omitted.

Why? Because it's stupid fast, fast means serving an order of magnitude or more clients before requiring scale up. Scale up means $. No stop the world GC time situations, etc. That's basically it. To be fair, I usually prefer to use go as well, lately though rust is more appealing.

I mean, there's no world in which my personal tastes wouldn't prefer Rust over Go -- I quite dislike writing Go. But as an engineer it is my responsibility to use the right tool for the job, not pick tools based on my tastes or gut feelings. There's different kinds of fast. For most kinds of fast that people doing 'web' type things need, a garbage collector and a VM are not going to be the bottleneck. Efficient manag…

Yea it's hard to say without context, I just gave the generic answer. I'm not sure you ever 'need' a garbage collector, and if avoiding one lets me save 20k in cloud expenses a year on a small team, it's probably worth it, because after scale out 20k isn't 20k anymore.

That said, people misuse technology all the dang time(I've done it). And in general I agree, Go is usually enough and has the best cloud ecosystem. I've had trouble with large go code bases exploding over time and requiring a lot of bodies to maintain compared with rust/scala.

Sometimes it's hard to speculate when one tool is clearly better than another. Some companies just want to use new stuff to sound cooler...

Post reply on HN