SatvikBeri

It's trivial to try another agent. You can spend $20 for a monthly subscription and ask it to import all your settings from Claude Code.

I use Julia! I like it a lot, and add type parameters to all application code. But JET.jl does not feel anywhere close to the assurances I can get from a statically typed language (yet)

What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.

Every interview method has some glaring flaws, and I find you mostly have a choice of which flaws you pick.

On my current team, I care a lot about the ability to write fast code. The most important part of my process is a take-home designed to take 2 hours where the main goal is to solve a relatively easy problem as performantly as possible. Answers have varied from 0.2ms – 50ms.

Take-homes have some obvious disadvantages, but overall I find they're better at finding the people we're looking for than just about every other method. But I'm at a small company, hiring for a fairly specialized team. If the situation was different (e.g. I needed to hire 50 people/year) I'd use a much more standard process.

I'm a fairly moderate user, never hit any kind of usage limits, but I used 44 million cache create tokens and 1.5 billion cache read tokens, which ccusage estimates would have cost $990, and calculates the different categories separately.

Not OP, but Dario said on Dwarkesh's podcast 3 months ago that their gross margins are "significantly higher than 50%"

Run rate is annualized revenue based on some recent period, e.g. taking the last month of revenue and multiplying by 12. Revenue (classic) is a historical measure, e.g. revenue in 2025.

Julia does this – you generally write synchronous, single-threaded functions most of the time, and can use code like `t = @spawn foo(b)` to get a Task, and then `output = fetch(t)` to wait for it and get the value.

I like this general approach a lot, it's overall quite nice for Julia's core use case of number crunching, it means you typically make decisions around concurrency at the call sites. Though it does rely heavily on Julia's runtime, and it can be a bit difficult to figure out what's going on under the hood.

I usually aim to have Claude end up with about 500 lines of code after a night of work. Most of what it's doing is experimenting with many different approaches, summarizing them, and then giving me a relatively small diff to review and modify.

The context window has nothing to do with RAM usage and even if it did, a million tokens of context is maybe 5mb.

9-5 Pacific Time

Yes, I've pretty much used Opus exclusively for the last year, except for a brief period when Sonnet was ahead

I've never actually run into the issues that people talk about online, like Claude suddenly getting dumb or running out of usage. So there's just not a lot of incentive for me to shop around. I've used Amp a bit, and it's quite nice, but a bit more expensive without the subsidized subscription.

Re: REPL use, you just use it to run code and look at results. e.g. for TDD – you can modify your code files normally in the IDE, changes get picked up by revise, and then you re-run the tests in the REPL.

For long-running jobs, I basically follow the same process as in any other language: make the functions I want to run, test them locally on a small dataset that runs relatively quickly, then launch them on the remote machines with the full data.

Revise.jl has struct redefinition now, but before that I would just use NamedTuples while iterating, then make a struct when I was ready to move something to production.

`using` is for importing modules, `include` is for specific files. At work, we currently have a monorepo, with one top-level OurProject.jl file that uses `using` to import external packages, and `include` for all the internal files.

It's definitely closer to matlab than python, but it's closer to python than most mainstream programming languages. I ported ~20k lines of python code to Julia over a couple years manually, and for the most part could do line-by-line translations that worked (but weren't necessarily performant until I profiled and switched to using Julia idioms.)

Well, my workflow uses Revise.jl. I develop either in Jupyter notebooks or in the REPL, prototyping code there and then moving functions to files when they're ready. In that context, rapid iteration is fairly fast.

Nowadays I often use Claude Code, working with a Julia REPL in a tmux or zellij session via send-keys. I'll have it prototype and try to optimize an algorithm there, then create a notebook to "present its results", then I'll take the bits I like and add them to the production codebase.

Yes, with unlimited development time I would expect C++ solutions to be as fast or faster. But Julia hits a really nice combination of development speed and performance that I haven't found in other languages, at least for number crunching and data pipelines.

This is 7 years old. Julia is a totally different language by now.

As a quick anecdote, in our take-home interview exercise, we usually receive answers in C++ or Julia, and the two fastest answers have been in Julia.

I actually do this, but that's mostly because our team reviewed all the existing autoformatters for the relatively obscure language we use, and either really hated the formatting or found that they actually introduced errors!

jj has almost 30,000 stars on github. You might not be looking for a different git ux, but plenty of people are!

Yes, but a patient who googled his real name would not find his blog. That was the point.

Are you aware that you can use tmux (or zellij, etc.), spin up the interpreter in a tmux session, and then the LLM can interact with it perfectly normally by using send-keys? And that this works quite well, because LLMs are trained on it? You just need to tell the LLM "I have ipython open in a tmux session named pythonrepl"

This is exactly how I do most of my data analysis work in Julia.

It's totally compatible though, and that's a big selling point. I use jj and nobody else at my work uses it and that has never been an issue.

I use a REPL in tmux. That lets Claude code read/write to it easily, as well as letting me take manual control to investigate.

One person's bug is another's feature.

I think my toddler saw roughly 100 dogs and cats before she was able to reliably tell the difference.

I've had the pleasure of working with some truly fast pieces of code written by experts. It's always both. You have to have a good sense of what's generally fast and what's not in order to design a system that doesn't contain intractable bottlenecks. And once you have a good design you can profile and optimize the remaining constraints.

But e.g. if you want to do fast math, you really need to design your pipeline around cache efficiency from the beginning – it's very hard to retrofit. Whereas reducing memory allocations in order to make parallel algorithms faster is something you can usually do after profiling.

Was 3 years a long time for an indie platformer in the early 2000s? Looking at some similar examples:

* Braid was 3 years

* Cave Story was 5 years

* World of Goo was 2 years

* Limbo was about 3 years (but with 8-16 people)

So Braid seems pretty average.

Per a different article, he pled guilty to the contempt charge: https://apnews.com/article/tommy-thompson-gold-coins-shipwre...

They charged him with contempt of court, which is a crime, after 3 years where he'd been avoiding demands to appear in court.