Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Several core problems with Rust

bykozy.me

Post reply on HN
Print view View original

181–190 of 341 posts

Re: Several core problems with Rust

#181

Post by eddd-ddde »

jandrewrogers wrote: post #149
lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

> Mutable shared state: make bad designs hard to write. Also makes good designs hard to write, designs that can be significantly more efficient. Passing messages is not a universal solution to shared mutable state. It is great for certain patterns but suboptimal for others.

Wrong, it makes good designs easy to write with clear safe APIs. If you know what you are doing just create a safe wrapper over unsafe functions and do what you need.

For example you can just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API. now you only need to pay attention to those specific unsafe calls.

Re: Several core problems with Rust

#182

Post by PaulDavisThe1st »

loeg wrote: post #177
PaulDavisThe1st wrote: post #155

Earlier quoted context omitted.

What do you think the "update" part of RCU actually does?

RCU publishes a new pointer after Copying and Updating the copied state. It's not mutating in-place. You don't use it for frequent updates. https://en.wikipedia.org/wiki/Read-copy-update#Name_and_over...

You may not use it for frequent updates; we do.

There is state.

It is shared state.

It is mutable state.

There are readers, who can see the shared state.

There are writers, who copy it, update it and push it back so that the new state is visible to everyone else.

I have no idea what your definition of mutable shared state might be if that doesn't fit it.

Re: Several core problems with Rust

#183

Post by super_flanker »

byko3y wrote: post #102
landr0id wrote: post #58

Rust has its issues and there are plenty of things to not like about Rust, but this article is giving me the impression that this person has not written much Rust. Unfortunately, many such cases with Rust criticism. > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliabi…

>Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface. Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source…

> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.

What has garbage collector to do with multithreaded code? Once you have two or more threads which needs to share data, they need to sync and you'd end up using some kind of lock, which will affect the performance. GC doesn't make anything efficient or less efficient here. It might make the code simpler as you don't have to worry about allocation/deallocation, but I don't see how it's magically going to remove the lock.

Re: Several core problems with Rust

#184

Post by Dylan16807 »

Capricorn2481 wrote: post #156
lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

> Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB. Doesn't mean I think it's…

If changing the safe code causes UB, the actual bug is in the unsafe code.

Re: Several core problems with Rust

#185

Post by indemnity »

hu3 wrote: post #86
jhhh wrote: post #70

You really have to compare articles like this, which are just a bunch of hand waving around the author's biases, against articles with more concrete statements like the Android team finding a 1000x reduction in memory vulnerabilities compared to C/C++. Thanks for your opinion but I'm going to weigh the people who actually use the language more than you.

Hard disagree. For my reality of developing for smaller projects than Android, I will absolutely weight Android team's opinion less than the opinion of smaller projects. Trying to mimic FAANG engineering practices is a fools endeavour that ranges between naiveness at best and CV padding at worst.

The objective data they provided is opinion now?

Re: Several core problems with Rust

#186

Post by csomar »

I am biased, so keep that in mind.

> Its compilation is slow.

I agree on this. But you can get better hardware, split a large code base into several crates, optimize for fast compilation when developing. On the other hand, I feel the guarantees of Rust compilation are discounted. If your code is more correct before deployment, wouldn't that save you debugging time later?

My biggest issue is with macros. I like them (and LLMs are good at writing macros) but they make both compilation and LSP ridiculously slow.

> It’s complex.

No, it is not. There is a learning curve. But after a while, you just alias your "Arc>>" and name it something you understand (mypipedtype) and then just fly over the abstractions. There is sunk time to build/architecture your complex type but I see that as investment that can save you time later.

> In fact, for many applications malfunctioning is better than crashing

What does malfunctioning mean? Leaking your secrets? Compromising your system? Corrupting your data/state? I'd take crashing any time of the day.

> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware)

This is a problem until the whole stack becomes Rust. If you are using lots of extern/FFIs in your code, I really sympathize with your position and you are kind of in a worst of both worlds situation.

Re: Several core problems with Rust

#187

Post by hyghjiyhu »

ModernMech wrote: post #145
Maxatar wrote: post #137

Earlier quoted context omitted.

That Rust produced a predictable and deterministic way of failing, while in C++ the equivalent code of accessing an uninitialized value without verifying it beforehand would have resulted in entirely unpredictable behavior whose reach is entirely unbounded.

Moreover, now they realize this is an issue for them, they can just do "Ctrl+F unwrap" and fix each instance. Then they can put a hook on their commits that automatically flag any code with "unwrap". In some languages where you're allowed to just ignore errors, you could fix the proximal bug, but you'd never be sure you weren't causing or ignoring more of the same in the future -- how do you search for what isn't the…

Due to the unfortunate naming of unwrap_or and friends it's a little (but only a little) more complicated than ctrl-f.

Re: Several core problems with Rust

#188

Post by osigurdson »

Klonoar wrote: post #44
edoceo wrote: post #8

Earlier quoted context omitted.

Not to worry, another tech thing will be along shortly to fill the hype/hate cycle with its own drivel.

Zig currently sits in the hype cycle like Rust/Ruby/Lisp/etc once did here. Eventually something will come along and Zig will be in the hate cycle. In reality none of these things need the religious wars that seem to go back and forth. It's just an incredibly unfortunate and annoying aspect of how programmer-centric communities tend to go.

The objective rate of improvement in programming languages has been slower than virtually every other field. Computers have gotten millions of times faster since the advent of C, but programming languages have arguably gotten maybe 10% better in that span.

Re: Several core problems with Rust

#189

Post by phi-go »

hyghjiyhu wrote: post #187
ModernMech wrote: post #145

Earlier quoted context omitted.

Moreover, now they realize this is an issue for them, they can just do "Ctrl+F unwrap" and fix each instance. Then they can put a hook on their commits that automatically flag any code with "unwrap". In some languages where you're allowed to just ignore errors, you could fix the proximal bug, but you'd never be sure you weren't causing or ignoring more of the same in the future -- how do you search for what isn't the…

Due to the unfortunate naming of unwrap_or and friends it's a little (but only a little) more complicated than ctrl-f.

You can also forbid unwraps as part of clippy.

Re: Several core problems with Rust

#190

Post by marisen »

boroboro4 wrote: post #172
anon-3988 wrote: post #131

> Arc >> is complex This is not the language problem, but its simply the nature of the problem no? It is like saying, full adders are complex, can't we design something simpler? No, full adders are the way they are because addition in binary is complicated. What you are saying is that this problem is not your kind of problem, which is fine. Not everyone needs to face the complexity of optimizing full adders. And so w…

Probably if you use a lot of Arc >> languages with proper runtime (like Go or Java) are gonna be more performant, in the end they are built with those abstractions in mind. So the question isn’t only how much the nature of the problem it is, but also how common the problem is, and is rust a correct way to solve this problem.

If you use a lot of Arc>> you you probably just learn to use Rust properly and just use Arc> instead because it pretty much never makes sense to have a Box inside an Arc...

I say that as someone that thinks Rust's learning curve is the main reason it rarely makes economic sense to use it.

Post reply on HN