211–220 of 310 posts
I love the expressivity of Rust, but compile times are a problem.
Someone with some sway, please convince a hyper-scalar to support something like https://borgo-lang.github.io/. I think it may be the AST that we all need.
I love the simplicity & practicality of Go, but can't get over the limited type-system. I love the expressivity of Rust, but compile times are a problem. Someone with some sway, please convince a hyper-scalar to support something like https://borgo-lang.github.io/ . I think it may be the AST that we all need.
Have yet to find a better choice than OCaml: - Strongly typed, including GADTs and various flavors of polymorphism, but not as inscrutable as Haskell - (Mostly) pure functions, but multiple imperative/OO escape hatches - The base language is surprisingly simple - Very fast to build/test (the bytecode target, at least) - Can target WASM/JS - All code in a file is always evaluated in order, which means it has to be def…
Earlier quoted context omitted.
You can add a callback to e.g. Claude to guarantee it does a cargo check and test.
Fwiw i used to do this (and with lints) - it was the only way to make Claude consistent in the early days when i first started using it (~August 2025). For many months now though, Claude is nearly consistent with both calling test and check/clippy. Perhaps this is due to my global memory file, not sure to be honest. What i do know, is that i never use those hooks, i have them disabled atm. Why? Because the benefit is…
Maybe for your case you could create a /maybe-check command, and run that in the hook? Then specify the conditions under which a check/test is needed in there.
Earlier quoted context omitted.
Unit tests in the same file wastes context and makes the whole thing hard to navigate for humans and machines alike.
I’ve been doing the least amount of unit tests possible and doing debug asserts instead.
Earlier quoted context omitted.
Rust is unstable and slow to compile. I think these two features make it bad for LLMs and everything else.
Why do you say it's unstable?
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it. Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns. The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams…
Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.
Java is a fine language, tech stack, and ecosystem, but I agree with the author and parent commenter that this is a sweet spot for Go. Their decision to use it makes a lot of sense.
Earlier quoted context omitted.
Unit tests in the same file wastes context and makes the whole thing hard to navigate for humans and machines alike.
It’s about the best possible documentation.
Earlier quoted context omitted.
Sure, things like counting the ‘r’s in strawberry, for example (till they are retrained not to make that mistake).
There are humans that can't do that but are clearly capable of reasoning. Not a meaningful categorical split.
Earlier quoted context omitted.
I've never actually seen it get a compiler issue arising from lifetimes, so it seems to one-shot that stuff just fine. Although my work is typically middle of the road, non-HFT trading applications, not super low-level.
That matches with actual Rust use actually, I've worked with Rust since 2017 on multiple projects and the number of times I've used the lifetime annotation has been very limited. It's actually rare to have to borrow something and keep the borrow in another object (is where lifetime happens), most (95% at least I'd say) of the time you borrow something and then drop the borrow, or move the thing.