441–450 of 586 posts
Earlier quoted context omitted.
Oreo is mostly praised in the USA. Which says more about the USA than it says about Oreos.
Interesting. Why is Oreos sold in over 100 countries and apparently sold very well?
Poor correctness guarantees, especially w.r.t concurrency. Nil pointer. Why.
LLMs are like a magnifying function. Whatever you put in you get back 10x over.
In the case of Go, in goes verbosity, Nil pointers, poor concurrency and synchronisation primitives (or poor performance of the safe ones, leading to sync.Mutex everywhere anyway). Also Go prioritises local readability over global understandability which is a poor tradeoff for LLMs with limited context windows.
So the LLM generates absolutely monstrously huge amounts of very hard to review very likely incorrect code.
No thanks.
Rust > Go.
In goes powerful, terse type system. Strong correctness guarantees not just around memory and pointers but also data races. A tendency towards using the type system to model invariants instead of relying on procedural guards and runtime assertions etc. Producing denser code is an LLM feature, it increases context window efficiency. Similarily the typesystem takes something that the LLM can spend a bunch of thinking tokens on to create a powerful global constraint. This fixes the global reasoning/context problem by pushing it back onto the typesystem.
Depending on the quality of your robot you will get different quality of code out but the ceiling is much higher. With Go better robots don't help much, even the highest quality robots output insanely verbose Go. Sort of just like with people... sort of like the language was designed as a lowest common denominator tool...
For a seasoned Rust programmer the output probably won't be hard to review, it will be easy to look at the types and either say "yeah that should probably be correct" or "no robot, do better".
You simply can't actually review the output of the slop cannons with Go, there is too much, looking at a struct tells you almost nothing about how correct the thing likely is, etc. The tests don't help either because there is going to be 10x the usual amount of those too so trying to review those for correctness is the same Sisyphean endeavour.
It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
Earlier quoted context omitted.
just curious, what problems do you see with gobgp? (I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)
Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1]. [1] https://elegantnetwork.github.io/posts/comparing-open-source...
Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.
Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://goo…
If you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I know some people like but it is suboptimal in my view. While far better than C# and Java's exceptions, far worse than Zig's model.
Earlier quoted context omitted.
The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 Are you saying that this implementation is wrong? "This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Pr…
etcd is notoriously unreliable and one of the biggest problems in k8s. I didn't know Go just isn't a good language for it, but now that I know I'm no longer surprised at etcd being problematic.
Sure it may not be the best fit in a scenario where you want a cluster spanned over the entire globe (thats why GKE uses paxos-based Spanner instead of it) , but even spanned across an entire continent (in europe via glass fiber) it works quite well for me. Its one of the least problematic parts of the stack.
Earlier quoted context omitted.
Go wins for simplicity. however what I have seen is companies end up going with Java coz it's simple enough - not simple as Go, but simple enough + fast enough. though the letdown with Java is the wider ecosystem that makes unwarranted contraptions out of simple things.
Go's big advantage was M:N threads. Java's biggest flaw has been the lack of cooperative multitasking, which people worked around by mangling their code with promises. Now Java has M:N threads too thanks to Project Loom, but there's so much code written before that will never really go away.
Thus most JVM implementations had a mix of red (1:1:) and green (M:N) threads, eventually only red threads were kept in the surviving implementations.
With Project Loom now both models are officially supported and part of the specification.