benschulz (u/benschulz)

benschulz commented on Effect Systems vs. Print Debugging: A Pragmatic Solution blog.flix.dev/blog/effect... · Posted by u/degurechaff

vlovich123 · 3 months ago

> Hence, when the compiler is run in production mode, we disable the lie that allows the implicit Debug effect. As a result, using dprintln in production mode causes a compilation error.

The team can’t seem to make up its minds of the language is intended for high performance or not. They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code (eg imagine something like a browser and you’re trying to figure out some weird behavior that’s difficult to catch in a debugger but too slow to reproduce in a debug build or even not reproducible due to different timings resulting in different race conditions)

Also blaming the users of your language for your language not being able to meet their needs isn’t a good look. It suggests the language is probably attracting the wrong users or positioning itself incorrectly in the market place.

benschulz · 3 months ago

This seems like an uncharitable reading of the post.

> They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code

I imagine they're talking about their defaults. One can commonly reconfigure how different build profiles work.

> Also blaming the users of your language for your language not being able to meet their needs isn’t a good look.

Isn't that what the whole post is about though? They even say the following.

> Returning to earth: we may be academics, but we are trying to build a real programming language. That means listening to our users and that means we have to support print debugging. The question is how?

benschulz commented on Deterministic Simulation Testing in Rust: A Theater of State Machines polarsignals.com/blog/pos... · Posted by u/lukastyrychtr

dm3 · 5 months ago

Disadvantages don't list performance hit for proxying every operation through another indirection layer. Can this sort of interface be implemented with zero overhead in Rust?

benschulz · 5 months ago

Most approaches, I assume, will leverage conditional compilation: When (deterministic simulation) testing, use the deterministic async runtime. Otherwise, use the default runtime. That means there's no (runtime) overhead at the cost of increased complexity.

I'm using DST in a personal project. My biggest issue is that significant parts of the ecosystem either require or prefer your runtime to be tokio. To deal with that, I re-implemented most of tokio's API on top of my DST runtime. Running my DST tests involves patching dependencies which can get messy.

benschulz commented on Rust’s worst feature mina86.com/2025/rusts-wor... · Posted by u/aw1621107

rendaw · a year ago

Why is it particularly more dangerous or likely than other logic errors?

benschulz · a year ago

Because the compiler optimizes based on the assumption that consecutive reads yield the same value. Reading from uninitialized memory may violate that assumption and lead to undefined behavior.

(This isn't the theoretical ivory tower kind of UB. Operating systems regularly remap a page that hasn't yet been written to.)

benschulz commented on Making Rust a Better Fit for Cheri and Other Platforms tratt.net/laurie/blog/202... · Posted by u/ltratt

davidhyde · 4 years ago

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usize often seems wasteful for indexing into small arrays and slices and casting makes the code look ugly (also dangerous because the effect of casting is checked by the developer, not the compiler). Admittedly, this would have the downside of having code that compiles on one architecture but not another so it’s probably not worth it.

benschulz · 4 years ago

IIRC integer literals are the blocking issue here. Bounds checking (and elision) happens anyway, but when `Index<T>` is implemented for multiple integer types, `foo[0]` becomes ambiguous.

benschulz commented on FreeBSD has serious problems with focus, longevity and lifecycle (2012) lists.freebsd.org/piperma... · Posted by u/rsync

rsync · 4 years ago

I wrote this in 2012 - almost exactly ten years ago - and it remains true.

Looking at freebsd.org right now I see that my options for production, release systems are 12.3 and 13.0 ...

... which means that if 12.1-RELEASE came out at the end of 2019 and 13.0-RELEASE came out in April of 2021, you had all of 16 months to make investments in the 12 branch before it was hopelessly passe and all queries regarding it would be answered with:

"That's fixed in current ..."

The 4.x nostalgia is justified: it was polished and polished and polished over many years and many organizations were incentivized to invest in that branch

benschulz · 4 years ago

> It's difficult to escape the notion that FreeBSD is becoming an operating system by, and for, FreeBSD developers.

I'm curious: Why _shouldn't_ it be an OS primarily for its developers? Why should they focus on others when they're the one building it?

