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

271–280 of 811 posts

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

#271

Post by mmarq »

SuperQue wrote: post #139
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.

The problem is there is more than one kind of "fast". There is latency "fast" and throughput "fast". For a lot of web stuff you need throughput more than you need latency "fast". In order to do throughput well you need concurrency.

There’s also how much it takes to hire 5 developers ”fast”. At least for now, Rust is not that performant on that respect.

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

#272

Post by Gigachad »

tmcw wrote: post #170

The author is 17 and writing code (and posts) at this level? The kids are all right.

Some people are just so ahead of the average. I thought I was pretty good knowing the basics of Rails/Databases at that age, but I was no where near the level of writing coherent posts on languages.

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

#273

Post by ncmncm »

mikebenfield wrote: post #237
DeathArrow wrote: post #199

>So why Rust is so hard? Rust is a systems language. To be a systems PL, it is very important not to hide underlying computer memory management from a programmer. For this reason, Rust pushes programmers to expose many details that would be otherwise hidden in more high-level languages. Examples: pointers, references and associated stuff, memory allocators, different string types, different Fn traits, std::pin, et ce…

To me C++ is much, _much_ harder than Rust. Maybe in C++ it's easier to get a program to compile, but it's dramatically harder to make sure you've checked all the boxes you're supposed to check to make sure your code is safe and complies with best practices. For instance, consider the rules of 5 [1]. There are so many rules like this in C++, so much complicated stuff you're supposed to know to write anything at all,…

Rule of 5 was a C++11 thing, maybe even mainly a C++03 thing.

Your complaints about C++ have aged badly. C++20 is not the same language as C++11, which was not the same language as C++03.

Rust's complexity is rapidly approaching C++'s. In 5 years, if Rust hasn't fizzled, it will get there. Only being used to it will make it seem any simpler.

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

#274

Post by orangetuba »

VWWHFSfQ wrote: post #8

I've been programming in Rust for the last few years. My daily work is mostly just fumbling through compiler errors until the code works. Some observations: - The compiler is always right. - Do what clippy and rust-analyzer says. Don't ask questions. - If you're fighting the compiler, clippy, AND rust-analyzer, then you're almost definitely wrong. Virgins try to use &str everywhere. Chads just use String.

I wonder what approach acts as the best mentor for someone who wants to eventually develop a good mental model for how systems work. The C approach where you suffer at runtime and then have to debug ferociously, or the Rust approach where your mentor hits you with a stick all day?

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

#275

Post by HacklesRaised »

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

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

#276

Post by ncmncm »

Diggsey wrote: post #18
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…

Writing widely useful, performant, reusable, correct and stable libraries is very hard. Rust is the easiest language to do that in. If someone says programming in another language is easier, it's because they are not attempting (or are failing) to do one or more of those things. Those things are not always important so that's fine, but a lot of programmers (myself included) have this dream of being able to solve a pr…

> Writing widely useful, performant, reusable, correct and stable libraries is very hard.

Correct.

> Rust is the easiest language to do that in.

Wrong.

Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down.

Rust might get more of what C++ offers library designers as it matures, but only at the cost of whatever simplicity it can still claim.

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

#277

Post by Twisol »

viktorcode wrote: post #254

I never got the point of having borrow checker in a single-threaded environment. Can someplace please explain its usefulness to me in that scenario?

The borrow checker statically prevents having mutation and aliasing at the same time. Aliasing is when two names refer to the same state; mutable aliases make it possible for "someone else" to act on that state while you're using it.

Consider the humble for-each loop:

    for (let x : xs) {
      xs.remove(0);
    }
If you're not careful, modifying a collection while you're traversing it can cause you to visit elements multiple times, or skip some elements entirely. There are effectively two tasks occurring at the same time -- interleaved, not parallel, but still concurrent: the ordered traversal and the action on each element. Both tasks can view the list, but one of them also modifies it behind the other's back.

This problem simply can't happen in Rust (without going out of your way, at least), because you can't independently mutate a list you're already iterating over.

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

#278

Post by timClicks »

HacklesRaised wrote: post #275

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

No, it really is wonderful once you make it. Which resources have you used to learn?

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

#279

Post by Animats »

brabel wrote: post #242
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. Rust is normally used only when high performance is of uttermost importance, so it will always attract people who want to optmise everything. > Most of the time, the solution is to be less clever I've done it myself and saw performance degrade, as was expected. That's fine, but by that point you might as well just use another language that has none of the ha…

> Rust is normally used only when high performance is of uttermost importance, so it will always attract people who want to optimise everything.

Which is not the way to do things. Profile, then optimize.

I'm writing a metaverse client that's heavily multithreaded and can keep a GPU, a dozen CPUs, and a network connection busy. Only some parts have to go fast. The critical parts are:

* The render loop, which is in its own higher-priority thread.

* Blocking the render loop with locks set during GPU content updating, which is supposed to be done in parallel with rendering.

* JPEG 2000 decoding, which eats up too much time and for which 10x faster decoders are available.

* Strategies for deciding which content to load first.

* Strategies for deciding what doesn't have to be drawn.

Those really matter. The rest is either minor, infrequent, or not on the critical path.

I use Tracy to let me watch and zoom in on where the time goes in each rendered frame. Unless Tracy says performance is a problem, it doesn't need to be optimized.

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

#280

Post by adastra22 »

blub wrote: post #269
adastra22 wrote: post #247

Earlier quoted context omitted.

> Pretending Rust is easy just sets beginners up for disappointment when they get into Rust and realize it wasn't what they were sold. Or worse, they start doubting themselves when they encounter the hard parts because Rust fans were busy insisting it's all easy. You could be describing me. I recently convinced my boss to let me write a server in Rust for the safety, speed, etc. After being two weeks overdue, I threw…

Which libraries did you use in C++?

Boring things like boost, abseil, and the standard library.
Post reply on HN