Readit News logoReadit News
whytevuhuni commented on Squashing my dumb bugs and why I log build IDs   rachelbythebay.com/w/2025... · Posted by u/zoidb
valicord · 19 days ago
How would the compiler have caught this bug in rust?
whytevuhuni · 19 days ago
The short answer is that both values and errors are usually better scoped to only the places where they should be used.

For one, Rust's unwrapping of values is done in one step, as opposed to a "check first, unwrap second".

    if let Some(inner_value) = wrapped_value {
        // ..do something with inner_value..
    }
Or this:

    let Some(inner_value) = wrapped_value else {
        // compiler forces this branch to divert (return, break, etc)
    };

    // ..do something with inner_value..
This makes it so you can't check something and unwrap something else.

Second, for pulling out errors, you would usually use a match statement:

    match my_result {
        Ok(good_value) => {
            // use the good_value; the bad_value is not available here
        }
        Err(bad_value) => {
            // use the bad_value; the good_value is not available here
        }
    }
Or:

    let good_value = match my_result {
        Ok(good_value) => good_value,
        Err(bad_value) => { /* return an error */ },
    };

    // bad_value no longer available here
This makes it so that you can't invert the check. As in, you can't accidentally check that it's an Err value and then use it as an Ok, because its inner value won't be in scope.

You also can't use an Ok value as an Err one beyond its scope, because the scope of the error and the scope of the good value are a lot more limited by how if let and match work.

What the C++ code is doing is repeatedly calling `value.unwrap()` or `value.unwrap_err()` everywhere, pinky-promising that the check for it has been done correctly above. There's some clever checks on the C++ side to make this blow up in bad cases, but they weren't enough.

whytevuhuni commented on Python performance myths and fairy tales   lwn.net/SubscriberLink/10... · Posted by u/todsacerdoti
weinzierl · 19 days ago
"There is a reason Python and C both have a use case [..]"

If you mean historically, then yes, but I don't think there is an inherent reason why we couldn't have a language as convenient as Python and fast as C.

whytevuhuni · 19 days ago
I think there is indeed an inherent reason.

In order to get conciseness, you need to accept defaults that work for everyone. Those defaults might not be that great for you, but they're good enough.

In order to get performance, those "good enough defaults" are suddenly no longer good enough, and now you need to get very specific with what you're doing.

Maybe with a smart enough compiler, a high-level language could be compiled to something with very good performance, but the promise of that "sufficiently smart compiler" has yet to be fulfilled.

whytevuhuni commented on Typed languages are better suited for vibecoding   solmaz.io/typed-languages... · Posted by u/hosolmaz
randomifcpfan · 22 days ago
The study points out, “Python and Rust are the two most popular languages used by Advent of Code participants. This may explain why Rust fares so well.”
whytevuhuni · 22 days ago
Ah, that makes a lot more sense. Thanks!
whytevuhuni commented on Typed languages are better suited for vibecoding   solmaz.io/typed-languages... · Posted by u/hosolmaz
randomifcpfan · 23 days ago
Here’s a study that found that for small problems Gemini is almost equally good at Python and Rust. Looking at the scores of all the languages tested, it seems that the popularity of the language is the most important factor:

https://jackpal.github.io/2025/03/29/Gemini_2.5_Pro_Advent_o...

whytevuhuni · 23 days ago
But isn't it the case that Python is vastly more popular than Rust?

If Gemini is equally good at them in spite of that, doesn't that mean it'd be better at Rust than at Python if it had equal training in both?

whytevuhuni commented on This Month in Ladybird   ladybird.org/newsletter/2... · Posted by u/net01
desdenova · 24 days ago
I'm pretty good at C++.

By using a very simple technique, I've managed to write 0 bugs in it in the past 15 years.

whytevuhuni · 24 days ago
I assume that simple technique is to not write any C++, despite being pretty good at it?
whytevuhuni commented on Pony: An actor-model, capabilities-secure, high-performance programming language   ponylang.io/... · Posted by u/RossBencina
archerx · a month ago
You say that but I will never use Rust because of it's awful syntax, I'll stick with C/C++ and be happy and not miss out on anything. I don't know much about erlang so I have no comments on it.
whytevuhuni · a month ago
> I will never use Rust because of it's awful syntax, I'll stick with C/C++

Oh, that's very interesting. Rust tried to match C++'s syntax as much as possible.

Which parts do you find awful? Lifetimes and trait bounds?

whytevuhuni commented on Ask HN: What are you working on? (July 2025)    · Posted by u/david927
thomasmg · a month ago
I'm working on a new memory-safe systems programming language that is supposted to be (almost) as fast as C, Rust etc, but as simple and concise as Python: https://github.com/thomasmueller/bau-lang

There is a playground which is using a C compiler and WASM, and so is quite fast, while running fully in the browser. Theres also a (online) conversion tool to convert and compare source code. There are some benchmarks as well.

Writing my own (concise, simple) programming language was a dream for me since I'm 20 or so. Feedback would be great!

whytevuhuni · a month ago
The "Comparison" section feels unfair. Add some things that some languages have but Bau is missing. I have no idea what trade-offs I'd be doing when choosing Bau.

You have the "Non-Features" section of course, but I'm looking more into what I'd be losing by going from C to Bau. Bau's price for safety.

whytevuhuni commented on The borrowchecker is what I like the least about Rust   viralinstruction.com/post... · Posted by u/jakobnissen
Thiez · a month ago
You can also do something like:

    fn xy_mut(&mut self) -> (&mut f64, &mut f64) {
        let &mut Point { ref mut x, ref mut y } = self;
        (x,y)
    }
The fact of the matter is that doing mutable getters in Rust is a bit inconvenient at times. There are various workarounds.

whytevuhuni · a month ago
You can do that with less syntax, this works just fine:

    fn xy_mut(&mut self) -> (&mut f64, &mut f64) {
        let Point { x, y } = self;
        (x, y)
    }
Also, I assume this is just a super trivial example, because in this case I'd just make x and y public. After all, you're giving public access via these methods, and the caller can do anything it wants with them, so there's no real difference.

And if the fields are public, it's much easier to take mutable access of multiple fields separately.

whytevuhuni commented on The borrowchecker is what I like the least about Rust   viralinstruction.com/post... · Posted by u/jakobnissen
Mawr · a month ago
Your "great read" is horrible.
whytevuhuni · a month ago
From HN's guidelines:

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

I'm curious to know why you think so, I thought it was a great article, showcasing how simplicity in the language doesn't make complexity go away, it just moves it to programs written in it.

whytevuhuni commented on A Rust shaped hole   mnvr.in/rust... · Posted by u/vishnumohandas
borkido · a month ago
What would the benefit be of not associating functions that operate on a struct with said struct? You would just end up with a bunch of functions that take a struct of that type as their first argument.
whytevuhuni · a month ago
> You would just end up with a bunch of functions that take a struct of that type as their first argument.

I don't see that as a necessarily bad thing, it brings uniformity with the rest of the functions. I've coded with libraries like APR, Nginx's API, and GTK's GLib, and the result looks quite aesthetically pleasing too (subjective of course).

I'm also not considering this as a deal-breaker or anything. The point is not that this one particular feature makes a language complex, but rather that features like these tend to pile up, and what once looked like a simple language quickly becomes less simple due to dozens of such simple features added together. But one or two of these is fine.

u/whytevuhuni

KarmaCake day303September 30, 2023View Original