tinco

I'm happy with ghostty now too, but until a couple months ago it didn't have search. Which made me uncertain how people use terminals without built-in search. It really surprised me that it apparently was so low on the must-haves list that it took over a year to have it. I think I search terminals multiple times a day when I'm operating production systems.

I think it's mainly the "business requirements in natural language" part that would require full AGI. In practice though, most requirements don't require that much intelligence to accomplish as illustrated by the recent success of coding agents.

It also makes sense that the language would necessitate having some algorithms as (pseudo-)code embedded in the specification when the requirement is complex enough.

Ah I haven't seen that before. I must admit that I'm not in the literature side of things. Any time I've seen a queue in production it would use put/get or enqueue/dequeue and in Ruby scripts you'd use an array and use push/shift.

Ok, but shift is the commonly used name for that operation, and pop commonly does something else than what you just described. If you could come up with a better word than shift that would be fine, but pop should be the inverse of push in my opinion. If you push, then pop, you should have the same data as you started with.

Very cool, might I suggest you rename your `pop` function to `shift` (or if you like ugly names `popleft`)? Popping windows isn't really a thing, it made me double take on the code.

So here's a crazy conspiracy theory for you: Google is not letting outside people use their models because if they did they would have to scale up their TPU production faster than they can manage, and they would instead have to buy and use nvidia hardware which would destroy their profit margins and tank their stock.

Gemini runs fully on TPU's right? Is Google maxing out the production on those?

Maybe an increase in sign ups due to people learning of their existence from the IPO? It's the authentication that seems to be failing, not the actual inference.

All the hobbyists were using proxybot because it allowed you to use more fun languages than C/C++ but proxybot lacked the features to effectively play Zerg. I really wanted to play Zerg so I built a really sweet API+DSL in Ruby around proxybot and then used that to give the other newbies a hard time with a zergling rush.

Unfortunately the proxybot limitations precluded me from expanding its capabilities so I tried to switch to having ruby embedded in C++ and I basically got mired there and was eventually distracted by real world concerns like actually finishing my degree.

I think I played against Krasi0's bot a couple times in the early days. Hopefully they stuck with AI and have suddenly become crazy rich after 2016. It certainly wasn't a given that AI was going to lead to a fruitful career back then, let alone to unimaginable riches.

It's a true power struggle. As a software engineer I have actually fallen into the trap of thinking that because of the law or a contract something would happen. It is a softer power than I expected.

The board wants to make money, that's why they hold shares and positions. If Mullenweg has the power to destroy value, that will be powerful leverage over them. If his employees side with him, if he holds the accounts, they'll have to negotiate carefully.

Of course, you would need a lawyer to determine when this crosses from a civil dispute to a criminal dispute because at some point him using the keys when he's not authorized could be a crime and if they can get the cops involved that certainly changes the dynamic.

It's not pedantry, you're trying to find something in Rust that's simply not there. If this sort of thing turns you off on Rust you should be looking at a programming language with other priorities.

Not sure if that's true, there's some frozen supermarket pizza now that's seriously good. If I ordered fast food and they delivered a freshly baked Crosta Mollica pizza I wouldn't send it back. Of course a fresh pizza is better, but imo you couldn't get a Crosta Mollica quality frozen pizza 10 years ago.

From my evaluation[1] neither Kimi K3 nor Qwen 3.8 are as good as GLM 5.2 at coding. I wonder if there's a marketing gap that's got people underestimate it.

It uses twice as much tokens to achieve the same but the results are significantly better and because it's so much cheaper it's the most economical choice too.

[1] https://blog.bosun.ai/software-maintenance-with-open-weight-...

This is really interesting. I built a similar product (not released yet), but it uses Kubernetes as the infrastructure layer instead of Cloudflare OS. I guess all these years later I am left with the same existential question that plagued Sandstorm. What is its relevance in the context of Linux containers? This is not a rhetorical question, is there a real benefit for a Sandstorm grain over a docker style Linux container? Does a containerized process not have all the same benefits of a Sandstorm grain, with the added benefit of not requiring any modifications of the containerized software?

One argument I could bring is that despite all its claims, OpenAI still had to switch from containers to MicroVMs because its agents under test still managed to break out from their containers. Is the security model of a Sandstorm grain so much better that agents wouldn't figure out how to break out of it?

When I was in university the course was called compiler construction. Making a language like G# is very simple and about the level that the final project of the course would be if the team was working together really well and went for maximum bonus points.

