misternugget

Hey! Author of the post here. Sounds like I failed my mission with the post then :)

Yes, like many things, Orbs are "wrappers" around VMs, but the point is that some wrappers enable new ways to hold and use and reuse the thing they wrap, and even give you a different perspective on it.

That's what happened with our team once we had Orbs working. We knew beforehand all the things they're made of (fast to start sandboxes, scale to zero, live streaming updates on all clients, one machine per conversation, etc) but what really surprised us was how it changed our workflow by removing friction we didn't even know was there. The friction of creating new checkouts and worktrees and managing local resources -- it sounds trite, of course, but man, once you can stop thinking about it, it's so much better.

So, yes, maybe they're wrappers but hey, some people say the tortilla is what makes it a burrito, you know?

Engineer working on Amp here.

I'm very surprised that it took them this long to crack down on it. It's been against the terms of service from the start. When I asked them back in March last year whether individuals can use the higher rate limits that come with the Claude Code subscription in other applications, that was also a no.

Question is: what changed? New founding round coming up, end of fiscal year, planning for IPO? Do they have to cut losses?

Because the other surprise here is that apparently most people don't know the true cost of tokens and how much money Anthropic is losing with power users of Claude Code.

Hey! Thorsten Ball here. Thanks for the shout-out. I was quite confused when someone sent me this article: same "Emperor has no clothes", same "it's only x hundred lines", implements the same tools, it even uses the same ASCII colors when printing you/assistant/tool. Then I saw the "January 2025" in the title and got even more confused.

So, thanks for your comment and answering all the questions I had just now about "wait, did I wake up in a parallel universe where I didn't write the post but someone else did?"

Thank you! There's a long way to go still, but it makes me happy to hear when what we think about this, well, new way to program seems to resonate with others.

Working on it!

That is about the idea of rewriting existing tooling in Rust to get rid of node_modules folders, not about prompting users whether to download a language server or not.

One mini-feature I really like: authors highlighting their own favorite or popular articles.

I think I saw it first on Julia Evans' blog (https://jvns.ca/categories/favorite/). I also added it to mine (https://thorstenball.com/blog/) and found the exercise of going through the posts and tagging them very enjoyable.

That's right, someone linked me to this article: https://www.macobserver.com/analysis/apple-dry-run-apfs-prio...

Pretty impressive.

> I'm shocked by how many developers check in code that passes the tests but they have not actually tested to make sure it works.

That's actually one of the other topics I wanted to write about yesterday. Chose to write the article above instead.

Yes, 100%. I've seen it many times: manually testing reveals more in 1min than hours of previous discussions/reviews/test-writing.

Hey, author here. Yeah, I worked at Sourcegraph and I do think we built some high-quality stuff and we did write tests. I also think a lot of them were necessary. But, like I wrote here, I think that maybe we/I sometimes overdid it with tests and I'm not so sure about the use of /some/ of them anymore.

Rust's debug-print {:?} quotes the path here.

Hey! I'm the mentioned Thorsten. Linux is actively being developed. Here's a PR from 2 days ago that shows file-opening in Linux starting to work: https://github.com/zed-industries/zed/pull/7852

And so far Linux support has been a big community effort. I think more community member contributed to Linux support than Zed teammates. Very cool to see.

So: Linux is in the works. Windows will probably happen after that, or if someone in the community wants to emulate what the Linux users are doing and start before that.

I think that is on the roadmap too, but possibly further down.

I only joined Zed, the company, a week ago, so take this with a grain of salt, but:

I've never really used real-time sharing (tried VS Code's Live mode and other apps) for longer than just 1-2 attempts, but at Zed things are different somehow. Everybody is constantly available in a channel and people just hop in or out. In the last 7 days I spent 3-5hrs every day pairing with others, using Zed's live mode. No video, only audio and sharing code in Zed (no video was weird at first, but now I think I'm starting to get used to it?)

IMHO it's a combination of culture and technology, but when the mix of that is right it really feels game-changing.

Hey! Engineer at Zed here. Linux port is on our roadmap. Hopefully we'll get it done this year!

You know what, you're right. And it's actually something that's been bugging me for a while, I just never got around to fixing it. I'm going to update my config now. Thanks!

(Author of post)

> I've seen a lot of programmers fall into what I'd call the bureaucracy trap. Bureaucracy is often very attractive to a certain type of engineering because it's essentially programming the behavior of other humans.

That is very insightful and reading it now I wonder whether this isn’t the point I’ve been trying to make (author of post). Thank you!

Author here. Yeah, that’s fair, it is over-generalizing (and I even admit to that in the post).

I do think there might be some value (insight?) into trying to generalise things sometimes. In this case it’s me trying to split all software engineers along a single axis and seeing whether it fits. I don’t think it’s a neat split, but the more I think about it the more I think I could, if pressed, sort a lot of engineers into one of these two buckets. Not at all times, but sometimes.

Generally speaking: over-generalisation can be lazy and it was in this case — I write these posts very quickly, as a braindump, and you shouldn’t read too much into it, except that it might be food (snack?) for thought.

