Dr_Emann's comments

Dr_Emann | 4 months ago | on: Upcoming Rust language features for kernel development

Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)

Dr_Emann | 2 years ago | on: Mojo vs. Rust: is Mojo faster than Rust?

Hi, I think even the remaining benchmark isn't showing what you're trying to show:

https://rust.godbolt.org/z/r9rP6xohb

Rust realizes the vector is never used, and so never does any allocation, or recursion, it just turns into a loop to count up to 999_999_999.

And some back of the napkin math says there's no way either benchmark is actually allocating anything. Even if malloc took 1 nanosecond (it _doesn't_), 999_999_999 nanoseconds is 0.999999999 seconds.

It _is_ somewhat surprising that rust doesn't realize the loop can be completely optimized away, like it does without the unused Vec, but this benchmark still isn't showing what you're trying to show.

Dr_Emann | 2 years ago | on: Mojo vs. Rust: is Mojo faster than Rust?

Rust optimizes factorial to be iterative, not using recursion (tail or otherwise) at all, and it turns `factorial(15, 1)` into `1307674368000`: https://rust.godbolt.org/z/bGrWfYKrP. As has been pointed out a few times, you're benchmarking `criterion::black_box` vs `benchmark.keep` (try the newer `std::hint::black_box`, which is built into the compiler and should have lower overhead)

And no: in the example with `&String` and `usize`, the stack isn't growing: https://rust.godbolt.org/z/6zW6WfGE7

Dr_Emann | 5 years ago | on: Why asynchronous Rust doesn't work

I believe they're asking for "this function returns a function of the same type (Fn/FnMut/FnOnce) as its first argument, but with different arguments. A generic way to write something like `fn bind<T, F: Fn(T,...) >(f: F, arg: T) -> Fn(...)`

Dr_Emann | 5 years ago | on: Go is not an easy language

And for move to front, why not `a[..i+1].rotate_right(1);`, rather than moving to the back and then shifting everything?

Dr_Emann | 5 years ago | on: Go is not an easy language

Expand does actually exist in the standard library, but it's a bit of a strange incantation...

    vec.splice(i..i, std::iter::repeat(0).take(length));
This replaces the values in range `i..i` (an empty range starting at i) with `length` copies of `0`.

Dr_Emann | 5 years ago | on: State of Rust Survey 2020 results

_Implementing_ a variadic function in rust requires nightly. I'm guessing that's what they meant. Calling one has been available for forever.

Dr_Emann | 5 years ago | on: A Defer Mechanism for C

I would absolutely support something to replace ((((a).b).c).d).e with a->b->c->d->e, regardless of how much code had been written without that feature.

Do you not like the array subscript operator, either, since a[b] can be *(a+b)? How about a && b, you can replace that with (!!a) & (!!b), with an extra 'if' if you need the short circuiting.

Dr_Emann | 5 years ago | on: A Defer Mechanism for C

Of course. There should never be more than one way to do something in c, even if it makes things easier or less error prone. This is why the -> operator would never be included in c. You can already use (*x).y, it would be SILLY to introduce a whole operator which isn't orthogonal to all existing features of the language.
page 1