you implied that not being given early access could bias you in the other direction. Which in my opinion would demonstrate that you are easily biased. Which would then call into question any opinion you share about the subject.
What "cloud memory costs"? Most Rust code is an informally-specified version of the old Python reference-counting GC. That's how you're supposed to write it, with clone() everywhere, and then dropping down to optimize. You can do the same thing with Go in the other direction by writing an allocator.
People believe a lot of weird things about these languages.
Why would I roll custom allocation strategies in Go (and then be accountable for supporting them) that affect multiple teams and services when I can have an LLM port to Rust and get dozens of additional benefits?
Depends on whether you'll ever need to use a mutable shared tree structure in your project, I guess.
But do remember that the logic you're using depends on nobody on your team reading the LLM code. If you're close-reading LLM outputs, all the complexity of Rust's memory management model is back on the table.
Java’s collectors vastly outperform Go’s. Look at the Debian binary tree benchmarks [0]. Go just uses less memory because it’s AOT compiled from the start and Java’s strategy up until recently is to never return memory to the OS. Java programs are typically on servers where it’s the only application running.
I have the same feeling, and my best guess is that it's the intentional (and imo arbitrary) friction that has been sprinkled into the language. And camelCase.
Lol. Funny enough I actually like camel case because I've spent so much time in Java.
Yeah, I can see that. It's also difficult to put my finger on, but for a language that claims to be simple it seems to make a lot of things needlessly complicated. I'm also not loving how everything is deeply nested structs so I have to do struct.doThefirstThing.doTheSecondThing.doTheThirdThing().etc() all the time.
reply