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

91–100 of 811 posts

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

#91

Post by cmrdporcupine »

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…

I wrote plenty of vaguely web stuff in C++ at Google. A lot of services at Google are C++. But it's kind of, not how the rest of the industry expects things. And most of that stuff there is now moving to Go.

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

#92

Post by josephg »

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…

> If you have a long-running async function, then pass parameters by value! If you have a polymorphic async function, then return your result in a Box.

I've taken to making heavy use of the smallvec and smartstring crates for this. Most lists and strings are small in practice. Using smallvec / smartstring lets you keep most clone() calls allocation-free. This in turn lets you use owned objects, which are easier to reason about - for you and the borrow checker. And you keep a lot of the performance of just passing around references.

I tried to use async rust a couple of years ago, and fell on my face in the process. Most of my rust at the moment is designed to compile to wasm - and then I'm leaning on nodejs for networking and IO. Writing async networked code is oh so much easier to reason about in javascript. When GAT, TAIT and some other language features to fix async land I'll muster up the courage to make another attempt. But rust's progress at fixing these problems feels painfully slow.

https://crates.io/crates/smallvec / https://crates.io/crates/smartstring

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

#93

Post by bombela »

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…

Rust doesn't protect you against deadlock.

I wonder if it is similar to the halting problem. Can deadlocks even be prevented in theory?

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

#94

Post by eternalban »

jeroenhd wrote: post #53
PragmaticPulp wrote: post #9

Earlier quoted context omitted.

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…

Rust isn't hard for the things you try to solve in Rust. The author compares Rust code with Go code. Those two languages serve entirely different purposes, with entirely different mechanisms behind it. Go does what the author does with ease because the runtime fixes all the complicated parts for you. You tell Go what you want and it'll try to solve all the memory management/threading/memory safety issues for you, usu…

> 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' problems are intellectually interesting, solving them is satisfying, and over the years the design lessons build upon each other. At which point you don't need a Mommy Dearest Compiler to ensure correctness.

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

#95

Post by chowells »

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

That's definitely a description of GHC Haskell. All network IO in Haskell goes through a subsystem called the IO manager, which makes use of platform appropriate high-performance non-blocking APIs. (Actually, I think windows isn't getting an IOCP implementation until the next major release, but Windows has always been a bit undersupported by GHC.)

The nice thing about this is... You don't have to care. Haskell is a good enough programming language to just put the platform-specific non-blocking hell APIs in a library and let you write code that looks linear and blocking. If you want more control you can get down to the low level non-blocking APIs, but that's usually not going to be worth the trouble.

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

#96

Post by crabbygrabby »

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.

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 complexity is worth it for me, even for hobby projects, mostly because after a few weeks of toiling with it, I learned it wasn't that complicated, and what it gives me in price of mind way surpasses that.

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

#97

Post by bombela »

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…

But what when you have some threads slacking off, and others too busy? It would be nice in this case to use those idle threads, even if it means a little bit of CPU cache trashing. And I believe this is what Tokio offers with a work stealing thread pool.

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

#98

Post by adeon »

birdfood wrote: post #35
adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

I've bounced around a few languages this year, looking for a language to use in my spare time for fun / enjoyment / skills growth (I have a similar set of criteria to you). I've looked at rust, swift, haxe, zig, and now nim, and I think I'll be sticking with nim. I like that it's seemingly simple, and takes care of memory management for you, but you still have access to pointers if you want them and can extend the la…

There were many things I liked about Nim:

* The compiled programs run pretty fast.

* Compiling is pretty fast too (compared to Rust or Haskell).

* It's easy for me to bind to whatever C library I have even if nobody made nice Nim packages for it. This one was important for the project I was working on.

* There is a GC, but if you choose the proper GC it will be based on reference counting (or if you are compiling to JavaScript, it'll use JavaScript's GC). It means I don't have to care about cleaning up resources. My memory may be wrong but I think Nim also tries to remove reference counting checks when it can. I haven't ever checked in the compiled code does it do a good job at this.

* The language rarely complains that something in my code is wrong; there's no borrow checker complaining. Even with little experience I was able to write some quite complicated code. It's like Nim wants to do its best to compile and run my crappy code.

* It's easy to read. Maybe because it looks so much like Python and I have lots of Python experience. Nim does not want to complain about your code unless it has to. Despite being statically typed, you don't have to write type definitions that much.

There are things I don't like as much:

* The story for running threads in Nim is not great. You can run OS-level threads but it's a bit janky (you'll have to now care what data can be shared). It wouldn't stop me from writing multi-threaded software though if I really needed threads.

* The documentation could be a bit better. I think Nim project should take this giant page: https://nim-lang.org/docs/manual.html and reorganize it and make sure the language is easy to read and find stuff. I often have trouble finding documentation on some language feature. I think the project is acknowledging this right in the first paragraph "This document is a draft! Several of Nim's features may need more precise wording. This manual is constantly evolving into a proper specification."

This one is harder to pinpoint into specific examples but the language feels a bit immature. I feel like there's bunch of half-baked features that were thrown in on a whim idea. And obviously the package ecosystem isn't as wide as in more established programming languages. I looked it up and Nim has apparently existed since 2008; I'm sure it used to be way more immature ;)

Despite the negatives, I think Nim is an amazing tinkerer's language. I can very quickly write programs that will be speedy and easy to read. I'm not sure I'd start a very complicated large project in Nim though. I am bullish that Nim will mature and its userbase will grow, fixing some of the warts.

In a few months I plan to take a long vacation and work on a video game with my friend. There is a high chance that I'm going to use Nim for this project; to make something that runs both in browser and also natively.

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

#99

Post by duped »

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.

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

#100

Post by mftb »

0des wrote: post #23
adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

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

Just wacky I had to scroll this far to see Go mentioned. In certain contexts Rust is very impressive, in others Go is a much better choice. I'm really starting to hope that we'll see some of the important advancements in Rust packaged up in a better language.
Post reply on HN