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

281–290 of 341 posts

Re: Several core problems with Rust

#281

Post by aw1621107 »

Capricorn2481 wrote: post #273
Dylan16807 wrote: post #184

Earlier quoted context omitted.

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

Nope. I would encourage you to actually read what unsafe does, because nowhere in the Rust docs does it say "scopes bugs to the unsafe block" See the below code. The unsafe code is doing exactly what it's supposed to. The safe code frees a value while it's being used. This compiles. There's nothing to change here in the unsafe code. ```rust use std::slice; // Unsafe block that creates a slice from raw parts fn make_s…

I think one can argue make_slice is in fact at fault here since it's unsound (i.e., it doesn't enforce the requirements of from_raw_parts() and so allows safe code to invoke UB) and therefore either should be marked unsafe or should actually enforce the requirements of from_raw_parts().

That being said, I think in this context that's more of a nitpick since you're right in stating that bugs that result in UB need not be scoped strictly to unsafe blocks.

Re: Several core problems with Rust

#282

Post by josephg »

byko3y wrote: post #90
josephg wrote: post #67

Earlier quoted context omitted.

A couple years ago I implemented a btree (technically order statistic tree) in a couple thousand lines of unsafe rust for a project. I wrote it more or less how I'd do it in C. Each internal node and leaf node was a separate heap allocation and internal nodes had an array of child pointers. It was surprisingly hard to program up. And complicated! In my opinion, unsafe rust code is worse to use than C because rust is…

>Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers. Optimizations are very complex and potentially fragile in Rust, LLVM has to sort t…

> Particulary, Rust is able to optimize out some bound checks.

It doesn’t optimise out the bounds checks. I checked the assembly.

Bounds checks in rust always look so ugly if you look at the assembly output because there’s all this panic string building and whatnot. But in practice, I think it’s just that modern CPUs have excellent branch prediction. A branch that follows the same path 100% of the time is cheap. Especially when it has UNLIKELY() annotation hints in the code. This is the case for bounds checks. They just don’t really show up in benchmarks as much you’d think.

Re: Several core problems with Rust

#283

Post by QuiEgo »

deng wrote: post #200

> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…

> Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly.

Strong agree on this one, usually embedded systems are designed to "fail safe" on crash - the watchdog will trip, and hardware reset will put everything in a deterministic, known safe state.

What you want, above all else, is not to fall into undefined behavior. That's the beauty of `unsafe`, it bounds UB into small boxes you know to test the hell out of.

Re: Several core problems with Rust

#284

Post by kiitos »

rowanG077 wrote: post #79
tptacek wrote: post #21

Earlier quoted context omitted.

Node.js and Go are both memory safe, as are Python, Ruby, and Java. "Memory safe" is a term of art referring to susceptibility to memory corruption vulnerabilities in code written by an ordinary practitioner of the language. Almost invariably, attempts to show languages like Go and Python as memory-unsafe involve a programmer deliberately working to defeat the language. But you can do that in any language, including…

Having run into memory issues in go but not (yet) in rust I would tend to disagree with this. It's really not hard or esoteric to run into it in go.

"running into memory issues" doesn't relate to memory safety as a property

Re: Several core problems with Rust

#285

Post by Dylan16807 »

Capricorn2481 wrote: post #273
Dylan16807 wrote: post #184

Earlier quoted context omitted.

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

Nope. I would encourage you to actually read what unsafe does, because nowhere in the Rust docs does it say "scopes bugs to the unsafe block" See the below code. The unsafe code is doing exactly what it's supposed to. The safe code frees a value while it's being used. This compiles. There's nothing to change here in the unsafe code. ```rust use std::slice; // Unsafe block that creates a slice from raw parts fn make_s…

The unsafe code is not fulfilling the contract of "unsafe", which requires the coder to uphold the memory safety rules as seen from outside. make_slice is putting a very wrong lifetime on the slice it returns.

Re: Several core problems with Rust

#286

Post by IshKebab »

aw1621107 wrote: post #210
IshKebab wrote: post #209

Earlier quoted context omitted.

OCaml has other serious issues.

What are those issues, if you don't mind me asking? Don't see much OCaml discussion here so I'll take interesting discussions where I can get them.

