chrfrasco

It was Jeff Dean and Noam Shazeer: https://www.dwarkesh.com/p/jeff-dean-and-noam-shazeer

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

The limiting factor is managed isolation. You can return if there are flights from where you are currently, but you need to secure a spot in managed isolation first (2 weeks in a hotel). https://www.miq.govt.nz/travel-to-new-zealand/secure-your-pl...

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

Sum types and exhaustiveness checking are doable with typescript! Though it's not especially ergonomic

https://www.typescriptlang.org/play?#code/C4TwDgpgBAygrgWygX...

One more suggestion for you – dropbox paper (https://paper.dropbox.com/) has latex support + syntax highlighting. It's quite simple but it works well as a google docs replacement. As others have mentioned Notion is also fantastic.

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.

Hey all, as some keen-eyed commenters have pointed out, it looks like the rust program is not actually equivalent to the go program. The go program parses the string once, while the rust program parses it repeatedly inside every loop. It's quite late in Sydney as I write this so I'm not up for a fix right now, but this post is probably Fake News. The perf gains from jemalloc are real, but it's probably not the allocators fault. I've updated the post with this message as well.

The one-two combo of 1) better performance on linux & 2) jemalloc seeming to fix the issue lured me into believing that the allocator was to blame. I’m not sure what the lesson here is – perhaps more proof of Cunningham’s law? https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_L...

> 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")

run.js is not doing the benchmarking. If you look at the source for each of the programs being benchmarked, you'll see that the programs themselves are responsible for benchmarking

Nice catch, thanks for pointing this out. I've updated the cache initialization to use `len(targetChars)` rather than `len(target)`:

    cache := make([]int, len(targetChars)+1)
    for i := 0; i < len(targetChars)+1; i++ {
        cache[i] = i
    }

AFAIK this makes them equivalent (fingers crossed). It seems to not have made much of a difference (-0.03s)

Looks like we need prefers-prefers-color-scheme

Man, I wish I could use the eye-roll emoji here

> This to my mind verges on civil rights infringements

You're funny!

make sure they're rose-tinted too

  fizzbuzz = lambda n: [print((“fizz” * m % 3 == 0) + (“buzz” * m % 5 == 0) or m) for m in range(n)]

Not sure if this is great or terrible

Python doesn’t do any implicit coercion (apart from ints and floats etc), right?

I use the personal blocklist extension (https://chrome.google.com/webstore/detail/personal-blocklist...) just to block w3schools.