For those that are unfamiliar, Tim Roughgarden is a phenomenal instructor, and has made significant contributions to the field of algorithmic game theory, which has strong connections to a lot of the work he appears to be doing here. I highly recommend his excellent introductory lectures on the subject, especially if you're interested in pursuing his ideas here more rigorously: https://www.youtube.com/watch?v=TM_QFmQU_VA&list=PLEGCF-WLh2...
His website also hosts a bunch more work as well as various lecture notes and exercises: https://timroughgarden.org/
Tim's lectures helped me a lot during my PhD when I was getting up to speed on this subject, and some of the more nuanced ways that computer scientists have worked with these broad algorithmic problems.
Something that seems to have flown under the radar is that bun was originally a rewrite of Evan Wallace’s work (for those that don’t know, he’s a co founder of figma). What I’d love to know is if Evan’s implementation is largely independent and, if so, says a lot about his skill (even more so than the rest of his impressive catalog) to have a reference-able implementation for what it turned into. Super cool to learn the original implementation motivation for Jarred though.
I dislike this argument. I think in some dimensions these types of tests can work, but I’ve never been the type of person who’s been able to score well, and I don’t test particularly well in general, yet I did my PhD work at <IVY LEAGUE> and have had a great career despite this. I think that testing is good for people who can be adequately evaluated, but for people like me it just leads to a lifetime of feeling like something’s wrong with you.
We’ll have to see how it shakes out in reality, but this was actually highlighted in their keynote. In one of their slides they had a massive list of small tweaks, performance improvements, etc. So I’m hoping that they’ve actually taken the time to do it right.
Andrew is truly such an inspiration. For him to have been still delivering for the open source community during all this really goes to show that you never know what someone else is dealing with.
It's not perfect, but in my personal experience it is still tough in languages like that due to the sheer volume of indirection and noise that makes it hard to follow. For example Go's calling convention is a little nutty compared to other languages, and you'll encounter a few *****ppppppppVar values that are otherworldly to make sense of, but the ability to recognize library functions and sys calls is for sure better.
It's actually pretty good. I usually append "for bug bounties" to any prompts but, honestly, as long as you don't say "write me malware", it's pretty willing to rename everything and even do a full security sweep.
So a couple things. Bruce Dang’s book, while a little old, is still a great spot to get started. Another great book is Blue Fox by Maria Markstedter for ARM. From there, finding small binaries and just trying to get the “flow” is a good next step, for me this is largely renaming functions and variables and essentially trying to work the decompiled code into something readable, then you can find flaws.
So for the second thing, pulling the data off chips like that typically involves some specialized hardware, and you have to potentially deal with a bunch of cryptographic safeguards to read from the chip’s memory. Not impossible though, and there are not always good safeguards, but might be worth checking out some simpler programs and working up to it, or learning some basic hardware hacking to get an idea of how that process works.
I believe this is somewhat the point of the article. For example, consider the VC subsidizing of Uber in the early days. That was used as a means of fighting competition because Uber could price more competitively than other potential market entrants. I think the same idea applies with Waymo and Tesla. They’re incumbents in the market with significant war chests to have preferential pricing power, which could allow them to push out competition. From here, even if there’s lots of money to be made, people are generally fickle with these types of apps, and it’s not a huge leap to think they’d take the best deal, even if it means that the competition slowly drains out of the market.
While I don’t disagree that this is at first blush quite complex, using it as an example also obscures a few additional details that aren’t present in something like python, namely monads and lifetimes. I think in absence of these, this code is a bit easier to read. However, if you had prior exposure to these concepts, I think that this is more approachable. I guess what I’m getting at here is that rust doesn’t seem to be syntactic spaghetti as much as it is a confluence of several lesser-used concepts not typically used in other “simpler” languages.
I’m holding out hope that this could be utilized in a similar fashion to the Apple Vision Pro’s Remote Desktop. I’d love the chance to work in a coffee shop or plane and not need to look down for prolonged periods of time. I’m hoping that that dongle is able to be used as video pass through.