Hacker News: Dr_Emann

New comment by Dr_Emann in "Bugs Rust won't catch"

Dr_Emann — Wed, 29 Apr 2026 06:20:47 +0000

To be even fair-er, it wasn't actually memory unsafety, it was "just" unsoundness, there was a type, that IF you gave it an io reader implementation that was weird, that implementation could see uninit data, or expose uninit data elsewhere, but the only readers actually used were well behaved readers.

New comment by Dr_Emann in "Upcoming Rust language features for kernel development"

Dr_Emann — Thu, 16 Oct 2025 13:44:21 +0000

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)

New comment by Dr_Emann in "DARPA project for automated translation from C to Rust (2024)"

Dr_Emann — Thu, 02 Oct 2025 01:38:55 +0000

Rust has access control. Fields are private by default.

New comment by Dr_Emann in "Speeding up C++ code with template lambdas"

Dr_Emann — Sun, 16 Mar 2025 21:40:52 +0000

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

New comment by Dr_Emann in "Asahi Linux lead developer Hector Martin resigns from Linux kernel"

Dr_Emann — Fri, 07 Feb 2025 13:36:22 +0000

"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

Show HN: One Million Sliders

Dr_Emann — Fri, 12 Jul 2024 11:42:09 +0000

Inspired by onemillioncheckboxes.com, I made my own version, where everyone shares 1 million sliders, setting one to a value sets it for everyone.

Comments URL: https://news.ycombinator.com/item?id=40944633

Points: 1

# Comments: 0

New comment by Dr_Emann in "Mojo vs. Rust: is Mojo faster than Rust?"

Dr_Emann — Thu, 15 Feb 2024 16:20:08 +0000

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.

New comment by Dr_Emann in "Mojo vs. Rust: is Mojo faster than Rust?"

Dr_Emann — Tue, 13 Feb 2024 16:40:47 +0000

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

New comment by Dr_Emann in "A byte string library for Rust"

Dr_Emann — Thu, 08 Sep 2022 12:05:10 +0000

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

New comment by Dr_Emann in "The Bourne shell lets you set variables in if expressions"

Dr_Emann — Sat, 15 May 2021 12:13:44 +0000

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

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

New comment by Dr_Emann in "Rust in the Linux Kernel (Android Security Blog)"

Dr_Emann — Thu, 15 Apr 2021 12:50:23 +0000

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

New comment by Dr_Emann in "Why asynchronous Rust doesn't work"

Dr_Emann — Wed, 10 Mar 2021 12:36:29 +0000

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(f: F, arg: T) -> Fn(...)`

New comment by Dr_Emann in "Go is not an easy language"

Dr_Emann — Tue, 23 Feb 2021 15:05:32 +0000

Yes it does exactly that. It returns an iterator over the removed items, but when that iterator is dropped, it modifies the collection. See https://play.rust-lang.org/?version=stable&mode=debug&editio...

New comment by Dr_Emann in "Go is not an easy language"

Dr_Emann — Mon, 22 Feb 2021 16:00:32 +0000

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

New comment by Dr_Emann in "Go is not an easy language"

Dr_Emann — Mon, 22 Feb 2021 15:43:31 +0000

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

New comment by Dr_Emann in "State of Rust Survey 2020 results"

Dr_Emann — Thu, 17 Dec 2020 03:47:41 +0000

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

New comment by Dr_Emann in "A Defer Mechanism for C"

Dr_Emann — Tue, 15 Dec 2020 13:48:48 +0000

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.

New comment by Dr_Emann in "A Defer Mechanism for C"

Dr_Emann — Tue, 15 Dec 2020 03:46:22 +0000

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.

New comment by Dr_Emann in "Pointers Are Complicated II, or: We need better language specs"

Dr_Emann — Mon, 14 Dec 2020 21:10:10 +0000

Because there is no UB in the original program.

It constructs a pointer to the "one past the end" element, but that is fine, and the original program never dereferences that pointer. Again: there is no UB in the original program.

New comment by Dr_Emann in "Pointers Are Complicated II, or: We need better language specs"

Dr_Emann — Mon, 14 Dec 2020 20:56:29 +0000

Your block of code can be (and absolutely is) optimized to output zero directly (in c, because the assembly is easier to read):

https://c.godbolt.org/z/qe3f4K

`*(&i+1)` dereferences the pointer "one past the end" which is UB.