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

171–180 of 341 posts

Re: Several core problems with Rust

#171

Post by bigstrat2003 »

> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.

This is not objective. You're entitled to your opinion, but I at least am fine with compile times the way they are. For it to be objective, it would have to be something that is true independent of your or my opinion, but ultimately this is a subjective matter.

> 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% reliability with Rust — it crashes all the time.

This is a completely baseless assertion; Rust does not "crash all the time". If a programmer chooses to crash rather than keep going when the program is in an unforseen state, that is his choice, not something the language requires. Presumably that programmer feels that crashing is beneficial (because it helps to make bugs obvious sooner), but you aren't required to do the same.

Re: Several core problems with Rust

#172

Post by boroboro4 »

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.

Re: Several core problems with Rust

#173

Post by vacuity »

benjiro wrote: post #73
tptacek wrote: post #56

Earlier quoted context omitted.

"Memory corruption vulnerabilities" != "concurrency bugs" or even data corruption. The last thread I was in about this, someone pointed to Go segfaults and said "see! memory corruption!" (obviously: no). An easy response to claims like this: there's a huge tower of software written Go at this point, including the entire K8s ecosystem. Show me the memory corruption exploits.

The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword. The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind. Unsafe in a language like Go is very rare, mostly because people do not program at such low system le…

While unsafe is always a risk in Rust, measuring the risk is not nearly as straightforward as counting lines of code. In particular, Rust focuses on encapsulating unsafe code behind safe wrappers that prevent misuse, so the better measure is determining which crates don't do this, and to what extent they can be easily patched to do so.

Re: Several core problems with Rust

#175

Post by bigstrat2003 »

Mauneam wrote: post #151
rddbs wrote: post #144

Earlier quoted context omitted.

You get to choose between UB, a crash, or handling the error — same as most other languages. It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.

No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent. The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "cho…

> The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt.

This is totally false. It's not in the least hard to avoid crashing.

  match some_result {
    Ok(value) => { // handle the value },
    Err(e) => { // handle the error condition } 
  }
The fact that Cloudflare chose to handle a result with the "panic if this result is an error" function is 100% on them, not on the language. Blaming the language is like claiming that any language which has assert is a problem because the assert can crash your program. Yes, that's what it's there for, so don't use it if that isn't what you want.

And don't give me the "the method name isn't obvious enough" argument you used elsewhere. That holds no water. It's basic Rust knowledge to know that "unwrap" will panic if the value is an error (or None if it's optional). If the engineers writing the code didn't know that, then the problem is they didn't bother to learn how their tools work, which again is not the language's fault.

Re: Several core problems with Rust

#176

Post by arresin »

teleforce wrote: post #108

>Its compilation is slow. I mean SLOW. D language smiling in the corner [1]. "D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." [2] [1] Kevin James meme creator tries to guess why the photo went…

Maybe it’s not a fair judgement because I just looked at the docs, but I didn’t like the syntax on first looking at it.

Re: Several core problems with Rust

#177

Post by loeg »

PaulDavisThe1st wrote: post #155
loeg wrote: post #122

Earlier quoted context omitted.

No, it's the mutable shared state that is the problem. Lock contention is just downstream of the same problems as any other mutable shared state. > patterns like RCU RCU isn't mutable shared state! It's sharing immutable state! That's the whole paradigm.

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

Re: Several core problems with Rust

#178

Post by vacuity »

leoh wrote: post #114

>Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. Refactor your build. >It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc >> on every single step directly impacts the quality of the logic bei…

> Refactor your build.

People do this, and at best it works for some people. This kind of messaging towards people who bring up a valid criticism of Rust does not help.

Re: Several core problems with Rust

#179

Post by weedhopper »

I don’t think i’ll ever understand the compile time argument https://xkcd.com/303/

One thing that this blog doesn’t address though, is the cult-like following of Rust. It’s like the “AI” of oss — a main selling point by itself despite not being a feature. Seemingly, there is an assumption that software written in Rust is inherently better than any other, or that if something is written in Rust, it cannot have any errors.

Sure, new software should be written in it instead of C. But why fix programs that are already memory safe?

Re: Several core problems with Rust

#180

Post by loeg »

jandrewrogers wrote: post #157
loeg wrote: post #62

Earlier quoted context omitted.

Idk, it's a general rule of thumb that the more mutable shared state an algorithm has, the worse it scales. So if you're trying to scale something to be concurrent, mutable shared state is an antipattern.

At scale, algorithms are commonly limited by memory bandwidth, not concurrency. Most code can be engineered with enough cheap concurrency to efficiently saturate memory bandwidth. This explains why massively parallel HPC codes are mostly minimal mutable state designs despite seemingly poor theoretical properties for parallelism. Real world performance and scalability is dictated by minimization of memory copies and m…

It's certainly true that some things are limited by memory bandwidth. But it's also common to be limited in other ways.
Post reply on HN