My biggest gripes:

* Windows support is mediocre due to decades of not supporting it at all.

* OPAM is a nightmare. Surprisingly buggy and extremely confusing. We're not talking Pip levels of badness but it's nowhere near as good as Rust, Zig or Go's equivalents.

* A silly obsession with linked lists. Ok I understand why but it's still annoying.

* Ocamlfmt thinks it is writing an essay, and generally makes things less readable IMO.

* The syntax is not easy to read. They threw away all the useful punctuation that help you visually parse code.

* Tiny community.

* Very spartan documentation. Examples are very rare.

* Global type inference is definitely worse than Rust's local approach because it makes errors much worse, and makes the code harder to understand.

* Native int type is 63 bits.

I haven't even done much OCaml but it's definitely got enough issues that I strongly prefer Rust. Just the community size is reason enough really.

That said, it's still way better than Python, Ruby, PHP, Java, JavaScript and Perl. Those are kind of the Z-tier languages though so I guess that's not saying much.

If it was a choice between OCaml and Go, Swift, C#, Dart... then it wouldn't be a slam dunk either way. Unless you wanted Windows support and then OCaml is a crazy choice.

Re: Several core problems with Rust

#287

Post by vacuity »

leoh wrote: post #278
vacuity wrote: post #178

Earlier quoted context omitted.

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

Although naively factored builds can be slow on rust, I firmly believe that most folks complaining about this problem have not taken the time to learn how to do this and their builds could be perhaps 10x faster. Bringing this up an important counter-point that all too frequently is ignored or met with hostility, as this replier has done.

I do not understand how you justify your claims. Should I link any number of instances where Rust team members admit to compile times being a major issue, one which prompts significant effort to improve? Perhaps you are right about 10x speedups, but then that clearly isn't enough, reading the room.

I also do not understand how you see hostility in my comment. For one thing, I did not downvote you. Rather, your original comment is dismissive, even if the article it replies to is dubious. For another, it would also be trivial to see that I am both highly supportive and informed about Rust. Your comments simply do not help, certainly not with the common perception of Rust fans as zealots.

Re: Several core problems with Rust

#288

Post by vacuity »

Capricorn2481 wrote: post #272
vacuity wrote: post #162

Earlier quoted context omitted.

Internal use of unsafe requires securing the safe code at the module boundary. However, the design of unsafe still greatly reduces the burden of memory safety, both when it is and isn't used directly. The specific semantics of Rust aside, unsafe is more or less the ideal way for a language to express unsafe escape hatch constructs.

> Internal use of unsafe requires securing the safe code at the module boundary Not even that, because you can pass data structures from unsafe code at arbitrary depth.

If the goal is to make a safe abstraction, which is what I'm talking about, proper use of visibility and safe code at the module boundary encapsulates the unsafe code soundly.

You seem to be talking either about improper encapsulation or unsafe that is intended to be exported and used unsafely. Or perhaps some method that is not sound according to the language.

Re: Several core problems with Rust

#290

Post by leoh »

vacuity wrote: post #287
leoh wrote: post #278

Earlier quoted context omitted.

Although naively factored builds can be slow on rust, I firmly believe that most folks complaining about this problem have not taken the time to learn how to do this and their builds could be perhaps 10x faster. Bringing this up an important counter-point that all too frequently is ignored or met with hostility, as this replier has done.

I do not understand how you justify your claims. Should I link any number of instances where Rust team members admit to compile times being a major issue, one which prompts significant effort to improve? Perhaps you are right about 10x speedups, but then that clearly isn't enough, reading the room. I also do not understand how you see hostility in my comment. For one thing, I did not downvote you. Rather, your origin…

Don’t know what to tell you. Just trying to keep things real in response to a highly ungrounded post. The issues with compilation times are as severe an issue because of the reason I mentioned — folks don’t like to think about how they factor their build. So some members of the core team are sympathetic to that — and for good reason.

But the virtues of shifting context to the build and refactoring it is rarely discussed and would alleviate many individuals problems. I see it rarely mentioned, just “rust is slow to compile” so I really do feel it should be discussed more; even if I could have perhaps mentioned it in a way you (and others?) would have experienced as less dismissive.

Post reply on HN