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

171–180 of 811 posts

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

#171

Post by armchairhacker »

crabbygrabby wrote: post #54
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…

Although I agree with almost everything you said, I still feel rust is a general purpose language. Most programming projects are single thread, not async, and if you aren't juicing for performance, is pretty easy to write. Even in rust. I think what makes writing rust for general purpose projects hard, is knowing you can do something better that doesn't have to be better.

Yeah I get that Rust tries very hard to be general-purpose. It also has a great ecosystem, has rare features like proper ADTs/macros and no annoying backwards-compatible quirks, and its one of the best languages for WebAssembly. So there are reasons you might want to write something in Rust that doesn't need to be low-overhead.

But even when you're doing everything single-threaded with Rc and RefCell and Box, you can still run into pitfalls. More significant, when you do this your code becomes incredibly verbose. You have to constantly specify over and over again you're doing this the high-overhead way and not the weird optimal way, it gets annoying.

Honestly I think Rust should have an "easy mode", where you everything is implicitly wrapped in ARC / dyn / mutex, and when you write code it's almost like you're working in a truly general-purpose "regular" language. Except it interfaces perfectly with regular Rust and compiles to Rust, so you can still use your favorite cargo packages and even jump into real Rust when you need to.

The issue with that is Rust is already stretching itself kind of thin. So this "easy mode" has to be implemented so it's very simple and you can completely ignore it if you want. Maybe it will just be adding better FFI support to Rust, or maybe it will be another ambitious language like Rust but has better support for implicit easiness.

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

#172

Post by dataangel »

eternalban wrote: post #82
mynameisash wrote: post #45

I started picking up Rust a bit over two years ago, and it was HARD. I didn't have teammates who knew it to help me out, so I used community resources (/r/rust, exercism.io, etc.) I'm still not great with the language, but I'd say I'm about as proficient in it as anything else. The progress is slow enough that you find many more opportunities to quit, but once you do become productive, I think the hard work really pa…

Rust and Python sit at almost extreme opposite ends of programming paradigms. The question on the table remains if the excessive complexity of the Rust language is factually worth the pain.

lol "excessive complexity". Compared to what? Every language if you learn it to sufficient depth starts to appear that way, and Rust is mostly displacing C++ which is insanely more complex.

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

#173

Post by [deleted] »

charlieflowers wrote: post #163
infogulch wrote: post #129

Earlier quoted context omitted.

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.

[deleted]

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

#174

Post by travisgriggs »

d3nj4l wrote: post #141
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.

I cannot, for the life of me, recommend Elixir enough! You write your code without every thinking of words like "async" or "await" and the VM handles it for you !

So this. You have to learn to think differently about your problem. But then when you do, so many of these other issues just go away. A small amount of our product offering is implemented in Elixir. I wish more of it was. It’s my favorite part of the whole thing.

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

#175

Post by dataangel »

FpUser wrote: post #86
cmrdporcupine wrote: post #66

Earlier quoted context omitted.

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

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

#176

Post by jen20 »

Hirrolot wrote: post #169
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 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.

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

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

#177

Post by marcosdumay »

3np wrote: post #81
gregwebs wrote: post #75

Earlier quoted context omitted.

Haskell has always been the best. Go's did the same as Haskell. In either case IO is automatically async. If you want concurrency you create very light weight threads. This approach works very well for most use cases, but when you want the best performance possible the light weight threads can still be too much. Zig is going for a lowest possible overhead approach like Rust but has an interesting take: https://kristo…

Are you sure you are talking about Haskell and not Erlang? I'm not aware of how Haskell IO would be "automatically async".

Yeah, many people don't even see a reference about Haskell IO being async. That's what the "automatic" part is doing.

Haskell IO is basically as async as Javascript, as in every operation is fully asynchronous, you need to call some foreign function if you want otherwise. Except that you have parallelism and can have concurrency too added if you want.

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

#178

Post by jen20 »

ipodopt wrote: post #39
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…

It has been a sec but if I were to do another multi-threaded async Rust project I would do one thread per async runtime and explicitly pass anything that needed to be shared. This should be more ergonomic as this should get rid of everything needing to have send/sync traits. I also suspect it may be more performant as I am not sure how good the async runtimes are about keeping scopes pinned to a particular core so it…

Look at Glommio, it’s essentially what you describe.

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

#179

Post by jandrewrogers »

megous wrote: post #79
nyanpasu64 wrote: post #52

Earlier quoted context omitted.

Rust marks cross-thread shared memory as immutable in the general case, and allows you to define your own shared mutability constructs out of primitives like mutexes, atomics, and UnsafeCell. As a result you don't get rope to hang yourself with by default , but atomic orderings are more than enough rope to devise incorrect synchronizations ( especially with more than 2 threads or memory locations). To quote an earlie…

Re: fearless concurrency... Would Rust prevent you in general from writing code that could deadlock, btw? Thread1: takes lock A, ..., tries to take lock B Thread2: takes lock B, ..., tries to take lock A Looks like you should be able to pass Mutex and Mutex to both threads otherwise what's the point of mutex if there's no way to share data protected by it, so it doesn't look like it prevents you from hitting this sce…

No, deadlock-free code requires some additional structure. There is no general way that I know of to prevent deadlocks in any software with non-trivial lock graphs, but there are standard techniques to detect deadlocks programmatically so that they can be broken and resolved. OLTP databases figured out how to do this decades ago, but those techniques are expensive for general purpose programming.

The common method for deadlock-free code is roughly that when a thread is required to wait on a lock owned by a second thread, it checks to see if the second thread is waiting on a lock already owned by the first thread. This requires that the lock graph essentially be a high-performance and concurrent global structure.

Locks like this can be expensive, particularly under high concurrency or contention, so they aren't used for most software. If you can fit your software in a simpler model e.g. where locks are singular or only acquired as a DAG, then much higher performance options are available that don't require deadlock detection.

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

#180

Post by jen20 »

eternalban wrote: post #82
mynameisash wrote: post #45

I started picking up Rust a bit over two years ago, and it was HARD. I didn't have teammates who knew it to help me out, so I used community resources (/r/rust, exercism.io, etc.) I'm still not great with the language, but I'd say I'm about as proficient in it as anything else. The progress is slow enough that you find many more opportunities to quit, but once you do become productive, I think the hard work really pa…

Rust and Python sit at almost extreme opposite ends of programming paradigms. The question on the table remains if the excessive complexity of the Rust language is factually worth the pain.

I’d agree they’re at opposite ends of the complexity spectrum: it’s very difficult to write a moderately complex python program which uses even a single dependency and is bug free, then deploy it to the machine of a non-technical user. Rust meanwhile excels at this task.

Oh wait, that’s not what you meant?

Post reply on HN