Thread

1. muglug · 1790345200 · focus · HN ↗

   > Rust is the best general-purpose language for the new world of AI-driven development.

   Funny, the Python guys say Python is the best general-purpose language for AI and the Go guys say Go is the best general-purpose language for AI etc etc

   1. Tuna-Fish · 1790346839 · focus · HN ↗

      I've found that the guardrails of a strong, expressive type system are amazing for LLMs, especially if you don't use the top-of-the-line models but stick to the cheaper options. Agents need feedback to do their magic, and the type system is great for that.

      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.

      1. tmpz22 · 1790347528 · focus · HN ↗

         Can your team read and audit Rust code as fluently as Go or Python?

         I realized all the Rust code produced meant squat if it couldnt be audited well afterwards.

         1. Tuna-Fish · 1790348155 · focus · HN ↗

            Auditing Rust is much easier and faster than either Go or Python. They both contain a lot of footguns that are not always immediately apparent from visible code. Rust is much more explicit.

            1. lucideer · 1790348713 · focus · HN ↗

               This is assuming equal familiarity with all languages but I presume this comment is more referring to talent pools & experience. A good engineer can traverse & review many languages but most are quite restricted in the scope of what they can easily read - they miss a footgun or two in python but they're not grokking any of the rust whatsoever.
      2. dabinat · 1790350178 · focus · HN ↗

         Compile times in Rust are partly the amount of analysis that occurs, partly that it uses LLVM which is optimized for creating fast code at runtime but not necessarily fast-compiling code, and partly the fact that the Rust compiler is inefficient and does the same work twice or recompiles things it doesn’t need to.

         But you can speed things up a lot by organizing your project into separate crates (which are compiled in parallel) and tweaking compiler flags. I speed up a large project by 7x this way.

         Also, if you’re using fat LTO in release builds, switch to thin. It’s almost as fast at runtime and much much faster to compile.

      3. stymaar · 1790352758 · focus · HN ↗

         > But on the other hand, the compile time of Rust is really counterproductive.

         Since it's going to be mostly cargo check and incremental builds, I don't think it matters in practice.

         1. selfhoster1312 · 1790371722 · focus · HN ↗

            Even incremental builds can be slow depending on eg. what macros you use. For example, i had bad surprises with askama which is a delight in most cases, but really makes compilation slower as you add more templates. On a project with ~20 templates, incremental build in debug mode now takes ~40s on a very fast machine.
      4. scns · 1790353799 · focus · HN ↗

         > 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.

         There is OCaml which compiles very fast in debug mode.

      5. pjmlp · 1790368537 · focus · HN ↗

         OCaml, Haskell, F#, Standard ML.

         The big difference to Rust is the availability of interpreters, REPL, which can equally load compiled code, and full blown AOT for release builds.

         Rust's problem isn't type system, rather lack of tools.

      6. jaen · 1790368974 · focus · HN ↗

         Python has a strong, expressive static type system with a very fast type checker (Pyrefly).

         1. selfhoster1312 · 1790371555 · focus · HN ↗

            I love python for some stuff, but i definitely would not say it has an expressive type system. Enums are a second-class citizen, and typed dicts are definitely not as convenient as i would like. And to my knowledge, type checkers don't support proper exception catching rules; rust also has no guarantee that a function won't panic, but usage of Result type makes it less of a problem (because panic is more or less exclusively for unrecoverable invariant violations), and there's ecosystem tools to make sure you don't ever panic.

            1. jaen · 1790412371 · focus · HN ↗

               If by enums you mean sum-type ADTs (like in Rust), then Python is certainly quite expressive - it has union types, which can represent polymorphic variants - those are slightly more expressive than pure Rust-style ADTs since you can arbitrarily subset or extend the enum cases.

                 @dataclass @final class CaseA[T]:
                    field: T
               
                 type MyEnum[T] = CaseA[T] | CaseB
               

               This also gets exhaustiveness checking in `match` statements (depending on the type checker). Overall, enums have a similar style to Scala and Java >=21 (mixing OO + ADT). I guess syntactically it can be slightly verbose depending on the exact situation... I wouldn't call them second class, but yeah, not a lot of existing libraries use this style.

               Typed dicts (with the latest PEPs) are an improvement over any other language besides TypeScript. Yes, in TS, certainly `Partial` / `Pick` / `Omit` and intersection types make modeling the web API swamp easier, and that's one place TS is superior to anything else.

               Python does have the Type Manipulation PEP 827 [1] out to give it similar powers to TS, but I feel that's unlikely to be implemented soon / as-is.

               Having an effect system for exceptions would be nice indeed. That's actually something I'm looking into (having an "allowed exceptions" annotation for functions and then checking it at test-time via failure injection and possibly in type checkers).

               [1]: <a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0827&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0827&#x2F;

Unofficial Hacker News client; not affiliated with Y Combinator.