331–340 of 544 posts
Earlier quoted context omitted.
I don't agree with the parent comment, but mmap is exposed (low-level) in the standard library and there's a high-level wrapper in x/exp. You need to be careful with mmap no matter where you're using it. What Go mmap CVE were you thinking of?
> What Go mmap CVE were you thinking of? Every time you see "segmentation fault", that right there is a CVE.
Meanwhile.. Java's still around. Modern, and fits the LLM paradigm quite well. It's not going to be as amazing or fast as Rust is, but close.
> as amazing or fast as Rust For cli tools, game engines, etc. certainly so. But what about monoliths? Do we have enough data to say Rust handles long-running monolith apps exposing web and other network services better than the JVM with its hot spot? I haven’t come to any stats on that matter, yet.
JVM hotspot optimization is just band-aid for something Rust does always everywhere naturally? Assuming that you use lifetimes etc properly and not going to Arc rampage.
If verbosity is a main stickler, this is coming to golang 1.28 which will cut it down drastically: https://github.com/golang/go/issues/12854#issue-110104883
var A string = "A"
type Foo struct { A string }
var a Foo
var b map[string]string
a = {A: "abc"}
b = {A: "abc"}Earlier quoted context omitted.
Exactly. 95% of programmers are application programmers - they ship software used by regular users. I think it's insane to use a non-GC language for most of those cases. Manual memory management is mentally taxing and it's easy to make catastrophic mistakes. The marginal benefit from it is just not worth it unless you're making games or a trading system. 5% who write tools or other "infra" layer for the other 95% to…
This post is specifically about backend development, where you're not shipping software to regular users.
This is a weird document that is simultaneously trying to serve as a migration guide and an advocacy document for Rust. Ultimately, if you have to ask , the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". A generation of Rust programmers has convinced itself that "managed runtime" is bad, that not having one is an important feature. But that's obviously false: there a…
> concurrency — eliminating data races essentially, which we had before. Really gnarly bugs
> this is the one teams report most enthusiastically. The classes of bugs that survive go test -race and reach production (data races, nil dereferences, missed error paths) just don’t compile in Rust. Oncall rotations are typically very boring after a Rust migration. ...
> I hadn’t had to chase down a crash, or some weird multi-threaded race condition, or some of these other things which actually consumed a huge amount of my time before.
(They say at InfluxDb)
That's not a Rust vs. Go slapfight? Instead, sounds like a good judgement to me
Earlier quoted context omitted.
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 .…
same experience. any good claude skills to ease the pain?
I could see migrating from C or C++ or Python to Rust, for various reasons, but for web back-end work Go is a good match. I write almost entirely in Rust, but the last time I had to do something web server side in Rust, I now wish I'd used Go. The OP points out the wordyness of Go's error syntax. That's a good point. Rust started with the same problem, and added the "?" syntax, which just does a return with an error…
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…
Earlier quoted context omitted.
I do think that AI models should get better at logic. But if code generators are supposed to be tools, we have to tell them what to do. I'm not sure what combination of languages is best for that purpose.
It would be so much easier if we could precisely specify what we wanted, without all the double meanings, slang and general ambiguity that comes from using a natural language. If only there was an entire class of well-studied languages which don't have any such ambiguity. They'd be perfect for programming LLMs! We could call them "programming languages" perhaps.