Monodraw is one of my favorite macOS applications. It’s really well made and - I don’t know how else to put this - lots of fun. I used it for all diagrams in compilerbook.com and now use it to create diagrams of control-flow graphs that I can then copy&paste as text comments into test cases. Highly recommend it.

Author here. Just wanted to add that I don’t think all forms of snark, sarcasm, and cynicism are bad. Or even negativity! But what I learned the hard way is that there’s a time and a place for this and often it’s not “your team & whenever something pops in your head”. I very much agree with the GP here in that I value mindfulness when it comes to negativity.

Yup, correct. I used Monodraw [0] for that (and the diagrams in the book). Highly recommend Monodraw, easily one of the loveliest pieces of Mac software I used. And it just got an update!

[0]: https://monodraw.helftone.com

Ha! I was going to comment in here that I used Monodraw for the book and really fell in love with the tool.

What I did more recently is to use Monodraw to create diagrams of CFGs and put those next to the test cases (see [0] or [1]) which exercise those graphs - the power of ASCII, you can just copy the graphs into your code.

[0]: https://twitter.com/thorstenball/status/1363053307409932288 [1]: https://twitter.com/thorstenball/status/1368802505963016197

FWIW I've ran into this too with a new 16" MBP and what largely fixed it for me (happened once in two weeks vs. every time the computer went to sleep) was to disable "Power Nap while plugged into a power adaptor" in the "Energy Saver" system preferences.

(I'm aware that this might not be applicable to your situation, since you might not even use a power adaptor when the crashes happen, just wanted to point this out in case it helps someone else)

Hey! Thorsten Ball here. I'd say: yes, they're similar, but still two different perspectives on the same subject. (I actually recounted elsewhere [0] how Bob convinced me, 4 years ago now, that it's valuable to have multiple teachers of the same subject.)

So if you're into the topic I think you can get something out of my books ([1], [2]) even if you've read Bob's book before. And if you read mine, then Bob's book will also show you something new.

I'm currently working through Bob's book myself (chapter 23) and I'm enjoying it immensely: the language, Lox, shares a lot of things with the one in my books (Monkey), like first-class functions and closures, but also has classes which Monkey does not. So now I can read Bob's book and on one hand think "Ohh, I wonder how he does _that_" and on the other hand "classes! let's see how that works."

My books also use Go exclusively and Bob's uses Java and C. I enjoyed using IntelliJ and writing Java for the first time in my life a lot and was always a fan of C, so that was also really interesting, to see how the ideas translate across three languages.

[0]: https://lobste.rs/s/43h7rz/crafting_interpreters_handbook_fo... [1]: https://interpreterbook.com [2]: https://compilerbook.com

> I have experience with a project that was based on that book, and there were (and probably, are) a lot of bugs in the parsing code, that wouldn't have been there if a parser generator was used.

I think I need to a add a big "do. not. use. in. production!" disclaimer then :) The parser we build in the book is, of course, not a battle-tested, industrial-grade parser that can survive every fuzzer you throw at it. Far from it, but that's fine, since that was never the goal. The goal was always to learn.

So, yes, I agree. If you do need a production-ready, stable parser: use a mature parser generator or, maybe, invest more time in getting good at writing parsers than it takes to read and work through the ~100 pages I wrote on the subject.

I haven't worked through it (yet!), but read parts of and only heard good things about Bob Nystrom's Crafting Interpreters [0]: http://craftinginterpreters.com/

If you like Scheme/Racket, I can also recommend Beautiful Racket [1]. That was quite a dose for my macro-loving brain.

Then I also recommend this "Let's Build A Compiler" series of blogposts [2] that roughly follows Abdulaziz Ghuloum's relatively famous (amongst fellow compiler fans) paper "An Incremental Approach to Compiler Construction" [3]. I've followed that series and paper for the past three months and built a Scheme to x86 compiler in Scheme. That was a lot of fun!

[0]: http://craftinginterpreters.com/ [1]: https://beautifulracket.com/ [2]: https://generalproblem.net/lets_build_a_compiler/01-starting... [3]: http://lambda-the-ultimate.org/node/1752

Author here. I'm going to be super shameless here and quote myself in that chapter:

> [...] we are here to learn, we want to understand how parsers work. And it’s my opinion that the best way to do that is by getting our hands dirty and writing a parser ourselves. Also, I think it’s immense fun.

In other words: use a parser generator when you need a working parser, quick. But if you want to learn how parsers work, what ASTs are, what "top-down parsing" means, etc. then I recommend you write your own. It's not that hard once the concept "clicked" and, again, it's a ton of fun :)

Shameless self-plug, but I specificities wrote interpreterbook.com and compilerbook.com because I’m also a huge fan of start from scratch and build it line-by-line tutorials and couldn’t find such a thing for interpreters/compilers that wasn’t about a toy language. You might like it too.

Author here. Yes, that's exactly right. I wanted to show how to write a parser/interpreter for something that you encounter every day. JavaScript-like syntax, with curly braces and `if`/`else` is just that.

I wrote a longer justification for this in the introduction of the second book, but the short version is exactly what you wrote: they're easier to build. Since since the goal of the book(s) is not to show how to build production-ready, industrial-grade interpreters, but rather to learn and to understand, that was a good enough reason for me.