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

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

#241

Post by adastra22 » Fri, Jun 03, 2022, 6:30 AM UTC

rfiat wrote: post #101

0des wrote: post #23

Earlier quoted context omitted.

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

It's interesting that you find Go to be Rust-adjacent. Setting aside the USPs of each language (goroutines and borrow checker respectively) and just speaking about the general experience of writing code, I find Go painful for all the reasons that I find Rust pleasant. The best summary I can give of Rust is that it was designed by people who learned from the mistakes of the programming languages that came before it. T…

If your primary criticism of golang is that its creator doesn't like syntax highlighting, then it must be doing pretty good.

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

#242

Post by brabel » Fri, Jun 03, 2022, 6:32 AM UTC

ekidd wrote: post #60

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…

> 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 hard problems and end up having very similar performance, which is what I did.

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

#243

Post by formerly_proven » Fri, Jun 03, 2022, 6:34 AM UTC

hintymad wrote: post #221

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…

A naive question: do I have to use async to build a web service or RPC service? If I code in Java, I rarely need to worry about async since a service framework will take care of concurrency. I may throw in thread local and a scheduler here and there to handle some shared context or background tasks, or using some bounded queue to manage some boutique concurrency. Will using Rust be similar? Or I’d have to know all th…

No, you don't. Threaded HTTP servers and standard, blocking network clients are available, just not that en-vogue. The very highest performance servers and clients will be async, because threading doesn't get you there, but then again, you (as in: application developer) almost never need that kind of performance in your HTTP stack anyway (this does not make using Rust for such a project pointless in any way).

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

#244

Post by lelanthran » Fri, Jun 03, 2022, 6:35 AM UTC

dataangel wrote: post #175

FpUser wrote: post #86

Earlier quoted context omitted.

>"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 "we…

Modern C++ isn't really safe. Safe means the compiler catches you, generally C++ compilers don't. Trivial example is iterator invalidation -- even with all warnings and errors on compilers don't catch it.

> Modern C++ isn't really safe.

Can we cut it out with the hyperbole? Using "It Isn't Really Safe Unless It Is Written In My Favourite Niche Language" as an argument is .. well ... ridiculous. You can extend that argument to any practical programming language.

So ... Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted, where your application deadlocks, or threads starve, etc.

Haskell ... "Isn't Really Safe" because it is not possible to formally verify the logic.

Etc, ad infinitum ...

Maybe go for "Not As Safe As". After all, I don't even like C++ (see my comment history), but it's certainly possible (and not very hard) to get about 90% of Rust safety in C++.

Safety is not a binary, it's on a spectrum. Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. That's certainly not true.

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

#245

Post by brabel » Fri, Jun 03, 2022, 6:35 AM UTC

galangalalgol wrote: post #181

xyzzy_plugh wrote: post #161

Earlier quoted context omitted.

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.

You think Java and Go are slow but like Julia? It takes 2 seconds just to fire up a Julia interpreter. Its runtime is extremely heavy.

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

#246

Post by jedisct1 » Fri, Jun 03, 2022, 6:38 AM UTC

DeathArrow wrote: post #217

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

>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. I don't get why are you so dismissive about web programming? The Go libraries are good because it's easy to write good libraries in Go. And it's easy to write good libraries in Go, because of design decisions. Same for C#, F#, Java, Python and more.

Go's ecosystem is amazingly stable. Its rich standard library helps, but in general, there's a lot of attention to backward compatibility.

Once an application has been written in Go, updating dependencies or using a more recent compiler version is a breeze. Nothing breaks.

Rust code on the other hand comes with a high maintenance cost. The ecosystem is still very unstable. Core dependencies constantly have breaking API changes, or get abandoned/deprecated/superseded. Keeping everything up to date is not trivial and very time consuming. I abandoned projects due to this, and others use dependencies with known vulnerabilities, that may not even compile any more at some point. But dealing with changes in Rust dependencies instead of the actual application logic is not fun.

So, for a project that has to be maintained long-term, I would choose Go anytime. Productivity is so much higher, especially when including maintenance cost.

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

#247

Post by adastra22 » Fri, Jun 03, 2022, 6:38 AM UTC

PragmaticPulp wrote: post #9

mc4ndr3 wrote: 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…

> 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 it all out and wrote a working version in modern C++17 in an afternoon. Of course part of the issue was language familiarity, but I think also what I was trying to do was objectively harder in Rust in many respects, and the ecosystem of crates was less mature than battle-tested set of libraries I was using in C++.

At the end of the day I want to ship code and move on to the next project. Rust wasn't helping me there.

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

#248

Post by ainiriand » Fri, Jun 03, 2022, 6:40 AM UTC

newuser46547 wrote: post #220

jandrewrogers wrote: post #197

Earlier quoted context omitted.

C++ templates are an inscrutable nightmare, the reputation is deserved. Rust is a bit different. Any software engineer that doesn't have a love/hate relationship with C++ templates is lying. On one hand they are extremely opaque and not user friendly, unnecessarily so. On the other hand, mastery of that dark art allows metaprogramming that you could only dream of in other systems languages -- the modern C++ template…

>mastery of that dark art allows metaprogramming that you could only dream of in other systems languages Can you give an example for this?

Unreal Engine vs Unity. Unreal Engine has a visual editor that allows the developers to accomplish most task without the need of entering the code editor thanks to a visual scripting language, it mirrors the C++ counterpart 100%. I believe it is not possible to do that in C# (Unity language).

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

#249

Post by jedisct1 » Fri, Jun 03, 2022, 6:42 AM UTC

azemetre wrote: post #43

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…

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.

Go, Erlang, Scala, Pony.

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

#250

Post by ThePhysicist » Fri, Jun 03, 2022, 6:42 AM UTC

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 novel approach of borrow checking, though I'm not sure if it's more "elegant" than C++'s approach with unique pointers, move constructors etc.. What I love is the modern ecosystem and build tooling around the language (including documentation and package management), for me that's Rust's main advantage over C++.