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

301–310 of 811 posts

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

#301

Post by HacklesRaised »

conradludgate wrote: post #290
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.

Definitely not. I've been a full time rust developer for a long time now. Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler so I have to test my code a lot more thoroughly to be confident. With rust I'm pretty confident in my code from the start

That's a really helpful perspective. Thanks.

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

#302

Post by HacklesRaised »

gspr wrote: post #292
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.

I think I'm quite fad-resistant (others would use less positive words to describe the same attribute). I still find Rust truly excellent, and the most joy I've had programming since Haskell (while at the same time being a lot more mainstream and pragmatic choice for collaborative projects than Haskell).

My wife calls my stubborness 'Cultural Stamina', I think it's an excellent phrase that always raises a smile.

I really enjoyed Haskell when I tried it years ago (2004) and I definitely agree that Rust is much more apropos to the mainstream.

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

#303

Post by lenkite »

Compare the Rust Handler-Dispatcher program with the Go Handler-Dispatcher program and look at the truly extraordinary complexity that Rust adds to what is effectively a simple design problem that any of us have implemented several times, if your career has had a few years of original coding.

Handler-Dispatcher is not some complicated design pattern. It is very basic. Its implementation in any language should be short and elegant. This is NOT something you should be losing sleep over.

Rust, unfortunately, is even MORE complicated than C++ in language complexity today. Good tooling does not eliminate the burden of extraordinary complexity that Rust wants to enforce on its adopters.

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

#304

Post by ncmncm »

bpye wrote: post #183
anonymoushn wrote: post #168

Earlier quoted context omitted.

never allocating memory can be and should be simple.

What language actually makes it simple?

This is very commonly done in C++. My programs do a flurry of mmaps in the first second, then run for, sometimes, years without allocating again.

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

#305

Post by pjmlp »

lelanthran wrote: post #206
jen20 wrote: post #176

Earlier quoted context omitted.

Which parts of Rust would you give up to make this happen? And how would this be implemented?

> Which parts of Rust would you give up to make this happen? And how would this be implemented? Traits, maybe? Switch to an OO model more closely aligned to what the majority of developers understand. Dump all of the line-noise-type syntax. My Own Toy Language (ComingRealSoonNow)^tm that I started designing had exactly one goal - prevent the majority of memory errors, not prevent ALL memory errors. All I wanted was t…

Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages.

Also the basis for one programming language that used to be widespread in the enterprise for quick and dirty solutions, VB and its ecosystem of OCX libraries.

It is more widespread that people think, because when many argue about OOP, they miss the full spectrum of how OOP is approached.

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

#306

Post by ThePhysicist »

dochtman wrote: post #293
ThePhysicist wrote: post #250

Just got started with Rust and yeah, my biggest pain point so far were lifetimes and async code. I finally replaced tokio with multithreaded blocking code, which seems to be much simpler and more familiar. The problem with async was that some of the libraries I needed (e.g. for QUIC) didn't support it, so you had an unholy mixture of blocking and non-blocking code. Coming from a C++ background I appreciate Rust's nov…

Which QUIC library did you use? Quinn (the one I work on) comes with an async/await interface.

Quiche.

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

#307

Post by chombier »

teaearlgraycold wrote: post #167
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…

Step one is just clone() everywhere all the time. Then you should cut back AFTER analyzing where all of your memory is being lost to.

Can one really escape clone hell afterwards, though?

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

#308

Post by marcusramberg »

timClicks wrote: post #278
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?

Sounds like survivor bias :)

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

#309

Post by jhugo »

411111111111111 wrote: post #287
mikojan wrote: post #260

Earlier quoted context omitted.

I've successfully replaced tokio with the lower-level mio in one such case. After all threads and async serve different purposes: Threads when you're computing a lot, async when you're waiting a lot, no?

I'm just an average web developer, so I could be wrong here, but that's not my understanding of it. Your application has n threads to begin with, if you use async, these will be utilized to schedule tasks. You're basically trusting your language to properly pause and restart the procedures. If you spawn new threads, these will be managed by your kernel. If that kernel is Linux, that it already has a pretty good algor…

The important difference is in purpose, not implementation. Most async runtimes use a thread or more per core, and the OS is doing that thread scheduling, so it's not the either-or situation that you describe.

The interesting thing about async (especially async-await) is that it is a fluent way to write a program that waits for events (e.g. I/O), without resorting to inefficient designs like thread-per-client in order to achieve concurrency.

Software (even in C) has made use of this concept for a long time through poll() and friends; async-await is just a higher level abstraction over the same concept.

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

#310

Post by ncmncm »

jcelerier wrote: post #264
est31 wrote: post #128

Earlier quoted context omitted.

> In C++ I could always use my own styles / paradigms / patterns etc. etc. That's also one of its major disadvantages, unless you literally rewrite the entire thing when major maintainer changes happen, because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it.

> because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it. I'd be really interested in meeting someone who has enough mental flexibility to learn C++ but not enough to accommodate different code styles in a single codebase.

Yes. It is always easy to see what generation a piece of code is from. Trying to maintain a "consistent style" just amounts to failing to improve.

If you are not embarrassed by your old code, you have not learned anything since.

Post reply on HN