We have so many programming languages because it's a fun and relatively easy thing to start, and lots of people have differing opinions of how it should be done. Also making a programming language seems like a difficult thing from the outside so it has a certain allure.

Swift exists because objective c has archaic language design that modern developers reject. Objective C exists because as far as I know at the time smalltalk style object oriented programming was hip and C++ made the wrong decisions in their eyes. It could also be that C++ wasn't popular enough yet at that point for Apple to commit to it. In that period basically all major operating systems went different ways. The Unix derivatives went all in on plain C, Microsoft went C++ and Apple objective c, though I think OSX itself is plain C for the most part.

I don't know how CarPlay is, but Android Auto restricts the apps and app interactions you can do in the Android Auto user interface. On my phone the only apps that show up are google maps, spotify, and my podcast player and my phone interface I think.

They might, but the final outcome of that depends on whether the tokenmaxxing rust-using zero-user startups are using more memory in ci/cd than the users of efficiently written successful apps are using in production.

Seems like not being compatible with Sentry's agent is a missed opportunity for Appsignal, which I think is the premier EU based (Amsterdam) APM suite at the moment. It sounds like Bugsink is rather barebones in comparison and I bet a quick agentic coding session would make short work of a migration to AppSignal.

Ok so how does he know that? This whole podcast is about how we don't even know how tau clumps and amyloid build ups relate to the progression of the disease.

A transistor effectively is an AND gate. If there is a charge on both the source and the gate, then charge can move to drain. So if you charge up the capacitor and you connect it to the source of another transistor then you can check whether it is still charged by putting a charge to the gate and see if there is charge on the drain.

And you are right, that charge on the drain can then be used both to drive some logic and to activate the recharging of the capacitor that was just discharged.

By the way I am being handwavy about "charge" moving about, if you really want to learn the electronics it is more correct to call it a voltage relative to some ground that the charge always moves towards.

It might count, but it is easy with git as well, what is the feature in jj that makes this easier? Switching branches and pushing changes to remotes is the core feature of git and in my opinion really easy so I'm curious how jj improves on it.

I came into Steins;Gate completely cold. I watched it when it came out and I only just realised there's more to the universe. It's a ridiculously good anime, probably a top 10 for me. It's got a really cool storyline with loads of plot twists, interesting characters and deep mystery.

Never worked at a FAANG, but from what I read from their cultures I don't think a letter to the CEO from a senior engineer would go entirely unnoticed there. CEO's might receive crazy letters, but hopefully not regularly from their senior engineering staff..

No we can't. In the early 2000s we desperately tried to get our governments to be less dependent on Microsoft and we completely failed. Europe is not a federation like the US, worse many of the countries in Europe themselves are governed much like federations. We are easy prey for big American corporations. It's easy for Palantir to sell their product and then a thousand little government organizations will claim there simply is no alternative at the same quality level.

I know it can, but it can't download it faster than the network card can write it into its buffers. That's the part I would count as the 50ms that both can't improve upon.

> That's not how anything works. Different languages will perform differently on IO work, different runtimes will degrade under IO differently, etc. That's why even basic echo HTTP servers perform radically differently in Python vs Rust.

> This isn't how computers work and it's not even how math works.

What are you disagreeing with? There's some baseline amount of I/O that the kernel does for you, that's what I'm assuming is 50ms, and everything else like runtime degrading is overhead due to the language/platform choice. I'm saying Rust is upwards of 100x faster in that regard thanks to its zero cost abstraction philosophy. You can't just include the I/O baseline in a claim about Rust's performance advantage. You'll be really disappointed when Rust doesn't download your files 100x as fast as the Python file downloader.

Anyway, I'm sorry I provoked your antagonism with my terse messages, I wasn't trying to be blase. I believe uv is the sort of tool that wouldn't suffer much from the downsides of Python and that in most situations the reduced runtime overhead of Rust would have a negligible impact on the user experience. I'm not arguing that they shouldn't build uv in Rust. Most situations is not all situations, and when a tool is used so widely you'll hit all edge cases, from the point where the 10s of milliseconds of startup time matters to the point where Pythons I/O overhead matters at scale.

I'm saying that the Rust might execute in 50ms and the Python in 150ms. You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds.

That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Python.

Sure, within 100ms. Who cares what the performance multiples are?

It would come pretty close, probably close enough that you wouldn't be able to tell the difference on 90% of projects.