181–190 of 226 posts
Earlier quoted context omitted.
Because something like slotmap has to use `unsafe` to get around the inadequacies of the borrow checker...
Author of slotmap here. There is absolutely no need for unsafe in slotmap. I chose to use unsafe (wrapped in a safe API) to reduce memory usage using intrusive linked freelists. If done using safe Rust this would involve `enum`s that would take up extra space.
Well, what's new here? Generational References , random or sequential That's an old idea. Goes back to at least the 1980s. It's a useful way to detect use-after-free at run time, but doesn't prevent it. "To get access to an object, we first check ("generation check") that the current generation number matches the remembered generation number. If not, we safely signal a segmentation fault." Um. Rule 5: We can only rea…
Yeah, not everyone likes those of us that share development roles alongside security best practices enforcement.
Earlier quoted context omitted.
Often missed here is that the Rust library author is strongly protected from faulty code written by Users. The C/C++ library author is not. The most obvious examples of this are memory allocation. The C/C++ user claimed the buffer was large enough to contain the result. The Rust user received back an object that protected the memory and returned it at the right time. But it could also be a file handle or mutex that u…
That may be true but it doesn't help downstream users know what they're opting into. Knowing that a rust library can use no unsafe code is not the same as knowing that that library did use no unsafe code, in a similar way to knowing that a C library can be coded with the help of various tools to provide additional safery (in some cases beyond what rust provides natively) is not the same as knowing they did . In other…
Earlier quoted context omitted.
> rust demands that I cross every last t before I can run it at all. It's worse than that IMO. Rust makes it very awkward/impractical to have cyclic data structures, which are necessary to write a lot of useful programs. The Rust fans will quickly jump in and tell you that if you need cycles, your program is wrong and you're just not a good enough programmer, but Maybe it's just that the Rust borrow checker is too li…
> currently can't do better The limitations are an inherent consequence of basic tenets of Rust's design. Rust wouldn't be Rust anymore if you fixed them. > Some of the restrictions of the Rust borrow checker and type system are arbitrary. They're there because Rust currently can't do better. They're not the gospel, they aren't necessarily inherent property that must always be satisfied for a program to be bug free.…
For everything else there are more productive options.
Earlier quoted context omitted.
That makes it expensive to move from experimentation to "fairly usable", though.
Your Lisp program will be entirely usable once you have experimented and found the right way to do it. Lisp compilers are really good, and they support gradual typing: you can write your program with no explicit type information, and then speed it up by adding type information in the hot spots. You can deploy that to production and it will serve you well. At some point your Lisp program will be mature, you will have…
Earlier quoted context omitted.
> Slotmap uses unsafe everywhere, it's a memory usage pattern not supported by the borrow checker. Is disabling the borrow checker really a common pattern in Rust? Wrapping "unsafe" code in a safe interface is a common pattern in Rust, yes. There is absolutely nothing wrong with using "unsafe" so long as you are diligent about checking invariants, and keep it contained as much as possible. Obviously the standard libr…
> "unsafe" just means "safe but the compiler cannot verify it". "unsafe" means "safe"? I would say "unsafe" means "only safe if used in a manner that cannot be checked by the compiler".
An `unsafe fn` however does need to be used correctly (and should document those requirements). However, these can only be called within `unsafe` blocks, so see above.
I.e. the compiler/tool to go through the code, as if it was executing, and apply reference counting to objects, revealing whether an object will be destroyed normally, prematurely or never.
This is what we actually do as humans by the way, when we are developing an algorithm in C++ with manual memory management. We do it implicitly though.
Earlier quoted context omitted.
I agree these planes are important and deserve care. At the same time pretty much all suggestions on how to meaningfully improve the safety of those planes boil down to successor languages Cpp2, Carbon etc. or require some other complex manual rewrite of components of said plane. There is an argument to be made for having good out-of-the-box interoperability, however even in some of the most complex and important cod…
Rust in Firefox is a very tiny portion of it and now they are using some WASM sandbox tricks, because they aren't going to rewrite everything in Rust, given the effort. Chrome only now started to consider to allow adding Rust, and it is baby steps, not coming close to V8, graphics engine and such.
My idea for C++ memory safety would be compile time reference counting. I.e. the compiler/tool to go through the code, as if it was executing, and apply reference counting to objects, revealing whether an object will be destroyed normally, prematurely or never. This is what we actually do as humans by the way, when we are developing an algorithm in C++ with manual memory management. We do it implicitly though.
Earlier quoted context omitted.
Author of slotmap here. There is absolutely no need for unsafe in slotmap. I chose to use unsafe (wrapped in a safe API) to reduce memory usage using intrusive linked freelists. If done using safe Rust this would involve `enum`s that would take up extra space.
Thus not adequate for performance requirements.