Dr_Emann (u/Dr_Emann)

Dr_Emann commented on Upcoming Rust language features for kernel development lwn.net/Articles/1039073/... · Posted by u/pykello

remix2000 · 2 months ago

I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.

Dr_Emann · 2 months ago

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 commented on DARPA project for automated translation from C to Rust (2024) darpa.mil/news/2024/memor... · Posted by u/alhazraed

AnimalMuppet · 2 months ago

Access control.

Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created.

You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class. The surface area where the bug can be is much smaller.

The bigger the code base and the more well-used the class is, the more this matters.

Dr_Emann · 2 months ago

Rust has access control. Fields are private by default.

Dr_Emann commented on Speeding up C++ code with template lambdas lemire.me/blog/2025/03/15... · Posted by u/ingve

Dr_Emann · 9 months ago

Wow the comments are.. Bad. Not all single instruction operations are the same.

Dr_Emann commented on Asahi Linux lead developer Hector Martin resigns from Linux kernel lkml.org/lkml/2025/2/7/9... · Posted by u/Mond_

nicce · 10 months ago

That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area.

About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.

Dr_Emann · 10 months ago

"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/

That doesn't sound like he's only talking about in his area to me

Dr_Emann commented on Mojo vs. Rust: is Mojo faster than Rust? modular.com/blog/mojo-vs-... · Posted by u/samuell

jack_clayto · 2 years ago

I did a lot more benchmarks and Rust TCO is happening in a lot of scenarios. Thanks for pointing this out, I updated this section in the blog.

Dr_Emann · 2 years ago

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 commented on Mojo vs. Rust: is Mojo faster than Rust? modular.com/blog/mojo-vs-... · Posted by u/samuell

jack_clayto · 2 years ago

Hi author here, definitely not trying to diss Rust, I love Rust! I'm pointing out some interesting overheads that aren't well known by the average Rust programmer, which Mojo was able to improve upon with the power of hindsight and being a newer thing. For your points below, let me clarify:

> There's no implicit string copying in Rust. Even when passing String ownership, it will usually be passed in registers.

The String metadata can be passed in registers if LLVM does that optimization, but it's not guaranteed and doesn't always happen. Rust move is just a memcpy, there are situations where LLVM doesn't optimize them away, resulting in Rust programs doing a lot more memcpy than people realize.

> It's idiomatic to use `&str` by default.

True if you want it to be immutable, but this actually adds to my point. That is the default behavior in Mojo without having to understand things like deref coercion and the difference between `&str` and `&String`. In Rust it's an unintuitive best practice, which everyone has to learn pretty early in their journey. In Mojo they get the best behavior by default, which gives them a more gentle learning curve, important for our Python audience. Default behavior > idiomatic things to learn.

> The borrow checker doesn't influence destructors.

I didn't claim that, my point was that Rust does do runtime checks using drop flags, to check if a value should be dropped. This can be done statically during compilation, but won't happen if the initialization state of an object is unknown at compile time: https://doc.rust-lang.org/nomicon/drop-flags.html

> &String and usize can't have a destructor, and can be forgotten at any time

In the example, the call stack is growing with a new reference and usize in each frame for each call. This is why tail recursion in Rust has so many issues, those values need to be available to the end of scope to satisfy Rust's guarantees, they can't be "forgotten at any time". It also overflows the stack a lot faster.

> Their benchmark intended to demonstrate tail call cost compiles to a constant, with no `factorial()` calls at run time. They're only benchmarking calls to black_box(1307674368000). Criterion put read_volatile in there. Mojo probably uses a zero-cost LLVM intrinsic instead.

If the Rust benchmark isn't calling `factorial()` it should be instant and faster than Mojo, the Rust version is must slower. `benchmark.keep` in Mojo is a "clobber" directive, indicating that the value could be read or written to at any time, so LLVM doesn't optimize away the function calls to get the result.

Thanks for taking the time to read the post, and write out your thoughts. Really enjoying the discussion around these topics.

Dr_Emann · 2 years ago

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 commented on A byte string library for Rust blog.burntsushi.net/bstr/... · Posted by u/ingve

rwmj · 3 years ago

Please don't design bit/byte string libraries until you understand how Erlang handles them, because that language has by far the best support. https://www.erlang.org/doc/programming_examples/bit_syntax.h...

Here's my OCaml library influenced heavily by Erlang: https://bitstring.software/examples/

Dr_Emann · 3 years ago

Honestly feels like a very, very different use case from utf8-ish strings, at a quick read?

Dr_Emann commented on The Bourne shell lets you set variables in if expressions utcc.utoronto.ca/~cks/spa... · Posted by u/justaj

twooster · 5 years ago

You should almost always be running Bash in `-e` (exit-on-error) mode. This necessitates precisely the construct mentioned in this article.

For example:

  set -e

  var="$( false )"
  if [ $? -eq 0 ] ; then
    echo Ok: "$var"
  else
    echo Not ok: $?
  fi

If you run this program, neither "Ok" or "Not ok" will be echoed, because the program will exit with an error on the `var=` line. (Not to mention the $? on the not-ok line won't work because it will be the exit code of the `[` test command in the conditional, not the exit code of the captured subshell command).

Instead the following will work:

  set -e

  if var="$( false )" ; then
    echo Ok: "$var"
  else
    echo Not ok: $?
  fi

Note that this will _not_ work:

  if ! var="$( false )"; then
    echo Not ok: $?
  fi

Your output will be "Not ok: 0". This is because negation impacts the exit code of the previous command.

Dr_Emann · 5 years ago

For simple cases, I'll do that, but for longer commands, I've taken to doing

rc=0 long command || rc = $? if (( rc == 0 ))...

Dr_Emann commented on Rust in the Linux Kernel (Android Security Blog) security.googleblog.com/2... · Posted by u/ndesaulniers

hulitu · 5 years ago

File operation in kernel (hello windows 2000- graphics). What can go wrong. Nevermind, it is android, it has other security problems.

Dr_Emann · 5 years ago

Literally every file operation HAS to go through the kernel. This is implementing "what does it mean to read/write this special device file"