Indeed, and then there are dozens of grieving families from folks driven mad by LLM helping murder their children.
LLM use makes people feel more productive, but provably most lose 17% of their core skills performance. Also, homework cheats improved scores at some schools, but saw 35% drop in exam scores. LLM literally makes young people dumber.
We should never kink shame adult cognitive dildo choices. As the same folks sound like a tobacco lobbyist marketing kicker. =3
That's less because of what it's implemented in - and more to do with all the tracking and libraries they want to reuse...
BigCo apps will take up lots of space and memory for BigCo reasons - obviously less if it's in Rust vs Go vs Python, but you could easily write Go apps that use far less memory than Rust apps written at BigCo due to BigCo reasons.
It's just not really that much of a priority for them to have their weather app use less than 1GB of memory. It's a far bigger priority for someone to insist that somebody else uses some bloated framework so they can get promoted.
I've been having _a lot of fun_ writing Go apps that don't allocate anything and that use small, preallocated buffers to stream through requests/etc. Basically TigerStyle for Go. I don't use arenas, I just size everything for the worst case (or make the sizes configurable at startup) and still end up using much less memory.
This is really only possible because I told Fable to build the underlying allocation-free HTTP, JSON, etc libraries and consequently I'm not building anything serious yet (although the libraries are well-tested using pre-existing corpuses from reputable projects e.g. curl as well as fuzz tested).
Most "outputs" are passed as out parameters for the function to fill in, and results are Rust-like enums (a Go tagged union containing only small data). I could also have returned (T, error) but I would have to take care that the thing I pushed into the error argument doesn't allocate--not sure if I made the right decision or not, but for now it feels nice. The worst part is that I don't really have a good way to communicate detailed error information, but that hasn't bitten me yet.
This has also been a lot less effort than writing Rust, although Rust would have real checks for lifetimes and im/mutable and enum exhaustiveness and so on--so far I haven't been bitten, and I suspect things like enum exhaustiveness can be addressed via linter if necessary.
> This has also been a lot less effort than writing Rust
I have never written such Go, but as an experienced Rust programmer I can tell you Rust is not hard to write after learning it. Learning it can take more time than usual (although there is also contrary evidence, e.g. from Google) but after you're used to it, you're basically as proficient as in other languages, except some glitches (that can be expensive - rewriting your main structure, but are fortunately rare). Considering the effort involved in coding in such unnatural Go variant, I tend to believe it is far easier to code in Rust (including coding in Rust using this style, since it is more suited to it).
Of course, if you're just vibe coding everything, maybe it is easier because maybe the LLMs write such Go better that they write Rust. But if you're not, even if you're only reviewing the code, I believe it's easier to review Rust code than to review such Go code (and potentially than reviewing any Go code, but that is a different matter).
If I was writing no-alloc production code, I would stick with Rust, FWIW, at least until Go's library ecosystem improves.
I don't mind writing Rust (have been dabbling with it since ~2014), especially with some AI assistance. It's just more of a grind for me than working with Go.
> Considering the effort involved in coding in such unnatural Go variant,
I was also expecting writing Go in this style to be more friction, but it was surprisingly smooth. The friction was entirely from lack of libraries and a little uncertainty about how to communicate errors without allocating. Rust has better libraries by far, but I felt more friction from the language (e.g., if you have a buffer you have to initialize every element of it or you have to use something like `heapless::Vec`--not a big deal, just decisions to make to figure out what the happy path is).
I was a little bit scared at first, but after 1k lines of code written by hand I started to forget that Rust was complicated. It's not the Go experience, but it's not that bad at all.
I touched OCaml several years ago and ran into a bunch of problems with build tooling, standard library, syntax noise, ideological/unhelpful community, etc that turned me off. I'm also just not experienced enough to write OCaml without a GC; that would be biting off a lot of learning.
> I think it's very clear that DeepSeek is obviously the best AI lab in the world.
It's pretty clear they're the best at what they're optimizing for - which does seem aligned with what a lot of people on HN want from models - but not everyone...
Song as old as time - people were doing this well before AI, there's just yet another reason for these types of people to categorize workers and pretend that management can be perfect and easy and that the world isn't hard.
It's almost as if it's a little bit harder than people think to figure out how good people are at their jobs and who deserves promotions, etc, and that maybe they may not have the most perfect unbiased judgements.
reply