benschulz commented on Rust in 2022 ncameron.org/blog/rust-in... · Posted by u/pjmlp

zaarn · 4 years ago

As someone with difficulties telling left and right apart, using Either isn't particularly straight forward. This plus the left and right variant become meaningless on their own.

Ie, if I wanted an enum of either a string or an integer, it becomes "Either<&str, i64>".

But what I wanted is that it's either a string identifier or the database Id of something to be later referenced, which might be better described as "enum IdentOrDbId { Ident(String), DbId(i64) }".

This is of course a much simplified example of things I've faced.

benschulz · 4 years ago

Sorry, based on the replies I'm getting I did not make myself clear. I only want to use Either in cases like the following.

    fn some_func() -> impl SomeTrait {
        if some_condition {
            Either::Left(a)
        } else {
            Either::Right(b)
        }
    }

Both a and b will implement SomeTrait which is all callers care about. However, because they're structurally different they must be wrapped in an Either that delegates all methods from SomeTrait to a or b respectively.

benschulz commented on Rust in 2022 ncameron.org/blog/rust-in... · Posted by u/pjmlp

the_mitsuhiko · 4 years ago

I think most people end up regretting code that users itertools::Either at the moment and use it reluctantly.

benschulz · 4 years ago

Can you expand on that? As long as the public type is opaque I don't see what there is to regret.

benschulz commented on Rust in 2022 ncameron.org/blog/rust-in... · Posted by u/pjmlp

the_mitsuhiko · 4 years ago

> My other big beef with Rust is its lack of a comprehensive stdlib, unlike Go.

I think many of us are feeling these days that the rust standard library might already be too large and it's better to be very conservative adding stuff there or only after an extended period of time of independent vetting. I have yet to not experience that standard libraries turn into very stale and outdated things relatively quickly that carries an enormous maintenance burden.

benschulz · 4 years ago

I wish there was an `Either` type in std. I realize that there used to be one and we have `Result` now. However, now that we have `impl Trait` it's worth revisiting, I believe. If we don't we'll have the one from `itertools`, the one from `futures` etc.

In most GCed languages it wouldn't matter so much because you'd return a boxed `Iterator` or `Future` or what have you. But in Rust you generally want to avoid the allocation.

benschulz commented on The Bug in Paxos Made Simple brooker.co.za/blog/2021/1... · Posted by u/mjb

ignoramous · 4 years ago

mjb (author) links to an SO post which goes:

> If you look at _Lamport's paxos proofs_ he treats an accept as a promise... But this is not pointed out in _Paxos Made Simple_. In fact, it appears Lamport took great pains to specify that an accept was not a promise.

> The problem is when you combine the weaker portions of both variants; as the OP did and several implementations do. Then you run into this catastrophic bug.

That is, Lamport's proofs and Paxos Made Simple contradict each other ever so slightly to trip everyone all at the same time:

> What's more I looked through several proprietary and open-source paxos implementations and they all had the bug submitted by the OP!

https://stackoverflow.com/questions/29880949/contradiction-i...

Lamport himself acknowledges as much: https://www.youtube.com/watch?t=4398&v=8-Bc5Lqgx_c

benschulz · 4 years ago

Lamport acknowledges the report, not the error. I'm still not convinced there even is an error.

The state after step 9 should be the same as after step 7, i.e. `A(-:-,100) B(100:b,100) C(100:b,-)` because C needs to retain the "highest-numbered proposal" it accepted, not the one it accepted last. That means the nine steps outlined in the post/on StackOverflow do not, by themselves, demonstrate any problem.

So what additional steps are missing/what alternative steps actually produce an inconsistency/divergence?

benschulz commented on The Bug in Paxos Made Simple brooker.co.za/blog/2021/1... · Posted by u/mjb

benschulz · 4 years ago

Quoting from the paper's description of Phase 1:

> (b) If an acceptor receives a prepare request with number n greater than that of any prepare request to which it has already responded, then it responds to the request with a promise not to accept any more proposals numbered less than n and with the highest-numbered proposal (if any) that it has accepted.

It says an acceptor must respond with the highest-numbered proposal (if any) that it has accepted.

How is acceptor C going to do that after step 9? That's where the bug is introduced, I think, not anywhere in the paper.