Topcoat is pushing the boundary of server applications with Rust

But on the other hand, the compile time of Rust is really counterproductive. On large, established projects, most prompts I write now spend more time compiling on my machine than they spend outputting tokens. In a way this is great because the tokens are the expensive part, but it does mean that when faster LLMs will come, they will not meaningfully improve iteration speed for me.

I wonder how much of the compile time of Rust is inherent to the type system. There might be room for a language with slower runtime speed (GC?), but as good of a type system as Rust, so long as compile times are much faster. Switching languages has never been easier, anyone have any suggestions? IMO hard requirements are algebraic types and error handling based on them.

With or without AI - doesn't matter. Only at that point you gain understanding of the limitations both of LLMs and of dynamic languages.

edit: Forgot about "Nightmare" difficulty - try enjoying dynamic languages and LLMs when your legacy codebase is earning tens of thousands $ per second.

1. Humans writing code: here the usability, readability, accessibility of the language matters - strictness can be a hurdle depending on how a language is designed, so ultimately it's a trade-off.

2. Humans reviewing AI-authored code: here the requirements of (1) still apply to the code reviewer

3. Autonomous agents writing code: above requirements no longer apply so having a strictly-defined language with tight guardrails is the primary consideration.

I think most people are operating workflows in category (2), but it seems uncontroversial to say Rust is more suited to category (3) than python or golang. Typescript, Haskell, Elm, Ocaml could be considerations but you'll find Rust hard to beat here. Certainly neither python nor golang are in the running at all.

1. Python has a lot of training data

2. Go runs with the philosophy of one same way to do stuff even further than Python. It’s also typed

3. Rust’s type system and strict compiler is what helps keep AI on guardrails

I think the reason for that is, the text to me feels immediately AI generated which evokes a feeling of "the human didn't care enough to do the easiest part, which is to describe their project themselves".

Topcoat is very cool though, and there’s a few others in this space too, like Loco. So maybe we’ll see folks move to something more batteries included.

I won't get into the HTML part (I think it's obvious), but the

  $(|_e| count.increment())

pretty simply

The majority of rust's ugliness is the fact that it's handling a different problem than Java does. Java relies heavily on a GC to simplify. Rust does not.

I think the only thing that I find ugly in rust is that memory leaks are considered memory safe. [1]

That, unfortunately, means that you can't 100% rely on the language to not leak memory. Though, it's possible to leak memory in Java as well (Use `Deflate` incorrectly and you'll quickly find a hard to catch memory leak).

[1] https://brson.github.io/rust-anthology/1/memory-leaks-are-me...

You absolutely do get used to it and I really like the built in formatters. I would write everything in Rust going forward if I could, it really is a different way of thinking about how to write code. I don’t agree it’s the right tool for every job though.

- In SQLite UUIDs are default stored as compact blobs instead of inefficient varchar/text (SeaORM)

- Timestamps were easier via jiff instead of chrono (SeaORM)

- Model structs use the actual name of the $table instead of being named like $tablemodule.(Model|ActiveModel) (SeaORM) they are just $Table. This makes writing libraries a little simpler that need to use entity struct's from two separate modules/crates otherwise you get a name collision on Model/ActiveModel and need to do alias imports.

- There's an API to fetch related data to a query similar to Django ORM. IIRC this is missing from SeaORM

- The query expression language doesn't cover as much of SQL as SeaORM but seems to be enough for most web apps.

- I didn't like how the migration system works. I would skip that part of the library

I personally like Rust for web applications a lot because you can catch many bugs at compile time instead of during tests or runtime.

because a non-determinist chain of reasoning is not the same as a fully deterministic algorithm. Its the best tool when a deterministic system is not feasable.

Here is a idea, why not combine both? Have the advantage of Rust its build in checks and LLMs independent checks. Now you get both for a even more safe program.