chrfrasco

I believe Nat is referring to a full stop rather than menstruation in the sentence about crying into tiktok.

> This is how a new product gets across the chasm. Find a pragmatist in pain. Do whatever-it-takes to make them happy with your product. Then go back and do it again.

Good advice, I think the useful idea is: An excellent product in competition with a very good incumbent is a bad idea. A mediocre product in competition with an absent or terrible incumbent is a great idea

mind expanding on this? you've piqued my interest but I can't quite see the connection

> I wonder if we could reduce binary size with a dead-simple scheduler and GC

For many CLIs I think even a brain-dead bump allocator would work

This is so cool. I especially loved the Makefile, it's nice to see "bootstrapping" laid out so plainly. I remember finding the concept quite hard to wrap my head around when I was introduced to it. Seeing this would have made it a lot easier to understand!

I hope you didn't take too many of these comments to heart. You unfortunately got the standard HN comment section treatment – a delightful mix of nitpicking, assuming bad intent, and completely missing the point. I also hope you continue to share things on the internet – it's far easier to criticise than it is to create.

Yeah, I can definitely see how that would be a more performant approach.

I suppose I wasn't so interested in figuring out how to make this algorithm as fast as possible as much I was interested in diving into why this particular implementation was slower.

I'm not totally convinced that this difference is down to the string being parsed over and over, though

> doing the UTF-8 decoding up-front is exacerbating the performance difference in the allocator

This seems to suggest that allocation might be dominating here. WDYT? Either way, I've added a disclaimer to the post.

> The second problem is that at least the Rust code is decoding UTF-8 every iteration of the inner loop instead of decoding once and saving the result, or even better interning the characters and having versions of the inner loop for 32-bit chars and 8-bit and 16-bit interned indexes.

I tried this. Pulling the .chars() call out of the loop & collecting into a Vec made the performance even worse – the following balloons the runtime from ~2.7s to ~5s:

    let target_chars: Vec<char> = target.chars().collect();
    for (i, source_char) in source.chars().enumerate() {
        let mut next_dist = i + 1;

        for (j, target_char) in target_chars.iter().enumerate()  {

> written mindlessly > incompetence of the person

No challenge there :P I am operating under the assumption that I don't need to understand how compilers work to get good performance from rust (where good is "similar enough to an equivalent go program")