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

211–220 of 811 posts

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

#211

Post by oxff »

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…

This isn't really an easy async programming issue the author was having. I mostly do server backends I'd do with Java or Node with Rust and its fine.

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

#212

Post by nyanpasu64 »

ModernMech wrote: post #137
eternalban wrote: post #94

Earlier quoted context omitted.

> I think the difficulty in Rust lies in that it will enforce correctness. Competing languages are less strict about that, especially when it comes to threading. Enforcing correctness at compile time is not the only way to insure correctness. Some do enjoy solving language puzzles (so choose Rust) and some prefer thinking before coding and prefer solving design puzzles. I personally prefer that latter, as the 'hard'…

This is the "don't do anything wrong" model of software development, and while it works well for some, we have enough experience as an industry to know it doesn't scale. Crucially, it's hard to prove whether or not you've actually solved whatever design issue you wanted to overcome. Such a proof usually would entail some sort of analysis of the program as written (because it may actually differ from your design). To…

To quote threatofrain:

> All type systems will have meaningful and true propositions which are apparent to the programmer but not yet to the language team... Some of what the author is complaining about matches my conversations with people who aspire to be Rust library authors — that you're often trying to hijack the type system because you actually know better.

Rust catches some problems (like data races and use-after-free). Safe Rust translated into correct C++ is still correct. Rust also fails to catch some problems (like preventing out-of-bounds indexing at compile time); admittedly idiomatic C++ fails to catch bounds errors at runtime. And when encountering problems that Safe Rust cannot solve (like the generic lifetime quagmires in the original post), C++ often makes it possible (and easier than esoteric programming languages like Unsafe Rust) to solve the problem correctly in the current situation; though admittedly, ensuring you haven't missed any UB cases, and validating that your assumptions don't break later on, is difficult (Unsafe Rust is better at marking unsafe code for future readers).

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

#213

Post by jandrewrogers »

armchairhacker wrote: post #40

I personally believe that Rust is an exceptional language and it’s ahead of its time. Seriously, can you think of any other language with as incredible type system, incredible tooling, incredible performance, incredible package management and general package quality, incredible compilation target support, and practically no few backwards-compatibility quirks? But Rust is a really bad general-purpose language. Because…

Rust is hard, from a systems programming perspective, not because of anything about the problem domain but because Rust has an unusually narrow perspective of what systems programming entails. And it is unforgiving for software that has requirements outside that perspective, which happens more often than I think some Rust proponents allow.

Modern systems software architectures are thread-per-core, involve a lot of DMA, etc for performance reasons. That is language agnostic, though most is written in C++ because it is amenable to it. This obviates a lot of the safety features Rust obsesses over. It often feels like the Rust community hasn't acknowledged that this is how systems software actually works these days, or the deficiencies of the language in supporting these software architectures.

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

#214

Post by MrBuddyCasino »

kenhwang wrote: post #208
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…

I just tell everyone, just write Rust like you'd write Scala. Don't try to optimize the crap out of anything until you need it, especially if no one else is going to use your code. Just make the allocations. Even if you write it that way it's still significantly more performant and lightweight than the alternatives without much loss in productivity.

No post body was provided.

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

#215

Post by DeathArrow »

Performance, safety, ease of use. You can only pick two.

I like the strategy that Nim employs. Due to multiple ways of memory management strategy you can use (different types of garbage collectors, reference counting, manual memory management or no memory management), you can have different combinations of performance, safety and ease of use - so it can fit nicely what you are trying to accomplish.

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

#216

Post by jjnoakes »

eternalban wrote: post #123
crabbygrabby wrote: post #96

Earlier quoted context omitted.

If you need performance, compiled binaries, etc then yea it sure can be worth it. In some cases you don't have a product if you can't get the performance to reach a certain level. In other cases you spend a lot more money tracking bugs in production that rust just doesn't allow to happen in the first place. Every project has different priorities, some projects don't need rust at all, some greatly benefit from it. The…

You are basically asserting that performance & correctness are beyond the reach of developers who build systems in other languages. So based on this I suppose all systems developed in other languages are either performing subpar and/or are incorrect? "Is the pain worth it" is the question. My 42 years of professional development tells me the answer is no. (I lean towards programming pleasure and not pain). YMMV.

I would say most systems are either slower or less correct, yes. The nice thing about being a developer is that these costs are mostly hidden from us. The business pays for more compute if you churn out slow code, and churning out bugs just increases your job security.

Imagine if you had to pay for the performance loss or production bugs directly though...

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

#217

Post by DeathArrow »

Animats wrote: post #21
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…

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

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

#218

Post by inejge »

Hirrolot wrote: post #165
duped wrote: post #99

Earlier quoted context omitted.

The last thing I would take away from async/await in Rust is that it's "half baked." It's incredibly deeply thought out with years of RFCs, great contribution work that required both low level implementations in nightly and creating extensions to the memory model, and extensive bike shedding and discussion with the community on surface APIs.

async/.await in Rust is a perfect example of "code duplication" in the language core. Okay, you have a nice syntax for performing do-notation on futures, but what about iterators, streams, etc? We have generators in nightly and some third-party macros for streams, which sucks. A proper algebraic effect system could resolve the problem. You can take a look at Koka to see how elegantly it abstracts common control flow…

A proper algebraic effect system could resolve the problem.

It could also take as long as the async MVP itself to get off the ground, and you can't know if it wouldn't hit its own snags when deployed at scale. (From long ago, I remember the "non-parametric dropck" RFC as an illustration of a neat concept colliding with reality.)

Languages with mainstream aspirations evolve under greater pressure. I don't know this, but I strongly suspect that async was necessary for Rust to gain acceptance at, say, Amazon. So it couldn't practically have been designed with a wide-open timeframe. The result is what we have; one can uncharitably call it "half-baked" and tut-tut about the sharp edges, but it's workable if you know what to avoid. (But it's so tempting to imagine what could have been, eh?)

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

#219

Post by DeathArrow »

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 agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff.

Mostly because of performance. Looking at latest Techempower benchmark, stuff written in Rust is 50% faster than stuff written in C# or Java. [0]

If that difference in performance and the tradeoffs to obtain it are worth, that's for everybody to decide.

[0] https://www.techempower.com/benchmarks/

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

#220

Post by newuser46547 »

jandrewrogers wrote: post #197
koyote wrote: post #47

As someone that has only dabbled in Rust, the post reminds me of C++ and its mind-boggling templating system. Rust even seems to provide you with the multi-page compile errors. Is it really as bad, or does the post only highlight the misery you get when you're working on the fringes of what the language is capable of doing?

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?

Post reply on HN