HackerTrans
TopNewTrendsCommentsPastAskShowJobs

kobebrookskC3

no profile record

comments

kobebrookskC3
·27 giorni fa·discuss
china seems to be doing fine. what are you gonna do, tariff the country that makes all your stuff? 100% tariff on iphones and macbooks?
kobebrookskC3
·2 mesi fa·discuss
> Constructing an invalid pointer in rust is UB

no, it is dereferencing, not constructing, an invalid pointer, that is UB. there is even a safe function provided to construct an invalid but non-null pointer: `https://doc.rust-lang.org/stable/std/ptr/fn.dangling.html`
kobebrookskC3
·2 mesi fa·discuss
is the fact that CHERI works better with C/C++ because of C/C++'s "anything goes" attitude, or simply that any hardware design that didn't support C/C++ well was discarded?
kobebrookskC3
·3 mesi fa·discuss
> simply by adding the formal verification that proves the safety which will work automatically

"simply" and "formal verification" are usually oxymorons, never mind "automatically"
kobebrookskC3
·4 mesi fa·discuss
i was responding this claim

> It would be perfectly possible to design a variant of Rust that gets you to 80-90% of Rust's usability, with the same safety, without macros.

i then present an api that i think relies on macros to expose a safe api

> Of course macros are good for encapsulation and abstraction, but that's a different subject.

no it's not. exposing safe abstractions is pretty much rust's raison d'être
kobebrookskC3
·4 mesi fa·discuss
but without macros, how would you expose a safe interface?

  fn pin(x: T) -> Pin<&mut T> { ... }
would move the value
kobebrookskC3
·4 mesi fa·discuss
no, you just missed my point. expanding the implementation is not a safe abstraction. show me how you'd implement the functionality of the pin macro as a safe abstraction.
kobebrookskC3
·4 mesi fa·discuss
yes, but the code inside is unsafe. the pin macro is like a safe function.
kobebrookskC3
·4 mesi fa·discuss
the macro uses unsafe inside, so that's another instance of unsafe you'll need to check, whereas the pin macro is like a safe function
kobebrookskC3
·4 mesi fa·discuss
how would you implement https://doc.rust-lang.org/stable/std/pin/macro.pin.html without macros? a macro is used to shadow the original variable so that you can't move it (safely) after you pin it
kobebrookskC3
·6 mesi fa·discuss
isn't that more like optimistic concurrency control?
kobebrookskC3
·7 mesi fa·discuss
> and you dont really have the choice - every society you could choose to be in, with the exception of yourself being a dictator, will have such people

in ancient times, you could banish people from the village
kobebrookskC3
·8 mesi fa·discuss
> engineers are expected to read the data sheet

even if you know what the data sheet says, it's easier said than done, especially when the tool gives you basically no help. you are just praying people will magically just git gud.
kobebrookskC3
·8 mesi fa·discuss
in my mind it would be doing what fil-c does for c to unsafe rust: a hypothetical memory safe implementation of unsafe rust using the same methods fil-c does e.g. gc
kobebrookskC3
·8 mesi fa·discuss
what would fil-rust do that miri doesn't?
kobebrookskC3
·8 mesi fa·discuss
> With non-deterministic tests I would always wonder if it's going to fail randomly after the code is already in production.

if you didn't use property-based testing, what are the odds you would've thought of the case?
kobebrookskC3
·9 mesi fa·discuss
it seems like the clean syntax makes the type checker's life harder and so performance is unacceptable. would you rather have clean syntax or acceptable compile times?
kobebrookskC3
·9 mesi fa·discuss
そんな暇ねぇよ
kobebrookskC3
·9 mesi fa·discuss
if it was in c, who knows how many memory corruption bugs would be found before they stumbled upon this...
kobebrookskC3
·9 mesi fa·discuss
they are memory safe