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

161–170 of 811 posts

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

#161

Post by xyzzy_plugh »

mwcampbell wrote: post #156
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. 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…

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.

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

#162

Post by StillBored »

est31 wrote: post #128
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…

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

I don't know, I never got heavily on the C++ inheritance bandwagon when it was popular in the late 1990's early 2000's. Rather preferring aggregation.

If you application is actually using the OO parts of the language that way, even without modern C++ its fairly easy to maintain as the different styles/etc area also encapsulated in their classes. Then hopefully the top level is using some kind of message passing interface/whatever to avoid trying to glue everything together into a god class.

AKA, there are a few fairly easy to understand rules that allow people to do their own thing without creating a maintainability nightmare even with very large C++ codebases. If an experienced engineer/architect/etc with a track record of successful C++ projects is in charge during the initial application design/etc you should have a fairly maintainable application.

I'm not sure this is really a C++ thing though, rather being a general engineering thing. If the main architecture is well thought out and understandable, a lot of sins can be burred in places where they can't create application wide chaos.

There are a lot of things that can make C++ applications suck, but you don't tend to hear about the success stories on your favorite board, those systems silently do their job. So many of the things people rail about with C and C++ simply aren't problems when appropriate engineer culture is maintained. AKA, having solid unit tests for most of the base classes being agragated, means that running them under various address sanitizer/etc tools will find the errors that aren't picked up by static analysis tools/etc.

Yes, sometimes things sneak by, but i'm not sure there are any languages java/rust/etc that solve that problem completely.

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

#163

Post by charlieflowers »

infogulch wrote: post #129
jacksnipe wrote: post #46

Earlier quoted context omitted.

Oh my god we’ve strayed so far from the light T_T Once upon a time, the whole promise of Rust was “fearless concurrency”.

I don't understand. What about this thread would make you fear running rust? Fear of learning a solution to rusts memory model, and 'fighting with the borrow checker' as they say -- sure. But rust never claimed that you wouldn't have to climb a steep learning curve, it claims that if you do make it up then the result can't hurt you due to a memory fault. So "fallen from the light" seems a little overdramatic.

IMO fallen from the light sounds spot on (not gp). I’m shocked to hear the state of async from real practitioners saying to avoid it.

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

#164

Post by ntr-- »

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

Go is the prime example. For example, in your typical web application a Goroutine is spawned for every incoming connection. This basically gives you a dedicated runtime for each simultaneous connection. In Node or Python, this would be the equivalent of starting a whole new process for every request. But in Go, there's very little cost to doing it this way. The advantage is that each connection basically never blocks…

Can't comment on Python, but I once worked on a Node.js codebase that could only handle tens of requests per second, it was highly unusual and doing some incredibly dumb things like pinging out to Redis to check for DDOS protection counters before starting to serve any request.

See: https://www.fastify.io/benchmarks/

Node is more susceptible to poor code and out of band IO slowing it down, but the V8 runtime itself is cpp and simple services are close to just writing decorators over a cpp webserver. It's obscenely fast and good enough for most purposes.

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

#165

Post by Hirrolot »

duped wrote: post #99
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…

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 patterns using the concept of an algebraic effect.

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

#166

Post by tptacek »

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…

I spent about 10 years as a professional C programmer, userland and kernel on Linux, BSD, and WinAPI systems, and I feel like I have a pretty solid grip on "how computers actually work and how languages compile" (I've written compilers with codegen), and "the what, why, and how of threads, the stack / heap, I/O, endianness, etc.", as well as (from C++) "dynamic dispatch, references, memory management etc.." and, like everyone coding in the 2000s, "async runtimes" as well.

Rust is hard. It's not hard because you have to understand all those things. It's hard because you have to understand how Rust understands all those things. Different kettle of fish.

I'm perpetually leery of "you'd have an easier time with Rust if you had a better grip on the CS of systems programming". No, that's not it at all.

(It's fine that Rust is hard. I recognize the achievements, and see where it's a near-perfect fit; I'm looking forward to Rust kernel code. But then, there's a reason almost nothing I write is in-kernel, even when I need "performance".)

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

#167

Post by teaearlgraycold »

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…

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.

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

#168

Post by anonymoushn »

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…

never allocating memory can be and should be simple.

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

#169

Post by Hirrolot »

mwcampbell wrote: post #156
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. 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 agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.
Post reply on HN