281–290 of 544 posts
"services that your organization relies on, that have high uptime requirements, that are critical to your business" Kind of funny when your Rust service runs on Kubernetes.
Even if you believe language X to be the bees knees, are you going to stop using it until everything below it in the computing stack has been rewritten in X? Of course not.
Earlier quoted context omitted.
The benefit is if you lean heavily on types then successful compilation is a massive indicator in the feedback loop. Using stop hooks to ensure successful compilation after every iteration is a game changer. Go also has compilation of course but because the type system is so much more robust in Rust the compilation guarantees so much more about the behaviour of your program. You end up just code reviewing the shape a…
Code compiling is really the lowest bar of code validation, and doesn't say much of anything of the code running correctly. AI will pump out the most convoluted, over engineered, and at the same time sloppy code if you let it - and it will all compile fine.
Earlier quoted context omitted.
For me the bottleneck now is reading/reviewing code, not writing code. As you said, AI makes it way easier to write, but do you not review the code? And isn't a verbose, cryptic language with lots of nitty gritty memory management not harder to read/review? I'm not sold on Rust being a great language to use with AI unless the reason to use it is a lot more than just Rust being fashionable.
It's the same logic for human and for AI code: In Rust the compiler catches many bugs so you don't have to. If the LLM gives you safe code you know there are entire classes of things you don't have to review for. That said, I agree with you. My experience is that LLMs are great if you are highly competent in the domain in which you let them work. And it's probably easier to be competent in Go than in Rust.
Go has shorter and more predictable GC pauses. If a reference count drops to zero in Rust, it may take an unbounded time to free all the things it refers to (recursively if necessary).
I still prefer having deterministic control over when the free occurs. For example, I can transmit the response to the client and then free the memory afterwards so they're not kept waiting.
Earlier quoted context omitted.
Conversely, the Go community tends to actively shun frameworks, especially anything Rails-like, and will tell you to just use the standard library. Which is good advice, the standard library really does have everything you need . But it's also roughly on a par with what's available in Rust (though as someone said above, the Go stdlib routines have been heavily, massively, tested in production by now, and are fully ma…
Interesting! Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? Or each person and org has their own toolkit they use?
Earlier quoted context omitted.
Maybe I'm misunderstanding something but non-GC language doesn't mean you have to do memory management manually? I mean, for example, in Rust (or modern C++), it's basically automatic. There is no mental tax or catastrophic mistakes as far as I know.
Ok. https://rust-unofficial.github.io/too-many-lists/ I'm not saying Rust is worse than Go. It obviously isn't. But this argument that Rust's memory management isn't more cognitively demanding than Go's memory management --- that isn't true.
So the linked list is a thing Go doesn't have at all, in Go the equivalent document probably just reminds you of Go's rule "Don't be clever". Thanks Go, I'll keep it in mind.
Generally the argument is that non-GC languages require you to worry about memory management because of Use-after-free, but of course safe Rust just won't compile if you wrote a typical use-after-free so that's not really extra cognitive demand.
Earlier quoted context omitted.
I love Go and used to write it heavily for anything non LLM based. Now that we have agentic coding I just write everything in Rust and couldn’t be happier. The struggle with rust was writing it, go was made so it was easy to write for mid level engineers. Now that we have agentic coding I’m not sure Go’s value prop holds up anymore My rust services have been nothing short of amazing from a performance and reliability…
In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust. They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .…
Earlier quoted context omitted.
For me the bottleneck now is reading/reviewing code, not writing code. As you said, AI makes it way easier to write, but do you not review the code? And isn't a verbose, cryptic language with lots of nitty gritty memory management not harder to read/review? I'm not sold on Rust being a great language to use with AI unless the reason to use it is a lot more than just Rust being fashionable.
In my experience, Rust is only mildly unpleasant to review, if only because the GitHub PR review interface is not an IDE. It can be hard to tell why .as_ref()s and whatnot had to be used without being able to hover over a variable to see its type. This is probably because of the language's preference for type inference, though personally I would rather that than having to skim over explicit types. Compared to Rust, G…
Absolutely insane syntax choice in a language where everything returns 2 values. At least do var:, err: =