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

121–130 of 811 posts

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

#121

Post by ModernMech »

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 do it because the toolchain is so nice. I just do

  wasm-pack build --target web
And it builds a little wasm file and some js shim, and that's all it takes to get a Rust website up and running.

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

#122

Post by Waterluvian »

nyanpasu64 wrote: post #52
Waterluvian wrote: post #38

Earlier quoted context omitted.

I’m a Rust newbie. Mind if I ask: are you referring to using threads and locks and queues and such? Does Rust give you rope to hang yourself when doing it without async or does it continue to be very specific about forcing you to guarantee that you’re not going to run into races and whatnot?

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…

I really appreciate this detailed response. You gave me plenty to base my searches and reading on.

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

#123

Post by eternalban »

crabbygrabby wrote: post #96
eternalban wrote: post #82

Earlier quoted context omitted.

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…

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.

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

#124

Post by birdfood »

adeon wrote: post #98
birdfood wrote: post #35

Earlier quoted context omitted.

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…

Good summary, I haven't touched threads but I'd agree with everything else. I'd also add that since the language feels dynamic, I feel like my code is less structured, but I think this might just be because all the boilerplate you have to write in other languages isn't there. So maybe my code is just as unstructured and with nim I can't be fooled by boilerplate into thinking it is.

I've been following the nature of code and making a little 2d platformer at the same time using nim + raylib. Compiling to wasm I found to be even simpler than when doing the same thing with C++. It's really nice being able to compile to native or wasm with a single compiler flag.

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

#125

Post by Waterluvian »

bombela wrote: post #93
megous wrote: post #79

Earlier quoted context omitted.

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?

Only if the priority is flat and not some sort of graph, is my guess.

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

#126

Post by tick_tock_tick »

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…

I'm pretty sure "fearless concurrency" is just a meme at this point since Rust does very little to make concurrency "fearless".

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

#127

Post by ModernMech »

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.

Any language which is dataflow based will be great in an async context. Async is hard in most languages because they are imperative, which stands in stark contrast to the whole idea of asynchrony. This whole exercise of adding async features to various imperative languages is coming at the problem from the wrong way around in my opinion. It's a recognition that async programming is hard in imperative languages, and the thought is that maybe this could be made better with more language features. But the sad truth is that async features clash hard with the imperative nature of most mainstream languages.

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

#128

Post by est31 »

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…

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

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

#129

Post by infogulch »

jacksnipe wrote: post #46
Waterluvian wrote: post #38

Earlier quoted context omitted.

I’m a Rust newbie. Mind if I ask: are you referring to using threads and locks and queues and such? Does Rust give you rope to hang yourself when doing it without async or does it continue to be very specific about forcing you to guarantee that you’re not going to run into races and whatnot?

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.

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

#130

Post by estebank »

beltsazar wrote: post #113

While I can see why zero-cost abstractions are important in Rust, I was wondering how much simpler Rust async could have been if zero-cost had not been a hard requirement. The way I see it, Rust async is most useful for IO-bound applications, which can afford some non-zero abstraction CPU cost.

If zero-cost wasn't an aim then it would indeed be much easier. For example, async fn in traits isn't (yet) in the language. The type system level changes to make them possible is being actively worked on (it is high priority!), but if we didn't care about "you can't write more efficient code by hand", then we would have provided that feature with the semantics of the async-trait crate[1], which provides a macro that turns `async fn foo() -> i32 { 42 }` into `fn foo() -> BoxFuture { Box::new(async { 42 }) }`. Going down that route would have "silenced" that criticism, at the cost of locking us to subpar behavior at least until the next edition. The approach of waiting until things are baked well enough to land in stable is frustrating as a user today, but I believe has a better chance of standing up to scrutiny long term. In the meantime, the community is able to "plug" those failings, at the cost of worse dev UX due to not being builtin.

[1]: https://crates.io/crates/async-trait

Post reply on HN